The estimated project time is critical to the success of the project. Project Time Management includes the completion of the project on time required for each process. However, in actual projects, project delays, inaccurate estimates of serious recurring phenomenon.
Estimated time itself is difficult. Each programmer with time estimates will really need some gaps.
Estimated time short description some things are ignored (compile, test, submit code).
Estimated time over the task description is too difficult to understand.
For junior programmer, this estimation error is confusing, they often underestimate the number of tasks at the same time on some tasks a little difficult overestimated.
I think, for a programmer experienced at the time of a task should be between a half hour to 24 hours, 24 hours beyond the tasks need to be split.
Programmers in the brain might think that to 60 hours,
But in fact even experienced programmers also need to make a decision analysis tasks come into manageable modules.
There is also a need to recognize the very important point is that experience is not the same programming experience to estimate the time.
Never done a duration estimation is not good at the estimated time of programmers.
If you do not really need to pick up time and the estimated time to compare,
You can not get the correct estimated time from the experience of other feedback information.
Each programmer will be used to assess skills. In order to improve your skills that you can exercise on each task you are doing. At the start of the task before the estimated time required for development, take it with you would really be compared elapsed time. In this way, you not only have to improve in the understanding of the details of the task, but also improve the skills of your time estimates.
Hofstadter's Law: The actual time is always longer than expected, even if you take into account Hofstadter's Law.
PM often have complained that why the company never developed their own estimates of project time? ! However, this witty programmers has long been commonplace.
I've even seen a completed project is expected to last two days it took four months,
Even under the "double time" rule of thumb point of view is quite exaggerated.
From the senior level, the problem is - engineers and other personnel or PM
A method of estimating time and different ways of thinking.
The first reaction of most engineers is that if everything goes according to plan normal, then write the shortest time required for a prototype. While the PM or other downstream workers want to know is, when will the project be ready from this moment to release this time is how long? So this is an entirely different story.
So for engineers to master time estimate is an essential skill,
This means that you are a professional, stable and efficient developers.
Why the need for time estimates?
External dependencies
any effective thing would not happen out of thin air. Projects are often external dependencies exist, with functions such as team communication (financial, PR, customer support) and exchanges and other customers. And with these external coordination is often dependent on the work of the CEO or PM, which means that the most qualified person to do time estimates (engineers) do not need most of these people are estimated. This asymmetry leads to a fundamental tension.
Priority
time calculation is also critical to determine priorities. In the field of engineering cost is an important indicator, even if you are doing the function is the most powerful in the world, found that the elapsed time calculation takes a long time to achieve, then the priority of this function will not be too high.
Let's say you're doing a project, you can make your site later made 50% faster, but with the same time you could complete the two projects,
And each item can make your site faster 40%. If you do not take the time to preliminary calculations, you never know you can also do a faster website!
Primary time estimates
assume that we have reached a consensus on this very important time estimates, we continue to look at how to estimate. Under normal circumstances, we underestimated the time required is because we want is "how long it takes to write a prototype?."
However, things are often delivered the prototype than most, and you also need to consider testing, debugging, optimizing the time it takes. There are meetings, interviews, code review, or even e-mail all it takes time.
Another reason is underestimating the time required for unexpected problems that often can not be fully taken into account, such as IDE updates and let you spend more than a day to configure the environment, and so on.
Based on this, we'd better not be too sure so-called experience and intuition.
Step 1: develop technical solutions
before starting any major project, you should have a plan or technical design documents. The purpose of this document is to let people know what you're doing and get feedback. When you notice the technical details, you will more clearly know the exact time spent, such as a library is updated to the new version, you may spend a day. You even have to write yourself a library.
Particle size here is very important. If there is a part of what people think is not clear, either you should know more about them, either have to break it down into more detailed steps. At the same time, if a step too fine, then it may be too fragile invalidate the whole project, so to grasp the degree.
Want to know what your document should consider something, you can look AliciaChen this article. The key is to communicate clearly with the PM, eliminate ambiguous place, so as not to lead to the final to be reversed.
Step 2: Add one step each time estimating
how much time documentation of every step of implementation needs, which often involves the study of the details (this is not already have a library?). Therefore, depending on the nature of the project in terms of, do a simple prototype can help reveal many potential pain points.
Step 3: additional fault tolerance time
now you've got a preliminary estimate of the time, but there are many other factors to consider.
At any time debugging: Bug difficult to avoid, depending on the maturity of the developer specific code base of experience and code libraries. Conferences and holidays: a meeting or holiday is generally not knock code, so the code really knock How long? So when you want to take a look at the schedule time estimates. The final test: the test should normally while the encoding side, but a lot of teams need to do integration testing before release, so allow time for this part in your estimation. Code review: In this code base you usually need several rounds? How much time is required for each round? How many reviewers have to go through? Pay attention to reviewers schedule to ensure that the time code review.
When you put the cost of the delivery time is also taken into account, you will be able to see the actual time of their release time estimates and projects to match much more.
While the actual situation may also be longer, you may also need to shorten the construction period due to stress.
But we understand when your estimate more accurate, they will trust you more.
Step 4: After the release of the review time estimates
Replay quite painful, but the next time you make better review. Every item that does not match the expected real time what happened, to find the cause and improve it.
All in all everything is communication. Advance communication, regular communication, understand each other's needs and schedule changes.
PM with relevant actors such communication also allow the other party to provide important information that may affect your estimation. A designer might say this animation takes a week schedule, simply do not cut up. Another PM may also be added that this is just a prototype for further study and only, this iteration process without too much bug.
For engineers, the unrealistic not to do a shorter duration of compromise, openness more professional.
For the PM and others, to respect this estimate may need a process, but you know it is impossible to shorten the construction period alone nagging of.
Project Time is not easy to estimate, only good communication, empathy and determine the function priorities can.
--------------------------------------------------------------------------------------------------------
Reference users know almost part of the answer, quite interesting, you can see.
Hofstadter's Law: The time it takes to do things always take longer than you expect, even if your expectations are taken into account Hofstadter's Law.
Scrum philosophy is: Duration is no way to estimate accurate.
So Scrum approach is to use various means to the Product Owner (you can think of is the customer) pulls / narrow the project development process, let him have a better understanding of the development, which can accept the goods within a period of time we can get ( even when the product is only semi-finished products).
Personally think that this practice is quite clever, because:
1, so that the original developers know nothing about, have automation fantasy customers see process development, breaking his fantasy, reduce the psychological expected value;
2, so that customers understand the process needs to put forward their own implementation, you can avoid a lot of changes in demand shabby thing;
3, as customers full participation in development, so when developing suspension or termination, output of the product must be acceptable to the customer, which avoids rework, misunderstanding;
4, developers can have many opportunities to talk to customers to explain all kinds of difficulties in the development process, which to some extent also reduce the customer too much attention to the cut-off point in time.
Of course, the implementation of Scrum, the most troublesome is the exchange, as technical staff, to white customers do science is always the most annoying thing, but the other way around, and technical personnel to go to understand customer needs, but also customers need to repeatedly explain and emphasize their intent, motive thing. Increase exchange opportunities in order to get things done, both sides happy, this is the purpose of the project, is not it?
safer practices, according to project manager experience to develop a preliminary plan, then try a small interval (I usually once a week, encountered unstable up to 3 days 1) to check and adjust the
time the developer is very valuable, always try not to interrupt them
The shortest refers threw himself into the shortest time.
- Done before a similar function
- Direct estimates based on experience, basically can not go wrong.
- Not previously done, but clear thinking
- Usually estimate the time is too short. Give your BOSS two points in time, let him have the mental preparation.
- Shortest Time: everything goes smoothly, according to the idea of one-stop complete. Happy.
- The longest: the shortest time x 3
- Previously done
- Do not rush to estimate. Let BOSS give you enough time to conduct research.
- If the larger project, said: the next day to confirm the time.
- If the project is small, said: after a while in order to confirm the time.
- When the research, the work split off, each individually estimated.