Content from Saturday may 9th on ALM with TFS 2013

1. ALM with TFS 2013
Vincent Grondin
General Manager – Solutions Vet a CDMV subsidiary
C# MVP
.NET Montreal User Group Leader
Blog: http://geekswithblogs.net/vincentgrondin

2. Content
• How to setup your Iterations
• How to setup your Areas
• Moving from one Iteration to the next
• How to add work item types to the Backlog
• How to create work item types
• Useful queries for tracking a project properly
• How I use windows 8 to save dev time

3. Content
• Creating release notes from your work items
• What work should be done in which branch
• When should you branch your code
• Useful things to automate inside a build
• Do I need a branch or a new workspace?

4. How to setup your Iterations

5. • Iterations are a way to slice your development in
time
How to setup your Iterations

6. How to setup your Iterations

7. How to setup your Iterations

8. How to setup your Iterations

9. How to setup your Iterations

10. How to setup your Iterations

11. How to setup your Areas

12. • Areas are the logical parts of your project
• Create an area for each zone or functionality
• Don’t create too fine grained areas, it’s less
reportable and chartable.
• You can then assign a Bug to an area and build a
query to see…
– which areas of your product are more or less problematic
– which areas of your product should you revamp first
– where have you spent the most time fixing bugs recently
How to setup your Areas

13. • Use areas to track your “Operational” work vs your
Development work!
• Exclude the “Operational” area from your queries !
How to setup your Areas

14. Moving from one iteration to the next

15. • First, if I’m starting a new Release I create a folder in my “Shared
Queries” for the Release and copy old queries to this folder
Moving from one iteration to the next

16. • My iterations are 2 weeks Sunday to Friday + 3 days off (1 Sat & 2 Sun)
• My iterations start on Sunday.
• My iterations stop on Friday.
• I move my iteration from Current to Past and the other one from Future to
Current on Sunday night, why?
Moving from one iteration to the next

17. • Moving iterations around is quite easy, just drag and drop!
Moving from one iteration to the next

18. • Then, I move a “Future” iteration to “Current”
Moving from one iteration to the next

19. • Move items that were not started to the next iteration
• 2 ways of doing so, the long way from the backlog, one at the time….
Moving from one iteration to the next

20. • …or build a query on everything under “Current” Iteration Path and multi-
select if you have many items to move….
Moving from one iteration to the next

21. • Make sure all tasks on items that aren’t finished are closed with the right
amount of remaining time.
• Don’t move the parent work item to the next iteration
• Create a new Task in the new iteration with the remaining time from a
previous task and assign it to the same parent work item
• It should appear again in the backlog for the new iteration with only it’s
new Task as the todo
Moving from one iteration to the next

22. How to add work item types to the Backlog

23. Adding Bugs to the backlog

24. Adding other work item types to the backlog
• There are missing fields for a WIT to appear in the
backlog, add them !
• witadmin exportwitd and start editing the WIT
• Add the Story Points field
• CMMI Template? Add the Size and Requirement
Type fields
• Import back the WIT to the server
• Explained clearly on MSDN

25. How to create work item types

26. How to create work item types
Use the process editor!

27. How to create work item types

28. How to create work item types

29. How to create work item types

30. How to create work item types

31. Useful queries for tracking a project properly
 Useful queries for tracking your Devs
 Useful queries for tracking your Iteration
 Useful queries for tracking your Releases
 Useful queries for tracking your Product

32. • Create a folder “Base Queries” and copy all original Shared TFS queries
in that Folder.
• This will save you the trouble of creating a team project just for copying
it’s queries when you ruin them .
• Use Visual Studio to copy multiple queries at once because the Web
Access can’t
Useful queries for tracking a project properly

33. Useful queries for tracking your Devs

34. • One query per DEV in the team
• Avoids playing the little bee game
• You want to track the Tasks not the Bugs/Requirements/Features
• Tree of work items where:
– The Task is the Parent
– The parent work item is the child
Work in progress

35. • Expand the parent to see which item the person works on
Work in progress

36. • This is the query in edit mode
Work in progress

37. Useful queries for tracking your Iteration

38. • Features or Functional Requirements or bugs Resolved
• These items need to move to CLOSED State (tested)
• I’m making sure this Query is empty at the end of an Iteration
• Flat list of work items
• Pin it to the HOME page
Work to be tested

39. Useful queries for tracking your Releases

40. • In the Team Queries, create a Folder with your
Release name like “Version 5.2”
• Copy your queries from a Release to the next
• If you followed the “Current” rule, they should work
effortlessly
Useful queries for tracking your Releases

41. • At the start of a Release (or way before), decide
what it will include
– Features
– Requirements
– Operational Work (you’re lucky if you have none)
– Bug fixes
What’s planned for Release 5.2

42. • PIN it on the HOME page
• Keep it there for the Release and replace it every Release
What’s planned for Release 5.2

43. What’s planned for Release 5.2

44. • PIN it on the HOME page, right beside the Planned Work!
• Keep it there for the Release and replace it every Release
• Compare it with the Planned Work to see your progress!
Items closed in Release 5.2

45. • PIN it on the HOME page, people just love to know how
many issues you fix in a release…
• Keep it there for the Release and replace it every Release
Bugs closed in Release 5.2

46. Useful queries for tracking your Product

47. Bugs backlog by severity

48. Other useful queries to track your product
• Bugs by area
– What to refactor first
– Where to focus next time
• Bugs closed by area
– Where not to focus anymore
– Where have you spent to most energy

49. How I use windows 8 to save dev time

50. • Install on SSD or go home!
• Native Hypervisor!
• Each dev has his set of VMs to test on!
• Everyone is isolated from others
• Reduced impact and friction
• Quicker dev to test to dev feedback
• Still need to test in a integrated environment
• Accelerates development time (yes it does, VM haters !!!)
How I use windows 8 to save dev time

51. Creating release notes from your work items

52. • Go to Visual Studio
• Select the query
• Open with Excel
• Remove unnecessary columns
Need I say more?

53. What work should be done in which branch
 One way to do it
 A better way, I think

54. • Use iterations but don’t check the « Iteration » box
• PROS:
– Easy for devs to see what Branch to use (use the HotFix V5.1 Branch) in their WI
– Not everyone can create the Iteration just like branches !
• CONS:
– Constantly need to create the Iteration from one iteration to the other
– Queries have to be re-adjusted from one iteration to the other
One way to do it

55. • Use Tags !
• PROS:
– Tags are persistent across iterations, no need to create them all the time
– No need to adjust queries when moving to the next iteration
• CONS:
– Can be hard to see which Tag is the Branch (when multiple tags are used)
– Anyone can create, delete or misspell a Tag which can mess up your queries
A better way, I think

56. When should you branch your code

57. • Branch when you start work and don’t know if it will make it in time for the
release
_____WORK_____________
|
___DEV__|____________
|
___MAIN____|_____
• Branch when you want to isolate code for a release
___DEV__________
| |
___MAIN____|________________|____
|
|___RELEASE_____
When should you branch your code

58. • Branch when you want to isolate code for a release
_____RELEASE_____________
|
___DEV__|____________
|
___MAIN____|_____
• Branch when you want to release often
__REL1_ __REL2__ __REL3___
| | | | | |
___DEV__|_______|_____|________|____|_________|______
|
___MAIN____|_____
When should you branch your code

59. Useful things to automate inside a build

60. • Setup!
– Wix !!!
– Each build = 1 setup
– Each dev can deploy his own build
– Each build is INSTALLABLE… ok but can you test it?
• SQL Scripts!
– Many companies have built their own SQL Script Diff tools…
– Automate their execution in your build process
– Each build is now TESTABLE, not just installable!
• Versioning of your assemblies
– Each build is now a potential RELEASE!
Useful things to automate inside a build

61. Do I need a new workspace?

62. • If you’re about to merge branches, YES
• If you have unfinished work and need to start new work, YES
• If you need to work on multiple branches at once, YES
• The more workspaces you have, the more in control you are!
• A workspace should be associated with only 1 branch
• You can have many workspaces pointing to the same branch
Do I need a new workspace?

63. QUESTIONS
Helpful at all?

64. Thank You For Attending!!!
Vincent Grondin
General Manager – Solutions Vet a CDMV subsidiary
C# MVP
.NET Montreal User Group Leader
Blog: http://geekswithblogs.net/vincentgrondin