Agile Software Development Methodologies

4,658 views
4,437 views

Published on

Revenge of the Programmers (presentation given to colleagues at Pason Systems, 2002)

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,658
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
250
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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



  • Agile Software Development Methodologies

    1. 1. Agile Software Development Revenge of the Programmers? Guy Davis – Pason Systems 1 10/01/09
    2. 2. Overview Agile Manifesto eXtreme Programming (XP) Scrum XBreed, XP@Scrum, Crystal, dX, FDD, ASD Agile Resources 2 10/01/09
    3. 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. 4. eXtreme Programming (XP) Core Values Project Variables Communication Cost Simplicity Scope Feedback Time Courage Quality 4 10/01/09
    5. 5. Key Practices of XP 5 10/01/09
    6. 6. XP Process 6 10/01/09
    7. 7. XP Iteration 7 10/01/09
    8. 8. XP Development 8 10/01/09
    9. 9. XP Collective Code Ownership 9 10/01/09
    10. 10. XP Planning 10 10/01/09
    11. 11. XP Roles Programmer Customer Tester Tracker Coach Consultant Big Boss 11 10/01/09
    12. 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. 13. Scrum 13 10/01/09
    14. 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. 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. 16. Sprint Planning Meeting 16 10/01/09
    17. 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. 18. Sprint Burndown 18 10/01/09
    19. 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. 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. 21. XP/Scrum Hybrids 21 10/01/09
    22. 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. 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. 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. 25. Adaptive Software Development Short iterations Deliverable-centric instead of task-centric 25 10/01/09
    26. 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. 27. Milos Agile Project Tool 27 10/01/09
    28. 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

    ×