Software Development Process Models II Agile Methodologies Extreme

Software Development Process Models (II) Agile Methodologies Extreme Programming

Agile Methodologies p Agile methods are a family of software development processes for teams facing unpredictable or rapidly changing requirements. n n n n 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).

Agile Methodologies (cont’d) p Reject the notion that we should design for future change n p 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: p p p 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 n 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) p p Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Team: include all the people necessary to finish software n p 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. n Agile methods differ from iterative methods p p p 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 Agile home ground Junior developers Low requirements change Large number of developers Culture that demands order Plan-driven home ground

12 principles of Agile 1. 2. 3. 4. 5. 6. "The highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-toface conversation.

12 principles of Agile 7. 8. 9. 10. 11. 12. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams. 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. p Places a higher value on adaptability than on predictability p n p as all the agile methodologies do Target: Small to medium sized teams (<10 members) building software with vague or rapidly changing requirements n Risky projects with dynamic requirements are good candidates for XP.

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

XP Practices p The XP methodology has 12 practices. n n n The Planning Game Small releases Metaphor Simple Design Testing Refactoring Pair programming Collective ownership Continuous integration 40 -hour week On-site customer Coding standards p 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 p Planning Game: Determine the next release’s scope by working with customers n n Customer: what is desirable Programmer: what is possible -balancing p Small Releases: Put a system into production quickly (release every 1 -2 weeks) p Metaphor: Guide the development with a simple story of how the system works n p E. g. “Desktop” is a metaphor used in OS referring office desktop Simple Design

12 Practices of XP (cont’d) p Testing: tests are written first, by both programmers and customer: unit tests, acceptance tests n n n p 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 n Simplicity: focus on current requirements and no more p n Future may change Maintain simplicity via frequent refactoring p Instead of upfront design; re-architect for simplicity

12 Practices of XP (cont’d) p Pair programming: 2 programmers at 1 machine write codes n n p 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) p Continuous integration: Integrate and build the system many times a day n Keep testing while integrating=always a working product 40 -hour a week: Work no more than 40 hours per week p On-site customer: Have the customer on the team to answer questions full-time p n p Resolve disputes; set short term priorities; decisions Coding standards: n Improve communication by adopting coding standards; collective ownership; maintanance

When not to try XP p XP is very appealing to many programmers – often because they think can get away from heavy documentation n p 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: n When it is not supported by the company culture p n n 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 p n e. g. belief in big specifications, or overtime seen as a proxy for commitment to company e. g. already in production using a $1, 000 machine that is already at full capacity When the physical environment is wrong

Extreme Programming – 5 Values p Communication (with customer and within the team) n p p p 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 n p "XP programmers communicate with their customers and fellow programmers. " "With this foundation XP programmers are able to courageously respond to changing requirements and technology. " Respect: (the latest value) respect others and their work n E. g. never commit change that break compilation Based on http: //www. extremeprogramming. org

Comparison of activities Time Test Implement Design Analyze Waterfall Iterative XP

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