Brian A White's Blog : Work Item Tracking

Team Foundation Extensibility Kit

brianwh — Tue, 25 Jan 2005 21:44:00 GMT

The team foundation extensibility kit is available as of today! This goes with the December CTP release and includes quite a few things. For those of you following the work item extensibility it includes updated specs and updated witimport.exe for creating and modifying your work item types. There is also early documentation on the work item API/object model. Enjoy.

http://download.microsoft.com/download/5/4/6/5466ad0d-dd6d-4b2e-9402-63352bda1798/VSTF 1204 CTP Extensibility Kit.msi

Project Management, Version Control, Work Item Tracking Presentations

brianwh — Mon, 15 Nov 2004 19:06:00 GMT

Last week I presented at Visual Studio Connections in rainy Las Vegas (Yes, rainy. Sadly, yet not surprising I can also report moderate losses). Several of you asked me for copies of these presentations and thanks to the help of Rob Caron you'll find the presentations (below) downloadable here.

VMS352 - Visual Studio 2005 Team System: Software Project Management
In this session you will learn how to take advantage of the combined power of Visual Studio, the Microsoft Office System, and industry proven practices to successfully manage software projects—from conception to deployment.

VMS355 - Visual Studio 2005 Team System: Enterprise Class Source Control & Work Item Tracking
This session introduces the new Team Foundation Server in Visual Studio 2005, including the new Source Code Control, Work Item Tracking and Team Portal. See how an integrated and extensible server-based system will boost your team’s productivity by significantly streamlining your development processes.

The Makings of Visual Studio Team System Work Item Types

brianwh — Fri, 30 Jul 2004 23:33:00 GMT

Visual Studio Team System is extensible. For work item tracking that means you have the ability to define your own work item types. One person’s bug is another person’s defect, requirement, feature, risk, issue, change request, or task. In doing the design, we decided to first be capable of defining work item types in XML and then using that XML definition to instantiate a work item type in the team system database.

The design goals of the work item type definition language (WITD) were:

· Extensible - to accommodate future functionality

· Simple – the basic language should be simple to understand and produce

· Human readable – users should be able to type in simple WITDs and have them work without having to resort to specific design tools

And, of course, the fact that the information can be stored in an XML file makes the WITD shareable and versionable as well.

So, what are the core elements that make up a work item type?

First you need to identify the work item type from others. This leads to the obvious name and description:

<DESCRIPTION>Bug work item types are used to track software defects.</DESCRIPTION>

Secondly, you need to define what kinds of data you want to collect. This is done by specifying a set of fields.

</FIELDS>

Thirdly, you need to define the workflow. That is, the states and legal transitions between those states. This example shows the simplest state transition model we support one state, one way in, with one reason for being.

</STATES>

</REASONS>

</TRANSITIONS>

</WORKFLOW>

And finally, you need to define how this information is presented to the user. This is done in the form layout section of the WIT definition language.

<FORM>

</FORM>

</WORKITEMTYPE>

And that is about it. You may wonder, how do I define the business or rules of behavior for a work item type. These are also defined in the work item type definition language as rules associated with fields and scoped by state and transition. But I will leave that for another post.

As always, thoughts, comments, concerns, and especially improvement ideas are very welcome.

Workflow and Visual Studio Team Foundation

brianwh — Fri, 04 Jun 2004 16:33:00 GMT

The software industries ability to produce acronyms and talk in jargon may only be matched by the military. One of our other abilities is using the same word to mean hundreds of different things. My favorites are object and project, closely followed by component. However, today, I am thinking about the word “workflow”.

The Merriam-Webster’s Online Dictionary doesn’t contain this word. It instead suggests that I was looking for the word “workfolk” defined as “working people, especially farm workers”. You have to admit that this is funny (or perhaps you had to be there). So, if workfolk are following a process are they doing workflow? I turned to the Oxford English Dictionary and I quote “The definitive record of the English language” with no luck. This clearly illustrates my previous point that software developers do not speak English.

In desperation I turned to our trusted companion Google and got 3,000,000 hits. Top on the list was “Need a Workflow system? www.savvion.com Use our enterprise-class solution for workgroup to enterprise process”. This proved to be an interesting site if you are looking for a business process modeling tool. However, our friend Google along with the 3,000,000 hits also had a link to “definition” right at the top. Aren’t those guys great? This link takes me to dictionary.com (obviously not the definitive record) with this definition:

Workflow

- The flow or progress of work done by a company, industry, department, or person.

- The rate at which such flow or progress takes place.

Ok, now we’re getting somewhere. In my opinion, workflow for software development is about defining the processes by which individuals on a software team accomplish a larger goal and then being able to instantiate process tasks in a way that people can use them to determine what work need to do, when it needs to be done, and indicate progress which can then be tracked. Workflow as opposed to managing a todo list is aso focused on the interrelationships between tasks and the automated generation of tasks to drive a defined process. Most workflow tools on the market have failed to be wildly successful primarily because they were not tightly integrated into the everyday tasks of the people who were doing the actual work. Process in my mind should disappear into the tools you are using to get a job done.

The Visual Studio Team Foundation will include a work item tracking component (there is that word again). You may hear that it supports workflow and even I am guilty of using tags like <WORKFLOW>… </WORKFLOW> in the work item type definition language to describes the state transition diagram for work items. In reality, however, we are introducing in VSTF only the basic elements that will later enable true workflow support. These are work item types which define the work performed by an individual. Each work item type has a state transition diagram composed of states and legal transitions that drive the process for that specific work item. More on states and transitions later...

If you’re wondering about the term “work item”, visit my colleague Kevin Kelly.

Software Lifecycle Tools and the Visual Studio Team System

brianwh — Thu, 27 May 2004 05:52:00 GMT

I’ve been in the software tools industry for the majority of my career. It has been utterly amazing to me to see the rise of the importance of software development tools. In fact, when people ask me what I do, I say “software tools for software developers”. Typically this stops the conversation right there.

The interesting thing is that in all those years, the capabilities offered by the tools have been only marginally improving. Take SCCS to RCS to CVS. These are great examples of freeware version control advances, but not break-through innovation. Most software applications today require several if not hundreds of individuals to pull off. We are also seeing increases in geographically distributed teams, from broadband access at Starbucks to major outsourcing initiatives with a global reach. All of these things have greatly increased the importance of tools to help software teams collaborate and be more productive.

There are only a few advanced software lifecycle tool sets on the market today, yet none have been architected and built from the ground up. I feel incredibly lucky to have become deeply involved in what is now publicly called the Visual Studio Team System. In particular, my focus is on the Visual Studio Team Foundation. The Team Foundation is a server product with client-side functionality that is designed to support all roles on a software development team. The Team Foundation includes source code control, work item tracking, metrics and reporting, MS project and Excel integrations, and a rich integration infrastructure that delivers such services as artifact linking, events and notification, authorization, and tool configuration.

It is rare when you have the chance to do something that has a positive impact on millions of individuals on software teams. As Brian Harry said in his first ever blog post, we won't get everything done in V1. However, we are committed to improving and innovating as we move forward. I’m looking forward to those of you who would be so bold as to help me and our team shape the direction of the Visual Studio Team Foundation through this new medium of the blog.

-Brian

Work Item Tracking @ TechEd 2004

brianwh — Tue, 25 May 2004 01:45:00 GMT

What an exciting day! Head to Visual Studio Team System for more information on the announcement at TechEd today. Microsoft will be releasing an extensible set of software development life-cycle tools that help software teams collaborate to reduce the complexity of delivering modern service-oriented solutions. This solution includes brand new source code control and work item tracking components.

If you are attending TechEd and interested in work item tracking, defect tracking, bug tracking, requirements management, or software project management, try the following sessions:

Tuesday 10:45am DEV200 An in-depth demo of the entire Visual Studio Team System

Tuesday 1:30pm DEV300 A drill down on the project management aspects of VSTS

Thursday 3:15pm DEV303 A drill down on source code control and work item tracking

I myself will be presenting a cabana session on extensibility and customization of the work item tracking component on Thursday 5-6:15pm DEVC39. I’ll also be available at the Visual Studio booth in the pavilion. If not me, you might try to find Kevin Kelly another program manager or Amit Ghosh who is one of the developers working on the work item tracking component.

You may be asking yourself, why is Microsoft developing a bug tracking solution? Aren’t there enough of these out there already? The answer is yes and no. Yes, there are several bug tracking tools out there, but if you think too narrowly about just bug tracking you’re missing the point. The intention is to deliver an extensible infrastructure that can be configured and extended to support all work item types that are important to software teams. These could be tasks, features, requirements, scenarios, bugs, etc. The second difference is we want to support deep integrations with other aspects of the software development lifecycle like source code control and project management without (and this is key) compromising ease-of-use .

More soon on what makes up a Visual Studio Team System work item type…

Why Work Item Tracking? - Its not just all about bugs

brianwh — Thu, 20 May 2004 17:51:00 GMT

Software development continues to increase in complexity with results being of higher quality and produced in less time. It is a recipe for disfunctional teams and stressed out individuals. To establish successful track records software teams turn to various means of define the work that needs to be done and track its progress. There are a significant number of similarities between the management disciplines involved and I would argue that a common infrastructure to support these disciplines is key to taking the next steps in software process automation and software team collaboration.

The “management“ disciplines I'm referring to are: requirements management, bug and defect tracking, project management, risk and issue tracking. I'm going to take some broad brushes here so bear with me. Requirements management focuses on defining the “what”. What are we trying to build? Bug tracking focuses on identifying and resolving the things in the current “what” which deviate from the defined “what”. Project management focuses on the “how“. What is the work required to achieve the “what” and emphasizes who is doing that work, what is the ordering of that work, and when will it be done. Risk and issue tracking focuses on reducing project risk by identifying risks and issues and tracking the work needed to reduce or eliminate these risks and issues.

What do these things have in common? First, they are all lists that software development teams want to keep track of. What will the system do? How high a priority is feature A? Don't forget to fix bug 20303! Hey Joey did you finish implementing that performance improvement yet? Items in the list have a name or identity, they typically have someone assigned to them, they have state (e.g. Active, Complete, Deferred), and they have relationships between them and in fact interdependencies. For example, a high-level requirement such as “The system must support e-mail notification” may produce bunch of lower level features such as “Implement Notification API”, “Add e-mail event listner”, and “E-mail template deisgner”. To implement these features, developers get assigned tasks (coding work) and testers get assigned tasks (test case development and execution). All this work is tracked by the project manager as tasks with a result being as schedule for delivery of the “what“. As testers start testing, bugs or defects are found and identified. This produces additional work to be done along the way.

It is all a web of work trying to produce the right what.

With the state of practice today, I believe there are significant gaps between the team member tooling causing inefficiencies in communication and collaboration. Each member of the team uses different, but poorly integrated tools to get their particular job done. The analysts defining the what, the project managers defining the plan, and developers and testers who attempt to build the what by following the how. The difficulty is for a developer or tester in the trenches is to determine what a project's real requirements are and for a project leader to keep a schedule up to date with what is really happening on a project. Both of these are key symptoms of these gaps.

I would assert that a common infrastructure that delivers a way to manage lists of items and their interelationships and yet supports the unique needs of each member on the team will signficiantly improving communication, support more sophisticated automation, and generally help teams achieve their goals more efficiently.

I'm keenly intersted in what people are doing to address these problems on their own teams. I'll be at Tech Ed next week so feel free to drop me an e-mail and we'll find time to chat. You can find me in the TechEd RIO system at http://rio.crgevents.com/TechEd2004/Rio/

+++++++++++++++++++++++++++++++++++++

This posting is provided "AS IS" with no warranties, and confers no rights.