Scrum Introduction


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • searches millions of jobs from thousands of job sites.This job trends graph shows the percentage of jobs we find that contain your search terms.RUP - Rational Unified ProcessCapability Maturity Model (CMM) and CMMICMM is being replaced by CMMI == Capability Maturity Model Integration
  • SCRUM方法論的用語很多是套用英式橄欖球術語,如果對橄欖球規則稍有涉獵,應該就有助於SCRUM的了解;SCRUM是指雙方爭球,如下圖,暗喻團隊合作的精神。Agile的一個分支ScrumXPKanbanLean software developmentI think we should run as a startup, using Kanban
  • PO is PMThe Product Owner writes (or has the team write) customer-centric items (typically user stories), prioritizes them, and adds them to the product backlogScrum is facilitated by a ScrumMaster, who ensures that the Scrum process is used as intended.
  • A very simple DoD might include the following:Code CompleteUnit Test completeFunctional / UI Test CompleteApproved by Product Owner
  • Sprint 0
  • 不是幹譙大會,不討論誰做錯
  • Gourmet 美食
  • Scrum Introduction

    1. 1. Agenda  What is Scrum  Dive into User Story
    2. 2. Job Trends
    3. 3. What is Scrum
    4. 4. What is Scrum Scrum is an agile process that allows self organizing teams to focus on delivering the highest business value in the shortest time.
    5. 5. Scrum Process
    6. 6. Scrum Lifecycle
    7. 7. Scrum Roles  Stakeholder  The stakeholders are the customers, vendors.  They are only directly involved in the process during the sprint reviews.  Product Owner  Creates and prioritizes the product backlog  Understands the customer’s needs and the business value  Scrum Master  Organizes the process  Keeps track of the teams progress  Removes obstacles from the path of the team  Scrum Team Member  Organizes itself to perform the work and deliver business value
    8. 8. As a QA in Scrum  Building Test Cases  Participate In Estimating Stories  Help Keep Vision And Goals Visible  Collaborate With Customers And Developers  Provide Fast Feedback  Automate Regression Testing  Participate In Release Readiness/Demos  Enforce the Definition of Done
    9. 9. As a QA in Scrum  QA tasks are included on every sprint, and your sprint is not successully completed unless all QA tasks for that sprint are completed or  QA always runs a sprint behind development, in which case QA's testing tasks for sprint 1 are done while devs work on sprint 2.
    10. 10. Product Backlog  Used to determine the work for the next sprint  A prioritized list of everything needed or wanted for the entire product  Often written in the form of user stories  Have estimates associated with them (often Story Points)
    11. 11. Product Backlog Phase  The Product Owner compiles the requirements  The requirements is broken down into segments  Each segment should be part-deliverable and add business value to the product  The Product Owner personally creates a prioritized list  The list reflect the order in which the items should be delivered. This order can change over time.
    12. 12. What is a Sprint  Scrum projects make progress in a series of sprints  Target duration is pre-decided. Scrum suggests 2 weeks to one month.  Scope does not change within a sprint.  In the beginning of each Sprint, the Product Owner freezes the foremost items on the list and summons the Scrum Team to a meeting
    13. 13. Sprint Backlog  List of tasks that are to be completed in a sprint  The tasks are created by breaking down the stories during the planning meeting  Have estimates (often in hours) associated with them
    14. 14. Sprint Backlog Phase  The first day of the Sprint is reserved to create a Sprint Backlog  Created from the frozen items of the Product Backlog  When the tasks and required time has been determined, the Product Owner lets go.  As of now the Scrum Team works under its own responsibility in a time box
    15. 15. Daily Scrum  Every day at the same time  Everyone stands - it helps keeping the meeting short  Anyone can attend, but only the team may speak  Each participant should answers 3 questions  What have you done since yesterday?  What will you do today?  Is there anything preventing you from doing what you have planned?
    16. 16. Agile Board in Jira
    17. 17. Burndown Chart
    18. 18. Demo and Evaluation  The Sprint ends with a demonstration during which functioning software is run before a larger group  Consisting of, besides the Product Owner, users and representatives from management as an example.  This is the basis for an Evaluation Meeting that in turn is the starting block for the next Sprint
    19. 19. Retrospective  All team members reflect on the past sprint  Make continuous process improvements  Two main questions are asked in the sprint retrospective  What went well during the sprint?  What could be improved in the next sprint?  Two-hour time limit  This meeting is facilitated by the ScrumMaster
    20. 20. Myths about Scrum  Scrum means no documentation  Scrum means no plan  Scrum is easy  Scrum is a silver bullet solution to solve any problem  Scrum is only for team players  Scrum doesn't need up front design  We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
    21. 21. Dive into User Story
    22. 22. User Story  As a role  I want something  [so that I get a benefit]  As a User  I want to login  so that I can access personal data on the website
    23. 23. More Examples  As a student, I can find my grades online so that I don’t have to wait until the next day to know whether I passed.  As a book shopper, I can read reviews of a selected book so that I can decide whether to buy it.  As a user, I want to search for my customers by their first and last names.
    24. 24. Good User Stories  Focus on the user  Keep your stories visible  Use stories to facilitate a conversation with the team and with the users  Keep your stories simple  Progressively decompose your stories  Don’t forget the acceptance criteria  Consider grouping user stories into themes
    25. 25. Well-formed User Stories  I – Independent  N – Negotiable  V – Valuable  E – Estimable  S – Small  T – Testable
    26. 26. Counterexamples  As Product Owner, I want a list of highly- rated restaurants on the website.  Drawbacks: It’s not only about you!  Better: Focus on your end users and stakeholders. “As a gourmet tourist, I want a list of highly-rated restaurants on the website.”
    27. 27. Counterexamples  Write game rules.  Drawbacks: not independent, no business value, not small.  Better: “As a newbie game player, I want to know who goes first so we can start the game.”
    28. 28. Non-functional Requirements  Reliability  Availability  Portability  Scalability  Usability  Maintainability  Security  Performance  Robustness
    29. 29. Non-functional Requirements Think of non-functional requirements as constraints  As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.  As a user, I want the site to be available 99.999% of the time I try to access it so that I don't get frustrated and find another site to use.  As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don't have one more database to maintain.
    30. 30. Reference  Use cases - User Stories: so precious but not the same !  Non-functional Requirements as User Stories
    31. 31. Questions?