The case for agile methods (or: the Cubicle Strikes Back) Software - PDF document

Three cultures of software development Chair of Software Engineering Three cultures: Software Engineering Prof. Dr. Bertrand Meyer  Process  Agile Software development:  Object “Process” vs “agile” The first two are usually seen as exclusive, but all have with material by Marco Piccioni major contributions to make Software Engineering, Process vs Agile 2 Process-oriented Agile (Sometimes called formal ) Extreme Programming (XP) Examples: Lean Programming  Waterfall model (from 1970 on) Test-Driven Development (TDD)  Military standards Scrum  CMM, then CMMI  ISO 9000 series of standards  Rational Unified Process (RUP)  Cluster model Overall idea: to enforce a strong engineering discipline on the software development process  Controllability, manageability  Traceability  Reproducibility Software Engineering, lecture 8: Process vs Agile 3 Software Engineering, lecture 8: Process vs Agile 4 This lecture (today and tomorrow) - 1 -  1. The case for agile methods  2. Process-oriented methods  3. Towards a combination The case for agile methods (or: the Cubicle Strikes Back) Software Engineering, lecture 8: Process vs Agile 5 Software Engineering, lecture 8: Process vs Agile 6 1

“The agile manifesto” Scheme 1: predictable manufacturing agilemanifesto.org 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 Assembly-line production is possible :  Working software over comprehensive  Define specifications and constructions steps documentation  Build some instances and perform measurements  Customer collaboration over contract negotiation  On the basis of that experience, estimate &  Responding to change over following a plan schedule future production That is, while there is value in the items on the right, we value the items on the left more. Software Engineering, lecture 8: Process vs Agile 7 Software Engineering, lecture 8: Process vs Agile 8 Scheme 2: new model development Assembly-line vs prototype Assembly-line manufacturing Prototype-style manufacturing Specify, then build Hard to freeze specifications Reliable effort and cost estimates Estimates only become possible late, are possible, early on as empirical data emerge Can identify schedule and order all Activities emerge as part of the Each model specific, evolving process: activities process  Requirements change between races Stable environment Many parameters change; need  Static reasons (specific tracks) creative adaptation to change  Dynamic reasons (weather, competitors)  High level of competition  Continuous experimenting Prototypes rather than products C. Larman Agile & Iterative Development A Manager guide Addison Wesley 2003 Software Engineering, lecture 8: Process vs Agile 9 Software Engineering, lecture 8: Process vs Agile 10 Agile methods: basic concepts What about software? In the agile view, most software development is not a Principles: Practices: predictable, mass-manufacturing problem, but falls under  Evolutionary requirements Iterative development  the new product development model  Customer on site Customer involvement   User stories Support for change   Pair programming Primacy of code   Design & code standards Self-organizing teams   Test-driven development Technical excellence   Continuous refactoring Search for simplicity   Continuous integration  Timeboxing Shunned: “big upfront requirements”; plans;  Risk-driven development binding documents;  Daily tracking diagrams (e.g. UML); non-  Servant-style manager deliverable products Software Engineering, lecture 8: Process vs Agile 11 Software Engineering, lecture 8: Process vs Agile 12 2

Another view: lean programming Manager’s role in agile development Mary Poppendieck* The manager does not: The manager does provide:  Eliminate waste “Documentation that is not part of the final program”  Create a work  Coaching  Minimize inventory breakdown structure,  Service and leadership  Maximize flow Iterative development schedule or estimates  Resources  Pull from demand  Tell people what to do Decide as late as possible  Vision  Empower workers (usually)  Removal of impediments  Meet customer requirements  Define and assign Build in tests;  Promotion of agile  Do it right the first time build in change detailed team roles principles  Abolish local optimization Fret about value, not scope  Partner with suppliers  Create a culture of continuous improvement *See www.poppendieck.com Software Engineering, lecture 8: Process vs Agile 13 Software Engineering, lecture 8: Process vs Agile 14 Iterative development Iterative development  Each iteration is a self-contained mini-project Not a new idea (see Microsoft’s Daily Build, cluster model)  Iteration goal: a release, that is a stable, integrated Avoid “big bang” effect of earlier approaches and tested partially complete system Short iteration cycles  All software across all teams is integrated into a release each iteration  Most iteration releases are internal  During each iteration, there should be no changes from external stakeholders Software Engineering, lecture 8: Process vs Agile 15 Software Engineering, lecture 8: Process vs Agile 16 The waterfall model Waterfall risk profile Feasibility study Potential impact of risk being tackled Requirements Requirements Design Implementation Integration, V&V… Specification Global design Detailed design Implemen- tation V & V Time Distribution C. Larman Agile & Iterative Development A Manager guide Addison Wesley 2003 p. 58 Software Engineering, lecture 8: Process vs Agile 17 Software Engineering, lecture 8: Process vs Agile 18 3

Risk-driven vs. client-driven planning Timeboxed iterative development Set iteration end date, no change permitted  What would you choose to implement first? If requests cannot be met within timebox:   The riskiest, most difficult tasks… or Place lower priority requests back on wish list   What the client perceives as his highest business Never move a deadline  value? Never ask developers to work more to meet a deadline  Iterations may typically last from 1 to 6 weeks Software Engineering, lecture 8: Process vs Agile 19 Software Engineering, lecture 8: Process vs Agile 20 Parkinson’s law* Arguments for timeboxing For developers: Work expands so as to fill the time available for its completion  More focus (to limit Parkinson’s law)  Forced to tackle small levels of complexity For managers:  Early forcing difficult decisions and trade-offs  Better skill assessment of people involved and better balance and optimization provided For stakeholders:  They see the actual progress of the application every iteration end *C. Northcote Parkinson: Parkinson's Law, or The Pursuit of Progress , 1957 Software Engineering, lecture 8: Process vs Agile 21 Software Engineering, lecture 8: Process vs Agile 22 Arguments against upfront requirements Requirements uncertainty  Details are too complex for people to grasp  Stakeholders are not sure what they want  They have difficulty stating it  Many details will only be revealed during development  As they see the product develop, stakeholders will change their minds  External forces cause changes and extensions (e.g. competition) Jones C. 1997 Applied Software Measurement MCGraw Hill Software Engineering, lecture 8: Process vs Agile 23 Software Engineering, lecture 8: Process vs Agile 24 4

Actual use of requested features Requirements in practice, the agile view Realistic approach, based on 200+ SW projects: Never: 45% Seldom: 19%  Requirements always change Occasionally: 16%  Developers get complete specifications only 5% of the times Often: 13%  On average, design starts with 58% requirements Always: 7% specified in detail J. Johnson, XP2002 From: D. Reinertsen, S. Thomke: Agile Product Development: Managing Development Flexibility in Uncertain Environments, in California Management Review , Vol. 41, No. 1, Fall 1998, pp. 8-30. Software Engineering, lecture 8: Process vs Agile 25 Software Engineering, lecture 8: Process vs Agile 26 Evolutionary requirements analysis User stories Do we need to know all the functional requirements to start building a good core architecture?  Agile answer: the architect needs most nonfunctional or quality requirements (e.g. load, internationalization, response time) and a subset of functional requirements Software Engineering, lecture 8: Process vs Agile 27 Software Engineering, lecture 8: Process vs Agile 28 Test-Driven Development: basic cycle TDD: a first assessment After Kent Beck* 1. Add a test For: 2. Run all tests and check the new one fails  Central role to tests 3. Implement code to satisfy functionality  Need to ensure that all tests pass 4. Check that new test succeeds  Continuous execution 5. Run all tests again to avoid regression 6. Refactor code But:  Tests are not specs  Risk that program pass tests and nothing else Stay tuned… * Test Driven Development: By Example, Addison-Wesley Software Engineering, lecture 8: Process vs Agile 29 Software Engineering, lecture 8: Process vs Agile 30 5