Agile Software Development Methodologies
•Download as ZIP, PDF•
5 likes•4,687 views
Revenge of the Programmers (presentation given to colleagues at Pason Systems, 2002)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile Software Development Methodologies
Similar to Agile Software Development Methodologies (20)
More from guy_davis
More from guy_davis (12)
Recently uploaded
Recently uploaded (20)
Agile Software Development Methodologies
- 1. Agile Software Development Revenge of the Programmers? Guy Davis – Pason Systems 1 10/01/09
- 2. Overview Agile Manifesto eXtreme Programming (XP) Scrum XBreed, XP@Scrum, Crystal, dX, FDD, ASD Agile Resources 2 10/01/09
- 3. 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 3 10/01/09
- 4. eXtreme Programming (XP) Core Values Project Variables Communication Cost Simplicity Scope Feedback Time Courage Quality 4 10/01/09
- 5. Key Practices of XP 5 10/01/09
- 6. XP Process 6 10/01/09
- 7. XP Iteration 7 10/01/09
- 8. XP Development 8 10/01/09
- 9. XP Collective Code Ownership 9 10/01/09
- 10. XP Planning 10 10/01/09
- 11. XP Roles Programmer Customer Tester Tracker Coach Consultant Big Boss 11 10/01/09
- 12. XP Limitations Good for consultants, custom software dev. What about other types of software dev.? Shrink-wrap software? Misson or life critical systems? Fixed price, fixed scope contracts? Scalability of the XP process to large teams? On-site customer possible for your project? Team must be co-located? Distributed teams? 12 10/01/09
- 13. Scrum 13 10/01/09
- 14. Scrum Roles Product Owner Solely controls the product backlog (prioritized) Arbitrates requests from all customers Does NOT control the sprint backlog Scrum Master Enforces the values, practices, and rules of Scrum Interface between developers and management Removes impediments for developers 14 10/01/09
- 15. Scrum Team No traditional roles Cross- functional Self-organizing Size: 7 people ± 2 Has both authority and Scaling Scrum Projects responsibility Can follow any 15 10/01/09
- 16. Sprint Planning Meeting 16 10/01/09
- 17. Daily Scrum Each team member answers three questions: What have you done since the last scrum? What are you planning to do before the next scrum? What got in the way of doing your work? Goals of this short meeting: Identify impediments slowing progress Make decisions collectively as a team Track team progress during the sprint 17 10/01/09
- 18. Sprint Burndown 18 10/01/09
- 19. Sprint Review Meeting Demonstrate functionality added during sprint Team, product owner, and customers attend Product increment is assessed against sprint goal Discuss successes and failures from last sprint Short prep time for team (~2 hours; no M$ PP) 19 10/01/09
- 20. Scrum Benefits/Drawbacks Benefits Empirical process control Socialization and knowledge transfer Team controls their own destiny Risk management Drawbacks Management not used to letting go of the reins Outcome dependent on the team (variable?) 20 10/01/09
- 21. XP/Scrum Hybrids 21 10/01/09
- 22. Crystal Light Methods Rank projects by # of people & error consequence Adapt your methodology to your project's need Use the least disciplined methodology that will still succeed 22 10/01/09
- 23. dX: Hybrid between RUP & XP An agile RUP-dervived approach (oxymoron?) Inception: use-case cards, prototypes, velocity Elaboration: iterative, UML, refactor, test Construction: indistinguishable from elaboration Transition: early release, active feedback Helping drive sales of Rational's tools ($$$) 23 10/01/09
- 24. Feature-Driven Development Deliver frequent, tangible working results A feature defines a task Group features into business-related sets Focus on delivering features every two weeks Track and report progress through feature progress Plan, build, and design by feature 24 10/01/09
- 25. Adaptive Software Development Short iterations Deliverable-centric instead of task-centric 25 10/01/09
- 26. Agile Resources Calgary Agile Methods User Group Monthly meetings at the U of C http://can.cpsc.ucalgary.ca/camug/ Books (tons of these on Agile topics) eXtreme Programming eXplained by Kent Beck Agile Soft. Dev. with SCRUM by Schwaber et al. Articles, discussion, information on the Web 26 10/01/09
- 27. Milos Agile Project Tool 27 10/01/09
- 28. References Beedle, Mike. XBreed web site (description page). 2002 Cohn, Mike. The Scrum Development Process. Mountain Goat Software. 2002 Cockburn, Alistair. Crystal Light Methods. Cutter IT Journal. 2001 Law, Amy and Keijin Huang. SENG 623: Scrum class presentation. 2002 Martin, Robert. Object Oriented Analysis and Design with Applications. 2001 Maurer, Frank. SENG 609.24: Agile Methods Class Slides. 2002 McBreen, Pete. SENG 609.33: Agile Testing Class Notes. 2002 McBreen, Pete. Questioning eXtreme Programming. 2002 Murthi, Sanjay. Scaling Agile Methods. New Architect Magazine. October 2002 Schwaber, Ken. XP@Scrum web site. 2002 Sliwa, Carol. XP, Scrum Join Forces. ComputerWorld Magazine. March 2002 Wells, Don. www.extremeprogramming.org web site. 2002 28 10/01/09
Editor's Notes
- Welcome to Tech Talks. Hoping to have participants present on interesting topics in software development. Goal: Further our programming practice as Software Engineers. Art, Craft, Science, Engineering question -> good topic :) “Revenge of the Programmers” : Phrase coined by Bertrand Meyer upon learing of Agile methodologies. What are programmers getting revenge against? Development Methodologies: 1) Lightweight: agile world 2) Heavyweight: RUP, CMM, MILSTD world 3) Ad-hoc: What's a methodology? 4) Tailored: Take the best of all worlds to suit your situation...
- Agile is a group of lightweight software development methodolgies. “Agile Alliance” created by representatives from various methodologies in 2001 on a ski trip in Utah. Fancy term for light weight. Includes: Extreme Programming: Beck (1996) Scrum: Sutherland, Schwaber, Beedle (1996) Crystal: Alistair Cockburn (1995) DX: Robert Martin (1998) Feature drvien design (FDD): Coad, Lefevbre, Deluca (1997) Adaptive Software Development (ASD): Peter Highsmith (1994) Dynamic systems development method: ??? (1992) Pragmatic Programming: Thomas, Hunt (1999)
- Not to say that things on the right are never done or are completely useless, just that agile processes have a preference for the items on the left. Basically about empowering the individual developer improves communication with customer improves time estimates through measurement of velocity improves testing (TDD, automated); better software quality attempts to reduce the pain caused by rapidly changing requirements no more death marches to meet arbitrary deadlines
- Communication: Most problems traced to miscommunication between team members. Simplicity: What's the simplest thing that could possibly work? Feedback: Rapid releases, automated unit testing Courage: Admit failure, to refactor, to pair program XP defines four project variables that affect the outcome of all software projects. Management can pin down any three of the variables, but not the fourth. Any software project were all four are dictated by management without developer feedback are likely to fail. Good example: Fred Brooks classic “Mythic Man Month” describing the a death march to release IBM OS/360, added more junior programmers
- Customer Satisfaction On-site customer: answer questions, define needs, prioritize features Small, frequent releases: early, constant feedback, easier to plan Software Quality Metaphor: Overall idea of the system, consistent naming scheme Testing: test first design; automated unit, regression, and acceptance tests Simple design: design for today, not for the future Refactoring: goal is to keep design simple Pair programming: peer review is good so do it all the time Project Management Planning game: determine user stories, priorities, release schedule Sustainable development: Never more than two weeks of OT in a row Collective code ownership: Keeps code clean, discourages “experts” Continous integration: avoids traditional big bang integration problems Coding standards: Easier for all developers to understand whole system
- User stories (requirements) from customer; input for acceptance tests Spikes: a throw-away test program that addresses major uncertainties Release planning: Overall project schedule meeting, based on user story estimates, move user story cards around on big table to set releases Iterations: plan each iteration just before entry; follows from release plan; consider current project velocity (total of story estimates completed in an iteration), generate acceptance tests Acceptance tests are black box system tests. Customer responsible for verifying correctness.
- Roughly 1-3 weeks long Initial planning meeting: Choose user stories to complete based on customer priority Handle failed acceptance tests from last iteration Estimates for stories must equal project velocity of previous iteration Break user stories down into programming tasks - developers choose and estimate their tasks (1-3 days of ideal time) - total estimates for tasks can't exceed project velocity (snow-plowing) All estimates are encouraged to be accurate, low-balling doesn't help May need to re-estimate all user stories and redo release plan every 3-5 iterations depending on requirements flux.
- Daily stand up meeting Short (no chairs) Communicate problems and solutions Promote team focus Encourages communication between whole team Replaces tedious meetings (can determine if private meetings are necessary, can remove need to even schedule official meetings) Nearly immediate heads-up if individual is overloaded Promotes collective understanding of system, sharing
- Any developer can add functionality, fix bugs, or refactor Reduces chance of one person becoming a bottle-neck - Move people around to promote cross-training Pair programming (proactive peer review) - One thinks tactically about method, other strategically about system Requires unit testing - drives design; test first design ensures the simplest solution is built - results in higher quality software, easier to refactor safely Requires continous integration - ensures unit tests are passing, catches problems fast! - only one pair integrates at a time (sequential integration) Allows constant refactoring to improve system (no more crusty code!) Class, Responsibilities, Collaboration (CRC) cards are used find simple solutions to complex problems; use cards in informal design meetings
- Don't plan with too much detail too far out. Set the right scope. Feedback is critical to ensure the project is on track. Most effective for responding to changing requirements and project conditions.
- These are not necessarily separate people; can wear multiple hats. Programmer: code, refactor, unit-test; strive for simplicity, communicate Customer: domain expert, able to make decisions, write user stories Tester: liase with customer to write, run, and report functional tests Tracker: track estimates and schedule, log defects, provide feedback Coach: responsible for process as a whole, steer the team (hands off) Consultant: XP doesn't create specialists, hire them to teach team Big Boss: courage, communication, occasionally oversight
- Consultants love it because it leads to higher customer satisfaction by involving customer throughout project. Same thing with custom software or in-house development. But shrink wrap software usually has diverse customer base Already do insane peer review & quality control -> space shuttle coders Nailing down all four project variables, no place for XP feedback Most experience indicates 20-30 is upper limit on team size - Servidium had 30+ , New Architect article two teams of 50+ total - Can you split up a big team into XP sub-teams? Issues? Anecdotal evidence indicates that XP requires an experienced group of coders; junior teams don't do as well with XP What is the affect on traditional architecture and design process? What is the affect on traditional quality assurance process? Currently research at the U of C on Distributed XP (Frank Mauer)
- Refers to scrum from rugby (team working to common goal) Originated in Japan in 1987 (Nonaka and Takeuchi) Mentioned in software context by Degrace and Stahl in 1990 Applied to software by Schwaber and Sutherland in mid-1990's Undefined (unpredictable, complex, dynamic) processes require different manage & control than defined (which CMM assumes) Concepts: Product Backlog: master list of all functionality (tasks and stories) - in order of priority with time estimates for each Sprint: an iteration (30 days) in which team has total freedom/responsibility to accomplish the goals Sprint Backlog: The portion of the Product Backlog the team selected for completion during the Sprint Tasks: Breakdown of items to complete to finish a sprint backlog item
- Note absence of traditional roles like programmer, tester, architect, etc. Leads to discussion of Scrum team in next slide.
- Like XP, Scrum uses cross-functional teams whose members have various strengths. All contribute. Like XP, requires a small team to enhance communication Inside sprint, team decides who will do which tasks, not dictated from management Important point: During a sprint, the team has full authority to make any decision to meet sprint goal (within org conventions and budget) Also have responsibility to meet the goal they have set for themselves. Scrum doesn't dictate engineering processes that team must use, could do XP, RUP, whatever as long as produce results. Use metascrums or “scrum of scrums” approach to scaling. Diagram shows 243 people in a number of scrum teams This approach has be scaled to over 800 people by Jeff Sutherland.
- Really two separate meetings... First between team and product owner (and other observers): Product owner presents high priority items from product backlog With input from all, the team selects the backlog it can do in next sprint Identify a “sprint goal”: a short theme for the sprint (like XP's metaphor) Team publicly commits to completing backlog in coming sprint Second just the team and scrum master (product owner can observe): As a whole the team creates a Sprint Backlog of tasks based on the Product Backlog items committed to. Tasks should 4-16 hours of “ideal work” to accomplish (estimates) Team self-organizes to assign the tasks to each other Can modify sprint backlog throughout the sprint
- Why daily? Brooks: “How does a project get to be a year late? A day at a time.” Short (~15 minute) meeting held each morning at same time (stand-up?) Only “pigs” can speak or ask questions, “chickens” just observe - Joke: A chicken asks pig to start a restaurant called “Ham 'n Eggs”. Pig says “No thanks. I'd be commited, but you'd only be involved!” Decisions: team has full authority to make any decision required to convert product backlog into product increment. Any items requiring further discussion should fork off follow-up meetings of just those involved. Scrum master plays role of meeting facilitator Create peer pressure to accomplish what you commit to...
- Main project metric is hours remaining to complete in a sprint. This provides a good measure of team progress. If team finds itself overloaded in a sprint, it can call a meeting with the Product Owner to reduce that amount or scope of product backlog selected (like XP's snow-plowing) A sprint can be abnormally terminated: Management can decide sprint goal is no longer necessary Team can cancel sprint if they face major roadblock or sustained outside pressure to modify sprint goal from external sources
- A Sprint Review Meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the Sprint.
- Empirical process control: better suited to complexities inherent in software development (more agile than CMM for example) Team controls their destiny: team sinks or swims together, have full authority and responsiblity -> allows good teams to be very productive Socialization and knowledge transfer: team develops strong ties, open environment and scrum meeting lead to good knowledge transfer, pecking order in team changes minute to minute based on knowledge/expertise Risk management: reduces risks of poor estimation, low customer satisfaction, not meeting commitments, not resolving issues, contanstly changing requirements Management: requires management sponsorship and buy-in Result varies between teams -> assumes you have good people who can work more productively (always hire the best you can get)
- XP and Scrum are complementary: XP is an engineering methodology (propeller heads) Scrum is a project management methodology (PHBs) XP@Scrum Ken Schwaber Applied by TransCanada Pipelines on their development projects - 300 people working on three large projects Scrum manages project while XP ensures high quality XBreed Mike Beedle Evolved from supporting multiple projects which resused components Can bridge gap caused by splitting up XP teams?
- Alistair Cockburn Hired as a consultant to IBM in '90s to determine best methodology: - found successful teams apologizing for not following the process - found failed teams thinking they didn't apply process correctly Devised a family of Agile Methodologies for different projects Reliance on people, communication, and frequent delivery of running code. The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.
- Does more in the way of documentation (particularly UML) as done by Peter Coad of TogetherSoft.
- Three non-linear, overlapping phases in ASD. Highsmith views planning as a paradox in an adaptive environment. (Draws heavily from chaos theory for his work)
- Calgary is hot-bed of Agile development right now both in industry and at the U of C. Next presentation: November 21 (6 -7 pm ) Agile Methods and Design: is software a big enough town for both of them? Martin Fowler (ThoughtWorks guru)
- Tracks: User stories Iterations Project velocity Developer tasks