How I was taught to work. Third day.
Two days ( first and second ) were a theoretical introduction.
It's time to see how all this is in practice.
Last week began with a feature planning rally. Ended directly work.
At the beginning I will talk a little about XPlanner and the project organization.
XPlanner - open-source tool for keeping time and drawing beautiful graphs for managers, is quite simple.
Our project consists of three teams. Each should make about 10 features for the entire project and solve several internal problems, such as test automation.
XPlanner does not know how to keep track of time by team, but for us it is important. Therefore it was necessary to create three separate projects for each. It gave:
')
The main minus of XPlanner is the inflexible work with tasks: their transfer from one sprint to another turns some things into a messy list. Before starting a project, it is worth exploring such tula and choosing the appropriate one.
Our team had to spend 2 days at the scheduled meetings. As practice has shown, the more people - the harder it is to agree on the dates: one believes that too much time is needed, the other - on the contrary, the third does not understand the meaning in the feature at all.
To avoid long disputes, SCRUM suggests using a card system with numbers.
We had these: 2, 4, 8, 12, 16, 20. Plus a card that says “Too much”. The time estimate is as follows:
1. A feature is selected. Split into tasks. Evaluation is given for each of the tasks.
2. Each of the rally participants chooses a card with a number of hours, sufficient, in his opinion, for the implementation of the task.
3. On the count of 3 all show their choice.
4. If the values ​​are very different - each argues (briefly) his choice and choose the optimal estimate.
By the end of the rally, the assessments become less objective due to the fatigue of the participants, so it’s worth taking breaks (it’s better to walk and not to spread around the chair). The team can meet people who will start a discussion on the topic: "What a fool came up with this feature." Such people, IMHO, should deprive the vote for 30 minutes or remove from the rally. Otherwise, time will be spent on empty evidence - the feature still needs to be done. If you are a leader in a team, make everyone ready, otherwise a bunch of questions might be formed: “What kind of ...?”.
On Wednesday, we had our first status rally. On it we had to tell what we had done, what we would do and what problems we had. Participants: team, manager and those. project coordinator.
In our case, the latter were actively wedged into the conversation - forbid everyone to speak except the team. The task of managers at this rally is to listen and record.
After the rally, everyone went to work. There is nothing special. But there are several important points:
1. The manager must remember that the rally ALWAYS has a goal. You can not assemble a team just for the sake of a story about the current status of the project - he is already known. If you want to talk with programmers - call them to drink tea. This will give you a plus to trust.
Any meeting without a useful goal leads to a loss of time for another 30 minutes - after a boring story about garbage, people go to drink tea and lose their mood to work.
2. Do not throw features at the beginning of the sprint, even if it is clear that you will not have time. This is extra work. Also at the beginning (especially when the team has not yet worked out) it is not clear what the pace will be. Perhaps it will be possible to make faster. Let these features be like a super-goal to do more and become better. Well, if there is a small spirit of competition between the teams, but not in the team.
3. Communicate with colleagues. Everyone in the team should know about your problems - maybe someone already knows the answer. Well, if you sit in the common room.
It's time to see how all this is in practice.
Last week began with a feature planning rally. Ended directly work.
At the beginning I will talk a little about XPlanner and the project organization.
XPlanner - open-source tool for keeping time and drawing beautiful graphs for managers, is quite simple.
Our project consists of three teams. Each should make about 10 features for the entire project and solve several internal problems, such as test automation.
XPlanner does not know how to keep track of time by team, but for us it is important. Therefore it was necessary to create three separate projects for each. It gave:
- The ability to see the dynamics in each of the teams, not the whole project
- Avoid “porridge” in the task list (there are about 50 of them)
')
The main minus of XPlanner is the inflexible work with tasks: their transfer from one sprint to another turns some things into a messy list. Before starting a project, it is worth exploring such tula and choosing the appropriate one.
Planning (time evaluation)
Our team had to spend 2 days at the scheduled meetings. As practice has shown, the more people - the harder it is to agree on the dates: one believes that too much time is needed, the other - on the contrary, the third does not understand the meaning in the feature at all.
To avoid long disputes, SCRUM suggests using a card system with numbers.
We had these: 2, 4, 8, 12, 16, 20. Plus a card that says “Too much”. The time estimate is as follows:
1. A feature is selected. Split into tasks. Evaluation is given for each of the tasks.
2. Each of the rally participants chooses a card with a number of hours, sufficient, in his opinion, for the implementation of the task.
3. On the count of 3 all show their choice.
4. If the values ​​are very different - each argues (briefly) his choice and choose the optimal estimate.
By the end of the rally, the assessments become less objective due to the fatigue of the participants, so it’s worth taking breaks (it’s better to walk and not to spread around the chair). The team can meet people who will start a discussion on the topic: "What a fool came up with this feature." Such people, IMHO, should deprive the vote for 30 minutes or remove from the rally. Otherwise, time will be spent on empty evidence - the feature still needs to be done. If you are a leader in a team, make everyone ready, otherwise a bunch of questions might be formed: “What kind of ...?”.
First 15-minute SCRUM rally
On Wednesday, we had our first status rally. On it we had to tell what we had done, what we would do and what problems we had. Participants: team, manager and those. project coordinator.
In our case, the latter were actively wedged into the conversation - forbid everyone to speak except the team. The task of managers at this rally is to listen and record.
First lines of code
After the rally, everyone went to work. There is nothing special. But there are several important points:
1. The manager must remember that the rally ALWAYS has a goal. You can not assemble a team just for the sake of a story about the current status of the project - he is already known. If you want to talk with programmers - call them to drink tea. This will give you a plus to trust.
Any meeting without a useful goal leads to a loss of time for another 30 minutes - after a boring story about garbage, people go to drink tea and lose their mood to work.
2. Do not throw features at the beginning of the sprint, even if it is clear that you will not have time. This is extra work. Also at the beginning (especially when the team has not yet worked out) it is not clear what the pace will be. Perhaps it will be possible to make faster. Let these features be like a super-goal to do more and become better. Well, if there is a small spirit of competition between the teams, but not in the team.
3. Communicate with colleagues. Everyone in the team should know about your problems - maybe someone already knows the answer. Well, if you sit in the common room.
Source: https://habr.com/ru/post/51591/
All Articles