Automated discussion support in the work item management
One of the biggest hurdles when organizing efficient workflow in a distributed team is the communication. Communication should be integrated with the rest of the workflow, imposing as low a burden on each team member as possible. By building on all other parts or layers of the workflow it achieves better quality because of the contextual information from those other parts (work items, code, documents etc.). At the same time communication has to be automated, so that each team member gets the right info in the right moment in the most efficient manner thus enabling him to react efficiently.
What does that mean in the context of Visual Studio Team System and work item management?
Each work item is a focus around which the information gathers. Each task, bug or scenario needs to be discussed and documented; the solution needs to be described etc. Sometimes, the information flow in a work item is in one direction only, from the team member defining the task to the one implementing the solution, but very frequently there are issues that need to be ironed out before the code can be developed.
The solution, I am about to describe, aims to automate the communication, especially in view of a distributed development team. The information is exchanged in the context of a work item, keeping it close to this context rich focus. Thus, we have better quality and self documenting (in the description field of a work item) communication at the same time.
Work items have an “Issue” field by design. Its meaning is with yes or no value to indicate if the task is blocked in some manner. If this field is set to Yes, the task displays on the project manager’s issue report. (Picture 1) We’ll use the field as a general sign that there is something to discuss. As designed out-of-the-box it is not known who it should be discussed with. That is the reason why we’ll add a new field “Issue depends on” with a list of team member’s names, analogous to the “Assigned to” field. (Picture 2)
What does that mean in the context of Visual Studio Team System and work item management?
Each work item is a focus around which the information gathers. Each task, bug or scenario needs to be discussed and documented; the solution needs to be described etc. Sometimes, the information flow in a work item is in one direction only, from the team member defining the task to the one implementing the solution, but very frequently there are issues that need to be ironed out before the code can be developed.
The solution, I am about to describe, aims to automate the communication, especially in view of a distributed development team. The information is exchanged in the context of a work item, keeping it close to this context rich focus. Thus, we have better quality and self documenting (in the description field of a work item) communication at the same time.
Work items have an “Issue” field by design. Its meaning is with yes or no value to indicate if the task is blocked in some manner. If this field is set to Yes, the task displays on the project manager’s issue report. (Picture 1) We’ll use the field as a general sign that there is something to discuss. As designed out-of-the-box it is not known who it should be discussed with. That is the reason why we’ll add a new field “Issue depends on” with a list of team member’s names, analogous to the “Assigned to” field. (Picture 2)
Picture 1
These two fields together with the work item’s description field should be used in the following manner:
The question is entered in the description field of a work item, issue flag is raised and “Issue depends on” set to the name of the person the issue is to be discussed with. That person receives an automatic notification, responds in the description field and assigns the issue back to the originator once again using “Issue depends on” field. Now, the originator receives the notification that the answer is ready. If the answer is satisfactory the originator removes the issue flag and the conversation is over. If not, it iterates once again.
In order to enable the scenario we’ll need customization in a work item type(s), an event subscription for each team member (notifying about a new issue addressed to her/him) and a new query “My Issues”.
Work item customization:
Using you WI customization tool of your choice (witimport and witexport or Process Template Editor) add the following in the work item types that should support this feature (or rather, customize them all - in our experience all WITs profit from this kind of automated discussion support):
After the definition of the Issue field
<FIELD name="Issue" refname="Microsoft.VSTS.Common.Issue" type="String" reportable="dimension">
…
</FIELD>
add:
<FIELD name="Issue Depends On" refname="Ekobit.VSTS.IssueDependsOn" type="String" reportable="dimension">
<HELPTEXT>Person that needs to resolve the issue before this task itself can be implemented.</HELPTEXT>
<WHEN field="Microsoft.VSTS.Common.Issue" value="Yes">
<VALIDUSER />
<REQUIRED />
</WHEN>
<WHENNOT field="Microsoft.VSTS.Common.Issue" value="Yes">
<EMPTY />
</WHENNOT>
</FIELD>
And after the definition of the Issue field’s control
<Control Type="FieldControl" FieldName="Microsoft.VSTS.Common.Issue" … />
add:
<Control Type="FieldControl" FieldName="Ekobit.VSTS.IssueDependsOn" Label="Issue depends o&n:" LabelPosition="Left" />
Notifications customization:
For each team member a new event subscription for WorkItemChanged event is needed. The event criteria should be
"PortfolioProject" = '{0}' AND ("ChangedFields/StringFields/Field[ReferenceName='Ekobit.VSTS.IssueDependsOn']/NewValue" = '{1}')
Instead of the {0} put the name of the Team Project and instead of the {1} put the name of the team member (as it appears in the Assigned to combo).
Skip the first part regarding PortfolioProject if you want to receive the notifications irrespective of the Team Project (the work item changes from the previous step were done in the context of a single project though).
You can subscribe directly using BisSubscribe.exe or this utility by Naren Datha.
There needs to be a separate subscription per team member. For large teams it might be impractical to do subscribing manually. Here is a handy utility that can ease the process. In the zip file you will find two files: “TeamEventSubscriber.exe” (the utility itself) and the “Subscriptions.xml” containing the data about the subscriptions. After updating the “Subscriptions.xml” (entering the name, e-mail address and the name of the team project for every team member that is to be subscribed), start the utility, choose the team foundation server name and process the xml by clicking the “Execute” button. After the processing is over, a message box appears, showing the number of successful and number of failed subscriptions together with the Ids of the newly added subscriptions. In case of an error, diagnostic info is dumped in a log file (“FailedSubscriptions.log”). Utility can be executed multiple times with same .xml data without adverse results – same subscriptions will be registered each time.
Work item query customization:
The final point of the scenario is the new work item query “My issues” which shows all issues that depend on the user. The easiest way to add the query is through the Visual Studio UI as shown on the following picture.
Conclusion
The text describes a Team System customization that enables easy, automated communication, focused on work items and integrated with the rest of the development environment. Additional work item field together with eventing functionality of the Team System enable low overhead, near real time communication. This scenario is especially effective with geographically distributed development teams and presents much better communication solution than ordinary mails.
0 Comments:
Post a Comment
<< Home