This training will provide a deep dive into Microsoft Team Foundation Server (TFS) for agile projects from setting up TFS through the end of the first sprint. This is a hands on training, attendees will actively engaged in a sample project using TFS in the cloud. Presenters will include senior Aspenware architects and project managers as well as Steve Lange, Developer Technology Specialist at Microsoft. This training is appropriate for developers, project managers and business analysts. A basic understanding of scrum and agile development is required.
Part 2 Agenda
*Brief review of Part I
*Reporting and tracking features of TFS.
*Setup Continuous Integration and discuss value
*Setup an auto deployment to Azure
*Testing features of TFS and how auto deployments aid that process
*End of Sprint Demo
*End of Sprint Retrospective
*Use TFS to review the tasks and determine velocity on this Sprint
*How to plan subsequent sprints
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
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
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
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.
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
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
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
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.
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
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
Notes de l'éditeur
Agree on definition of branching.
Agree on definition of branching.
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.
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.
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.
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!
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.
Forgot to check in dependencyForgot to add a file to source controlForgot to check something inWrong version of DLLService Pack
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
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
CompilesPackages TestsDeploysSteps:Gets latest…Label the code in version control…Compile the code…Runs tests…Copies the binaries to a “drop” directory