The case for 3. Towards a combination agile methods (or: the - PDF document

Three cultures of software development Chair of Softw are Engineering Three cultures: Software Engineering Prof. Dr. Bertrand Meyer � Process March 2007 – June 2007 � Agile � Object Software development: “Process” vs “agile” The first two are usually seen as exclusive, but all have major contributions to make with material by Marco Piccioni Software Engineering, lecture 8: 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 � CMM, then CMMI Scrum � 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 The case for � 3. Towards a combination 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 � Working software over comprehensive documentation Assembly-line production is possible : � Customer collaboration over contract negotiation � Define specifications and constructions steps � Responding to change over following a plan � Build some instances and perform measurements � On the basis of that experience, estimate & That is, while there is value in the items on schedule future production 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 Each model specific, evolving process: Can identify schedule and order all Activities emerge as part of the 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 � Build in tests; � Define and assign build in change � Promotion of agile Do it right the first time 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 Waterfall risk profile The waterfall model 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 35 � Stakeholders are not sure what they want 30 � They have difficulty stating it 25 20 Requirements � Many details will only be revealed during development change 15 � As they see the product develop, stakeholders will 10 change their minds 5 0 � External forces cause changes and extensions 10 100 1000 10000 (e.g. competition) Project size in FP 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… * T est Driven Development: By Example , Addison-Wesley Software Engineering, lecture 8: Process vs Agile 29 Software Engineering, lecture 8: Process vs Agile 30 5