Agile Software Development: Practices through Values

1. Agile Software Development:Practices through Values C Sc 335 Rick Mercer

2. Goal and Outline • Main Goal: • Suggest practices, values, and some process for completing a final project on time that is better than any one could do it in in four times the time. • Outline • Distinguish Waterfall (plan driven) from Agile • 11 Practices of quality software development • Four values of Extreme Programming (XP)

3. Waterfall Model • Waterfall was described by 1970 • Understood as • finish each phase • don’t proceed till done • W. W. Royce criticized this • proposed an iterative approach

4. Became Popular • Management liked phases to easily set deadlines • Customers provide all requirements • Analysts translate requirements into specification • Coders implement the specification • Reviews ensure the specification is met • Testing is performed by others (QA) • Maintenance means modifying as little as possible • old code is good code • Change is hard (and costly)

5. Sprial • Dr Barry Boehm proposed a spiral approach

6. Waterfall • It became popular • This process is still is used a lot • Craig Larman's book [1] provides proof that waterfall is a terrible way to develop software • In his study, 87% of all projects failed • The waterfall process was the "single largest contributing factor for failure, being cited in 81% of the projects as the number one problem." [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

7. Extreme Programming (XP) • As of 2009, about 14 years of growth • About 25% of new project are Agile • Set of SE practices that produce high-quality software with limited effort • Many books, first by Kent Beck: Extreme Programming–Embrace Change, Addison-Wesley, 2000, ISBN 0-201-61641-6 • http://www.extremeprogramming.org/

8. Extreme Programming • XP is • a disciplined approach to software development • code centric: no reckless coding, test-first • successful because it emphasizes customer involvement and promotes team work • not a solution looking for a problem • One of several "agile" (can adapt to change) software development processes http://www.agilealliance.org/

9. Essence of XP • Four variables in software development: • Cost, Time, Quality, Scope (# features) • Four Values • Communication, Simplicity, Feedback, Courage • Five Principles • Provide feedback, assume simplicity, make incremental changes, embrace change, quality work • Practices (or fewer, or more, or subject to change) • Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, Continuous Integration, on-site customer, coding standard

10. Cost of change Waterfall Cost of change XP time

11. Cost of the Project • Paraphrasing two companies from Agile • When we bid projects, we charge $X for doing it Waterfall and $X/2 for doing it Agile

12. Goal and Outline • Main Goal: • Suggest practices, values, and some process for completing a final project on time that is better than any one could do it in in four times the time. • Outline • Distinguish Waterfall (plan driven) from Agile • 11 Practices of quality software development to use on your final project • Four values of Extreme Programming (XP)

13. Practices: Planning Game • The planning game involves story cards, which are short descriptions of a feature • Provide value to customer • Independent of each other • Testable • Customer write stories cards and prioritize them • Developers estimate how long a story takes

14. Practices: The planning game • Business decisions (customer) • Scope: which “stories” should be developed • Priority of stories (features) • Release dates • Technical decisions (developers) • Time estimates for features/stories • Elaborate consequences of business decisions • Team organization and process • Scheduling

15. Practices: Estimation • Based on similar stories from the past • Team effort • We get good at estimation simply by just doing it • Ideal Engineering Time (IET) • could be points • Velocity = IET/Calendar Time • we can do 20 points each week • "Customer, which 20 points do you want next week?"

16. Practices: Small Releases • Releases should be as small as possible • Should make sense as a whole • Put system into production ASAP • Fast feedback • Deliver valuable features first • Short cycle time • Planning 1-2 months rather than 6-12 months • Or in our case, 2.5 weeks rather than 5 weeks

17. Practices: Simple design • The “right” design • Runs all tests • No code duplication, No code duplication • Fewest possible classes • Short methods • Fulfills all current business requirements • Design for today not the future • But design so the system can change

18. Practices: Testing • Software should be tested, but it is often spotty or overlooked • Automatic testing (JUnit, for example) help us know that a feature works and it will work after refactoring, additional code, and other changes • Provides confidence in the program

19. Testing • Write tests at the same time as production code • Unit tests  developer • Feature/acceptance tests  customer • Don't need a test for every method • Testing can be used to drive development and design of code • Allows for regression testing • Do changes break previously working code

20. SIM/SQS http://www.simgroup.com/Consultancy/regression.html • Regression Testing • re-testing of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of changes. • Regression tests are designed for repeatability, and are often used when testing a second or later version of the system under test. • Regression testing can be carried out on all applications, includinge-Commerce and web-based systems .

21. Testing • Strong emphasis on regression testing • Unit tests need to execute all the time • Unit tests pass 100% • Acceptance tests (we haven't seen these) show progress on which user stories are working • Other testing frameworks include • JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit

22. Can't unit test always • Won’t have unit tests for • GUIS: There are testing frameworks to simulate and test user interaction, but not this course • Network, use visual inspection while running • Randomness: Some strategies might have some randomness, which can be hard to work with

23. Practices: Refactoring • Restructure code without changing the functionality • Goal: Keep design simple • Change bad design when you find it • Remove dead code • Examples at Martin Fowler's Web site: http://www.refactoring.com/see online catalog

24. Practices: Pair programming • Write production code with 2 people on one machine • Person 1: Implements the method • Person 2: Thinks strategically about potential improvements, test cases, issues • Pairs change all the time. Has advantages such as • No single expert on any part of the system • Continuous code reviews, fewer defects • Cheaper in the long run, and more fun • Can you form a team of 4 and have everyone see all code? • Problems: • Not all people like it • Pairs need to be able to work together

25. Practices: Collective ownership • All code can be changed by anybody on the team • Everybody is required to improve any portion of bad code s/he sees • Everyone has responsibility for the system • Individual code ownership tends to create experts

26. Practices: Continuous integration • Integration happens after a few hours of development • Checkout build with your changes, Make sure all tests pass (green bar) • In case of errors: • Do not put changes into the build • Fix problems • Checkin the system to the common repository • Repeat • We will use CVS to store your code

27. Continuous Integration • Find problems early • Can see if a change breaks the system more quickly -- while you remember the details • Small increments

28. Practices: Coding standards • Coding Standard • Naming conventions and style • Least amount of work possible: Code should exist once and only once • Team has to adopt a coding standard • Makes it easier to understand other people’s code • Avoids code changes because of syntactic preferences

29. Practices: On-site customer • Many software projects fail because they do not deliver software that meets business needs • Real customer has to be part of the team • Defines business needs • Answers questions and resolves issues • Prioritizes features

30. Outline • Main Goal: • Suggest practices, values, and some process for completing a final project on time that is better than any one could do it in in four times the time. • Outline • Distinguish Waterfall (plan driven) from Agile • 11 Practices of quality software development to use on your final project • Four values of Extreme Programming (XP) • Process considerations adapted from Scrum

31. Values: Communication • Communication • Customer centric (write "Stories") • Pair programming • Task estimation • Iteration planning • What to do in the next time period • May be weekly goals • Design sessions

32. Values: Simplicity • Simplicity • Choose the simplest thing that will work • Choose the simplest design, technology, algorithm, technique

33. Values: Feedback • Feedback very important • Small Iterations • Frequent deliveries • Pair programming • Constant code review • Continuous integration (add often to the build) • automated unit tests (JUnit, for example)

34. Values: Feedback • Compiler feedback: seconds • Pair programming feedback: half minutes • Unit test feedback: few minutes • Acceptance testing: half hours • Customers write these, no can do in 335 • Customer feedback: daily (or several times/week in our case) • Iteration feedback: weekly • FeedBack?

35. 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: Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Agile Manifesto

36. Outline • Main Goal: • Suggest practices, values, and some process for completing a final project on time that is better than any one could do it in in four times the time. • Outline • Distinguish Waterfall (plan driven) from Agile • 11 Practices of quality software development to use on your final project • Four values of Extreme Programming (XP)

37. 335 Final Project • SLs and Rick are the customers • Projects still TBD • Hope to have specs by Tuesday 27-Oct • Will choose teams/projects next Thursday 29-Oct • As customers, we reserve the right to change requirements :-)