A question that cannot be answered in a short form. If it were simple, then the problem of violation of deadlines would not exist.
To make development deadlines more predictable, you first need to understand the reasons why programmers are constantly mistaken.
The first reason is that most of the tasks a programmer does are more or less unique. That is, most likely, the programmer will do a similar task for the first time. He does not know well how much this work will take. If he is a programmer with solid experience and had to perform a similar task, his assessment will be closer to reality.
Let’s use a simple analogy – if you’ve never dug a ditch, you can’t say exactly how long it will take to dig a trench 30 cm wide, 60 cm deep and 20 meters long. If you used to dig, the estimate of the time you have will be much closer to the actual duration of the work.
The second reason is that programmers are inherently optimistic. That is, considering the task, choosing an implementation option for it, giving an assessment of the improvements, the developer expects that everything will work as he expects. And he does not think about the problems that he will meet on the way. Often, he cannot foresee them. For example, there is a task that a programmer can implement using a third-party open-source software library. At the assessment stage, he found it on the Internet, read its description – it suits him. And he even correctly estimated the volume of his work to build in the use of this library. But he did not foresee at all that an error would occur in the environment of his software product in this library.
The developer will have to not only embed the use of the library in his code, but also fix the error in the library itself. And often, the developer does not provide time for fixing his mistakes. As statistics show, testing and fixing errors can take about 50% of the time that was spent on coding. The number depends on the skills of the developer, environment, development practices used (for example, unit tests significantly reduce this time and the total duration / laboriousness of the development task is less).
If we return to the analogy with a digger, the digger did not assume that he would break a shovel and have to spend two hours looking for a new cuttings.
The third reason is unforeseen requirements. There is no such stream of new requirements in any field of material production with which customers so much love to compare software development. Imagine the passage of a digger who dug 19 meters out of 20 and heard from the customer the wish that the ditch should not go in a straight line, but as a snake with a shoulder length of 97 centimeters.
How to deal with all this and how to live in conditions of such uncertainty? Reducing uncertainty and laying a reserve of time.
The easiest way to bring your expectations closer to reality is to use the funky rule of thumb “Pi.” Having received an estimate from the developer (in terms of time or labor intensity), you need to multiply it by the number Pi (= 3.14159). The more experienced the developer made the assessment, the lower this coefficient can be.
It is mandatory to decompose the original task into small tasks of no more than 4 hours. The more detailed the decomposition, the higher the chances that the estimate will be close to the actual labor / duration.
If you return to the allocation of the reserve – this time should be allocated at the end of the project. It’s bad practice to make a reserve and include it for each task. Parkinson’s law, “Work fills all the time allotted to it,” is strictly implemented.
If you summarize the short “total”, then in order to correctly determine the timing of the work, the following actions will be useful:
- perform work decomposition, break the task down into as detailed steps as possible;
- conduct prototyping;
- limit the implementation of previously unforeseen requirements. This does not mean that they do not need to be done, but it is advisable to highlight these requirements and coordinate with the customer the change in the terms and cost for their implementation;
- take into account the time to stabilize the solution;
- use practices to improve the quality of code, for example, write unit tests;
- lay a general reserve.
Well, and remember that if the fact exceeds your estimate by 30% – then this is a very good result.