During planning, it is important for the team to do three things:
- To agree on the result with interested parties.
- Make a project plan.
- Make a communication plan.
Agree on the result
At this step, it is important to understand what the alpha version of the product will be. In our case, the alpha version is the version of the program that is obtained at the end of the third stage – development, which we will talk about in more detail below. The alpha version may not include all the requirements that Customers have formulated in the concept, but only a subset. Why?
The fact is that the concept includes many “wishlist” Customers. Some of them have not been tested in practice, and may not be useful in reality. And, conversely, it may be necessary to implement something else that Customers did not think about when they wrote the concept.
Therefore, we try to make sure that Customers start using our program as soon as possible. Even if not in working mode, but at least in test mode. Only real use experience can show which requirements are important and which are insignificant.
To achieve this goal, we are trying to understand what the minimum working version should include. And of all the requirements — in agreement with Customers — we choose only those without the implementation of which it is really impossible to do.
The minimum working version is the alpha version. The development phase ends at its release.
Our own Genome editor allows 3D animators to visually program a character
After our Customers start using our program, bugs and various roughnesses are revealed. In addition, there is also the experience of using it first in test, and then in “combat” conditions. This experience allows us to evaluate the remaining requirements: which of them are important and which are insignificant.
We eliminate roughness, implement overestimated requirements and fix bugs at the maintenance stage.
Step 2.2. Make a project plan
To make a project plan, you need:
Make an assessment of the project
Evaluate available resources
Step 2.2.1. Make an assessment of the project
In my opinion, there are two types of project evaluation:
The preliminary assessment is rather rough. It uses simplified decomposition, but for this reason does not require too much time.
A detailed assessment is more accurate. But in order to get it, it is necessary to design and make a decomposition of the works.
To save time, we make a rough assessment of the project. However, even when using “rough models”, you can get an accurate result. How do we achieve this? To evaluate the project, instead of one model, we use three:
The functional model represents the program being developed in the form of a set of useful functions. It reflects the user’s point of view.
The component model represents the application as a set of modules. It reflects the engineer’s view.
The process model is a view of the program as a project that has some length in time and consists of a sequence of stages. Each stage has its own tasks (often organizational or managerial) and, as a result, its duration can be estimated as a superposition of the time required to complete each of the tasks. The process model reflects the manager’s point of view.
When combined, these three points of view represent a comprehensive view of the same product. It is better to evaluate some things through functions, some through modules, some through a process. As a result, a balanced assessment is obtained.
Perhaps this topic will be covered in more detail in a separate article.
Step 2.2.2. Evaluate available resources
To properly take into account the available resources, you need to understand that no employee spends 100% of his time on tasks. Surely, the programmer will spend some part of his time on communication with colleagues and a little rest.
Of course, if there are only 2 people in the team, and they work with approximately the same productivity, then unproductive waste of time can be neglected and assume that one working man-day is 8 hours. In fact, with such a team size, the time to coordinate some issues will not be too significant.
However, if there are already 4 people in the team, then both the time for communication and the different productivity of different people should be taken into account.
When evaluating available resources, we use the following table of labor productivity:
Lead Engineer 50%
Inexperienced beginner 25%
The lead engineer, in addition to programming, spends part of his time planning, distributing tasks, communicating with Customers, introducing newcomers, if there are any, and training inexperienced ones. Therefore, we believe that he can spend only half of his time on programming.
An ordinary engineer should work with 85 percent productivity. He spends the remaining 15% of his time communicating with the rest of the team, communicating with Customers and writing reports.
As you know, connecting new people to the project at first does not speed up, but slows down development. This is due to the fact that team members have to be distracted from work to train a new employee. And even the novice himself has a low labor productivity at first: we believe that he spends up to half of his working time on training. Over time, productivity should increase. If it does not grow, then this is a reason to think about the expediency of his stay in the team.
An inexperienced beginner is initially forced to spend more time on training than just a beginner. Therefore, the performance of 25% at the very beginning should not look like something terrible. However, over time, it should also grow.
Using these figures, it is possible to estimate the real productivity of the entire team.
Suppose a team consists of 4 people:
an inexperienced beginner
Then the performance of the entire team will be equal to:
1 * 50% + 1 * 85% + 1 * 50% + 1 * 25% = 210% = 2,1 man-days
This is two times less than with a simple approach, when it is assumed that each person works with 100 percent productivity.