Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Path to agility
Ähnlich wie Path to agility (20)
Path to agility
- 1. Solutions v.Next and Team Foundation Server KaleidaCare Development Team
- 2. Why? • Give Dev team ability to provide working software releases quickly • Increase accuracy and stability of schedule • Increase communication between Dev and rest of company • Less time spent creating and updating documentation
- 3. Team Roles • Kelly – Product Owner • Matt – Scrum Master • Woo – Team Member • Jeremy – Team Member • BJ – Team Member • Mary Ellen – Team Member • Lisa – Team Member
- 4. Overall Idea
- 5. Definition of Done What does it mean for something to be “complete”? 1. Code written per company standards and integrated 2. User story is accurately told 3. QA has written automated tests and the tests pass
- 6. User Story A requirement written from a users’ perspective
- 7. User Story As a <user> I want to <do something> so that <I get value>
- 8. Examples for the Client File • As an auditor I want to see all records created for a particular client so I can see their care history. • As a caseworker I want to see all records but be able to go straight to a particular record so I can make changes.
- 9. User Story • Wireframes • Acceptance tests • Other details including – Notes – Even entire documents – Priority
- 10. Epics
- 11. User stories can be further broken into tasks Epic User story User story Task Task Task Task Task Task
- 12. Example Tasks • Create table MY_SEARCH_TABLE • Create search page KaleidaCare.Web.UI/NewFeature/Search.aspx and add fields • Create class and write Search() method
- 13. Product Backlog
- 16. Sprints • Fixed 2 week time period, no matter what • Starts with a sprint planning meeting
- 18. Sprint Begins Daily standup meeting • What tasks/stories since yesterday? • What tasks/stories are you working on today? • Is anything holding up your work? – IT/Office issues – Code issues – Technical questions – Anything else blocking progress
- 19. Daily Standup • Short questions pertinent to team can be asked in Daily Standup • Longer questions should be held for after • Work with Kelly to ask questions
- 20. TFS: Task Board
- 21. Burndown Chart
- 22. Sprint Demo • Company wide meeting • One Hour • Optional, but team members should go
- 23. Retrospective • Immediately follows demo • Team members only • Identify areas for improvement for next sprint
- 24. Meeting Summary M T W Th F Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup Sprint Planning Sprint Begins Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup (code freeze @ (stability Retrospective midnight) changes only) Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup Sprint Planning Sprint Begins Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup (code freeze @ (stability Sprint demo midnight) changes only) Retrospective
- 25. Key Concepts • Requirements broken into smaller pieces called user stories • Definition of Done – testing happens in tandem with development • Anything not “Done” at end of sprint is worth 0 points and returned to product backlog
- 26. Build Schedule Changes dev7.kaleidacare.com qa7.kaleidacare.com solutions7.kaleidacare.com • Build every night • Build weekly for • Build manually triggered • Runs coded UI tests maximum consistency • Developer check-ins • Used as an integration no longer pushed to and staging area, not dev7 website for QA testing • Instead, gated check-ins perform code analysis and other sanity checks
- 27. Questions?
Hinweis der Redaktion
- It is actually not too dissimilar from what we’re already doing.But with a few key changesThe terminology has changed so it may seem like a lot, but actually it’s not too far from what we’re already doing.
- I want to spend a minute explaining why we’re doing thisGive Dev team ability to provide working software releases quicklyIncrease accuracy and stability of scheduleIncrease communication between Dev and rest of companyLess time spent creating and updating documentationFor example,Lisa, this means you won’t need to go back and update Requirement Documents anymore!
- Kelly is the product owner. It means she chooses what we work on (but not how we do it).She will continue to work as the business intelligence expert for stored procedures and so forth.I am the Scrum Master. I facilitate the process and remove impediments.I will continue to work as the system architect.Most important - Everyone here is a team member.We’ll talk more about this later on.
- I hesitated whether to include this diagram or notThe overall idea of being more agile is to do less AT A TIMEIt doesn’t mean we do less planning, it just means we do less planning UP FRONTIn order to help break work into small pieces, we break requirements into small pieces
- Moving forward we’ll need to define what it means for something to be “complete”The definition we have proposed is that “done” means these 3 thingsYou will notice that an item is not “complete” until QA has tested and approved it As you’ll see, this means we have to break up requirements into smaller pieces of individual funtionalityYou turn some code in to QA as soon as you’re done and ideally they will test it the next day or twoIssues reported back to the developer very quicklyAnything that doesn’t have an automated test that passes is considered “not done” and is returned to the Product Backlog
- User stories are the foundation of ScrumA requirement written from a users’ perspectiveShort and sweet – just one sentence but can have wireframes, acceptance tests, and additional details attached to it
- This is a good template for thinking of user storiesThe key is that a user story is written in terms of a feature that matters to a user.This mostly affects Kelly
- Here are some examples.All you need to get from this is that user stories are short, concise statements from a user perspective, HOWEVER…
- They also have wireframes, acceptance tests, and other details attached to them
- User stories can be group together into what’s called an “epic”In this example “Client File” would be the epicTogether these form the hierarchy of requirements
- User stories can be further broken up into tasks“Tasks” are specific units of work that can be implemented
- Here are some example tasksThey are very specific
- User stories get placed on a Product BacklogKind of like our “After First Release” box in BackOfficeList of all work for a project prioritized as 1, 2, 3, 4 not 50 high priority itemsA backlog item is not a contract – just a promise for further communicationJust because something is on the backlog does not mean we are committing to itSome of the work may get done now, some may never get done
- Here is what the product backlog looks like in TFSCan see User Stories expanded into specific Tasks
- Once there are enough backlog items, it’s time to start planning a sprintFirst we estimate the effort of each story as a teamWe do this using Planning PokerAfter estimating the items on top of the backlog we can begin planning for this sprint
- We have previous used the term, but not correctlyA sprint is a fixed 2 week time period, no matter whatAnything we don’t complete gets returned to the Product BacklogStarts with a Sprint Planning Meeting
- If we go back to our product backlog choose the items that we agree to commit to do in the upcoming sprintWhatever we pick, we are now making a commitment that we will finish these items within that 2 week sprintWe move those items into a new backlog called Sprint BacklogRoughly similar to the current Dev Box, although nobody but the team can add items to itAfter choosing what we agree to take on, the sprint begins
- Our daily standup meeting remains unchangedWe focus on these three questions
- The “Task Board” contains all user stories for this sprint and the progress of each oneEach team member updates the progress on their stories within TFS every day before Daily Standup
- As we go through the sprint, we will see the amount of work left steadily decreasingIf there are problems that slow progress, we can work with Kelly to remove stories from the sprint backlogIf things go really well, we can add additional storiesRemember the sprint time is fixed at 2 weeks no matter whatAnything not completed gets returned to the Product BacklogRemember “Definition of Done”
- At the end of every sprint we gather the whole company together to show them what we’ve doneEach developer demonstrates his work to the groupAt this point the work is done and we’re just showing it offThe group may give feedback, which Kelly can record and later add to the backlog if she chooses to
- Immediately following the Sprint Demo we’ll do a team-only retrospective where we can discuss what went well, and what we can improve.The idea is we’re constantly improving the process.
- In order to accommodate this new process I think we’ll need to update our build schedule