Shulou(Shulou.com)06/03 Report--

This article is the third in a series of "loose knot programming".

Estimation is an enduring management topic, which is roughly divided into two schools.

The first is the appointment of the leader, who says that it is a 10-day job and must be done as a 10-day job. if it cannot be finished, various methods such as overtime, loss of quality, and shrinking functions can be used to save the scene. Another variation is that everyone estimates it by themselves, but gives it to the leader for examination and approval; leadership examination and approval is actually the process of cutting it in half, but fortunately everyone has doubled it before, so he is not afraid.

The second is the self-management school (agile), in which the specific developers themselves say the development workload, leaders and others do not interfere. Despite the "self-organization", the leader thinks that this method has left the seeds of laziness, and the team members also think that someone's estimate is very unreliable (too long or too short). What on earth should we do?

Let's make a joint estimate.

-

Basic concept

Suppose it is a planning meeting, PO (product manager, planning team leader, project manager, some sales …... Having just finished talking about the requirements, the next step is not to give it to someone to make an estimate, but to a potential group (master + 1-3 apprentice).

Let the master take the lead in playing cards, yes, play poker at the planning meeting:

1. Everyone thinks about how long it may take to complete the task and deduct a card.

two。 The master shouted to open the card, everyone showed the card, compare the size

3. Generally speaking, the smallest and the largest two people compete, express their own views, and discuss them together.

4. The difference comes from two aspects: what to do and how to do it; PO participates in the discussion to answer the question of what to do, and the master and apprentice discuss how to do it.

5. After the discussion, there will be a few more rounds until everyone thinks that the result is almost done.

The anonymity and openness of poker estimates ensure that people will not follow others and will not be difficult to reach agreement because of a lack of communication.

The author's experience is that a game of playing cards is estimated to last about 1-5 minutes, which is still very fast. Occasionally there is Huangzhuang, usually because PO can't answer what it looks like, and whether the additional function of so-and-so should also be done. When there's a question.

A few questions

1. Why give it to a group instead of an individual?

Playing cards regardless of individuals makes everyone have to think, because they are afraid of making a mistake and can't say why. In this way, even if he does not do this function in the future, he will still know this function very well.

two。 Why not let the last person in charge of the task make his own estimate?

Because he probably does not know that a certain code is available, does not know that a certain software does not work, and does not understand template (so we have thrown a person-month code). And chose the wrong implementation method.

3. Why not let the master estimate that everyone will adopt him? isn't he the best?

The master's ideas are often incomprehensible to the disciples-for example, why not stay in the daughter's country but go to the western sky to learn scriptures, hehe-the common estimation is the process of allowing people to compare their own implementation methods and master differences in thinking.

4. Why does PO still participate? Don't you want others to interfere?

Many questions, such as "showing the martial arts ranking" in the game, the specific workload may not lie in how to do, but in what to do: based on what ranking? How many places do you rank? Real-time ranking or weekly ranking? How to display the ranking?... So PO can't write a bunch of documents and then don't attend agile planning meetings in the name of inconvenient intervention estimates.

PO can challenge estimates, such as: "does this really take that long? I remember the last time." But you have to be reasonable. In fact, what is easier to see in practice is that teams are often too aggressive and optimistic. Instead, PO makes them aware of the complete needs and requirements and make more realistic estimates. PO is also responsible for inaccurate estimates.

5. What if we have been unable to reach an agreement?

In fact, the estimation is not for the last number, but to figure out what to do and how to do it. If these two things are clear, but the result is that some people say four days and some people say six days. Just take a random number (in fact, you should take six days according to Murphy's theorem). With a master, it is rare to argue about the implementation method; with PO, it is rare to argue about what to achieve.

Do not rule out special circumstances such as PO finds that it has not thought about why the ranking is based on, then you should shelve this user story; for example, if you think that if the database is strong, you can also rank in real time but are not sure, you can temporarily shelve it until the time of development, but mark the story "if you need to automatically rank + 1 day per week". If Huangzhuang is frequent, Scrum Master should be analyzed and summarized to avoid.

6. If the four players play different cards, will the master or the apprentice speak first?

Think of a brain teaser: scientists, doctors, soldiers, nurses. Wait, a group of people are on the plane, and the plane is freezing and crashing. someone (maybe more than one) needs to jump off, ask who? The answer is to start with the heaviest person, because you can jump a few less.

Therefore, we are the one with the smallest number of cards, which has nothing to do with master and apprentice. Because it is very likely that he will know the best way to achieve it. If it turns out later that this is not the case, please refer to the next one.

7. What are the reasons for that?

According to the following order, those who are closer to the truth are closer to the truth. Those who feel that they are close to the truth must raise their hands first and say that they are annoying in hindsight:

Empirical fact: I have done it before. We have a class library... I've tried that method. It's not feasible.

Clues: who remembers the last time. I heard that next door... Compared with the last time. You didn't used to be...

Logical reasoning: in theory... I think.

Several points for attention

1. There should be no strong division of labor in the group, or everyone will think by default that it must be someone's work.

two。 The master should not be too eye-catching, but should encourage the apprentice to think through estimation and master the true level of the apprentice at the same time.

3. The master should not take it too seriously. The discipline of programming specification, ease of use and maintainability cannot be relaxed, but if the apprentice wants to try a different but similar method, he can be encouraged appropriately.

4. Scrum Master monitors the whole process to prevent details / disputes. Wait for the question.

5. PO must attend.

It is estimated that the problem of what to do is solved with the participation of PO, and the problem of how to do is solved with the lead of the master.

Joint estimation is one of the basic activities of "cross-functional teams", and they were able to share current progress and difficulties at daily meetings because they thought about the task together in the first place. therefore, I am very concerned about the actual situation of this task. When something goes wrong, people are more likely to help each other than to know nothing about it.

The next article will cover the work during the iterative period of daily work / daily assembly, etc.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.