Development management in projects for the creation of complex software systems. Experience using MS Project and Team Foundation Server
Many programmers, as they develop, choose for themselves the path of development management, regretfully limiting themselves in the creative process of learning new programming languages ​​and technologies.
And, starting from this moment, we, as managers, are already compelled to struggle with the complexity of developing software projects, the complexity of their homogeneous understanding by all participants and the complexity of taking into account changes that occur constantly with changes in the external environment. Focusing on the prophetic statement of Brooks that there is no silver bullet, we are still looking for a way to find a management technique that increases, even if not an order of magnitude, productivity, reliability and simplicity in software development.
So, each of the managers knows what a Gantt chart is, and everyone used MS Project. Even more readers, programmers, uses a task management system. And almost all non-lone programmers use source code management.
')
We are faced with a quite pragmatic task to ensure a single development process, when taking into account each new change in requirements, we can clearly see the change in project parameters.
We formulate this problem at the application level. Imagine a project as a set of stages, which in turn consist of a list of high-level tasks, each of which includes a number of user scenarios, store stories, and those are decomposed into tasks. We will purposely continue to use in the article such a mixed terminology, not either GOST or Agile, because the customers look at the project at about the level of detail of the stages, and they are not interested in knowing what Agile is, and the developers look at the tasks at about The level of tasks and they, in turn, are not interested in thinking about GOST.
Further, we must ensure that when new data about the project is received, replanning, taking into account all available information, will pass as quickly as possible, and we can get the most rapid feedback on the project as a whole, to provide it to the Customer (or take into account our own marketing expectations own product).
What tools should we use now to achieve the goal? I present the following selection criteria for these tools:
1) A Gantt chart is needed as a visual tool and as a planning tool.
2) Tools should allow decomposition of high-level tasks into user scenarios, and their tasks into programmers and analysts.
3) Tools should provide an automated way for interconnecting changes between tasks in the high-level Gantt chart and tasks. For example, if we make a mistake with the assessment of one of the tasks, and the programmer took twice as much time to complete the task, this could lead to an increase in the duration of one of the high-level stages. And since we don’t want the deadlines of the high-level stage to be broken, we need to analyze the critical path in order to rebalance the requirements and resources. Our tools, due to the interrelationships between the levels, should help us see the problem with possible deadlines on the Gantt chart.
4) It is also desirable to track the connections between the tasks of the programmers and the source code in the source code management system.
5) The source control system, in turn, must support the branching model, for example, a git + gitflow bundle will do.
6) In the task management system, you must be able to note the actually assigned time and take into account the amount of time remaining, as well as receive progress reports
There are several options for choosing such tools, consider three of them that seem to us the most suitable:
1) MS Project + Team Foundation Server
2) Jira
3) Redmine
Jira and Redmine will be discussed in the following articles, and in this we will focus on MS Project + Team Foundation Server (+ Visual Studio).
Installing Team Foundation Server 2013 is trivial in itself. Install SQL Server in advance to use it as a repository. Note that to configure TFS, you need to use both the Web application Control Panel, accessible via http: // hostname: 8080 / tfs (default), and the Windows Administration Console application. For example, from the Control Panel, you can distribute access to collections, and you can create collections only in the Administration Console.
Suppose that we work for the State Office, and after the meeting we received the task in a week to roll out the site, which will be able to keep “all citizens of our country who go there” and a mobile application under load.
Work is work, in Project we create the following plan:
In this regard, we see puzzles on developers, analysts, designer, layout designer, tester and engineer. Tasks are balanced in order of sequence, do not overlap for individual performers, contain in one of the cases a gap for effective load distribution.
All specialists are full of energy and rush into battle, so you need to get a list of tasks in TFS from this plan. In TFS, a Collection must first be created, a Project has been created in it (and it should be created in Visual Studio, I selected MSF for Agile Software Development 2013.4 as the process template).
To configure the upload in TFS, go to the Project tab Team, which appears after installing TFS, and select the team project:
Next we publish the tasks:
... and face the problem:
Well, Kaneshna, how could I not immediately have guessed: we must in fact determine the types of elements for TFS! To do this, you need to add the Work Item Type column to the Project, which appeared there after installing TFS. Please note that for proper grouping of elements in TFS, the type of embedding tasks must have a User Story, and the tasks they contain have a Task.
The screenshot shows that I added not only the Work Item Type, but also the Area Path and Iteration Path. These fields are also necessary to create tasks in TFS, they characterize, respectively, the module in the system being developed and the version.
You need to bind the specified cells by meaning, ensuring that both the corresponding resources are in AD, and the Area Path, and Iteration Path are created:
... and try to publish the data again. To view the tasks, you must also use Visual Studio, everything is standard, connect to the Collection, Project and execute the query (Query) in order to see the list of tasks
You may also notice that in the Work Item ID column in the Project, the corresponding item identifiers have appeared, which can then be used to synchronize data between Project and TFS.
Instead of the planned labor costs, zeros appeared in the Duration column. The fact is that the Work Item in TFS uses other fields to determine task durations: Original Estimate, Completed Work and Remaining Work. According to the sense of duration, in the first approximation, the Original Estimate field is the most appropriate, which is mapped on the Basic Work Costs field in Project
And, since we got to the mapping, that is, the correspondence between the columns of the Project and the TFS fields, we briefly mention how it can be changed. In one article on MSDN , the Project fields mapping file is described, and in another article , the export and import of this file to TFS is described.
And in order to deal with the transfer of the duration of labor costs, we use the materials of another article with MDSN ), because no documentation here to understand. Set, as recommended in this article, the basic settings of the scheduler in the Project (File-> Options-> Schedule)
... and determine, based on the duration of the tasks, the base labor costs
As a result, the base labor column will be filled with the corresponding values.
And then we publish the changes in TFS.
So we got a Gantt chart in MS Project, and in TFS, a set of related tasks that specialists can access through familiar tools, that is, through Visual Studio.
All items of our requirements are met? Yes, version control system is built into TFS, which can also be replaced with GIT, so clauses 4 and 5 are automatically supported from the list of criteria in such a scheme as well. And everything seems to be good, if not
Criticism is not the most pleasant thing, but in this case, objectivity requires us to format the article. Still, this is not the Project and TFS Tutorial, and we should consider this bundle as a tool that really reduces labor costs when working with a plan, and for this we need to avoid unnecessary difficulties in using tools.
Consider a few cases that arise during the actual use of Project and TFS.
Suppose that a bug has been added to the current iteration in TFS, which does not exist in nature. Errors happen, nothing can be done about it. Or the bug was not a bug, but features. That you have not happened? The analyst read his statement to the end and understood something, the tester opened all the files associated with the task, the programmer decided to ask all the questions that had been torturing him for a long time (let's not think about TDD, a conditional example).
What to do in this case in our planning? The bug can be safely closed in TFS, but if we update the changes in the Project (Refresh), then it will not disappear from the plan anywhere. It seems to be logical, entities are not deleted anywhere. And what about a single project plan? We'll have to rule everything by hand.
Conclusion. If the Work Item is mistakenly added to TFS, it will not automatically be removed from Project.
Also from experience ... Remember the customer from the beginning of the article? At the next meeting, he shortened the time to iterate from two weeks to a week. It is clear that we must go and work as soon as possible, but we want to update the plan first. Go down and reduce the iteration in TFS. How did it affect the hacks? Not reflected. Tasks do not understand that they do not fit into the time frame of iterations. Okay, microsoft, let's upload changes to Project.
And what has changed? Nothing, Project heard only about the names of iterations in TFS and does not know anything about the timing.
Conclusion. When you change the timing of the iteration to deal with the timing of the task will have to be in manual mode.
I note that here, on Habré-Megamind, there is an excellent article by the user ganouver , in which he describes how to use Project to manage projects. In particular, there you can read about balancing the plan, the ingenious tactics of dealing with the Project, and in the comments find the phrase that
In addition to changing the types of Work Item, removing unnecessary tasks, etc., in a real project, the plan can change almost completely, both in terms of the composition of tasks in high-level tasks (story), and in duration and composition of iterations. What does Project and TFS offer us to take into account these changes, to morph the tasks, re-balance the plan, calculate resources, take into account changes in the duration of iterations and prepare a new plan for releases? Nothing offers.
The solution from Microsoft for project management and software development in the form of joint use of Project + TFS + Visual Studio products can be used for one-time work planning and is not well suited for continuous automated replaning.
Reflecting on whether to publish an article with the conclusion that the Project + TFS technology stack in question is not very suitable for solving the set task, I decided that a negative experience is also an experience, and it will at least allow readers to make their own choice.
So, the task of complete development management on these tools can be solved only at the first drawing up of a plan and then on the basis of semi-automated labor of the manager or his assistant, and any replaning will take time for routine operations.
In the following articles we will consider other toolkits, the first candidates being Jira and Redmine.
And, starting from this moment, we, as managers, are already compelled to struggle with the complexity of developing software projects, the complexity of their homogeneous understanding by all participants and the complexity of taking into account changes that occur constantly with changes in the external environment. Focusing on the prophetic statement of Brooks that there is no silver bullet, we are still looking for a way to find a management technique that increases, even if not an order of magnitude, productivity, reliability and simplicity in software development.
So, each of the managers knows what a Gantt chart is, and everyone used MS Project. Even more readers, programmers, uses a task management system. And almost all non-lone programmers use source code management.
')
We are faced with a quite pragmatic task to ensure a single development process, when taking into account each new change in requirements, we can clearly see the change in project parameters.
We formulate this problem at the application level. Imagine a project as a set of stages, which in turn consist of a list of high-level tasks, each of which includes a number of user scenarios, store stories, and those are decomposed into tasks. We will purposely continue to use in the article such a mixed terminology, not either GOST or Agile, because the customers look at the project at about the level of detail of the stages, and they are not interested in knowing what Agile is, and the developers look at the tasks at about The level of tasks and they, in turn, are not interested in thinking about GOST.
Further, we must ensure that when new data about the project is received, replanning, taking into account all available information, will pass as quickly as possible, and we can get the most rapid feedback on the project as a whole, to provide it to the Customer (or take into account our own marketing expectations own product).
What tools should we use now to achieve the goal? I present the following selection criteria for these tools:
1) A Gantt chart is needed as a visual tool and as a planning tool.
2) Tools should allow decomposition of high-level tasks into user scenarios, and their tasks into programmers and analysts.
3) Tools should provide an automated way for interconnecting changes between tasks in the high-level Gantt chart and tasks. For example, if we make a mistake with the assessment of one of the tasks, and the programmer took twice as much time to complete the task, this could lead to an increase in the duration of one of the high-level stages. And since we don’t want the deadlines of the high-level stage to be broken, we need to analyze the critical path in order to rebalance the requirements and resources. Our tools, due to the interrelationships between the levels, should help us see the problem with possible deadlines on the Gantt chart.
4) It is also desirable to track the connections between the tasks of the programmers and the source code in the source code management system.
5) The source control system, in turn, must support the branching model, for example, a git + gitflow bundle will do.
6) In the task management system, you must be able to note the actually assigned time and take into account the amount of time remaining, as well as receive progress reports
There are several options for choosing such tools, consider three of them that seem to us the most suitable:
1) MS Project + Team Foundation Server
2) Jira
3) Redmine
Jira and Redmine will be discussed in the following articles, and in this we will focus on MS Project + Team Foundation Server (+ Visual Studio).
Using MS Project and Team Foundation Server
Installing Team Foundation Server 2013 is trivial in itself. Install SQL Server in advance to use it as a repository. Note that to configure TFS, you need to use both the Web application Control Panel, accessible via http: // hostname: 8080 / tfs (default), and the Windows Administration Console application. For example, from the Control Panel, you can distribute access to collections, and you can create collections only in the Administration Console.
Suppose that we work for the State Office, and after the meeting we received the task in a week to roll out the site, which will be able to keep “all citizens of our country who go there” and a mobile application under load.
Work is work, in Project we create the following plan:
In this regard, we see puzzles on developers, analysts, designer, layout designer, tester and engineer. Tasks are balanced in order of sequence, do not overlap for individual performers, contain in one of the cases a gap for effective load distribution.
All specialists are full of energy and rush into battle, so you need to get a list of tasks in TFS from this plan. In TFS, a Collection must first be created, a Project has been created in it (and it should be created in Visual Studio, I selected MSF for Agile Software Development 2013.4 as the process template).
To configure the upload in TFS, go to the Project tab Team, which appears after installing TFS, and select the team project:
Next we publish the tasks:
... and face the problem:
Well, Kaneshna, how could I not immediately have guessed: we must in fact determine the types of elements for TFS! To do this, you need to add the Work Item Type column to the Project, which appeared there after installing TFS. Please note that for proper grouping of elements in TFS, the type of embedding tasks must have a User Story, and the tasks they contain have a Task.
The screenshot shows that I added not only the Work Item Type, but also the Area Path and Iteration Path. These fields are also necessary to create tasks in TFS, they characterize, respectively, the module in the system being developed and the version.
You need to bind the specified cells by meaning, ensuring that both the corresponding resources are in AD, and the Area Path, and Iteration Path are created:
... and try to publish the data again. To view the tasks, you must also use Visual Studio, everything is standard, connect to the Collection, Project and execute the query (Query) in order to see the list of tasks
You may also notice that in the Work Item ID column in the Project, the corresponding item identifiers have appeared, which can then be used to synchronize data between Project and TFS.
Instead of the planned labor costs, zeros appeared in the Duration column. The fact is that the Work Item in TFS uses other fields to determine task durations: Original Estimate, Completed Work and Remaining Work. According to the sense of duration, in the first approximation, the Original Estimate field is the most appropriate, which is mapped on the Basic Work Costs field in Project
And, since we got to the mapping, that is, the correspondence between the columns of the Project and the TFS fields, we briefly mention how it can be changed. In one article on MSDN , the Project fields mapping file is described, and in another article , the export and import of this file to TFS is described.
And in order to deal with the transfer of the duration of labor costs, we use the materials of another article with MDSN ), because no documentation here to understand. Set, as recommended in this article, the basic settings of the scheduler in the Project (File-> Options-> Schedule)
... and determine, based on the duration of the tasks, the base labor costs
As a result, the base labor column will be filled with the corresponding values.
And then we publish the changes in TFS.
So we got a Gantt chart in MS Project, and in TFS, a set of related tasks that specialists can access through familiar tools, that is, through Visual Studio.
All items of our requirements are met? Yes, version control system is built into TFS, which can also be replaced with GIT, so clauses 4 and 5 are automatically supported from the list of criteria in such a scheme as well. And everything seems to be good, if not
A barrel of tar, or Microsoft, well, how is that?
Criticism is not the most pleasant thing, but in this case, objectivity requires us to format the article. Still, this is not the Project and TFS Tutorial, and we should consider this bundle as a tool that really reduces labor costs when working with a plan, and for this we need to avoid unnecessary difficulties in using tools.
Consider a few cases that arise during the actual use of Project and TFS.
Case 1. By mistake added a non-existent bug.
Suppose that a bug has been added to the current iteration in TFS, which does not exist in nature. Errors happen, nothing can be done about it. Or the bug was not a bug, but features. That you have not happened? The analyst read his statement to the end and understood something, the tester opened all the files associated with the task, the programmer decided to ask all the questions that had been torturing him for a long time (let's not think about TDD, a conditional example).
What to do in this case in our planning? The bug can be safely closed in TFS, but if we update the changes in the Project (Refresh), then it will not disappear from the plan anywhere. It seems to be logical, entities are not deleted anywhere. And what about a single project plan? We'll have to rule everything by hand.
Conclusion. If the Work Item is mistakenly added to TFS, it will not automatically be removed from Project.
Case 2. Iteration duration changed
Also from experience ... Remember the customer from the beginning of the article? At the next meeting, he shortened the time to iterate from two weeks to a week. It is clear that we must go and work as soon as possible, but we want to update the plan first. Go down and reduce the iteration in TFS. How did it affect the hacks? Not reflected. Tasks do not understand that they do not fit into the time frame of iterations. Okay, microsoft, let's upload changes to Project.
And what has changed? Nothing, Project heard only about the names of iterations in TFS and does not know anything about the timing.
Conclusion. When you change the timing of the iteration to deal with the timing of the task will have to be in manual mode.
Case 3. Generalization of the problem: replanning
I note that here, on Habré-Megamind, there is an excellent article by the user ganouver , in which he describes how to use Project to manage projects. In particular, there you can read about balancing the plan, the ingenious tactics of dealing with the Project, and in the comments find the phrase that
... a bunch of TFS - Project works somehow clumsy and uncomfortable.And in his article there is a statement that describes development management as well as Tom Kite describes Oracle DBMS:
The main thing is to regularly update the plan.
In addition to changing the types of Work Item, removing unnecessary tasks, etc., in a real project, the plan can change almost completely, both in terms of the composition of tasks in high-level tasks (story), and in duration and composition of iterations. What does Project and TFS offer us to take into account these changes, to morph the tasks, re-balance the plan, calculate resources, take into account changes in the duration of iterations and prepare a new plan for releases? Nothing offers.
Conclusion
The solution from Microsoft for project management and software development in the form of joint use of Project + TFS + Visual Studio products can be used for one-time work planning and is not well suited for continuous automated replaning.
Reflecting on whether to publish an article with the conclusion that the Project + TFS technology stack in question is not very suitable for solving the set task, I decided that a negative experience is also an experience, and it will at least allow readers to make their own choice.
So, the task of complete development management on these tools can be solved only at the first drawing up of a plan and then on the basis of semi-automated labor of the manager or his assistant, and any replaning will take time for routine operations.
In the following articles we will consider other toolkits, the first candidates being Jira and Redmine.
Source: https://habr.com/ru/post/293960/
All Articles