Software Quality and Agile SW Development

1. Software Quality and Agile SW Development Johan Lindvall TY 22.4.2005

2. Content • Backround and problems • IID • Scrum • XP • Quality

3. Backround and Problems • waterfall: response to ad-hoc code-and-fix 1960’s, Winston Royce (proponent of iterative dev.) • e.g. DoD standard 2167 • system should be clearly specified before its design and implemention • the clients are not sure what they want • details will only be revealed during development • as the product develop, clients change their minds • external forces (competitor’s product) -> high change rate, not predictable manufactoring

4. IID • Interative and incremental development • Agile methods are a subset of iterative and evolutionary methods • The key practices: iterative development risk-driven and client-driven timeboxing evolutionary development evolutionary requirements adaptive planning

5. Iterative Development • ID is an approach to build sw of several iterations • each iteration a mini-project • requirements analysis, design, programming, test • iteration release: a stable, integrated and tested internal (external) partially complete system

6. iteration by iteration system grows incrementally with new features  iterative and incremental development IID • at least 3 iterations • recommended lenght is 1-6 weeks per itr. • early risk mitigation and discovery • riskiest problems first • a study [Johnson2002]: • 45% of features were not used • 19% rarely • 16% sometimes • 13% often • 7% always

7. final product better matches true client desires  quality • iterative development is lower risk and better success, productivity, and defect rates than WF • early and regular process improvement • a per-iteration assessment • confidence and satisfaction from early, repeated success  team self-confidence  customer confidence in the team

8. Risk-Driven and Client-Driven Iterative Planning • What to do in the first/next iteration? • Risk-driven: the riskiest, most difficult elements for the early iterations • Client-driven: the choice of features comes from client, the currently highest business value

9. Timeboxing • the practice of fixing the iteration end-date and not allow it to change • if short of time, reduce the scope and leave features to the next iteration • no adding of new tasks to iteration

10. Evolutionary and Apadtive Development • requirements, plan, estimates, solution evolve and are refined • requires feedback from users, tests, developers • consept: evolutionary ~ adaptive = iterative-timebox

11. Evolutionary Requirements Analysis • requirements are not always changing (Boehm 1988 25%) • most requirements discovery and refinement usually occours during early iterations • e.g. 1-2 day req. workshop/itr. • early top-ten high-level req. (e.g. load, usability) • a study (1995, 107 projects) • 18% of the projects completed the reqs. in 1 iteration • 32% in 2 iterations • 50% in 3 or more iterations

12. Evolutionary and Adaptive planning • an initial phase of high uncertainty which drops • cone of uncertainty (effort, cost, shedule /time) • apadtive planning: no detailed schedule are created

13. Delivery • partial software produced, not merely documents • incremental delivery: system into production, deliveries between 3-12 months • evolutionary delivery: attempt to capture feedback, promoted in agile development

14. Agile sw development • requiring feedback to guide direction, early testing, early demos • agility – rapid and flexible response to change • motto: embrace change • practices and principles: simplicity, lightness, communication, self-directed teams, programming over documents • eg. Scrum and XP • whiteboard (wall sketches), snapshots • timeboxed iterative and evolutionary development, adaptive planning, promote evolutionary delivery • http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365

15. The Agile Manifesto Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following the plan

16. The Agile principles • early and continuous delivery of valuable sw • welcome changing requirements, even late • delivery working sw frequently • business people and developers daily together • motivated individuals • face-to-face conversation for information • working sw is the primary measure of progress • agile processes promote sustainable development • developpers, users maintain constant pace • attention to technical excellence and good design enhances agility • simplicity essentail – the art of maximizing the amount of work not done • the best architectures, requirements and desings emerges from self-organizing teams • the team regulary reflects on how to become more effective

17. Scrum • by Takeuchi and Nonaka 1986 paper of summarizing common best practises in 10 innovatoive Japanese companies • timebox exactly 30 days • working in a common room • daily meeting, at the same time and place • self-directed teams (one team <=7, many teams) • external demo at the end of each iter.

18. Cockburn scale C, D, E, L and 1-100-… • client-driven adaptive planning • Lifecycle: plannig, staging,development, release • Planning: • establish the vision, set expectations, funding • write vision, budget, initial Product Backlog • Staging: • identify more requirements, priorotize enough for first iteration

19. Development: • implenent a system ready for release in series of 30 days (sprints) • Sprint planning: choose goals for the next iteration, how to achieve the requests. Sprint Backlog: tasks (in next 4-16h) to meet the goals • during iteration do not add work, uninterrupted focus • quality assurance occurs specially in Sprint, with less new development Release: • operational deployment • or each release begins with staging

20. Product Backlog a list of all product requirements, functionality, features, techlogy never finished  evolves • Sprint Backlog daily estimate of work remaining for each task Scrum is based on the insight that SW development is creative and unpredictible new product development, and therefore empairical rather than defined methods are needed.

21. Scrum values • Commitment • the team commits to a defined goal and decide themselves how best to meet it • Focus • team not distracted, chickens and pics-rule, srcum master • Openness • product backlog makes visible the work and priorities • Respect – self-organizing • Courage – trust the team

22. XP • eXtreme Programming, Kent Beck 1980’s • truly adobted by developpers! • Cockburn scale C, D, E and 1-20 • small team projects, <10 developpers • emphasizes collaboration, quick and early sw creation • the cost of change may not rise over time

23. 4 values • communication: pairs, daily meetings, customer on-site • simplicity: ’Do simpliest thing that could possbly work’. Eg. avoid creating generalized components. • feedback: drives to quality and adaption • courage: simple design & tests  rapid and radical changes

24. 1-4 weeks iterations • story cards to summarize requirements, not required detailed workproducts • programming in pairs (deep skill transfer) • common project room • full-time participation by requirements donor (the client, end user) for ongoing verbal explinations • test-driven development, code reviews, frequent integration of all code short iterations, early feedback  quality • tests written ahead! • timeboxed, no working overtime

25. 12 core practices • The planning game • scope, priority, composition of releases, dates of releases • estmates, consequences, process, detailed scheduling • Small releases • the most valuable business requirements • Metaphor • the basic elements and their relationships, naive statement • Simple Design • runs all the tests, no duplicated logic, every intention important, fewest possible classes and methods

26. Testing • unit tests, functional tests • Refactoring • even more simpler? • Pair programming • implemention vs. strategy • Collective ownership • need to change now, not later • Continous Integration • integrated and tested after few hours - a day • 40 hour week • On-site customer • Coding standards

27. Others: Evo • 1960’s, published 1976 • 1-2 weeks iteration • evolutionary delivery on each iteration • plans iterations by highest value-to-cost ratio

28. Others: UP • Unified Process, 1990’s • iterative, not agile • risk-driven development in early iterations focusing on creation of the core architecture and driving down the high risks • 2-6 weeks iterations

29. Quality • research show that shorter steps have lower complexity and risk, better feedback, and higher productivity and success rate • early defect removal, less useless work, concentration on essential features • each iteration tested for acceptance real business value for customer.

30. References • Larman, Craig: Agile and Iterative Development, Addison-Wesley, 2004 • Beck, Kent: Extreme programming explained: embrace change, Addison-Wesley, 2000 • Scwaber Ken, Beedle Mike:Agile Software Development with Scrum, Prentice-Hall, 2002 • http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365