1. Agile

2. Processes Waterfall Traditional With prototyping Sprial Agile Dynamic Systems Development Method (DSDM) Scrum Crystal eXtreme Programming (XP) 1

3. 2 WaterfallSpiralAgile Emphasizes:-Simplicity -Traceability -Risk management -Exploring alternatives -Flexibility -Immediacy Weakness:Requirement/design mistakes can be costly Exploring alternatives can be costly Continual rework can be costly Style:-Highly controlled -High ceremony -Moderately controlled -Moderate ceremony -Rapid & organic -Low ceremony Some definitions -“traceability”: relationships between requirements and system elements are documented -“immediacy”: getting some sort of working system to the customer as fast as possible -“rework”: redesigning the architecture and/or refactoring the program code -“controlled”: conformance to process is highly valued, even if it slows a project down -“ceremony”: how much analysis, documentation, and planning is involved

4. When to choose what Waterfall: good for smaller systems where requirements can be fully understood before design and implementation Spiral: good for larger systems with vague requirements and many alternatives for designing and coding Agile: good for systems where you can rapidly create something very small but useful and then expand from there 3

5. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 4

6. Agile Processes 5 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests

7. Iterations Purpose Iterative gives you a few “oh drat”s instead of one OMG at the end. Timing Scrum: 1 month XP: 1-2 weeks Grouping Iterations can be grouped into releases Not ever iteration results in a new release Sub-dividing Each iteration has “micro-iterations” 6

8. Principles of DSDM (Dynamic Systems Development Method) Active user involvement is imperative The team must be empowered to make decisions Fitness for business purpose is the essential criterion for accepting deliverables Requirements are specified at a high level Focus on frequent delivery of products 7

9. Principles of DSDM (cont..) Iterative and incremental development necessary to converge on a solution All changes during development are reversible Testing is integrated throughout life cycle Collaboration and cooperation is essential 8

10. Key Practices of DSDM Ambassador users and facilitated workshops Users on-call and users en-masse (respectively) Stages of iterations: Pre-project exploratory phase (kick around ideas) Feasibility study (explore if ideas are doable) Business study (explore if ideas worth doing) Model, design, implement (a “timebox” of work) Post-project phase (what went well and what didn’t?) 9

11. Principles of XP (Extreme Programming) Communication- It’s good to talk with customer and between developers Simplicity- Keep it simple and grow the system (and models) when required Feedback- Let users provide feedback early and often Courage- Speak the truth, with respect 10

12. Practices of XP Whole team Metaphor The planning game Simple design Small releases Customer tests Pair programming Test-driven development Design improvement Collective code ownership Continuous integration Sustainable pace Coding standards 11

13. Practices of XP Whole team- Customer is part of team Metaphor- Design around a coherent idea The planning game- Be realistic re: meeting customer needs Simple design- Simple models, architecture, code 12

14. Practices of XP Small releases- Meet customer needs in small increments Customer tests- Customer participates in testing Pair programming- All code written with “co-pilot” Test-driven development- Write tests first, then code 13

15. Practices of XP Design improvement- Refactor only as needed Collective code ownership- Anyone can modify any code Continuous integration- Regularly check if system on track Sustainable pace- No all-nighters, no superheroes Coding standards- Pick a format, use it, move on 14

16. Agile Processes 15 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests

17. Agile Processes 16 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests collect user stories

18. Agile Processes 17 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests divide stories into tasks estimate effort

19. Agile Processes 18 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests customer selects stories allocate work among team

20. Agile Processes 19 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests write unit tests

21. Agile Processes 20 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests write and refactor code

22. Agile Processes 21 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests customer tests system

23. Agile Processes 22 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests customer uses system

24. Agile Processes 23 Customer provides short requirements System and acceptance tests evaluate & control risk Prioritize requirements and plan Implement Operation Write/run/modify unit tests collect user stories divide stories into tasks estimate effort customer selects stories allocate work among team write unit tests write and refactor code customer tests system customer uses system

25. Concerns About XP Constant refactoring can be expensive Pair programming can take extra effort XP is not very standardized Programmers don’t always specialize 24

26. Lessons from DSDM and XP Learn from: Users (DSDM) Customers (XP) Design based on: Business value (DSDM) Customer direction (XP) Requirements should be: High-level (DSDM) Succinct (XP) 25

27. Next Steps.. HW #4 (Design) due Friday!! Vision statement peer review next Tuesday!! Bring hard copy of rough draft Don’t forget your midterm!! Due 11/25 26