Almost everyone knows about the extensibility of the process template that defines the team project within Team Foundation Server. I’m always interested in hearing what other teams have done to modify either the Agile or CMMI template to better tailor it to their internal processes. So I thought I’d share what we’ve done to extend the process template ourselves.
We are big fans of the Agile methodology and work in a semi-scrum environment. We started with the standard Agile work items (Bug, Task, …) and everything was working pretty well. Fairly soon though we found we could really use some additional states on the work items to allow us to better report on the current status of our work. This was before the days of the power tools that have really simplified these types of changes. We jumped on the internet and started reading about witimport.exe and how to modify the XML that defines the work item types. We added the states and happily moved along.
After our team grew we realized we needed additional workflow to better manage the work as it moved through the team. So we once again extended the process template. Now, for example, the work item lifecycle looks something like this:
- A change request from the customer would be communicated to the project manager via email. She would then use TeamLook to create a work item and assign the appropriate priority and severity. At this point it would be dropped into a pending iteration waiting for the next triage meeting.
- At the triage meeting we estimate the effort needed to complete the work item and assign start and finish dates. This allows us to manage the work within Microsoft Project very easily, but that will need to be another blog post. We also assign the iteration that the work will be completed in. The iterations are generally a month long, depending on the project. The work item state is set to scheduled and ready for a developer to begin work.
- The developer uses TeamLook to view their work items and sort them based on the priority and importance. After choosing the most critical work item the state is changed to in-progress signaling that work is underway.
- When the developer has done their code review and checks in the changes, the work item is associated with the changeset, and TFS changes the work item state to resolved.
- A continuous integration build is fired off and an email sent to the team informing them of the state of the build. A nightly build runs that incorporates all of the changes checked in during the day and those changes are pushed to the test environment.
- The tester reviews the previous day’s changes and validates the work. Upon approval the changes are pushed to the staging environment and the work item state is changed to verified.
- The project manager uses TeamLook to aggregate the verified work items and sends the list to the customer to notify them that their requests have been staged. The customer can confirm the changes meet their expectations to the project manager, who then changes the state of the work item to reviewed.
- When the iteration’s release date arrives the deployment lead verifies that all work items are set to reviewed and can be released to production. We’ve created an internal tool that can pull out the changed code from source control based on a team query. This simplifies checking what changes need to be pushed to production.
That’s a lot to read, so where’s a pretty picture instead?
Posted
Sun, Nov 8 2009 8:58 PM
by
eric
|
Remove post from favoritesAdd post to favorites...
|
Remove blog from favoritesAdd blog to favorites...