Software Development Process Models (II) Agile Methodologies Extreme Programming

Agile Methodologies  Agile methods are a family of software development processes for teams facing unpredictable or rapidly changing requirements. Extreme Programming (XP) Agile Modeling Adaptive Software Development (ASD) Crystal Clear and Other Crystal Methodologies Dynamic Systems Development Method (DSDM) Feature Driven Development Lean software development Agile Unified Process (AUP) (For more detailed information, see The Agile Alliance).The Agile Alliance

Agile Methodologies (cont’d)  Reject the notion that we should design for future change don’t “borrow trouble”  Manifesto for Agile Software Development: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan”  Seductive, but Beware: it is not yet widely accepted in industry, and its own proponents admit that it is not always a good choice

Agile Methodologies (cont’d)  Agile methods emphasize real-time communication, preferably face-to-face, over written documents.  Team: include all the people necessary to finish software programmers and their customers, testers, interaction designers, technical writers, and managers.  Most agile methods share iterative development's emphasis on building releasable software in short time periods. Agile methods differ from iterative methods  time period is measured in weeks rather than months  treat their time period as strict time box.  work is performed in a highly collaborative manner.

Agile or Plan driven? Senior developers High requirements change Small number of developers Culture that thrives on chaos Junior developers Low requirements change Large number of developers Culture that demands order Agile home ground Plan-driven home ground

 Customer involvement  Incremental delivery  People not process  Embrace change  Maintain simplicity

12 principles of Agile 1. "The highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes 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 time scale. 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.

12 principles of Agile 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. 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. "

Extreme Programming (XP)  The most popular agile software development methodology.  Places a higher value on adaptability than on predictability as all the agile methodologies do  Target: Small to medium sized teams (<10 members) building software with vague or rapidly changing requirements Risky projects with dynamic requirements are good candidates for XP.

 Small iterations -2 weeks Feedback;customer involvement;schedule slips  Make each release work Make the smallest initial release that works: Establish credibility;results Keep delivering working products  Maintain test; re-run test after every change Keep Defect rate under control  Customer in team; continuously refining specs Do the right product; address need changes  Make your own estimates, human interaction, constant pace; collective work

 Simplicity: focus on current requirements and no more Future may change  Maintain simplicity via frequent refactoring Instead of upfront design; re-architect for simplicity  Pair programming Collective ownership and Informal reviews  Test first: tests are your goals to achieve Implement test first requires through understanding of the specification Ambiguities and omissions are captured before implementation  On site customer Decisions, clarification, prioritization, acceptance tests  Continuous integration: working product releases Relies on tests

XP Practices  The XP methodology has 12 practices. The Planning Game Small releases Metaphor Simple Design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards  Beck emphasizes that you can’t pick and choose: if you’re not doing them all, you’re not doing XP

12 Practices of XP  Planning Game: Determine the next release’s scope by working with customers Customer: what is desirable Programmer: what is possible -balancing  Small Releases: Put a system into production quickly (release every 1-2 weeks)  Metaphor: Guide the development with a simple story of how the system works E.g. “Desktop” is a metaphor used in OS referring office desktop  Simple Design

12 Practices of XP (cont’d)  Testing: tests are written first, by both programmers and customer: unit tests, acceptance tests Tests are your goals to achieve Implement test first requires through understanding of the specification Ambiguities and omissions are captured before implementation  Refactoring: Restructure the system without changing its behavior Simplicity: focus on current requirements and no more  Future may change Maintain simplicity via frequent refactoring  Instead of upfront design; re-architect for simplicity

12 Practices of XP (cont’d)  Pair programming: 2 programmers at 1 machine write codes Two programmer working side-by-side, on the same computer, interchanging roles back and forth. While one programmer actively implements, the other observes and identify defects and also thinks strategically about the direction of the code Informal reviews  Collective ownership: Anyone in the team can modify the code; Everyone is responsible of every bit of code

12 Practices of XP (cont’d)  Continuous integration: Integrate and build the system many times a day Keep testing while integrating=always a working product  40-hour a week: Work no more than 40 hours per week  On-site customer: Have the customer on the team to answer questions full-time Resolve disputes; set short term priorities; decisions  Coding standards: Improve communication by adopting coding standards; collective ownership;maintanance

When not to try XP  XP is very appealing to many programmers – often because they think can get away from heavy documentation in fact the test-first practice creates a lot of documentation, though in code form  Beck himself indicates that there are situations where XP is not appropriate. These include: When it is not supported by the company culture  e.g. belief in big specifications, or overtime seen as a proxy for commitment to company More than 10 or 20 programmers (now, he claims the opposite) Project too big for regular complete integration Where it inherently takes a long time to get feedback Where you can’t realistically test  e.g. already in production using a $1,000,000 machine that is already at full capacity When the physical environment is wrong

Extreme Programming – 5 Values  Communication (with customer and within the team) "XP programmers communicate with their customers and fellow programmers. "  Simplicity: Keep design simple and clean  Feedback: Get feedback by testing the software starting on day one  Courage: Deliver the system to the customers as early as possible and implement changes as suggested. Feel comfortable with refactoring or modifying or deciding to throw code away "With this foundation XP programmers are able to courageously respond to changing requirements and technology. "  Respect: (the latest value) respect others and their work E.g. never commit change that break compilation Based on

Comparison of activities Analyze Design Implement Test Time Waterfall IterativeXP

Other Software Process Models  Rational Unified Process  Rapid Application Development  Formal Systems Development  Reuse Based Development  Component Based Development  …