📜 ⬆️ ⬇️

How Microsoft DevDiv Uses TFS - Part 3 + Addition

In previous posts, I talked about our processes. Today I am going to introduce you to the implementation of these processes in TFS.
The picture below gives a rough idea of ​​how they look. Read this article to get more insight into the processes.

We use work items to track the information below.

Work Element Value Proposition (Value)

Work Item Value Proposition
Note the following:
  1. Scenarios (Scenarios) are implemented by adding a special script field in the work item of the type Value Prop and setting the value ALLOWEDVALUES to the list of scripts. Since the number of scenarios (also known as business goals) is limited to a rather small and, at the same time, a fixed number, this approach seems appropriate.
  2. The relationship between Value and Experience (Experience) is controlled by referencing each other of these types of work items.
  3. The type of the work element Value Prop must contain several fields and, above all, the Description field, which explains why the value itself was described.

Work Experience Element

Experience Work Item
Pay attention to the following points:
  1. Experience work item associated with parent Value Prop.
  2. The work item Experience refers to child elements of the type Functionality (Features).

Feature Feature (Functional)

Feature Feature
What to look for:
  1. The type of Feature refers to the parental type of Experience.
  2. The Features type must contain many fields describing it. The Description field specifies a summary of this element to facilitate searching.
  3. For a more detailed description, the user can go to the one-page specification of this functionality. This document is presented as an external link in a special field.

What's next...

Next we will talk about how planning processes worked in Orcas.


I received a question from Michiel about this article. The question was: how is the relationship between the work items? For example, Scenario for Value Prop, Value Prop for Experience, Experience for Feature?
For the case of Scenario to Value Prop, we used the ALLOWEDVALUES list. We added the Scenario field to the work element Value Prop and set ALLOWEDVALUES as the type of this field. ALLOWEDVALUES is bound to the GLOBALLIST type, which is a list of scripts.
For all other types of relationships, we used references from one work item to another. Thus, we created links between the work elements of Value Prop and Experience. These relationships simply show links in a special section of the work item form. You may have noticed that the default MSF work item templates contain the Links tab, but the work items that we discussed above contain a list of links on the same tab as the description. This approach is just a matter of design. You can display lists of links wherever you prefer.
A logical question may arise: “How do you prevent the creation of links from Value Prop to Feature directly? How do you maintain the right hierarchy? ”
The answer is: through exception reporting. Several people view reports that display incorrect references and remove such links. Perhaps not the best solution, but that is exactly what we did.


Source: https://habr.com/ru/post/100151/

All Articles