Estimating the timing of a software development project

But there are other project-specific activities that are much more difficult to evaluate. I usually divide such tasks into several activities. For example, for the task of implementing an algorithm for processing large amounts of data, I can single out subtasks that provide the search and testing of solutions, creating a prototype for testing under load, and integrating a debugged solution into a project. Decomposing complex tasks into subtasks reduces uncertainty and improves the quality of planning and estimates.

It is reasonable not only to define a list of tasks, but also to indicate their approximate duration, dependencies and performers, as well as the required infrastructure.

The duration of the task should take into account the time actually spent on its solution, and not the "ideal" hours. Good results are obtained by using the focus factor when obtaining real estimates. In this case, I borrow the focus factor from agile practices, where it is defined as the number of “ideal” hours devoted to solving a set of problems, divided by the amount of time actually spent on solving an account.