Are Gantt charts convenient in software development?
As you know, software development is a lengthy process, in which people mainly participate in different parts of this process.
People have long learned to plan and describe processes using the practices of calendar and network planning, a prominent representative of which is the Gantt chart. Developed and tested a lot of software tools that are easily accessible to anyone.
Due to the wide distribution and relatively convenient visualization of the described process, these diagrams are often used at the planning stage when developing software. But are these software development diagrams so convenient and necessary?
')
The main goal in building a chart is to understand how many resources are needed, what tasks need to be completed, predict the time by which these tasks will be completed, and understand the cost of the work. The goal is achieved by defining a list of tasks, required resources, determining dependencies between tasks, leveling the use of resources for their effective use, taking into account risks.
We use the classic analogy of software development - building a house. In this context, it is most relevant. To build a house, spend a minimum of funds and meet the required time it is necessary to understand: how many resources we will need (brick, cement, concrete, workers, etc.), when they are needed, in what sequence to perform the work, and also to sustain technological standards for the implementation of a well-known and fairly transparent process of building a house. Using the Gantt chart in this case fits well into the solution of this problem.
I always start when people who are unaware in the design often use the analogy with the construction of a house, and for them there are not some of the problems, however, they are significant. What is so different about the process of developing software from the process of building a house?
Resources
In development, the main and practically the only resource is a person, which is why he is often offended by the cynicism that lies in the essence of scheduling: a person is not a resource, he wants to be loved and respected. It is necessary to spend a lot of time, which could be spent on the achievement of the final goal, on drawing up a plan and keeping it up to date. A specific developer, tester or analyst is not a pure resource, because it is difficult and expensive to replace a specific performer, because only he knows a certain part of the system well and has specific experience and skills. A person is an extremely non-linear element of this whole chain, which means that you cannot rely 100% on his interest, loyalty and accessibility.
Project Scope
The list of tasks that the developer needs to perform is far from being so obvious even with a good understanding of the essence of the future product. You can use automatic tests, but you can not use them, you can skip some steps in the analysis, testing or documentation phase, and in some areas, on the contrary, you will need to pay more attention. The extremely high complexity of all the intricacies of the process makes it possible to cover the list of tasks only superficially, many of them will come out in the later stages of the project. Finally, the duration of the process contradicts the speed with which the requirements of the customer or users to the product change.
Timing
The development process is a much more flexible thing, which allows the customer to freely manipulate the project's purchase, the resources involved, the cost of the work. The fact that the concrete screed should dry for 3 days and is no less clear to the customer, but the fact that the subsystem of access rights is written a month, is much more difficult to understand. Any change in our triangle entails a substantial reworking of the plan, which takes a lot of time and requires a dedicated person, for example, a project manager.
Dependencies
It is practically impossible to understand and realize the whole tangle of tasks to be performed when implementing a relatively complex system, and, therefore, to determine the dependencies between the tasks. It is practically impossible to make an effective plan and minimize the cost, since any change in the process entails a re-re-planning of the use of resources.
Iteration
The overwhelming majority of projects use an iterative model of the process, but the linear calendar completely ignores this specificity. The product life cycle consists of several stages (releases), each of which has repeating parts. The life cycle of the implemented function consists of well-known phases of analysis, design, development, testing, etc. Any function has a life cycle. On the Gantt chart, you have to write tasks for a specific phase for each function, and this is an extremely tedious task, but if you do not do this, then your plan is no good.
findings
The Gantt chart is well used to describe deterministic and almost static processes that use the vast majority of linear resources, the technological cycles of which are well known and worked out.
I decided for myself that there is no point in wasting time on drawing up and maintaining these diagrams; it is better to spend this time and energy on communication between the participants, real assistance to the project and increasing the loyalty of the participants.
However, this does not mean that the scopes, terms, costs and resources do not need to be taken into account and planned, but only using other practices.
The continuation
People have long learned to plan and describe processes using the practices of calendar and network planning, a prominent representative of which is the Gantt chart. Developed and tested a lot of software tools that are easily accessible to anyone.
Due to the wide distribution and relatively convenient visualization of the described process, these diagrams are often used at the planning stage when developing software. But are these software development diagrams so convenient and necessary?
')
The main goal in building a chart is to understand how many resources are needed, what tasks need to be completed, predict the time by which these tasks will be completed, and understand the cost of the work. The goal is achieved by defining a list of tasks, required resources, determining dependencies between tasks, leveling the use of resources for their effective use, taking into account risks.
We use the classic analogy of software development - building a house. In this context, it is most relevant. To build a house, spend a minimum of funds and meet the required time it is necessary to understand: how many resources we will need (brick, cement, concrete, workers, etc.), when they are needed, in what sequence to perform the work, and also to sustain technological standards for the implementation of a well-known and fairly transparent process of building a house. Using the Gantt chart in this case fits well into the solution of this problem.
I always start when people who are unaware in the design often use the analogy with the construction of a house, and for them there are not some of the problems, however, they are significant. What is so different about the process of developing software from the process of building a house?
Resources
In development, the main and practically the only resource is a person, which is why he is often offended by the cynicism that lies in the essence of scheduling: a person is not a resource, he wants to be loved and respected. It is necessary to spend a lot of time, which could be spent on the achievement of the final goal, on drawing up a plan and keeping it up to date. A specific developer, tester or analyst is not a pure resource, because it is difficult and expensive to replace a specific performer, because only he knows a certain part of the system well and has specific experience and skills. A person is an extremely non-linear element of this whole chain, which means that you cannot rely 100% on his interest, loyalty and accessibility.
Project Scope
The list of tasks that the developer needs to perform is far from being so obvious even with a good understanding of the essence of the future product. You can use automatic tests, but you can not use them, you can skip some steps in the analysis, testing or documentation phase, and in some areas, on the contrary, you will need to pay more attention. The extremely high complexity of all the intricacies of the process makes it possible to cover the list of tasks only superficially, many of them will come out in the later stages of the project. Finally, the duration of the process contradicts the speed with which the requirements of the customer or users to the product change.
Timing
The development process is a much more flexible thing, which allows the customer to freely manipulate the project's purchase, the resources involved, the cost of the work. The fact that the concrete screed should dry for 3 days and is no less clear to the customer, but the fact that the subsystem of access rights is written a month, is much more difficult to understand. Any change in our triangle entails a substantial reworking of the plan, which takes a lot of time and requires a dedicated person, for example, a project manager.
Dependencies
It is practically impossible to understand and realize the whole tangle of tasks to be performed when implementing a relatively complex system, and, therefore, to determine the dependencies between the tasks. It is practically impossible to make an effective plan and minimize the cost, since any change in the process entails a re-re-planning of the use of resources.
Iteration
The overwhelming majority of projects use an iterative model of the process, but the linear calendar completely ignores this specificity. The product life cycle consists of several stages (releases), each of which has repeating parts. The life cycle of the implemented function consists of well-known phases of analysis, design, development, testing, etc. Any function has a life cycle. On the Gantt chart, you have to write tasks for a specific phase for each function, and this is an extremely tedious task, but if you do not do this, then your plan is no good.
findings
The Gantt chart is well used to describe deterministic and almost static processes that use the vast majority of linear resources, the technological cycles of which are well known and worked out.
I decided for myself that there is no point in wasting time on drawing up and maintaining these diagrams; it is better to spend this time and energy on communication between the participants, real assistance to the project and increasing the loyalty of the participants.
However, this does not mean that the scopes, terms, costs and resources do not need to be taken into account and planned, but only using other practices.
The continuation
Source: https://habr.com/ru/post/51451/
All Articles