Thought 4 days can fix the project, the result has been engaged for nearly one months ...

A friend mentioned the question:

I recently worked on small projects, part-time, and several people talking about projects that could be completed in 4 days, resulting in an entire cycle that took nearly one months.

It is expected to be 4 days, resulting in a few people being out of time and spending one months. There is also time is not unified, communication is not convenient, light communication has spent a lot of time. Usually the customer sends the demand to me, I again communicates to the developer, thus wastes a lot of time from it. And the customer needs are not very clear, my understanding and other partners understanding is not the same. Because of less cooperation, there is not so much tacit understanding, the technology is also sometimes docked.

My opinion:

When developing to estimate, it is often assumed that the demand is like this is not how to change, and then estimate the development workload, often think once can be done, there is no big mistake, do not need to communicate the cost, the test can be passed once, even without estimating the time of testing and repair defects, and do not estimate the time after the customer changed to change Wait a minute.

The estimate would be super optimistic, and judging by this estimate would be miscalculated. This is the process of learning and growth, at least the first to dare to estimate, this is still very good drop.

There are two areas that we can easily overlook, resulting in a very low estimate:

1) running-in within the project team

Project team members have not worked together in the project before, there will be a lot of running-in problems. A 3-month project, ideally, the project team must run for at least 1.5 months, in severe cases the project team still has a lot of running-in problems. To perfect the problem of running-in and so on, on the one hand, we need to have a working experience, on the other hand to find ways to make the project team work together and efficient operation of the method and process.

2) and customer's running-in

For the first time with this customer project, a variety of running-in problems will come. The customer's difficult, repetitive, unfathomable, finally surprised you, and so on the situation will appear. Before the project, you see the customer is "superficial", even let you think is "friendly", but after doing the project, especially when it comes to benefits, you can gradually discover the "true face" of the customer.

On the other hand, the customer feels the same way about us, and we start to think we are quite tall, and as the project progresses, we find that we are low-level, can't understand what I'm saying, promise things can't be done, often delay delivery, change a lot of reasons and dodge and so on.

Estimate, these two points can not be missed, you can make a big safety factor a oh, ka Ka

Experience: To enlarge your original estimate of 200%, of which 100% for internal running-in use, and another 100% to the customer running-in use. (for reference only, the consequences are at your own risk)

Project estimation is a perennial problem, my article for your reference, this is the first article series:

Practical Agile Estimation (1)--not just a question of uncertainty

http://blog.csdn.net/fireball1975/article/details/28437245

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Thought 4 days can fix the project, the result has been engaged for nearly one months ...