Process Template CustomizationAdapt the tool to your needs, do not adapt your needs to the tool

03/11/2011 DomusDotNet

Ricci Gian Maria, @alkampfer,alkampfer@nablasoft.com, http://www.codewrecks.com, http://blogs.ugidotnet.org/rgm, https://www.facebook.com/Alkampfer.ALM

TFS and ALM− Developing task

− Requirements− Code and build − Bug, Task, issues, and every operation that you want to

track down during development − Handle relations between all these artifacts

− Documentation− Integrated SharePoint portal centralizes document

management− SharePoint dashboard to visualize how the project is going− Have a lot of reports out-of-the-box to gain visibility over

process− Flexibility

− You can access TFS from Excel, Project, Visual Studio, web, Microsoft Test Manager, Blend, Windows Explorer

− External tools permits you to use Outlook, Word− API permits you to write code that interact with every

feature of TFS

Tfs is an ecosystem

And it is really flexible

Process TemplateEvery Team Project starts with a process template.

ProcessA software development process, also known as a software development life cycle (SDLC), is a

structure imposed on the development of a software product

…describing approaches to a variety of tasks or

activities that take place during the life of the project…

aims to be the standard that defines all the tasks required for developing and maintaining software

(WIKIPEDIA)

Process templates− A Process Template defines the

implementation of a process for Team Foundation Server.

− It contains a number of important components of the process:− Roles and responsibilities− Types of work items− Reports− Process guidance specific to the process.− Default work items

Default Process templates− TFS comes with 2+1 process template− You are encouraged to find other

process on the web or create your own

− A process template is fully customizable

− Usually you start from an existing template and adapt to your need.

− You can find a list of free templates on http://templex.codeplex.com/

Work ItemsWork items form a central feature of Team Foundation Server. They provide the mechanism for: communication, resource assignments and metrics gathering.Work items have the following definite properties:−Have a title and description−Are classified as work item types by area and iteration (for reporting purposes)

−Are dependent on the process template selected

−Are assigned to a single resource−Have a state which is controlled by the process template

Process guidance news

− In tfs2010 project guidance is fully customizable

− You can link to external or local resources

Are there processes out there? − Software industry is young and there

is nothing like “one process to Rule them all”

− There are classics and modern processes to choose from

− You should understand which one fits better for your organization

Customize the process− Assess your process, understand its

weak and strong points− Choose an existing Process Template

that closely resemble your actual process

− Start to adapt to satisfying your needs− Understand what part of your process

can improve thanks to TFS− Do not adapt your process to TFS

adapt TFS to your process

Demo – Customize the processUse the editor to configure the basic part of the template

Anatomy of a Process Template− The whole process template definition

is just a bunch of XML files− You can download everything in a

local folder for modification

Edit a Process Template− When you downloaded the Process

Template Definition in a local folder you can directly edit XML files

− Each directory represents a different section of the process template.

Upload the new template− From Process Template manager you

can upload your modified process to the Project Collection

Process Template Editor− Power Tools introduced a new tool

called “Process Template Editor”− You can simply open it and point to

the local folder where you downloaded the process template

Process Template Editor− It permits you to edit the template

directly from a nice UI

DemoBasic customization of Process Template

Microsoft Confidential20

Work Item TemplatePersonalize the structure of Work Items

Customization of− The most important section of process

templates is Work Items− You have two options to modify a

Work Item− Modify a Work Item definition of an existing

specific Team Project− Modify a Work Item Definition of a process

template.

− Modifying a WIT of an existing TP is useful to do a quick test of the modifications.

Modify a Work Item in-place− You can open a WIT directly from a TP− You choose the Team Project and then

the Work Item Type you want to Edit− You can edit the WIT and when you

save, all modifications are immediately applied to the Team Project

Work Item Definition - Fields− A Work Item is basically composed by

a list of fields− Some fields are mandatory, but the

vast majority are configurable per-process

Work Item Definition - Ui− TFS contains an UI engine that

dynamically creates the UI to edit the Work Item

− You should define the position for the control and the field you want to edit

Work Item Definition - Ui− You should only specify position and

details, the UI will be created automatically

DEMOAdding Fields to Work Item

Microsoft Confidential27

Work Item Definition - Rules− Each Field can have 0-* rules that

defines specific behavior− Each rule adds a specific behavior to

the field− UI behave accordingly to the RULES

applied to the field

Work Item Definition - Rules− Process template editor has a specific

section for RULES

EX: ALLOWEDVALUES− Specify the list of possible values for

the field− You can simply add a list of strings

Dynamic UI Generation− The good part of dynamic UI

generation is that TFS is able to reflect RULES in the UI

− With ALLOWEDVALUES the UI creates a ComboBox instead of a TextBox

RULES are securable− Each RULES can be applied only to a

specific group or user− You can apply same rules with

different values for different groups.

RULES are securable− Contributors can

only use “non effettuate” and “In Lavorazione”

− Administrators can use the value “approvate” in addition to the other two

Most useful RULES− ALLOWEDVALUES: list all valid allowed values for the

field− ALLOWEXISTINGVALUE: if the field has an existing

value that is not allowed, it will be kept− CANNOTLOSEVALUE: once it has a value it never

could be set to null− COPY: Copy a value from another field or from

constant value− DEFAULT: specify the default value of the field− EMPTY: The field is empty and Read-Only− FROZEN: Defines the field as frozen. Frozen means

that the field cannot be changed to any non-empty value after changes are committed. You can manually clear the field, save the work item, and then specify a different value.

Most useful RULES− PROHIBITEDVALUES: List a series of values that are

not allowed for the field− READONLY− REQUIRED: You should specify a value for the field− SUGGESTEDVALUES: create a combo in the UI, but

you can insert the value you want− VALIDUSER: the field must contain a member of the

specified group− WHEN, WHENNOT, WHENCHANGED,

WHENNOTCHANGED: Permits the application of a series of RULES only when a condition is satsified

Demo Add fields and rules to Work Item Template

Microsoft Confidential36

Status and transitionsLifecycle of a Work Item

Microsoft Confidential37

State and transition− Each WI possess a special field called status− This field is special, because TFS uses it to

manage a workflow− Each WI has a series of transitions that

permit to move from one status to another− The union of Status and Transition creates a

workflows that models the lifecycle of that specific Work Item.

Workflow of a Bug in MS for agile− This is the workflow of a bug in MS for

Agile 5.0 template− Blue boxes represent transitions, while

red boxes represent state

Workflow of a Bug in MS for agile− Workflow should have a transition with

no source− This is the transition that determines

the initial status of the work item− In this example the first status is

active

Reason field− Another special field is called reason− Reason field contains a string that

explains why the WI is in that state− You can change reason only during

status change− You specify the possible reasons in

transition definition

RULES on reason− You can apply rules on specific reason− Requirement: when a bug was

inserted in the system as «Signaled By Customer» you want a priority of 4

RULES on reason− Create a new bug, choose Signaled by

Customer− You can only choose 4 as priority

value

− If you choose a different reason you can choose every value

RULES on Status or Transitions− RULES can be applied to field in

association of Status and Transition− This is a great opportunity to model

the behavior of a WI with great flexibility

− These rules are applied only when the Work Item is in that status or use that transition

More advanced scenarioCreate a bug workflow that supports specific custom needs

Microsoft Confidential45

Support triaging− The bug should start in Triage Status− A bug can transition from Triage to

Closed, this mean that the bug is Rejected

− We should track down the reason why the bug was rejected

− If the bug is accepted it goes into Active state

Requirement #1Requirement: Only administrators can reject a bugSolution: Simply restrict the transition from Triage to Closed only to Project Administrators

Requirement #2Requirement: Add a field called Rejected ReasonSolution: Simply add the field and update the UI

Requirement #3Requirement: Rejected Reason should be editable only when the bug transition from Triage to ClosedSolution: 1. Add for each status, except for closed, the

EMPTY rule to Rejected Reason2. Add the EMPTY rule for the field even for

transitions from Active to Closed and from Resolved to Closed

3. Add REQUIRED to transition from Triage to Closed

Requirement #3bisRequirement: Once the bug was rejected, no one should be able to modify the value of Rejected ReasonSolution: − Add WHENNOTCHANGED rule to the

Closed Status, based on System.State and applying the READONLY RULE

− This means “When the field System.State is not changed, Rejected Reason is readonly”

Requirement #4Requirement: When a bug is rejected, we want to insert the value “rejected” into the field “Resolved Reason”Solution: 1. Add Rejected to the list of ALLOWEDVALUES

for the Resolved Reason2. Add a COPY rule in Transition from Triage to

Closed to copy the value Rejected into Resolved Reason

3. Add a REQUIRED rule in the Closed Status for Resolved Reason

Requirement #5Requirement: Rejected Reason Should be mandatory only when Reason is different from DuplicateSolution: 1. Add a WHENNOT Rule to the Transition from

Triage to Closed1. Select the field System.Reason2. Select the value “duplicate”3. Add the REQUIRED Rule

TipsOther useful little tips for process customization

Microsoft Confidential53

Configure Check-in action− If you look at the scrum 1.0 template,

you will notice that during a check-in you can only “associate” a work item and you cannot close it

− This is the standard for the scrum process, but you can configure this behavior

Configure Check-in action− You should manually edit the bug.xml

file − Just insert a CheckIn action into a

transition − This means that a CheckIn action can

trigger this transition.− Es. Add this actino to transition from

Committed to Done

Configure Check-in action− Old version of PTE had a bug that

prevent actions to be saved from the UI editor, so it is better to edit file manually

− After this modification is done, the process allow a bug in status Committed to transition to Close, during a checkin

Commandline− If you want to modify a WIT of existing

process without power tools you can 1. Export the definition locally

witadmin exportwitd /collection:http://localhost:8080/tfs/defaultCollection /p:TestAgile /n:Bug /f:bug.xml

2. Modify the file3. Import the definition in the project

witadmin importwitd /collection:http://localhost:8080/tfs/defaultCollection /p:TestAgile /f:bug.xml

Microsoft Confidential58

QUESTION

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after

the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.