Agile development One Thousand and One Q Series: How do I estimate playing cards under their respective division of labor?

This is Part 1 of the agile development One Thousand and One Q & A series. (Here, I would like to ask, one, two, three, and the General Directory of the question)

Post 15 floor http://blog.csdn.net/cheny_com/article/details/7564388

An excerpt from the original question is as follows:

If the development team may carry out several special projects at the same time, someone will participate in this special project and will not participate in another one.
In poker estimation, what should we do for a specific task? Is it true that all developers in the development team participate in the evaluation, or are those involved in the specific task?

One project may be done by one or two people. It is slightly different from a single head shot;
If we make an estimation together, there may be low efficiency issues;

What is the purpose of analysis and estimation?

Before estimation, you must ask yourself the following question:What is the cause or purpose of estimation?

There are many reasons for estimation, but in fact some of them are not very reliable, or it is difficult to refute them if someone is fond of them. For example:

1. To know how many lines of code can be completed (if you use the code line estimation ).

Tip: no matter whether it is 1000 rows or not, the number of rows is 1000. Why should we estimate it in advance? (This is a question I was asked eight years ago)

2. In order to know how long it will take to complete and make a plan.

TIPS: our plans are all reversed. How long will the leaders say, and how long will we do? What is the value of estimation?

......

So what estimates are missing or extremely valuable? There are roughly two types.

1. estimation before quotation/Contract occurrence

If we can complete the estimation between them, we can grasp the business initiative. Even if you are forced to sign a contract, it is much better to be "aware.

This is an early estimate of the cost and will be detailed later, but you can refer to http://blog.csdn.net/cheny_com/article/details/7672333.

2. Estimation of results can be improved

If we thought we would need 1000 rows -- and it would really need 1000 rows to be done directly, we would find it worthwhile to estimate as long as 100 rows were estimated.

If we thought it would take 100 days -- and it would take 100 days to do it directly, it would also be worthwhile to estimate the result as long as 10 days after estimation.

This is the best scenario for poker card estimation.

Preparatory activities Principle

Estimation can improve the estimation result by sharing information to reduce waste.

In general, there are two waste activities:

1. waste caused by incorrect understanding of requirements

In estimation, different people and different sides are used to discover the truth about the demand, which can effectively avoid such waste.

Estimation by testers and developers is a common method to clarify requirements. Developers, especially, often go deep into the kernel, so they often hear a little bit of demand and take it for granted as a similar requirement they once thought about, and are eager to think about implementation methods.

2. waste caused by incorrect or repeated implementation methods

One is to repeat the code and re-invent the wheel ......;

One is error implementation. For example, someone once wrote 65 functions because they were not good at using "templates" (that is, generic;

One is a dry job. For example, some people used hard encoding to package and unpack code streams for graphic purposes. The result code streams are constantly changing in the following days, and the result is hard to ride, two months of work were thrown away due to low quality, and the re-design of the code ended in two weeks.

......

Programmers with different levels and responsible for different parts can fully communicate and jointly estimate these situations. Especially experts and Veterans can remind new users to avoid mistakes.

Waste and waste prevention

You must be aware that, although estimation can prevent waste, it takes time to estimate the efficiency of estimation.

Methods to Improve efficiency include:

1. if not necessary, too many people are not involved in estimation.

139 the team is one way, that is, if we have 13 people, we try to divide them into three groups, each of which has 4 people. These four are basic estimation units. They should be responsible for similar functions and usually sit together, so they can communicate smoothly.

2. Try to use large granularity

It is often said that agile development practitioners have assigned tasks about two hours, or even 0.5 hours. Here, we do not directly say that we should not split it. Instead, we should remind you that four people are clamoring for 15 minutes, that is, one hour. We can spend 1 hour, but we must know what we get. If it is really worth it, we should do it. If it is not worth it, we should change to a larger granularity.

3. Try a faster Estimation Method

Playing card estimation is a very fast method, because if the numbers are the same, it is basically not discussed. (if the numbers are the same for the first time, we recommend that you let a person talk about it, others don't have too many different opinions ).

Solution

The analysis is clear, and the solution is easier to write.

Solution 1 is the easiest to implement, but the most ineffective. Later, it is better but more difficult to implement.

Solution 1

In teams that have never been estimated, if they are also responsible for their own business, we recommend that you pull a few people together to make an estimation based on the same technology; if these people sit together at ordinary times, they can add some places that cannot be mentioned at the meeting.

In a thorough "strong division of labor" environment such as open class classroom training, I found that as long as the technology is passed, people in both companies can estimate it together, not to mention within a team. The premise is that the product manager must be able to describe the requirements.

However, in the initial stage, we will find that the estimation takes a long time, because many background knowledge is unknown during the initial estimation, and even the person directly responsible for the issue cannot be clear, so the communication cost is relatively high. If you spend a day discussing the background, you will soon be able to avoid the exchange of basic background knowledge.

In the first two or three months, you don't need to be too strong in looking for any effect. If you understand each other's background, it's just an effect.

Solution 2

Create a group with a fixed organizational structure and then bind the estimation group to the group.

139 teams are one type. In fact, even if you simply appoint a team leader and then lead the other three ~ Four people develop something, which can be called a fixed group.

A fixed group should develop relatively close functions (whether the technology is the same but secondary), so that they can come up with their own opinions from different perspectives even if the technology is different. Many people think that if I don't understand a technology, I can't tell how long it will take to develop the part. If I am less than five meters away from that person, we are developing different parts of the same module, and his technology does not involve very confusing content such as general relativity, there is no reason to say no to a technology, especially the group leader.

In our 01-Year team, our 25-person department manager basically participated in the development of each group, including a development platform similar to a set-top box and a PC. At that time, the set-top box team found some defects in the code that were difficult to handle. He went over and "helped" and found that the entire code was too messy, after two weeks, He reconstructed the code structure in the entire set-top box and implemented an object-oriented structure close to C ++ in the C environment. Of course it takes quite a few days to do this. However ~ Within the scope of four people, this is not so complicated, and talents do not need to be too good.

Solution 3

Create an L-type code structure. For more information about the L-type code structure, see the relevant articles in the plug-in programming series (about 9th articles, three currently ).

I now have a division of labor with programmers. Although the estimation is not done (there are only two people now, there is too much communication, so the second purpose of the estimation mentioned above has been achieved early ), however, when assigning tasks to him, he will discuss the implementation methods of each method. The main discussion is to tell him two things:

1. The entire business process is similar to what I have written. It can be used as a reference for the overall process (generally concentrated on The View/controller ).

2. which underlying classes and functions can be used (concentrated on the model, and our model library accounts for 67% of the total amount of code, most of which are written as needed when I write my upper-layer applications, he has also done maintenance ).

Sometimes I will not take the initiative to communicate with the second department, because after reading 1, I can basically see it and communicate with others when I have doubts.

The L-type code has brought several changes to estimation:

1. The high-level calling process of L-type code is very easy to understand. Therefore, the discussion on "How to Implement" is relatively simple, and there is no need to involve too deep underlying implementation.

2. It is easy to find modules of similar businesses for reference.

We have an average controller of about 5 ~ 10 functions (for example, add, delete, modify, and query operations of "user": userscontroler. Index/details/create/batchcreate/delete/freeze/edit), each function has 4 ~ code ~ Five lines, so if you want to learn the whole process of adding, deleting, modifying, and querying another item, you will be able to understand the whole process after reading the 50 lines of code.

3. Because the underlying library has been used, it is easy to find the sample (search by IDE ).

4. during each discussion, we will find that some features that are not yet implemented by the underlying library need to be extended. No matter who implements them, we both know that this feature is required and will be helpful for the future.

However, it is relatively difficult to fully form the L-type code, and it is highly demanding to generate the underlying library "by the way.

Of course, the last question: "Do you not play cards or even estimate them? Is this agile ?"

For a long time, we have not re-invented the wheel because of the participation of new people, and the code has not rapidly increased or the quality has declined because of the arrival of new people, people know almost all major changes in code ...... When the goal is achieved, the process is not important.

I am participating in the csdn blog Star Selection. If you have read and liked this article, please vote:Http://vote.blog.csdn.net/item/blogstar/cheny_com