About flexible planning and work management in TFS 11 Beta
Let's get acquainted with the new planning tools that appeared in TFS 11 Beta , which can be used in the development of Windows, Web, mobile, cloud and cross-platform applications.
Since TFS allows you to use several process templates to support different methodologies for organizing the development process, we first consider only one of them, the most popular SCRUM.
For acquaintance to us can be necessary: ​​an image of the virtual machine , the manual to laboratory works , a practical lesson in Russian MSDN or this article is your choice.
')
Topic capture plan:
• Requirements Description (Backlog)
• Iteration planning
• Work planning
• Workload of performers
The context of planning and work management in the 11th version is the “Team”. This pleasant innovation makes it easier to organize the work of several teams on a single project. Thus, even large-scale projects can be implemented according to flexible methodologies, if we apply the approaches to scaling teams. However, we now focus on the work of one team.
For a team, it is necessary to determine:
• List of team members
• The set of subsystems that the command is working on.
• Iterations to which team work is tied.
The team on its website will see only those elements that relate to its subsystems and iterations, so if suddenly the team does not see the task, check whether the task is assigned to one of the command subsystems. To shorten the article, we will assume that the team has already been created.
So, from the main page we can go to the Product Backlog - a list of new product requirements. Those requirements that are already implemented and closed, go to the Past section and are not displayed. Those that are currently in the work - in the section Current.
SCRUM assumes maintaining a linear list of requirements, therefore the web interface implements just such an approach. However, no one bothers to build a hierarchical relationship between the backlog elements and work with such a tree in Visual Studio or via the web using queries.
The list should contain all the requirements - both functional and non-functional. The fastest way to add a new entry is to enter a title and click the Add button. The entry will immediately appear in the list, but we will not see any additional parameters. If you click the Add button when the Title line is empty, you will see the full parameter input dialog:
Here we are now interested in the Effort field - this is the field where the relative assessment of the complexity of the implementation of this requirement is introduced. The rating is entered in conditional units - Storypoints (“in parrots” - folk), which are obtained during the team evaluation. The SCRUM methodology uses Agile Poker for this, which may well be the topic for a small article. The tools for such an assessment are: a team, an enclosed space, a table, a deck of Agile Poker cards. In TFS, this process is not supported instrumentally in any way, and this is correct, otherwise it will not be Agile Poker, but box by correspondence, because the most important thing in it is the discussion of the team between iterations of the convergence assessment. Those. in the Effort field we enter one figure already obtained as a result of planning. These are not hours, not days, not money, not lines of code, not classes, this is an approximate relative conventionality. Storypoints. Sepulki .
However, after the first successful iteration, we have data on how many approximately Storypoints the team manages to implement in the iteration period - Velocity:
The Velocity indicator can be used for different purposes: to plan the amount of work for a new iteration, to determine the amount of payment for work, to measure it in the process of constantly improving the efficiency of the team’s work. One of the options you need to cross out necessarily.
By turning on the Forecast tool, we can see how approximately our labor-intensive requirements fit into the upcoming iterations:
Elements in this list can be moved up and down with the mouse (change the Order), other estimates of the current Velocity can be entered, we can specify a specific iteration (Sprint) in the Iteration field:
But before specifying the iteration, we must approve the requirements. Requirements (they are sometimes referred to as the “Wishlist”) are collected by everyone who comes from users, businesses, administrators, design teams, etc. They fall into the New state. After that, it is decided whether this requirement is approved (Approved) or rejected (Removed):
Rejected requirements leave the backlog, new and approved remain.
Before starting a new iteration, the team selects the requirements for implementation based on the priorities, its current performance, the wishes of the product owner, and commits to fulfill them. Requirements are transferred from the Approved to Commited state and also disappear from the Wishlist list and fall into the Sprint Backlog — a plan for a specific iteration.
In order for the requirement (and its tasks) to appear on the task board of the current iteration, the requirement (tasks) must have this iteration indicated (see above).
The board displays the task stickers that the team is working on to implement the selected requirements.
The implementation of each requirement may consist in solving several tasks: writing business logic, creating interfaces in clients for each of the platforms, describing tests, creating reference documentation, etc.
A non-functional requirement, like any other, requires consideration and efforts to implement it. For example, creating test infrastructure and performance tests - for performance requirements, etc.
The implementation of the requirement may take several iterations, while it is recommended not to do a separate task longer than 2–3 days.
Tasks can be created here, on the board, then they are automatically linked to the requirement, the subsystem, and the current iteration:
Immediately, in the field Remaining Work, you can enter the assessment in man-hours. Thus, the tool allows you to combine relative methods for estimating requirements and hourly load planning.
A new task will appear in the To Do status and the assessment of the remaining work will be added to the total assessment of the work on demand:
On the board, we can select the performers (or the performer can choose a task for himself), drag it with the mouse to the In Progress state, and at the end - to Done.
There are interesting features associated with easy task management in Visual Studio. This is a list of your active tasks in Team Explorer, and their association with changes in the source code and automatically switching to a completed state during check-in, but the article is too long.
Having a list of works, the duration of the iteration and estimates in hours of work, we can see the graph of the dynamics of reduction of the remaining work (schedule of "combustion of work"):
Now we have everything to return to the planning download artists.
Last glance at the board of works, but already grouped by performers:
Let's go to Backlog, select the current sprint and see the same tasks, but in the form of a tree and with a brief analysis of the team load on the diagram on the right:
We see the total workload of the whole team (Team 52 of 54h).
The breakdown of work by category (Work By: Activity) - we did not use this categorization, but there is an opportunity to assign each task to any category:
And then we see the workload of our performers. The congestion of Brian Keller is highlighted in red, to which an audit task has just been added.
To solve the problem, I go to Brian's manager and ask him to work on my project not 4 hours a day, as we agreed earlier, but 5. I will enter the information on the availability of resources on the capacity tab:
Please note that I also managed to keep intact the previously planned one-day country team-building.
On this day, we are scheduled to race in the gulf foursome. They say teamwork is well developed ...
UPD: It turns out that there is even a more detailed article on MSDN . But this one is mine! =)
Since TFS allows you to use several process templates to support different methodologies for organizing the development process, we first consider only one of them, the most popular SCRUM.
For acquaintance to us can be necessary: ​​an image of the virtual machine , the manual to laboratory works , a practical lesson in Russian MSDN or this article is your choice.
')
Topic capture plan:
• Requirements Description (Backlog)
• Iteration planning
• Work planning
• Workload of performers
The context of planning and work management in the 11th version is the “Team”. This pleasant innovation makes it easier to organize the work of several teams on a single project. Thus, even large-scale projects can be implemented according to flexible methodologies, if we apply the approaches to scaling teams. However, we now focus on the work of one team.
For a team, it is necessary to determine:
• List of team members
• The set of subsystems that the command is working on.
• Iterations to which team work is tied.
The team on its website will see only those elements that relate to its subsystems and iterations, so if suddenly the team does not see the task, check whether the task is assigned to one of the command subsystems. To shorten the article, we will assume that the team has already been created.
Description of requirements
So, from the main page we can go to the Product Backlog - a list of new product requirements. Those requirements that are already implemented and closed, go to the Past section and are not displayed. Those that are currently in the work - in the section Current.
SCRUM assumes maintaining a linear list of requirements, therefore the web interface implements just such an approach. However, no one bothers to build a hierarchical relationship between the backlog elements and work with such a tree in Visual Studio or via the web using queries.
The list should contain all the requirements - both functional and non-functional. The fastest way to add a new entry is to enter a title and click the Add button. The entry will immediately appear in the list, but we will not see any additional parameters. If you click the Add button when the Title line is empty, you will see the full parameter input dialog:
Iteration planning
Here we are now interested in the Effort field - this is the field where the relative assessment of the complexity of the implementation of this requirement is introduced. The rating is entered in conditional units - Storypoints (“in parrots” - folk), which are obtained during the team evaluation. The SCRUM methodology uses Agile Poker for this, which may well be the topic for a small article. The tools for such an assessment are: a team, an enclosed space, a table, a deck of Agile Poker cards. In TFS, this process is not supported instrumentally in any way, and this is correct, otherwise it will not be Agile Poker, but box by correspondence, because the most important thing in it is the discussion of the team between iterations of the convergence assessment. Those. in the Effort field we enter one figure already obtained as a result of planning. These are not hours, not days, not money, not lines of code, not classes, this is an approximate relative conventionality. Storypoints. Sepulki .
However, after the first successful iteration, we have data on how many approximately Storypoints the team manages to implement in the iteration period - Velocity:
The Velocity indicator can be used for different purposes: to plan the amount of work for a new iteration, to determine the amount of payment for work, to measure it in the process of constantly improving the efficiency of the team’s work. One of the options you need to cross out necessarily.
By turning on the Forecast tool, we can see how approximately our labor-intensive requirements fit into the upcoming iterations:
Elements in this list can be moved up and down with the mouse (change the Order), other estimates of the current Velocity can be entered, we can specify a specific iteration (Sprint) in the Iteration field:
But before specifying the iteration, we must approve the requirements. Requirements (they are sometimes referred to as the “Wishlist”) are collected by everyone who comes from users, businesses, administrators, design teams, etc. They fall into the New state. After that, it is decided whether this requirement is approved (Approved) or rejected (Removed):
Rejected requirements leave the backlog, new and approved remain.
Before starting a new iteration, the team selects the requirements for implementation based on the priorities, its current performance, the wishes of the product owner, and commits to fulfill them. Requirements are transferred from the Approved to Commited state and also disappear from the Wishlist list and fall into the Sprint Backlog — a plan for a specific iteration.
Work planning
In order for the requirement (and its tasks) to appear on the task board of the current iteration, the requirement (tasks) must have this iteration indicated (see above).
The board displays the task stickers that the team is working on to implement the selected requirements.
The implementation of each requirement may consist in solving several tasks: writing business logic, creating interfaces in clients for each of the platforms, describing tests, creating reference documentation, etc.
A non-functional requirement, like any other, requires consideration and efforts to implement it. For example, creating test infrastructure and performance tests - for performance requirements, etc.
The implementation of the requirement may take several iterations, while it is recommended not to do a separate task longer than 2–3 days.
Tasks can be created here, on the board, then they are automatically linked to the requirement, the subsystem, and the current iteration:
Immediately, in the field Remaining Work, you can enter the assessment in man-hours. Thus, the tool allows you to combine relative methods for estimating requirements and hourly load planning.
A new task will appear in the To Do status and the assessment of the remaining work will be added to the total assessment of the work on demand:
On the board, we can select the performers (or the performer can choose a task for himself), drag it with the mouse to the In Progress state, and at the end - to Done.
There are interesting features associated with easy task management in Visual Studio. This is a list of your active tasks in Team Explorer, and their association with changes in the source code and automatically switching to a completed state during check-in, but the article is too long.
Having a list of works, the duration of the iteration and estimates in hours of work, we can see the graph of the dynamics of reduction of the remaining work (schedule of "combustion of work"):
Now we have everything to return to the planning download artists.
Workload of performers:
Last glance at the board of works, but already grouped by performers:
Let's go to Backlog, select the current sprint and see the same tasks, but in the form of a tree and with a brief analysis of the team load on the diagram on the right:
We see the total workload of the whole team (Team 52 of 54h).
The breakdown of work by category (Work By: Activity) - we did not use this categorization, but there is an opportunity to assign each task to any category:
And then we see the workload of our performers. The congestion of Brian Keller is highlighted in red, to which an audit task has just been added.
To solve the problem, I go to Brian's manager and ask him to work on my project not 4 hours a day, as we agreed earlier, but 5. I will enter the information on the availability of resources on the capacity tab:
Please note that I also managed to keep intact the previously planned one-day country team-building.
On this day, we are scheduled to race in the gulf foursome. They say teamwork is well developed ...
UPD: It turns out that there is even a more detailed article on MSDN . But this one is mine! =)
Source: https://habr.com/ru/post/143268/
All Articles