I have just moved to a new company and they are using TFS 2010 (2012 in a couple of months) as their version control system and recently started to use it as a work tracking system for the developers.
However, there doesn’t seem to be a bug tracking system for use by people outside development & test. Production support are getting reports of issues, fixing them on the fly and reporting back to their users at the moment. This needs to be changed but I don’t really want to have a sperate system for tracking bugs and tracking dev work.
Is there a way that I can create a very light weight way of entering bugs into TFS similar to the way that FogBugz does? Logging into TFS to fill out a bug report seems to be a lot heavier and you have to associate it with a particular application. Support may be able to do this but I want to be able to triage the item and potentially change the association to something other than an application.
I have used FogBugz in the past and when adding a bug, you can add a much/little as you want to the item so it is at least recorded and later you can bounce it back to get more information when you come to triage the ticket.
3
It largely depends on what fields you would want, as 17 of 26 indicated: TFS is highly customisable. The reason I would want to do this as opposed to use something like JIRA is that you get a single view of what your developers are working on, as opposed to having to aggregate two systems.
TFS also has resource capacity planning, and if you’re not showing production defects in your planning (and they take up a significant fraction of your time), then you’re not really planning your capacity. I would in fact say that this is an ideal solution for teams where the developers make use of TFS and support Production (e.g. DevOps).
It doesn’t mean you can’t use other tools for the main Production Support/ITIL work, you’d just need to make sure they integrate, either manually or preferably automatically. Most such tools allow you to put in custom hooks, and TFS certainly does.
Anyway, to the main question. I use the CMMI TFS templates (which actually work fine with Agile BTW), and I just added a single field to one of the drop downs.
Here are the steps:
Install TFS Power Tools
Open the Work Item Template from the server
Edit the Discipline field
The discipline field is the “kind” of work related to the defect. The standard values are:
- Analysis
- User Experience
- User Education
- Development
- Test
What we’re just going to do is add “Production” to that list. First, edit the Discipline field:
Then, click the Rules tab and edit the ALLOWEDVALUES rule:
Then, Click “New”, and add in “Production” as one of the values.
Click “OK” repeatedly until you’re back at the field list.
Save the Work Item Template
OK, now you’re done. You can create new Bugs and indicate their type as Production. I’d also create a few Work Item Queries looking at Production defects, and add them to your pinned items. Finally, look at the existing Bug queries, and maybe change their ordering so that “Production” bugs come up first (if that’s possible).
2
No, that’s right – Microsoft’s premier ALM isn’t really useful outside of Visual Studio and the dev teams.
You can access the work items using the Team Explorer (which is a very cut down version of VS) or access it via the TFS web site. Neither are particularly good options as the bug fields are reminiscent of ancient ‘enterprise’ bug trackers I had the misfortune to use in the past.
There’s no real distinction between bugs in TFS – there’s only the single tracker that you filter using a field in the item itself, so use a category field and then create a report that only shows a particular type of category. I think that’s your only realistic option with TFS.
If you want external issue tracking, then I think TFS is a poor choice, you’re better off using something like Jira or Redmine and using that to manage bugs – their interfaces are much, much nicer and easier to use than TFS. I particularly liked the way you can send an email to Redmine and it creates a new issue for you, that was an ideal usability feature for off-site workers.
6
Non developer users can access the TFS work item tracking system by using a web browser to go to the Team Project Portal. To find the URL, go to Team->Show Project Portal in Visual Studio. From there, anyone with permissions can browse, create, or modify work items. They can also generate all kinds of reports to look at the status of things.
The types of work items available and the fields in the work items vary depending on how TFS is configured (primarily by which process templates were chosen).
The information required to enter a bug is also dependent on how you have TFS configured. In our case, we require a title, steps to reproduce, and the build that it was found in. The TFS work item tracking system is very powerful and flexible. It can be as complicated or as simple as you want it to be – it all comes down to how you have it set up.
This Microsoft blog post describes planned improvements in TFS that should help support lower-overhead:
- New work item form that’s easier on the eyes and includes discussion and mention options, similar to facebook and twitter.
- Custom fields
- Improved Kanban support, eg quick add tasks on a work item.
- Also mentions dashboards and metrics.