How to use TFS 2010 to improve the development process?

Question

Hi,

How can TFS 2010 improve my development process? For example, I use shelvesets to not lose checkin frequency but I can check in works in progress to shelvesets, thus not checking in code which breaks the build (check in gates help with this too).

Is there anything else along these lines which helps improve the quality of projects?

Thanks

Answer 1

To improve the quality there is a lot in the tool. You can think of:

• Unit testing
• Code Analysis
• Work Items to be able to better track your projects
• Test Impact Analysis to see what unit tests are impacted on code changes
• Test Manager to integrate Functional / Manual testing
• CodedUI to include funtional tests in your build

Answer 2

Hi, I will try to tell how can you improve but my english isn't very well, so sometimes i can babble.

With a source control system, your software development process will be improve automatically. For example, one day a bug had reported to me. When i control the bug, i saw that an existing code block was deleted. So i, use "Annotate" tool to learn who deleted the code block and why? With annotate tool, i saw my developer collegue deleted to code. I looked the Work Item why did she delete? When i look the work item carefully, i saw my analyst collegue ordered to delete the code block. So we ask him, why he wanted something like this? He said that that was a mistake, so we undo the change.

All of these are possible because of TFS. These are only source code tracking, TFS do much more better than this.

So what can do to improve development process?

1- Activate policies; TFS users must check-in files with linking an WorkItem.

2- Use TFS Reports and email them to all your developer team to show "what is the current state?"

3- Customize WI templates if you need.

4- Try to apply CMMI or TickIT certificate to improve your proccess. (TFS allways help you for the certificate requirements :) )

5- Use branches if you need. With 2010 branch mechanisism became better.

Answer 3

My number one tip is alerts.

You know that person in your office, maybe a manager or a team lead or whoever, who comes to your desk two or three times a day and interrupts your progress to ask you about your progress? Have that person set up an alert on all checkins for the project. Getting an email every time you check in code (and the email says what work item it was for) will give that person all the information needed - and you won't be interrupted so often. (Plus with any luck that person will get in the habit of running TFS queries to see how many bugs you have left or how many are high pri etc instead of coming and asking you.)

Also, remember that time you fixed something, but then it came back to you and they said "oh yeah, I know it said 5 in there when I gave you the bug, but a day later, before you started coding, they changed their minds so it needs to be 53 so you need to do the whole thing over." Set alerts to email you whenever your work items are edited by others and this will never happen again. You'll also get a kick in the rear (in the form of an email) when something gets changed from low priority to high priority.

There are many many things that TFS helps with but in my experience developers underuse alerts. Get them set and your life will improve immediately.

Answer 4

First, go pick up the Visual Studio Scrum Process Template which is the best template out there. It's simple and powerful. Read the guidance that comes with it, or better yet, sign up for a PSD course with Scrum.org. (Full disclosure, I lead Scrum.org PSD courses.)

Second, full automate your build AND DEPLOYMENT. I can't stress that last part enough. You should be able to check into an integration branch (possibly trunk or main) and have that build verify itself as much as possible and deploy to an area that your Product Owner can use. Many times, if the product permits, we will publish beta or alpha builds that anyone can use which allows us to gather quick feedback. You can auto publish Click Once, Web, and database projects with little effort.

Third, come to an understanding on your branching strategy. I am of the Branch-by-Feature ilk. This means I branch for each Product Backlog Item (normally in the scheme of $/Project/Branches/####-Shortname. My team swarms around that PBI or possibly 2 PBIs until we are done (as in shippable). We then merge back in to our integration branch which is auto published.

Fourth, be clear about what your definition of done. Publish your Definition of Done on the Project Portal. This doesn't have to be SharePoint, but can be a simple web page you setup. For a great description of what a definition of done is see this podcast with Ken Schwaber.

Fifth, install Urban Turtle. It's awesome! Best Backlog management tool available for TFS.