Agile Development Process & Scrum

1,185 views

Published on

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
  • Esta mal la serie de fibonacci.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,185
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
40
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Agile Development Process & Scrum

  1. 1. AGILE DEVELOPMENT PROCESS + SCRUMAugust 2010 Otavio Ferreira (@otaviofff)
  2. 2. Let’s meet up!2
  3. 3. Agenda3  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  4. 4. Principles4  Iterative  Incremental  Self-management
  5. 5. Agenda5  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  6. 6. Roles6 Hey, why dont we open a restaurant? Good idea. What do you want to call it? Why dont we call it Ham and Eggs? I dont think so. Id be committed, but youd only be involved.
  7. 7. Roles7  Product Owner: Owns the Product Backlog  Responsibilities  Manage the Product Backlog  Manage the Release Plan  Manage the Return on Investment  In a nutshell...  The PO represents the interests of everyone with a stake in the project. He is responsible for the final product
  8. 8. Roles8  Scrum Master: Owns the Scrum Process  Responsibilities  Manage the process  Remove impediments  Facilitate communication  In a nutshell...  The SM is responsible for the Scrum process. He ensures everybody plays by the rules. He also removes impediments for the Team
  9. 9. Roles9  Team Member: Owns the Software  Responsibilities  Implement user stories (SQA included)  Deliver functional software increments  Manage themselves  In a nutshell...  The team figures out how to turn the Product Backlog into an increment of functionality within a Sprint. Each team member is jointly responsible for the success of each iteration and of the project as a whole
  10. 10. Agenda10  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  11. 11. Rituals11  Sprint Planning  Part 1: The PO presents the User Stories  Part 2: When the Team thinks they have enough stories to start the Sprint, they begin breaking it down in Tasks to fill the Sprint Backlog Constraints Timebox 4 hours Owner Product Owner Participants Team, Scrum Master
  12. 12. Rituals12  Planning Poker  Part of Sprint Planning (1st half)  Consensus-based technique for estimating the complexity of User Stories  Fibonacci Numbers: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 4.27 cm ---{ 5x }--- 21.35 cm
  13. 13. Rituals13  Daily Scrum  Standup meeting  The Team daily inspects their progress in relation to the Planning by using the Burndown Chart, and makes adjustments as necessary Constraints Timebox 15 minutes Owner Scrum Master Participants Team (Other interested parties may silently attend)
  14. 14. Rituals14  Daily Scrum (continued)  Each member answers the following  What have you done since the last Daily Scrum?  What will you be doing until the next Daily Scrum?  What are your impediments, if any?  Try out these constraints  No verbs in continuous tenses  No finger pointing  The owner is always accountable for the results / status
  15. 15. Rituals15  Sprint Review  At the end of a Sprint, the Team reviews the work finished and unfinished, then presents finished work to stakeholders  Unfinished work cannot be demonstrated Constraints Timebox 2 hours Owner Scrum Master Participants Team, Product Owner
  16. 16. Rituals16  Sprint Retrospective  At the end of a Sprint, the Team evaluates the finished iteration  They capture positive ways as a best practice, identify challenges, and develop strategies for improvements  Focus on the process Constraints Timebox 2 hours Owner Scrum Master Participants Team, Product Owner
  17. 17. Agenda17  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  18. 18. Artifacts18  Product Vision  Makes the overall goal clear and public  Guides the Team, aligns stakeholders  Captures the essence of the product, briefly The minimum plan necessary to start a Scrum project consists of a Product Vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. – Ken Schwaber, 2004
  19. 19. Artifacts19  Product Vision: Questions  Who is going to use the product?  Which user needs will the product address?  Which product attributes are critical to address the customer needs selected?  How does the product compare against existing products?  What is the business model?  What is the target timeframe and budget to develop and launch the product?
  20. 20. Artifacts20  Product Vision: Template  FOR <target customer>  WHO <statement of the need>,  THE <product name> is a <product category>  THAT <product key benefit, compelling reason to buy>  UNLIKE <primary competitive alternative>,  OUR PRODUCT <final statement of primary differentiation> Source: Crossing the Chasm , by Geoffrey Moore, 1999
  21. 21. Artifacts21  Definition of Done  By the end of a Sprint, the software increment must be ready to be released  What does this mean to your organization?  Coded  Reviewed  Tested(functional, unit, load, etc.)  Documented  Deployed onto homologation  What else? What less?
  22. 22. Artifacts22  User Story  Piece of software relevant to end users  A functional requirement that aggregates value to end users  Complexity set according to Fibonacci Numbers  Card format:  As an <actor>,  I want to <action>,  So that <achievement>.
  23. 23. Artifacts23  User Story (continued)  Structure – 3Cs  Card  Conversation  Confirmation  Writing – INVEST  Independent  Negotiable  Valuable  Estimable  Small, or Sized Appropriately  Testable
  24. 24. Artifacts24  Task  Part of a Story  One step towards the achievement  Lower abstraction level  Writing – SMART  Specific  Measurable  Achievable  Relevant  Time-boxed
  25. 25. Artifacts25  Taskboard  Keeps track of progress. Enhanced visibility  Supports the Daily Scrum Sprint Backlog In Progress Done
  26. 26. Artifacts26  Product Backlog  The requirements for the product are listed in the Product Backlog  It is an always changing, dynamically prioritized list of requirements ordered by Business Value  Requirements are broken down into User Stories by the PO
  27. 27. Artifacts27  Sprint Backlog  It contains all the committed User Stories for the current Sprint broken down into Tasks by the Team  All items on the Sprint Backlog should be developed, tested, documented and integrated to fulfill the commitment
  28. 28. Artifacts28  Burndown Chart  It shows the amount of work remaining per Sprint  It is a very useful way of visualizing the correlation between work remaining at any point in time and the progress of the Team  It is useful for predicting when (and whether) all of the work will be completed  Types  Sprint Burndown Chart  Release Burndown Chart
  29. 29. Artifacts29 Source: Wikipedia / http://en.wikipedia.org/wiki/File:SampleBurndownChart.png
  30. 30. Agenda30  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  31. 31. Timeline31 Source: Wikipedia / http://en.wikipedia.org/wiki/File:Scrum_Process.svg
  32. 32. Timeline32  Extreme Scrum  5-day sprints  5-point stories, or less  2-developer teams, up to 4  Outcomes  More accurate story complexity estimation  Almost instant feedback  Quicker focus adjustment  Quicker response to requirements changing  Manageability goes through the roof
  33. 33. Agenda33  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  34. 34. Manifesto34  Values  Individuals and interactions over processes and tools  Working software over comprehensive docs  Customer collaboration over contract negotiation  Responding to change over following a plan – Manifesto for Agile Software Development, 2001
  35. 35. Manifesto35  Principles (1 to 3, out of 12)  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software  Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
  36. 36. Manifesto36  Principles (4 to 6, out of 12)  Business people and developers must work together daily throughout the project  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  37. 37. Manifesto37  Principles (7 to 9, out of 12)  Working software is the primary measure of progress  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely  Continuous attention to technical excellence and good design enhances agility
  38. 38. Manifesto38  Principles (10 to 12, out of 12)  Simplicity – the art of maximizing the amount of work not done – is essential  The best architectures, requirements, and designs emerge from self-organizing teams  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly – Manifesto for Agile Software Development, 2001
  39. 39. Manifesto39  And talking about Simplicity...  There are two ways of constructing a software design  One way is to make it so simple that there are obviously no deficiencies  And the other way is to make it so complicated that there are no obvious deficiencies  The first method is far more difficult – Sir Charles Antony Richard Hoare, 1960 Inventor of the Quicksort algorithm
  40. 40. Agenda40  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto Icons by David Lanham / http://dlanham.com/

×