Introduction To Agile And Scrum
•
63 gostaram•1,661 visualizações
Introduction to Agile development with Scrum
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (17)
Semelhante a Introduction To Agile And Scrum
Semelhante a Introduction To Agile And Scrum (20)
Mais de Robert Dempsey
Mais de Robert Dempsey (20)
Último
Último (20)
Introduction To Agile And Scrum
- 1. Hello
- 5. scrumd.com
- 6. rdempsey
- 7. Introduction to Agile and Scrum
- 9. Requirements
- 10. Requirements Design
- 11. Requirements Design Implement
- 12. Requirements Design Implement Verify
- 13. Requirements Design Implement Verify Maintain
- 14. Requirements Design Implement Verify Maintain
- 26. ScrumMaster
- 27. Product Owner
- 28. The Team
- 32. 24H 2W
- 33. 24H 2W
- 34. 24H 2W
- 35. 24H 2W
- 36. 24H 2W
- 38. As a role I want something so that I get a benefit
- 39. As a User I want to log in so that I can use the site
- 42. 2 Weeks
- 43. Part 1: What
- 44. Part 2: How
- 45. User Story User Story User Story
- 46. Task User Story Task Task User Story User Story
- 47. Task User Story Task Task Task User Story Task Task User Story
- 48. Task User Story Task Task Task User Story Task Task Task User Story Task
- 50. 24 Hours 2 Weeks
- 51. 24 Hours 2 Weeks
- 60. 24H 2W
- 61. 24H 2W
- 62. 24H 2W
- 63. 24H 2W
- 64. 24H 2W
- 66. 82%
- 68. 77%
- 70. 78%
- 72. 37%
- 73. Decreased costs
- 77. Increased productivity Increased quality Increased satisfaction
- 78. Increased productivity Increased quality Increased satisfaction Decreased costs
- 81. Letʼs Chat
Notas do Editor
- My name is Robert Dempsey
- I’m the CEO of ADS, a web development shop in Orlando
- Simple project management for agile teams
- Find me on Twitter
- The Old Way Requirements -> Design -> Implement -> Verify -> Maintain Waterfall
- The Old Way Requirements -> Design -> Implement -> Verify -> Maintain Waterfall
- The Old Way Requirements -> Design -> Implement -> Verify -> Maintain Waterfall
- The Old Way Requirements -> Design -> Implement -> Verify -> Maintain Waterfall
- The Old Way Requirements -> Design -> Implement -> Verify -> Maintain Waterfall
- The Old Way Requirements -> Design -> Implement -> Verify -> Maintain Waterfall
- Pros Find bugs early in the process Correct requirements now, less problems later (in theory) Emphasis on documentation - developers hate doing this Simple and disciplined Good for stable projects
- Cons Each step is not mutually exclusive Developers are usually (not) clairvoyant Documentation overhead Rigid and inflexible Stable project?!
- Reality Development phases overlap Software is emergent - the farther along we go the more we know “Done” is a moving target Flexibility is required - business requirements and the environment changes Collaboration is essential
- Lays out the philosophy for agile development Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- Agile Myths Lack of discipline - “self-managing” = do whatever you want, when you want Lack of visibility “That won’t work here”
- What is Agile? Group of philosophies and practices that provides the ablility to handle changing requirements Iterative development A lot of collaboration between business and developer Have self-organizing and self-managing teams Stressing leadership over management Utilizing these and a set of practices, a team gains the ability to continuously adapt.
- Agile Methods Extreme Programming (XP) Test Driven Development (TDD) Feature Driven Development (FDD) Behavior Driven Development (BDD) Scrum
- Scrum!
- A framework for developing complex products and systems Grounded in empirical process control theory Transparency Inspection Adaptation Three inspect and adapt points Sprint Review and Planning meetings Daily Scrum The Retrospective
- The Scrum Team Product Owner ScrumMaster The Team Called pigs: they have their bacon on the line
- Involved, but aren’t committed Users, stakeholders (customers, vendors), managers, and business units
- The driving force behind the process Helps the team and organization adopt and use Scrum A leader, not a manager Roles they play: coach, teacher, and supporter
- Manages and controls the product backlog Responsible for the value of the work done Keeps the product backlog in priority order, visible to everyone A single person, not a committee Must have authority, and the respect of others to succeed Single point of contact for the team
- The ones turning product backlog items into increments of potentially shippable functionality Cross-functional: everyone that needs to be on the team to make the stories happen Self-organized: everyone contributes No job descriptions, no titles, no exceptions Sink or swim as a team Optimal team size: 7, +- 2 Team composition may change at the end of a sprint; be careful in doing so
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Product Backlog Managed by the Product Owner Evolves along with the product and the environment Master list of all functionality desired in the product Includes all features, functions, technologies, enhancements, and bug fixes Requirements are typically written in user story format
- User Stories How we write our requirements From the user perspective
- User Stories
- Product Backlog Sorted in order of priority Requirements never stop changing Minimize work: add fine-grained detail to the highest priority items (for the next few sprints)
- Release Planning Purpose: establish a plan and goals that everyone can understand and communicate Establishes The goals of the release The highest priority Product Backlog items The major risks Overall features and functionality that the release will contain Probable delivery date and cost if nothing changes Composed of Sprints that deliver increments of the product, starting with the most valuable and most risky Once enough increments are completed, release! Most planning is done at the beginning of a release
- Sprint Sprint: 1-4 week block of time; all sprints are the same length Protected by the ScrumMaster - no changing once it's started Sprint Planning Meeting When the iteration is planned Max 8 hours for a one-month sprint, or 5% of the total Sprint length Two parts
- Sprint Planning Meeting: Part 1 - What 4 hours The Product Owner and Team mutually determine what functionality will go into the Sprint Considers the Product Backlog, the latest increment, team capacity, and past performance of the team Only the team can say what they can accomplish in the upcoming Sprint Sprint Goal: the purpose statement of the Sprint, the "why"
- Sprint Planning Meeting: Part 2 - How 4 hours Team determines how it will deliver a "done" increment Identification of tasks - where the details are A single task should take no more than one day Sprint backlog - the list of tasks Team self-organizes to assign and do the work Negotiation between the Team and the Product Owner happens here
- Sprint Backlog All of the tasks required to turn Product Backlog items into "done" increments Break each user story down so that changes in progress can be understood in the Daily Scrum Modified during the Sprint as-needed Tasks are added and removed if unnecessary Tasks are estimated in hours, by the Team Only the Team can change the Sprint Backlog during a Sprint Highly-visible and real-time
- Sprint Backlog All of the tasks required to turn Product Backlog items into "done" increments Break each user story down so that changes in progress can be understood in the Daily Scrum Modified during the Sprint as-needed Tasks are added and removed if unnecessary Tasks are estimated in hours, by the Team Only the Team can change the Sprint Backlog during a Sprint Highly-visible and real-time
- Sprint Backlog All of the tasks required to turn Product Backlog items into "done" increments Break each user story down so that changes in progress can be understood in the Daily Scrum Modified during the Sprint as-needed Tasks are added and removed if unnecessary Tasks are estimated in hours, by the Team Only the Team can change the Sprint Backlog during a Sprint Highly-visible and real-time
- Sprint Backlog All of the tasks required to turn Product Backlog items into "done" increments Break each user story down so that changes in progress can be understood in the Daily Scrum Modified during the Sprint as-needed Tasks are added and removed if unnecessary Tasks are estimated in hours, by the Team Only the Team can change the Sprint Backlog during a Sprint Highly-visible and real-time
- Sprint Backlog All of the tasks required to turn Product Backlog items into "done" increments Break each user story down so that changes in progress can be understood in the Daily Scrum Modified during the Sprint as-needed Tasks are added and removed if unnecessary Tasks are estimated in hours, by the Team Only the Team can change the Sprint Backlog during a Sprint Highly-visible and real-time
- Sprint Backlog All of the tasks required to turn Product Backlog items into "done" increments Break each user story down so that changes in progress can be understood in the Daily Scrum Modified during the Sprint as-needed Tasks are added and removed if unnecessary Tasks are estimated in hours, by the Team Only the Team can change the Sprint Backlog during a Sprint Highly-visible and real-time
- Sprint Burndown Graph showing the amount of Sprint Backlog work remaining Variable of interest: work remaining and date
- Daily Scrum 15-minute standup The Team is responsible for having the meeting The ScrumMaster ensures it happens, and that it stays short 3 questions Goals Improve communication Eliminate other meetings Identify and remove impediments Highlight and promote quick decision making Improve everyone's knowledge
- Daily Scrum 15-minute standup The Team is responsible for having the meeting The ScrumMaster ensures it happens, and that it stays short 3 questions Goals Improve communication Eliminate other meetings Identify and remove impediments Highlight and promote quick decision making Improve everyone's knowledge
- Increment Potentially shippable software: the Product Owner may decide to put it into production Bug free, tested, clean code Must work with everything already in place This is where regression testing and continuous integration servers come in
- Sprint Review 4-hour meeting for a one-month Sprint, or 5% of the total length of the sprint The Scrum Team and stakeholders collaborate on what was done Based on the feedback and changes to the Product Backlog during the Sprint, they collaborate about what to do next Informal meeting intended to foster collaboration Product Owner - tells what has/hasn't been done Team - discusses what went well, what problems they ran into, and what they did to resolve them Team - demos what's been done, and answers questions Product Owner - discusses the Product Backlog as it stands Group - collaborates on what to do next
- Release Burndown Graph showing the Product Backlog estimated effort remaining across time Product Backlog estimates are reviewed and revised Keep in mind: the Team is responsible for all estimates
- Sprint Retrospective Held between the Sprint Review and the next Sprint Planning meeting 3 hours max ScrumMaster encourages the Team to revise their development process to become more effective Purpose: inspect how the last Sprint went in regards to people, relationships, processes and tools Identify and prioritize the major items that went well, and those that didn't - discuss how they can be done better Discuss: team composition, meeting arrangements, tools, definition of "done" Result: actionable improvement measures
- Rinse and Repeat The process begins anew
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Scrum Overview Product backlog -> release planning -> sprint (daily scrum) -> increment -> sprint review -> sprint retrospective
- Results of Agile Adoption - Agile Survey (2/08) 642 respondents 82% increased productivity
- Results of Agile Adoption - Agile Survey (2/08) 77% increased quality
- Results of Agile Adoption - Agile Survey (2/08) 78% increased stakeholder satisfaction
- Results of Agile Adoption - Agile Survey (2/08) 37% decreased costs
- Compelling arguments for at least giving it a try
- Compelling arguments for at least giving it a try
- Compelling arguments for at least giving it a try
- Compelling arguments for at least giving it a try
- Additional Information Scrum Lunch and Learn
- Additional Information Agile Development with Scrum