Configuring workflow tasks in TFS
I want to talk about how you can extend the standard process (workflow) for some elements in TFS 2010 (about 2011 will be later) when choosing an Agile template for a project. It is also interesting to hear the opinion of the habrasoobshchestvo about the pre-configuration of templates, how to customize the workfolw. Tell us how you do it, very interesting.
The standard out-of-box project settings are rather poor in my opinion and do not provide adequate transparency if it is necessary to monitor / control the work of the distributed team’s project or when the manager (manager or some other manager) wants to see how things are going with the tasks. Standard settings do not allow, in my opinion, to confidently talk about the current state of tasks.
A typical work board (task board) has more states than the basic settings of typical project management artifacts of which the Agile process is built: UserStory, Task, Bug. I think these are basic things that should be considered and further configured, which I actually did for myself and the team. In the story below, I will only touch on the setting of the state transition process, without affecting the properties of the elements. Those. no customization of appearance and properties will not be.
')
Before moving on, I will tell you what tools you need. All the described manipulations are performed on TFS2010 with the TFS Power Tools package installed. I also assume that you will need TFS administrator rights.
Let's start by looking at how it was.
In its original form, the state diagram of user stories look very poor and miserable.
The big version of the picture is here.
In essence, a user history can only be in three states, which, in my opinion, is clearly not enough, since the “natural” processes themselves with a user history (hereinafter simply “history”) are much more.
I suggest first to pay a little more attention to the notation. Red indicates the state in which the story may be. Indication of the fields inside the block indicates that they participate in some rules that must be fulfilled when entering this state. The minus marks fields that will be cleared, an asterisk modifier that this is optional.
Blue shows transitions between states. Each such block must contain the reason for the transition; without this, it will be impossible to save the configured scheme. The Actions section contains an indication of some trigger for triggering which a transition should be applied. Fields indicate which fields will be filled in automatically, or which fields will have to be filled in without fail. An asterisk indicates a field that will be automatically filled by the system. A plus denotes a required field.
The diagram must contain a single transition without an initial state.
Let's go back to our story. In the basic version, it contains only three states:
I think this is not enough, here are the reasons:
You can come up with more reasons, but this will probably already flow from your peculiarities of working on a user story.
How do I see the “correct” organization of the User story state system? I'll tell you now.
The tuned version certainly looks bigger and you should not consider all the conditions of transitions on the diagram. The main thing is to describe the essence of the transition, and the reasons can be described independently.
The big version of the picture is here .
Now the standard process of working on the story is as follows:
In my opinion, the state of history can be determined with greater accuracy, since the previous state of Active could determine too many activities, which would lead to interviewing too many people to find out the real state of affairs. So, consider the assignment of states.
It all starts with the idea or wishes of business analysts, or developers. Those. There is some idea that can be briefly expressed, and which should carry business benefits. This state is New .
There are still no tests, it is still not clear how this will fit into the project, labor costs are not clear - there is only a bare idea. This is a reason to talk. Only after the initial idea has been fixed can you proceed to other phases of work.
At this stage, questions may be sent to the initiators of the task in order to receive an answer about the importance of the idea put forward.
In this phase, a more detailed collection of requirements for the task begins, the consistency of requirements is checked. Analyzed what needs to be done to perform the task, as it will fall on the architecture of the application. There is a collection and analysis of data that will need to be collected and used. Data streams are defined. An approximate estimate of the complexity and time to complete the task is given. There must be some acceptance tests.
After the specified data has been collected and verified, a document has been written for the task, and the transition to the next phase takes place.
Responsible at this stage are analysts and partly developers, or tech.
I was a little deceiving, in the previous paragraph. By the beginning of this phase, tasks for developers should already be defined. These tasks are written by the developers themselves, determine their size and composition independently. This task status label indicates that all preliminary work has been completed and you can take history into development. In this case, you can be sure that the problems as a result of the development will not arise with a high degree of probability.
During the formation of specific tasks, various ambiguities may emerge and the task is sent for additional analysis. This process can be repeated several times. The more times it happens again, the less professional business analysts in my opinion are. Although some tasks may have technical limitations and then, it is normal if there is a return to the analysis of history.
At this stage, the demand comes from the project manager, when the story will be included in the sprint.
History in the process of active development. All tasks are clear, described and actively performed by team members.
If there are unforeseen problems that developers cannot resolve on their own within a short time, the task goes into the Hold state until the problems are resolved.
Demand in this state of history comes from the developers entirely.
After the developers have done the functionality and acceptance tests pass, the story goes into the Resolved state, which means being ready for acceptance testing and assessing whether everything was understood and done correctly. After this phase, the history can be sent for publication or for revision to the WIP state with the description of the missing functionality or with the description of the errors found.
Responsibility for the state of the history and demand from business analysts and testers, if any.
This state was introduced in order to make it easier to navigate, which has already gone to any versions for reception by real users and for future potential automation of writing change log applications.
It is actually an indicator. The essence is the same as in Resolved .
This state of history means that history has been accepted, all acceptance tests have passed, no one has any complaints.
Of course, the story from this state can be transferred to the WIP state, if testers or analysts were slow or stubborn enough to push additional implementation requirements into the story.
In my opinion, such states in user history more accurately characterize the process of working on it and can be more clearly formalized and divided areas of responsibility. With this approach, it is easy to find answers to the questions asked at the beginning of the section. You can clearly say what is being done in history, at least the number of people who will have to be poked with a stick in order to get a state of affairs is reduced.
After you have dealt with the states of user history, let's talk about tasks. The basic view of the process of working on a task is as follows:
I do not even know what to say. For such states nothing can be said, except that the story is made or not. This is clearly not enough in my opinion. Again, there are a million questions about the status of the task, whether it was taken by someone to work or not, if there are difficulties or not, and so on.
In such a scheme, it will be necessary to invent roundabout ways by which it will be necessary to determine the task at work or just waiting in the wings. For this, the Assignee field can be used, but if a task must be initially assigned to a specific person, this creates certain difficulties.
Without torturing you more, you can go to the kind that I use now in my work.
The tuned process contains 4 new task states that are designed to facilitate the task of tracking and writing queries for reports.
Now the typical scenario of working on a task will consist of 4 steps:
If the task requires clarification from analysts or the problem cannot be quickly resolved, then the Hold state is provided.
If the task is canceled, that is, the state is Abandoned . This allows you to quickly distinguish the implemented tasks from those that were shot for any reason, instead of analyzing the reasons why the task was closed.
All tasks are initially created with this status. Literally literally: The task is proposed for work. There are no names in the Assignee field yet, no charges. It can be seen that the task is waiting in the wings and nobody is doing it. Further, as already mentioned, two options are possible:
The task is being actively developed, you can be interested in progress, completion dates. Clearly visible who makes it.
For any reason, the task has become irrelevant and this status indicates that this task has not been implemented.
If the task requires clarification from analysts or the problem cannot be quickly resolved, then it falls into this state and remains in it until the problem is resolved. Then the task can only go to the Active state.
When the developer decides that the task is completed, he moves it to this state. The idea is that in this state tests should exist for the task, and the result should be workable.
The task enters this state after the testing process, or the acceptance of the entire history. If testing has not found flaws, then the task is considered closed.
Again, how much easier will it be to write requests to TFS and at one glance assess the status of tasks without additional tinkering in the texts of the task or interviewing the technical support or developers themselves.
The one who does nothing is not mistaken. So whatever you may say, there will be mistakes in the process of work, and it is required to track the work on them in the same way. Analyze, draw conclusions.
The basic state scheme for bugs is also not so smooth. Again, most of the questions stick to the initial phases of work on the bug. It is impossible to say unequivocally whether the work is underway to confirm the bug, or whether it is already in the process of correction. Or did he just come in and nobody was looking at him.
In order to get answers to these questions at a glance, I created a diagram that you can see below.
Big size pictures here
The main changes affected the beginning of the process. Now the main script looks like this:
Consider these states in more detail.
With this state, any record of suspicious program behavior begins. This is an indicator of the fact that someone considers the described behavior to be incorrect. However, this does not mean that the bug is taking place, maybe it is a feature or the unfortunate position of the planets in which impulses are caused to the processor or something else.
In this case, the correct behavior of the functional must be described from the point of view of the person who starts the bug.
After the bug record has been made, it is necessary at least to analyze the behavior of the program and make sure that the bug is actually reproduced on the developers or testers machines. As well as, a primary analysis is conducted of what is causing this behavior, so that the scope and timing of work on correcting undesirable behavior can be assessed. Based on the results of these works, tasks for the bug are created.
After analyzing the error, the bug either closes or becomes Active when it is taken into operation.
Another reason for the closure of a bug can be a misunderstanding of the nature of the bug and features, or the side effect, when the bug develops into an independent business requirement.
This condition indicates that the bug is in the process of repairing and the developers are busy eliminating the causes and / or consequences of the bug.
In general, similar to the same items from UserStory and Task. The condition indicates that the work is completed and you can re-accept testing. If unwanted behavior persists, the bug is transferred back to the Active state.
This state has been introduced in order to make it easier to navigate, which has already gone to any versions for reception by real users and for future potential automation of writing change log applications.
It is actually an indicator. The essence is the same as in Resolved .
Acceptance tests passed, the bug is eliminated, everyone is happy.
Such small improvements will allow you to more accurately control the progress of work on bugs, in my opinion.
I think that on the basis of such a scheme of work it will be easier to determine the responsibility of the roles and people who are involved in the project for more harmonious, transparent and productive work. In order not to distract each other with questions that TFS and a minute of time can answer.
Tell us how your workflow works? In general, it doesn’t matter which system is used, almost any modern bug tracking system can be tuned up.
About setting all this happiness some other time. Ready examples of templates can be found here .
The standard out-of-box project settings are rather poor in my opinion and do not provide adequate transparency if it is necessary to monitor / control the work of the distributed team’s project or when the manager (manager or some other manager) wants to see how things are going with the tasks. Standard settings do not allow, in my opinion, to confidently talk about the current state of tasks.
A typical work board (task board) has more states than the basic settings of typical project management artifacts of which the Agile process is built: UserStory, Task, Bug. I think these are basic things that should be considered and further configured, which I actually did for myself and the team. In the story below, I will only touch on the setting of the state transition process, without affecting the properties of the elements. Those. no customization of appearance and properties will not be.
')
Before moving on, I will tell you what tools you need. All the described manipulations are performed on TFS2010 with the TFS Power Tools package installed. I also assume that you will need TFS administrator rights.
Let's start by looking at how it was.
User story
Out-of-box settings
In its original form, the state diagram of user stories look very poor and miserable.
The big version of the picture is here.
In essence, a user history can only be in three states, which, in my opinion, is clearly not enough, since the “natural” processes themselves with a user history (hereinafter simply “history”) are much more.
I suggest first to pay a little more attention to the notation. Red indicates the state in which the story may be. Indication of the fields inside the block indicates that they participate in some rules that must be fulfilled when entering this state. The minus marks fields that will be cleared, an asterisk modifier that this is optional.
Blue shows transitions between states. Each such block must contain the reason for the transition; without this, it will be impossible to save the configured scheme. The Actions section contains an indication of some trigger for triggering which a transition should be applied. Fields indicate which fields will be filled in automatically, or which fields will have to be filled in without fail. An asterisk indicates a field that will be automatically filled by the system. A plus denotes a required field.
The diagram must contain a single transition without an initial state.
Let's go back to our story. In the basic version, it contains only three states:
- Active,
- Resolved,
- Closed.
I think this is not enough, here are the reasons:
- It is impossible to separate a new story, just created, from the one that is in the works.
- It is impossible to determine the type of work with history, the formalization of requirements, development, testing, or something else.
- It is impossible to suspend the work on history if new aspects of implementation have emerged that require additional solutions.
- It is impossible to cancel a story, denoting it as lost meaning.
You can come up with more reasons, but this will probably already flow from your peculiarities of working on a user story.
How do I see the “correct” organization of the User story state system? I'll tell you now.
Customized
The tuned version certainly looks bigger and you should not consider all the conditions of transitions on the diagram. The main thing is to describe the essence of the transition, and the reasons can be described independently.
The big version of the picture is here .
Now the standard process of working on the story is as follows:
- New
- Analysis
- Ready For Development
- Work In Progress (WIP)
- Resolved
- Published
- Closed
- + Hold
In my opinion, the state of history can be determined with greater accuracy, since the previous state of Active could determine too many activities, which would lead to interviewing too many people to find out the real state of affairs. So, consider the assignment of states.
New
It all starts with the idea or wishes of business analysts, or developers. Those. There is some idea that can be briefly expressed, and which should carry business benefits. This state is New .
There are still no tests, it is still not clear how this will fit into the project, labor costs are not clear - there is only a bare idea. This is a reason to talk. Only after the initial idea has been fixed can you proceed to other phases of work.
At this stage, questions may be sent to the initiators of the task in order to receive an answer about the importance of the idea put forward.
Analysis
In this phase, a more detailed collection of requirements for the task begins, the consistency of requirements is checked. Analyzed what needs to be done to perform the task, as it will fall on the architecture of the application. There is a collection and analysis of data that will need to be collected and used. Data streams are defined. An approximate estimate of the complexity and time to complete the task is given. There must be some acceptance tests.
After the specified data has been collected and verified, a document has been written for the task, and the transition to the next phase takes place.
Responsible at this stage are analysts and partly developers, or tech.
Ready For Development
I was a little deceiving, in the previous paragraph. By the beginning of this phase, tasks for developers should already be defined. These tasks are written by the developers themselves, determine their size and composition independently. This task status label indicates that all preliminary work has been completed and you can take history into development. In this case, you can be sure that the problems as a result of the development will not arise with a high degree of probability.
During the formation of specific tasks, various ambiguities may emerge and the task is sent for additional analysis. This process can be repeated several times. The more times it happens again, the less professional business analysts in my opinion are. Although some tasks may have technical limitations and then, it is normal if there is a return to the analysis of history.
At this stage, the demand comes from the project manager, when the story will be included in the sprint.
WIP
History in the process of active development. All tasks are clear, described and actively performed by team members.
If there are unforeseen problems that developers cannot resolve on their own within a short time, the task goes into the Hold state until the problems are resolved.
Demand in this state of history comes from the developers entirely.
Resolved
After the developers have done the functionality and acceptance tests pass, the story goes into the Resolved state, which means being ready for acceptance testing and assessing whether everything was understood and done correctly. After this phase, the history can be sent for publication or for revision to the WIP state with the description of the missing functionality or with the description of the errors found.
Responsibility for the state of the history and demand from business analysts and testers, if any.
Published
This state was introduced in order to make it easier to navigate, which has already gone to any versions for reception by real users and for future potential automation of writing change log applications.
It is actually an indicator. The essence is the same as in Resolved .
Closed
This state of history means that history has been accepted, all acceptance tests have passed, no one has any complaints.
Of course, the story from this state can be transferred to the WIP state, if testers or analysts were slow or stubborn enough to push additional implementation requirements into the story.
In my opinion, such states in user history more accurately characterize the process of working on it and can be more clearly formalized and divided areas of responsibility. With this approach, it is easy to find answers to the questions asked at the beginning of the section. You can clearly say what is being done in history, at least the number of people who will have to be poked with a stick in order to get a state of affairs is reduced.
Task
Out-of-box settings
After you have dealt with the states of user history, let's talk about tasks. The basic view of the process of working on a task is as follows:
I do not even know what to say. For such states nothing can be said, except that the story is made or not. This is clearly not enough in my opinion. Again, there are a million questions about the status of the task, whether it was taken by someone to work or not, if there are difficulties or not, and so on.
In such a scheme, it will be necessary to invent roundabout ways by which it will be necessary to determine the task at work or just waiting in the wings. For this, the Assignee field can be used, but if a task must be initially assigned to a specific person, this creates certain difficulties.
Without torturing you more, you can go to the kind that I use now in my work.
Customized
The tuned process contains 4 new task states that are designed to facilitate the task of tracking and writing queries for reports.
Now the typical scenario of working on a task will consist of 4 steps:
- Proposed
- Active
- Resolved
- Closed
If the task requires clarification from analysts or the problem cannot be quickly resolved, then the Hold state is provided.
If the task is canceled, that is, the state is Abandoned . This allows you to quickly distinguish the implemented tasks from those that were shot for any reason, instead of analyzing the reasons why the task was closed.
Proposed
All tasks are initially created with this status. Literally literally: The task is proposed for work. There are no names in the Assignee field yet, no charges. It can be seen that the task is waiting in the wings and nobody is doing it. Further, as already mentioned, two options are possible:
Active
The task is being actively developed, you can be interested in progress, completion dates. Clearly visible who makes it.
Abandoned
For any reason, the task has become irrelevant and this status indicates that this task has not been implemented.
Hold
If the task requires clarification from analysts or the problem cannot be quickly resolved, then it falls into this state and remains in it until the problem is resolved. Then the task can only go to the Active state.
Resolved
When the developer decides that the task is completed, he moves it to this state. The idea is that in this state tests should exist for the task, and the result should be workable.
Closed
The task enters this state after the testing process, or the acceptance of the entire history. If testing has not found flaws, then the task is considered closed.
Again, how much easier will it be to write requests to TFS and at one glance assess the status of tasks without additional tinkering in the texts of the task or interviewing the technical support or developers themselves.
Bug
Out-of-box settings
The one who does nothing is not mistaken. So whatever you may say, there will be mistakes in the process of work, and it is required to track the work on them in the same way. Analyze, draw conclusions.
The basic state scheme for bugs is also not so smooth. Again, most of the questions stick to the initial phases of work on the bug. It is impossible to say unequivocally whether the work is underway to confirm the bug, or whether it is already in the process of correction. Or did he just come in and nobody was looking at him.
In order to get answers to these questions at a glance, I created a diagram that you can see below.
Customized
Big size pictures here
The main changes affected the beginning of the process. Now the main script looks like this:
- Proposed
- Analysis
- Active
- Resolved
- Published
- Closed
Consider these states in more detail.
Proposed
With this state, any record of suspicious program behavior begins. This is an indicator of the fact that someone considers the described behavior to be incorrect. However, this does not mean that the bug is taking place, maybe it is a feature or the unfortunate position of the planets in which impulses are caused to the processor or something else.
In this case, the correct behavior of the functional must be described from the point of view of the person who starts the bug.
Analysis
After the bug record has been made, it is necessary at least to analyze the behavior of the program and make sure that the bug is actually reproduced on the developers or testers machines. As well as, a primary analysis is conducted of what is causing this behavior, so that the scope and timing of work on correcting undesirable behavior can be assessed. Based on the results of these works, tasks for the bug are created.
After analyzing the error, the bug either closes or becomes Active when it is taken into operation.
Another reason for the closure of a bug can be a misunderstanding of the nature of the bug and features, or the side effect, when the bug develops into an independent business requirement.
Active
This condition indicates that the bug is in the process of repairing and the developers are busy eliminating the causes and / or consequences of the bug.
Resolved
In general, similar to the same items from UserStory and Task. The condition indicates that the work is completed and you can re-accept testing. If unwanted behavior persists, the bug is transferred back to the Active state.
Published
This state has been introduced in order to make it easier to navigate, which has already gone to any versions for reception by real users and for future potential automation of writing change log applications.
It is actually an indicator. The essence is the same as in Resolved .
Closed
Acceptance tests passed, the bug is eliminated, everyone is happy.
Such small improvements will allow you to more accurately control the progress of work on bugs, in my opinion.
Total
I think that on the basis of such a scheme of work it will be easier to determine the responsibility of the roles and people who are involved in the project for more harmonious, transparent and productive work. In order not to distract each other with questions that TFS and a minute of time can answer.
Tell us how your workflow works? In general, it doesn’t matter which system is used, almost any modern bug tracking system can be tuned up.
About setting all this happiness some other time. Ready examples of templates can be found here .
Source: https://habr.com/ru/post/147294/
All Articles