Implementing Scrum with Microsoft Team Foundation Service (TFS)
Download as PPTX, PDF6 likes3,130 views
The document outlines a two-day training on implementing Scrum using Microsoft Team Foundation Service (TFS), covering topics such as TFS overview, sprint planning, daily standups, build management, QA testing, and sprint retrospectives. It details the agendas for both days, emphasizing teamwork, the role of the scrum master, and the technical aspects of using TFS for developers. The training aims to enhance efficiency in Scrum processes through collaboration, reporting, and project management tools.
Implementing Scrum with Microsoft Team Foundation Service (TFS)
- 1. Day II Implementing Scrum with Microsoft Team Foundation Service (TFS)
- 2. Day I Review 2Aspenware: Scrum with TFS – Day II
- 3. Day I Topics • TFS Overview • TFS Version Comparison and Installation • Setting Up Your Code in TFS Source Control • Setting Up Your Code in Git Source Control • Scrum Overview • Sprint 0 Activities • Sprint Planning Exercise • Summary and Wrap Up 3Aspenware: Scrum with TFS – Day II
- 4. What is Team Foundation Service?
- 5. Executing Scrum Projects 5 Sprint Planning Sprint Review Scrum Update the Task Code Check-in Product Vision Product Backlog Sprint Backlog 2 – 4 weeks 24 hours Sprint Retrospective Test Potentially Shippable* Product Backlog Grooming “Sprint 0” Aspenware: Scrum with TFS – Day II
- 6. Day II Agenda • Daily Standup and Reporting • TFS for Developers • Merging • Build Management • End of Sprint Demo • QA Testing with TFS • End of Sprint Retrospective • Summary and Wrap Up 6Aspenware: Scrum with TFS – Day II
- 7. Daily Standups and Reporting 7Aspenware: Scrum with TFS – Day II
- 8. Ken Payne k.payne@aspenware.com || Delivery Director || 303.590.4390 Ken gets inspiration and energy by working alongside smart, creative people solving tough business problems and wowing clients. He believes great solutions evolve through focused collaboration and strongly supports the notion that "innovation is a team sport."
- 9. The Daily Scrum Aspenware: Scrum with TFS – Day II 9 What did I accomplish yesterday? What will I accomplish today? What is blocking me?
- 10. Keep it consistent, crisp, and quick Aspenware: Scrum with TFS – Day II 10 • Schedule a consistent location, preferably where the Task Board is visible • Start the Scrum at the designated time whether the entire team is present • Keep the Scrum to 15 minutes If you have to, interrupt an update and suggest that problem solving or technical discussions take place right after the Scrum or take a note to schedule a meeting
- 11. It’s not about you, Scrum Master Aspenware: Scrum with TFS – Day II 11 Create an environment that promotes the idea that the daily scrum is for the benefit of the team and not a status update for the Scrum Master • The Scrum Master should not question team member updates, except to clarify understanding • The Scrum Master should minimize direct eye contact with the team member giving an update • Let the team member who last spoke choose the next person to speak
- 12. It’s all about story throughput Aspenware: Scrum with TFS – Day II 12 • Ask team members to emphasize accomplishments not only what they are "working on” It is difficult to be aware of progress without describing what is being completed • Guide team members to speak to the tasks on the Task Board when describing accomplishments If a team member is giving an update for work that is not in the Sprint Plan, coach the team member (after the Scrum) to create a task
- 13. The Burn Down Aspenware: Scrum with TFS – Day II 13 Did not adjust Discovered new tasks Adjustment s made Did not update tasks until here Adjustment s made Too many stories, remove some!
- 14. Sally Tait s.tait@aspenware.com || Senior Consultant || 303.798.5458 Sally is a problem solver and information collector. From optimizing the way her kitchen is organized to modeling complex business processes, she is compelled to design systems that simplify getting things done.
- 15. Demo Team Explorer for PMs • Work Items • Excel and Project Round Trips • Queries 15Aspenware: Scrum with TFS – Day II
- 16. Break 16Aspenware: Scrum with TFS – Day II
- 17. TFS for Developers 17Aspenware: Scrum with TFS – Day II
- 18. Ely Lucas e.lucas@aspenware.com || Senior Software Developer Ely is a software developer by day and ninja by night. He has over 10 years experience delivering cutting edge solutions and sneaking around unnoticed. He enjoys sharing his knowledge with others, technology, being outdoors and levitating objects with his mind. He lives in Denver with his wife, son and dog.
- 19. Unit Testing 19
- 20. TFS for Developers Demo 20Aspenware: Scrum with TFS – Day II • Attaching Work to Tasks • Shelving • Spending and Resuming Work • Code Reviews
- 21. Ben Hoelting In truth, he’s just a big kid. He loves designing systems that solve real world problems. There is nothing more satisfying than seeing something you helped develop being used by the end users. Ben is also involved in the technology community and runs the South Colorado .NET user group. He also enjoys speaking at tech groups and events around the country. Ben Hoelting @benhnet b.hoelting@aspenware.com
- 22. Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) so that modifications can happen in parallel along both branches http://en.wikipedia.org/wiki/Branching_(software) Aspenware: Scrum with TFS – Day II 22
- 23. Aspenware: Scrum with TFS – Day II 23 Merging (also called integration) in revision control, is a fundamental operation that reconciles multiple changes made to a revision-controlled collection of files. Most often, it is necessary when a file is modified by two people on two different computers at the same time. When two branches are merged, the result is a single collection of files that contains both sets of changes. http://en.wikipedia.org/wiki/Merge_(revision_control)
- 24. Forward Integration (FI) & Reverse Integration (RI) DEVELOPMENT MAIN Branch Reverse Forward Aspenware: Scrum with TFS – Day II 24
- 25. DEVELOPMENT MAIN Branch RELEASE Branch Development Production / Release Basic Branching and Merging Aspenware: Scrum with TFS – Day II 25
- 26. DEVELOPMENT MAIN Branch SERVICE PACK RELEASE Branch Branch Development Production / Release Standard Branching and Merging Aspenware: Scrum with TFS – Day II 26
- 27. General Guidance Keep branching to a minimum. Merge (FI) from parent to child frequently. Ideally do not let a branch get more than 1- 2 days out of sync with the parent. Merge (RI) frequently from child to parent based on build and automated test results. Lock the Release branch at RTM Aspenware: Scrum with TFS – Day II 27
- 28. View History Aspenware: Scrum with TFS – Day II 28
- 29. TFS for Developers Demo 29Aspenware: Scrum with TFS – Day II • Merging Branches in TFS • Merging Branches in Git
- 30. Waughn HughesA native of DC, Waughn moved to Colorado ten years ago for a brief change of scenery, trading his soccer cleats for parabolic skis. Passionate about creating quality solutions, he joined Aspenware after years of business travel and is thrilled to be close to home, surrounded by people who take pride in their work. w.hughes@aspenware.com || Senior SharePoint Architect
- 31. “It works on my machine!” Aspenware: Scrum with TFS – Day II 31
- 32. TFS: Build Management & Automation • Continuous integration, including integrated unit testing • Continuous deployment to Azure Aspenware: Scrum with TFS – Day II 32
- 33. Build Definition • Triggers • Source Settings • Build Defaults • Process • Retention Policy Aspenware: Scrum with TFS – Day II 33
- 34. Hosted Build Controller • Easy (no infrastructure) • Supports testing (multiple frameworks) • Supports 3rd party binaries (in version control or via NuGet) • Software & completion restrictions • Continuous deployment to Azure, automatically Aspenware: Scrum with TFS – Day II 34
- 35. Deployment to Azure Demo Aspenware: Scrum with TFS – Day II 35
- 36. End of Sprint Demo 36Aspenware: Scrum with TFS – Day II
- 37. Break 37Aspenware: Scrum with TFS – Day II
- 38. Testing with TFS 2012 and Microsoft Test Manager v11 (MTM) 38Aspenware: Scrum with TFS – Day II
- 39. Michael Webster m.webster@aspenware.com || Senior Consultant || 303.798.5458 Michael loves the challenge, dynamic environment and the people at Aspenware. He also loves the learning curve. Always something new.
- 40. Environment Review Aspenware: Scrum with TFS – Day II 40
- 41. Data & Diagnostics Aspenware: Scrum with TFS – Day II Team project Test plan Test suite Test case Test case attributes 41
- 42. Creating Test Cases Demo 42Aspenware: Scrum with TFS – Day II • Test Plan • Test Suite • Test Cases
- 43. Running Tests Demo 43Aspenware: Scrum with TFS – Day II • Using TFS to run tests • Using MTM to run tests • MTM Test Walkthrough • Data Review
- 44. Exploratory Testing Demo 44Aspenware: Scrum with TFS – Day II • Walking through ad hoc testing process • Finding bugs and creating new work items
- 45. Wrap Up 45Aspenware: Scrum with TFS – Day II Key Features TFS and MTM testing tools Test plan hierarchy Testing using test cases Exploratory testing Data and diagnostic tools Integrated TFS items
- 46. Break 46Aspenware: Scrum with TFS – Day II
- 47. End of Sprint Retrospective 47Aspenware: Scrum with TFS – Day II
- 48. The Sprint Retrospective Agile Retrospective Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. Aspenware: Scrum with TFS – Day II 48
- 49. The Sprint Retrospective Process: • Review the Sprint goal • Review the Sprint results • Discuss what went well, what didn’t go so well, and what can be done better • Decide on just a few improvement ideas to implement next sprint • Review the Product Backlog Cumulative Flow Diagram Aspenware: Scrum with TFS – Day II 49
- 50. Summary and Wrap Up • What we talked about • Daily Standup and Reporting • TFS for Developers • Build Management and Merging • End of Sprint Demo • QA Testing with TFS • End of Sprint Retrospective • Review items in the Parking Lot • Visit http://www.aspenware.com/blog for the slides and any additional resources 50Aspenware: Scrum with TFS – Day II
Editor's Notes
- #23: Agree on definition of branching.
- #24: Agree on definition of branching.
- #25: It’s important that we get some basic terms down before we go any further. AS you can see here the MAIN branch contains completed functionality that has passed integration tests, and the DEVELOPMENT branch contains the code that is under construction. We initially BRANCH from MAIN to DEVELOPMENT in order to get a base set of code established between the two.When a new functionality in the DEVELOPMENT branch is completed and can pass integration tests, you can promote the code from the DEVELOPMENT branch to the MAIN branch. This process is referred to as REVERSE INTEGRATION. Conversely, if you merge the code from the MAIN branch to the DEVELOPMENT branch, the process is referred to as FORWARD INTEGRATION.
- #26: The Basic branch plan will work well for your organization if you meet some of the following criteria: You have a single major release that is shipped (i.e. a single release vehicle) to customers. 2. Your servicing model is to have customers upgrade to the next major release. 3. Any fixes shipped from the release branch will include all previous fixes from that branch.
- #27: As you add additional release vehicles you may need to create additional branches in the production/release area to enable concurrent development. The Standard branch plan introduces a new release branch to support an additional release vehicle. Most organizations will call this a servicing branch to enable development of Hotfixes and Service packs. This plan will work well for your organization if you meet some of following criteria: 1. You have multiple ship vehicles (e.g. major release and additional service packs for that release). 2. You want to enable concurrent development of service pack and next version products. 3. You have any compliance requirements that require you to have an accurate snapshot of your sources at release time. All of the guidance any key points from the Basic plan applies to the Standard plan. The Standard plan has these additional items to consider. RELEASE branches for release safekeeping and Service Pack work 1. RELEASE tree (i.e. SP and RELEASE) are branched from MAIN at the same time to create MAINSPRELEASE parent/child relationship. 2. Product releases from the RELEASE branch and then that branch is changed to read only. 3. Servicing changes are checked into the Service Pack (SP) branch. 4. Changes SP branches merge one-way to MAIN (SPMAIN). 5. Ship stopping bug fixes checked into the release branch should merge back to MAIN through the SP branch (RELEASE to SP to MAIN). 6. Duplicate RELEASE tree plan for subsequent major releases.
- #28: most days an FI won’t have any changes from day to day. These are, therefore, the easiest merges you’ll ever do, but they are a good habit to get into. This is really no different than the best practices around getting latest!
- #29: TFS, since 2010, introduced an improved View History feature. It is now possible to view change history across branches. For example, when you right-click on a team project, you can view all changesets that were checked into any branch within the Team Project. Similarly, when you view history for a specific file, you can see change history associated with that file across all branches that file has been checked-into. From the Change History view, you can select a single changeset and visualize changes for that changeset. This view will show which branches contain a given changeset. The timeline view will show, over time, how the changeset has been moved (as a result of branching and merging activity from one branch to another.
- #31: Forgot to check in dependencyForgot to add a file to source controlForgot to check something inWrong version of DLLService Pack
- #32: Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. CompilesPackages TestsDeploysSteps:Gets latest…Label the code in version control…Compile the code…Runs tests…Copies the binaries to a “drop” directory
- #33: Hosted Build Controller RestrictionsThe software already on hosted build serverCode in version control already mappedNon-compiled binaries are in version control or retrieved via NuGetAlready configured custom build activities or unit test frameworksCompletes in less than 1 hourUses no more than one gigabyte of total storage on the build server
- #34: CompilesPackages TestsDeploysSteps:Gets latest…Label the code in version control…Compile the code…Runs tests…Copies the binaries to a “drop” directory