How we set the development process on a 2 year project
That is how much we are already doing the Altergeo geosocial network. I will tell you how we manage to be and remain quite effective in development, maintaining a vigorous pace all the time.
Main:
Two years is a very long marathon, so it is important for everyone to get the tasks right and see the concrete results of their implementation. To do this, we have introduced a system of short periods, the distinction between goals and objectives, plus the maximum concretization of the latter. The shortest task is 2 minutes, the longest is 3 hours.
Planning before development is an obvious thing. True, I know a couple of companies where they do the opposite. Planning takes place at the beginning of each development period (sprint). We have - on average once every two weeks a plan is drawn up for the near term. Do not look further until we finish current goals.
')
The meaning of planning is to set strategic goals (what is needed for the network), which in turn fight for specific tasks (who does what).
The goal is a kind of change in the service that we want to make. For example - âadd friends recommendation mechanismâ. A task is part of a goal that one person can accomplish in a team. For example, "draw a design for recommendations of friends on a mobile site."
Tasks without superior goals should ideally not be. Practice differs from the ideal, so we have two meta-tasks in each sprint - âvarious triflesâ and âtestingâ, which seem to be ineradicable.
In our case, planning quite clearly fights in three parts:
Part of the task always remains unfulfilled. If everything is done, then probably there are not enough tasks for the team. I believe that there are people who are able to plan sprints with 100% accuracy, but we still do not know how.
The reasons for not performing are usually as follows:
Unfulfilled task is not scary. It is much more important to understand why it was not done and to look at the total failure rate of the sprint. If only 70-80% is done, we are looking for the answer to the question what happened and why. The second time such a joint is not needed. Important: we are not looking for the guilty, but the root of the problem.
As a result, we have to understand three things - what we managed to do for the goals, that we didnât have time, how much more time to spend, in order to bring the remaining goals to a working mind. When summarizing, we are talking about goals - you can keep specific tasks in your head, but usually it does not make sense.
This part of planning, with proper organization, is carried out without a team - data from daily stand-ups is quite enough.
At this stage we are talking about setting goals (not tasks!) For the sprint. The goals are set by an individual - Product Owner or PO (product political policy). In general, one thing is required of him - to understand how the project should develop further. He collects the requirements and wishes of third parties (marketing department, customer relations department, programmers), carefully sifts them, adds his ideas and, as a result, gives a list of things that we want to accomplish.
We are planning 4-5 major goals for the sprint. Examples are âredesign of a mobile site under the concept of Qâ, âimplementation of the N algorithm, selection of places for marks on the siteâ, âadding payment through J. Money without intermediariesâ.
The goal should be formulated clearly, it is recommended to use the rule "{verb} {noun} {additions}" - in a two-week sprint, forget what exactly was meant when formulating a pair of goals is quite simple.
In addition, at this stage we decide which tasks we have done from the last sprint we transfer to the current one, and which - to the backlog.
The schedule is conducted by the whole team - that is, the PO and the development team. Goals should be turned into tasks, put down an estimated time for each task and, in some cases, an artist. In our case, design and layout are separately distinguished - they are always occupied by specific people. The executor for the tasks of programmers, on the contrary, we try not to assign at once - they are executed by priorities in the mode âwho completed the task, he takes the next one for himselfâ.
The task execution time is estimated by the whole team together - including those who have never had a relationship to this section of the code. By workload, we assume a level of six hours of tasks per day per person. Taking into account stand-ups and negotiations with colleagues, this is quite reasonable. The main thing is that it does not motivate specialists to try to overstate the task execution time in order to meet the âplanâ.
If a task takes more than 2-3 hours - then it should be broken into several small subtasks. This not only improves the accuracy of time estimation and brings clarity to the process, but also makes it easier for programmers to work - it is psychologically easier to perform four small and clearly defined tasks leading to a goal than one large and amorphous one.
At this stage, some of the goals can go into backlog or be eliminated altogether - this is what happens if it turns out that it will take much longer to accomplish the goal than PO expected.
A full planning cycle takes about two days. Most of the time it takes for PO to understand exactly what goals he will set for the team. The schedule of tasks we usually have on Tuesday is about twelve o'clock - Monday is assigned to the team to correct the defects found and to complete minor tasks from the current sprint. The idea to carry out the painting (as well as the stand-ups) was considered unsuccessful in the morning - there is always some urgent work in the morning.
PS If it is interesting, I can tell you about the specific mechanics of working with Acunote and the construction of the process from the point of view of the developer, and not the team lead.
Main:- The number of the development team is 7;
- The duration of the sprint is about two weeks ;
- Stand-ups every day;
- Organizational items are stored in Acunote, google docs and MindMap;
- The code is stored in SVN, a new feature is a new branch, several developers are working on one feature;
- Testing - through unit-tests.
Two years is a very long marathon, so it is important for everyone to get the tasks right and see the concrete results of their implementation. To do this, we have introduced a system of short periods, the distinction between goals and objectives, plus the maximum concretization of the latter. The shortest task is 2 minutes, the longest is 3 hours.
Planning
Planning before development is an obvious thing. True, I know a couple of companies where they do the opposite. Planning takes place at the beginning of each development period (sprint). We have - on average once every two weeks a plan is drawn up for the near term. Do not look further until we finish current goals.
')
The meaning of planning is to set strategic goals (what is needed for the network), which in turn fight for specific tasks (who does what).
The goal is a kind of change in the service that we want to make. For example - âadd friends recommendation mechanismâ. A task is part of a goal that one person can accomplish in a team. For example, "draw a design for recommendations of friends on a mobile site."
Tasks without superior goals should ideally not be. Practice differs from the ideal, so we have two meta-tasks in each sprint - âvarious triflesâ and âtestingâ, which seem to be ineradicable.
In our case, planning quite clearly fights in three parts:
- Completed tasks;
- Setting goals;
- Concretization and discussion of tasks.
1. What is not done?
Part of the task always remains unfulfilled. If everything is done, then probably there are not enough tasks for the team. I believe that there are people who are able to plan sprints with 100% accuracy, but we still do not know how.
The reasons for not performing are usually as follows:
- Objective difficulties were discovered (the Facebook API documentation was out of date, the partners did not send XML in time, the design went for approval three times) and did not have time to complete the task;
- During the sprint, tasks with a higher priority were added and the task was postponed;
- The task itself was added during the sprint process and no one has taken it up yet;
- Someone from the team got sick or took time off - this also happens.
Unfulfilled task is not scary. It is much more important to understand why it was not done and to look at the total failure rate of the sprint. If only 70-80% is done, we are looking for the answer to the question what happened and why. The second time such a joint is not needed. Important: we are not looking for the guilty, but the root of the problem.
As a result, we have to understand three things - what we managed to do for the goals, that we didnât have time, how much more time to spend, in order to bring the remaining goals to a working mind. When summarizing, we are talking about goals - you can keep specific tasks in your head, but usually it does not make sense.
This part of planning, with proper organization, is carried out without a team - data from daily stand-ups is quite enough.
2. What do we want to do in this sprint?
At this stage we are talking about setting goals (not tasks!) For the sprint. The goals are set by an individual - Product Owner or PO (product political policy). In general, one thing is required of him - to understand how the project should develop further. He collects the requirements and wishes of third parties (marketing department, customer relations department, programmers), carefully sifts them, adds his ideas and, as a result, gives a list of things that we want to accomplish.
We are planning 4-5 major goals for the sprint. Examples are âredesign of a mobile site under the concept of Qâ, âimplementation of the N algorithm, selection of places for marks on the siteâ, âadding payment through J. Money without intermediariesâ.
The goal should be formulated clearly, it is recommended to use the rule "{verb} {noun} {additions}" - in a two-week sprint, forget what exactly was meant when formulating a pair of goals is quite simple.
In addition, at this stage we decide which tasks we have done from the last sprint we transfer to the current one, and which - to the backlog.
3. Schedule and discussion
The schedule is conducted by the whole team - that is, the PO and the development team. Goals should be turned into tasks, put down an estimated time for each task and, in some cases, an artist. In our case, design and layout are separately distinguished - they are always occupied by specific people. The executor for the tasks of programmers, on the contrary, we try not to assign at once - they are executed by priorities in the mode âwho completed the task, he takes the next one for himselfâ.
The task execution time is estimated by the whole team together - including those who have never had a relationship to this section of the code. By workload, we assume a level of six hours of tasks per day per person. Taking into account stand-ups and negotiations with colleagues, this is quite reasonable. The main thing is that it does not motivate specialists to try to overstate the task execution time in order to meet the âplanâ.
If a task takes more than 2-3 hours - then it should be broken into several small subtasks. This not only improves the accuracy of time estimation and brings clarity to the process, but also makes it easier for programmers to work - it is psychologically easier to perform four small and clearly defined tasks leading to a goal than one large and amorphous one.
At this stage, some of the goals can go into backlog or be eliminated altogether - this is what happens if it turns out that it will take much longer to accomplish the goal than PO expected.
Results
A full planning cycle takes about two days. Most of the time it takes for PO to understand exactly what goals he will set for the team. The schedule of tasks we usually have on Tuesday is about twelve o'clock - Monday is assigned to the team to correct the defects found and to complete minor tasks from the current sprint. The idea to carry out the painting (as well as the stand-ups) was considered unsuccessful in the morning - there is always some urgent work in the morning.
PS If it is interesting, I can tell you about the specific mechanics of working with Acunote and the construction of the process from the point of view of the developer, and not the team lead.
Source: https://habr.com/ru/post/133135/
All Articles