What is an Agile Method n Agile proponents

What is an Agile Method? n Agile proponents believe ¨ Current software development processes are too heavyweight or cumbersome n Too many things are done that are not directly related to software product being produced ¨ Current software development is too rigid n Difficulty with incomplete or changing requirements n Short development cycles (Internet applications) ¨ More active customer involvement n CMM focuses on process needed

What is an Agile Method? n Agile methods are considered Lightweight ¨ People-based rather than Plan-based ¨ n Several agile methods No single agile method ¨ XP most popular ¨ n n No single definition Agile Manifesto closest to a definition Set of principles ¨ Developed by Agile Alliance ¨

Agile Manifesto 1. Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software 2. Welcome changing requirements, even late in development. Agile process harness change for the customer´s competitive advantage 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Agile Manifesto 4. Business people and developers must work together daily throughout the project 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Agile Manifesto 7. Working software is the primary measure of progress 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely 9. Continuous attention to technical excellence and good design enhances agility

Agile Manifesto 10. Simplicity – the art of maximizing the amount of work not done – is essential 11. The best architectures, requirements, and designs emerge from self-organizing teams 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Agile Methods n n n n Extreme Programming (XP) Scrum Crystal Family Feature Driven Development Adaptive Software Development Open Source Software Development Pragmatic Programming Lean

I: What Is Extreme Programming? Deliberate and disciplined approach to software development. n Stresses customer satisfaction. n ¨ Deliver when needed. ¨ Respond to changing requirements.

II: What Is Extreme Programming? Emphasises team work. n Improves in Four essential dimensions: n ¨ Communication. ¨ Simplicity. ¨ Feedback. ¨ Courage.

A Change in the Way We Program n n Keep things simple and elegant. Emphasises testing. ¨ Automated tests. ¨ Create tests before, when and after coding. ¨ When bugs are found, new tests are added. n Embrace change. ¨ Early feedback. ¨ Acknowledges that requirements can/will change. n Constant integration.

Do We Need Yet Another Methodology? XP - Based on observations of what improves/reduces the speed of programming. n Re-examination of software development practices. n Lightweight/Agile software methodology. n ¨ Reduce cost of software. ¨ Simple and enjoyable.

What Is an Agile/lightweight Methodology? n Software Methodology: ¨ Set n of rules and practices. Heavyweight. ¨ many n rules, practices and documents. Lightweight. ¨ few rules and practices or some that are easy to follow.

Agile Software Manifesto n XP, Scrum, DSDM, ASD, Crystal, Feature-driven Development, Pragmatic Programming: ¨ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: n n Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following up a plan. ¨ That is, while there is value in the items on the right, we value the items on the left more.

User Stories n Same purpose as use cases. Used to create time estimates for release planning. ¨ Replaces large requirements documents. ¨ n n n Written by customers. Drives the creation of acceptance tests. Developers create estimates in “ideal development time”. A set of selected user stories form a release plan. Focused on user needs.

User Story Examples Story: Handle overdraft When a transaction causes a customer’s account to go into overdraft, transfer money from the overdraft protection account, if any. Story: Compute balance For each account, compute the balance by adding up all the deposits, and subtracting all the deductions.

Architectural Spike n Spike solutions: ¨ Figure answers to tough technical or design problems. ¨ Reduce the risk of a technical problem. ¨ Increase the reliability of estimate for a user story. n n Simple program to explore potential solutions. Address only one problem at a time.

Choose a System Metaphor Establish a common vocabulary for the system. n Consistent naming of classes and methods. n Names should be easy to learn and relate to. n

Examples: System Metaphor n n n Naïve Assembly line Shared blackboard Subcontractors Workflow n Editors: ¨ Card (Punched card imitation) ¨ Array of lines (vi) ¨ String (Emacs) ¨ Sequence of runs (Word) ¨ Tree (XML) ¨ Combinations

I: Release Planning Meeting n n n Establish a release plan. The release plan is used to create iteration plans for each individual iteration. Has a set of rules to balance technical and business decisions/forces to negotiate a schedule.

II: Release Planning Meeting n n n The release plan is based on developer estimates of a set of user stories and customer priorities (time/scope). Customer decides priorities of user stories. Most important first. User stories are selected for an iteration based on either time or scope. Early deliverable with business value is desired.

Release Plan n Contains: ¨ user stories to be implemented for each system release. ¨ dates for those releases.

Release Planning Split a Story (Customer) Sort Stories by Value (Customer) “Too big” Write a Story (Customer) Estimate a Story (Programmer) Declare Velocity (Programmer) “Don’t know how” Choose Scope (Customer) Spike a Story (Programmer) Exploration Planning

The 12 Practices of XP 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Metaphor Release Planning Testing Pair Programming Refactoring Simple Design Collective Code Ownership Continuous Integration On-site Customer Small Releases 40 -Hour Work Week Coding Standards

1. Metaphor Ø The closest XP comes to architecture Ø Gives the team a consistent picture of describing the system, where new parts fit, etc. Ø Words used to identify technical entities should be chosen from the metaphor Ø C 3 payroll. . . The paycheck goes down the assembly line and pieces of information are added. Ø Sometimes, you just can’t come up with one

2. Release Planning Ø Requirements via User Stories Ø Short (index-card length) natural language description of what a customer wants Ø Prioritized by customer Ø Resource and risk estimated by developers Ø Via “The Planning Game” Ø Highest priority, highest risk user stories included in early “time boxed” increments Ø Play the Planning Game after each increment

3. Testing Ø Test-Driven Development (TDD) Ø Write tests before code Ø Tests are automated Ø Often use x. Unit framework Ø Must Ø run at 100% before proceeding Acceptance Tests Ø Written Ø Acts with the customer as “contract” Ø Measure of progress

Usual Programming Style

XP Programming Style

4. Pair Programming Pair-programming has been popularized by the e. Xtreme Programming (XP) methodology With pair-programming: • Two software engineers work on one task at one computer • One engineer, the driver, has control of the keyboard and mouse and creates the implementation • The other engineer, the navigator, watches the driver’s implementation to identify defects and participates in on-demand brainstorming • The roles of driver and observer are periodically rotated between the two software engineers

Research Findings to Date Ø Strong anecdotal evidence from industry Ø Ø “We can produce near defect-free code in less than half the time. ” Empirical Study Ø Pairs produced higher quality code Ø Ø Pairs completed their tasks in about half the time Ø Ø 58% of elapsed time (difference not statistically significant) Most programmers reluctantly embark on pair programming Ø Ø Ø 15% less defects (difference statistically significant) Pairs enjoy their work more (92%) Pairs feel more confident in their work products (96%) India Technology Company 24% increase in productivity (KLOC/Person-Month) Ø 10 -fold reduction in defects Ø

5. Refactoring Ø Improve the design of existing code without changing functionality Ø Simplify code Ø Opportunity Ø Remove Ø for abstraction duplicate code Relies on testing to ensure nothing breaks in the process of refactoring.

6. Simple Design Ø Ø No Big Design Up Front (BDUF) “Do The Simplest Thing That Could Possibly Work” Ø Including documentation Ø “You Aren’t Gonna Need It” (YAGNI) Ø CRC cards (optional)

7. Collective Code Ownership Ø Code to belongs to the project, not to an individual engineer Ø Any engineer has the power to modify any code Ø Cleaner code Ø Engineers are not required to work around deficiencies in objects they do not own Ø Faster progress Ø No need to wait for someone else to fix something

8. Continuous Integration Ø Pair writes up unit test cases and code for a task (part of a user story) Ø Pair unit tests code to 100% Ø Pair integrates Ø Pair runs ALL unit test cases to 100% Ø Pair moves on to next task with clean slate and clear mind Ø Should happen once or twice a day.

9. On-Site Customer Ø Customer available on site to clarify stories and to make critical business decisions. Ø Developers don’t make assumptions Ø Developers don’t have to wait for decisions Ø Face to face communication minimizes the chances of misunderstanding

10. Small Releases Ø Timeboxed Ø As small as possible, but still delivering business value Ø No Ø Get releases to ‘implement the database’ customer feedback early and often Ø Do the planning game after each iteration Ø Do they want something different? Ø Have their priorities changed?

11. 40 -Hour Work Week Ø Kent Beck says, “. . . fresh and eager every morning, and tired and satisfied every night” Ø Burning the midnight oil kills performance Ø Tired developers make more mistakes, which slows you down more in the long run Ø If you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences

12. Coding Ø Use Coding Conventions Ø Considering Pair Programming, Refactor Mercilessly, and Collective Code Ownership. . . need to easily find your way around (other people’s) code Ø Method Commenting Ø Priority placed on intention-revealing code Ø If your code needs a comment to explain it, rewrite it. Ø If you can't explain your code with a comment, rewrite it.

The 13 th Practice? The Stand Up Meeting Ø Start day with 15 -minute meeting ØEveryone stands up (so the meeting stays short) in circle ØGoing around the room everyone says specifically: What they did the day before Ø What they plan to do today Ø Any obstacles they are experiencing Ø ØCan be the way pairs are formed

Trivia Quiz n Take out a paper and pencil and write at least five practices of Extreme Programming (XP)?

I: How Do I Start XP? n New project. ¨ Collect user stories. ¨ Conduct spike solutions. ¨ Release planning meeting. ¨ Iterative development (iteration planning meeting).

II: How Do I Start XP? n Already running project. ¨ Collect user stories if trouble with requirements. ¨ Iterative and just in time planning of tasks if changing requirements. ¨ Automated functional tests if many bugs in production, to be used in regression and validation testing. ¨ Automated unit tests if trouble with integration. ¨ Refactoring, test-first programming (on your own).

Extreme Programming in a Nutshell n Planning. n Designing. ¨ User stories are written. ¨ Simplicity. ¨ Release planning creates the schedule. ¨ Choose a system metaphor. ¨ Use CRC cards for design sessions. ¨ Create spike solutions to reduce risk. ¨ Make frequent small releases. ¨ The Project Velocity is measured. ¨ The project is divided into iterations. ¨ Iteration planning starts each iteration. ¨ No functionality is added early. ¨ Move people around. ¨ ¨ A stand-up meeting starts each day. Refactor whenever and wherever possible. ¨ Fix XP when it breaks.

Choose XP When … n n …you have loosely-defined or volatile requirements …you have or can develop strong engineering skills and practices …customers can be involved on a daily (hourly) basis …it’s important you hit the bulls eye right off and you think you can

Summary Ø There are 12 practices of XP; some of these are very inter-related and dependent on each other. Ø The focus is on getting value to the customer as quickly as possible and on embracing to change throughout the development cycle.

Scrum n n Another process that follows agile manifesto. Phases ¨ Pregame Planning - define system. Product Backlog n Architecture - high level design of system n ¨ Development n Iterative cycles (sprints) - new or enhanced functionality ¨ Postgame n Requirements satisfied - no new items or issues

Scrum

Scrum n Roles and Responsibilities Scrum Master - project following rules and practices Product owner -officially responsible for project Scrum Team - project team. Free to organize as they see fit to achieve goals of each sprint Customer - participates in Backlog items Management - Makes final decisions

Scrum n Practices ¨ Product Backlog -Current prioritized list of work to be done ¨ Effort Estimation - iterative on Backlog items ¨ Sprint - n day iteration ¨ Sprint Planning Meeting - decide goals for next spring and how team will implement ¨ Sprint Backlog -Product Backlog items for sprint ¨ Daily Scrum meeting - what doing, what will do, and any problems ¨ Sprint Review Meeting -present results of sprint

Product Backlog List of requirements n Each requirement has a n ¨ Id and name ¨ Importance ¨ Effort Estimate ¨ How to demo a requirement?

Product Backlog (Example)

How a Sprint begins? n A sprint planning meeting is carried out. ¨A set of requirements are selected. ¨ A goal is chosen. ¨ A duration is decided. ¨ A team is selected.

Sprint A sprint is started by keeping a prioritized sprint backlog items. n These items are checked out by teams member(s) and work is started. n A sprint master keep track of the sprint’s overall progress. n

Sprint Backlog

Sprint Backlog (after Day 1)

Sprint Backlog (after a few days)

Sprint Team Room

Sprint Team Room

Every Day During the Sprint begins with a small meeting in the team room. n A short meeting to discuss: n ¨ What each member did yesterday? ¨ What each member is going to do today? ¨ What are problems faced? ¨ How far is the team from sprint goal?

At the end of the Sprint The sprint backlog must be finished. n An executable product MUST be ready. n ¨ Why this is important? A demo is presented to the product owner. n Release planning is performed. n

Sprint Review Meeting (Retrospective) At the end of each sprint. n Discusses lessons learned in the sprint. n Spread lessons learned to other teams. n Discusses problems occurred during the sprint. n

Choose Scrum When… n n n …requirements are changing or emergent …you’re willing to let the team self-organize …you need a management framework more than a set of engineering practices …you want to better manage risk …you need a proven, scalable agile process

Trivia Quiz: XP and Scrum What are the major differences between XP and Scrum? n Can we combine XP and Scrum? n

What Software Process should a company follow? A lot depends on the company’s vision. n Other factors include n ¨ Expertise of the employees ¨ Nature of project ¨ Software Complexity ¨ Cost issues ¨ Cultural and religious issues

Dimensions of Software Complexity Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance An average software project: - 5 -10 people - 10 -15 month duration - 3 -5 external interfaces - Some unknowns & risks Lower management complexity - Small scale - Informal - Single stakeholder - “Products” Telecom Switch Commercial Embedded Compiler Automotive Software CASE Tool Small Scientific Simulation IS Application Distributed Objects (Order Entry) Defense Weapon System National Air Traffic Control System Large-Scale Organization/Entity Simulation Enterprise IS (Family of IS Applications) Defense MIS System IS Application GUI/RDB (Order Entry) Business Spreadsheet Lower technical complexity - Mostly 4 GL, or component-based - Application reengineering - Interactive performance Higher management complexity - Large scale - Contractual - Many stake holders - “Projects”

References n n Agile Software Development Methods by Abrahamsson et al. An Introduction to Agile Methods by Hayes et al. Scrum and XP from the Trenches by Kniberg et al. Slides and Notes by Laurie Williams ¨ Curtis Cook ¨ Carl-Fredrik Sørensen ¨ Carlo Ghezzi ¨

Example of a User Story Name: Sell soft drink Events: 1. A user inserts some money. 2. The vending machine displays how much money he has inserted so far. 3. If the money is enough to buy a certain type of soft drink, the vending machine lights up the button representing that type of soft drink. 4. The user presses a certain lit-up button. 5. The vending machine sells a can of soft drink to him. 6. The vending machine returns the changes to him. PITB-LUMS Advanced IT Skills Course © Naveed Arshad

PITB-LUMS Advanced IT Skills Course © Naveed Arshad