In a previous post I described some of the simple things we have used at work to improve our TFS life as developers, and today I thought I would share some finer detail.
One of the single greatest tools I use to combat TFS weariness today is this fantastic outlook add-in by the SRL Team. It has changed the way our company works with TFS, I highly recommend installing it. In short you can create work items (tasks, bugs etc) from outlook items (emails, tasks etc) and also search TFS by keyword or ID.
Another tool of note, which aids those who need to access TFS reports and source on the run, is TeamPlain, which I use at home quite a lot. This gem provides a much better web interface for developers than the standard portal TFS currently provides. Whilst you can't do bulk checkouts very easily, simple one file check-ins/outs are quite doable. I find it particularly useful for creating work items and running reports when I don't have intranet access to work. It's so good, that Microsoft actually bought the company who created it, and is now a free download. Please note, this doesn't suddenly earn you a portal for non licensed developers – you will still need CAL's for users on TeamPlain.
The TFS Administration Power Tool is the only way to fly when you need to setup permissions for new TFS users in a hurry. It streamlines the task of setting up permissions for TFS, Share point and reporting services in one place. Perhaps its greatest feature that puts it over the line for hard core command line users is that you can easily make multiple changes at once. It also displays the activity log for all changes made, in case you need to blame somebody else for some poorly configured permissions. ;)
Lastly, but certainly not least, if you haven't already downloaded it, then do yourself the favour of getting the TFS Power Tools. For starters tftp.exe has some excellent command line functionality for managing all manner of day to day TFS tasks; tree clean, undo unchanged, to name but a few. There is a myriad of commands and it is very easy to pickup. Along with tftp.exe there is the check in policy pack which has some fairly common check in policy examples for you to utilise. If you want to implement your own custom check-in policies, it isn't hard and I suggest you have a look at Marcel de Vries primer on the topic.
On the topic of check in policy, we recently added one more to our front line against bad check-ins: for VB projects option strict must be turned on. <Cue-sniggers-from-the-C#-crowd/> I think it's imperative that any serious VB development be done with Option Strict on (and Option Explicit, but luckily the power of defaults has saved us here.) There was once a time when I thought the idea of duck typing and implicit casting was convenient and I'm certainly not proud of those days. Coming from a C programming background I should have known better, but I was well and truly caught by the Dark Side™.
There are few things worse than being asked to maintain some buggy code, that has Option Strict off, and after turning it on you get an error telling you that the amount of errors that can be displayed has been exceeded.
So how does this all help us to know ourselves better? Do some fancy add-ons to an already confusing product actually make project analysis any easier? The short answer is YES. Basically, the two things you need in order to make effective use of the TFS data warehouse are as follows:
By encouraging your team to create good check-in data with easy to access tools, querying TFS data becomes a much more fruitful experience. If you only have one task to check in against, then querying check-ins really isn't going to give you answers on how long a particular feature took to achieve. Conversely, if you have a rich source control history then ascertaining the amount of time a feature took to implement is a sinch. That's just the beginning; this data store can lead to all sorts of revelations about productivity and quality. It's all about granularity, and it's easy enough to provide. At work we use the following conversion to provide a decent work item tree:
Areas contain Scenarios, Tasks and bugs are assigned to Iterations. We create related work items from a Scenario when creating a new task or bug, so that they have some link. We don't really bother with Quality of Service or Risk items, but if you feel they apply to your product, by all means use them. We have started to store function specifications into TFS using this convention in order to kill the proverbial two birds. Firstly, it gives us a structured and consistent means of entering a function spec, and also provides a convenient skeleton to create work items from.
The net result is that if Mr. CEO would like to know how application X is coming along, we can immediately ascertain which scenarios have or haven't been satisfied (I.E % completion). If Mr. Lead Dev wants to know how many tasks to add to an Iteration, he can look up the project velocity report (a standard TFS report) to get a good idea of how quickly his team churns through tasks per day.
In my next post I will give some examples of querying against the TFS warehouse and how it can make your life a little easier when the boss starts asking the hard questions.
Subscribe