A little Software Engineering: Agile Software Development

1. A little Software Engineering:Agile Software Development 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 person could do it in in four times the time • Outline • Distinguish Waterfall (plan driven) from Agile • Practices of quality software development • Moving from User Stories -> Sprints with Tasks

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

4. Became Popular • Management (usually software ignorant) likes waterfall • 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 testers (not devs, QA team) • Maintenance means modifying as little as possible • old code is good code • Change is hard, and costly

5. A Spiral Approach • Dr Barry Boehm proposed a spiral approach

6. To waterfall or not • Waterfall 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. Cost of change Waterfall Cost of change Agile time

8. Agile Software Development • 60% of survey 2011 respondents: up to half of company’s projects are Agile http://www.versionone.com/state_of_agile_development_survey/11/ • Set of SE practices that produce high-quality software with limited effort • Many books • Kent Beck • Extreme Programming–Embrace Change • Ken Schwaber, Mike Beedle, • Agile software development with Scrum

9. eXtreme Programming • 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/

10. 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 • Planning games, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, Continuous Integration, on-site customer, coding standards

11. Cost of the Project • Paraphrasing from two software development companies I've talked to in Chicago and in Denmark • When we bid projects, we charge $X for doing it Waterfall and $X/2 for doing it Agile

12. An Agile Practice: The Planning Game • The planning game involves user stories • Short descriptions of desired features • Testable (and part of your grade, 10 points per sprint) • Did you get those stories implemented in this 1 week sprint? • Clients write stories and assign story points • In 335, SLs wrote the stories (see final project specs) • And have assigned story points to each, which are estimates of relative complexity: 1 3 5 8 13 • Scrum calls these the Product Backlog • In 335, the project specifications have those User Stories and points

13. An Agile Practice: Estimation • Based on similar stories from the past • You get good at estimation simply by • just do it

14. An Agile Practice: Sprints • Sprints range from 1 to 4 weeks • We choose 1 week sprints (because classes end in 4 weeks) • A sprint should make sense as a whole • Need to track stories during a sprint • Product Backlog is the complete list of stories that needs to be implemented—see the project specs • The Iteration/Sprint contains just the things to be executed during that sprint

15. Sprints continued • Plan a sprint (we will do this three times) • Meet with you PM each of the next three weeks • Prioritize: Which “stories” should be developed next • Move stories from product backlog to the sprint backlog • Create a list of tasks • A task is a technical requirement such as implement a Command hierarchy for 5 commands • Volunteer for those tasks • Finish those tasks so the stories are working • By the end of Sprint (or lose team project points)

16. 335 Sprints • Your first planning meeting is next week • Have Artifacts Complete (10pts) • Which means you know what you are supposed to do and have an idea of its architecture (classes and relationships between major objects) • Have a Repo set up with access to all on team • Have a Rally Community edition setup with all story points in the Product Backlog (can plan the sprint more quickly next week) • Attendance and Engagement: 13pts

17. Preview a Sprint in Progress Ken Schwaber task board mockup

18. Actual Task Board

19. How do we plan and track • We will be using Rally’s Application Lifecycle Management platform • Been around a long time • Developed by Agile people • Will help us plan and track the 335 final project • Keeps us on task • Can see who did what

20. ScreenShot of BackLog

21. ScreenShot of Plan

22. ScreenShot of Track

23. Need a Volunteer • Request Rally’s Community License http://www.rallydev.com/product-features/rally-community-edition • Add a 2nd user (a team member) • Select Setup > Users > Add • Let Rick edit the Sample project a little • We only have one project and max of 10 people