Your SlideShare is downloading. ×
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Agile Development Process & Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Development Process & Scrum

777

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
777
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. AGILE DEVELOPMENT PROCESS + SCRUMAugust 2010 Otavio Ferreira (@otaviofff)
  • 2. Let’s meet up!2
  • 3. Agenda3  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  • 4. Principles4  Iterative  Incremental  Self-management
  • 5. Agenda5  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  • 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. 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. 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. 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. Agenda10  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  • 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. 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. 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. 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. 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. 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. Agenda17  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  • 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. 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. 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. 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. 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. Artifacts23  User Story (continued)  Structure – 3Cs  Card  Conversation  Confirmation  Writing – INVEST  Independent  Negotiable  Valuable  Estimable  Small, or Sized Appropriately  Testable
  • 24. Artifacts24  Task  Part of a Story  One step towards the achievement  Lower abstraction level  Writing – SMART  Specific  Measurable  Achievable  Relevant  Time-boxed
  • 25. Artifacts25  Taskboard  Keeps track of progress. Enhanced visibility  Supports the Daily Scrum Sprint Backlog In Progress Done
  • 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. 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. 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. Artifacts29 Source: Wikipedia / http://en.wikipedia.org/wiki/File:SampleBurndownChart.png
  • 30. Agenda30  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  • 31. Timeline31 Source: Wikipedia / http://en.wikipedia.org/wiki/File:Scrum_Process.svg
  • 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. Agenda33  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto
  • 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. 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. 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. 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. 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. 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. Agenda40  Principles  Roles  Rituals  Artifacts  Timeline  Manifesto Icons by David Lanham / http://dlanham.com/

×