Never allow the schedule to drive the project or to demoralize the team. In the early Microsoft, no one cares about whether the project is progressing, but any progress is not allowed. If the programmer's missem worms continue to increase, it is not a serious problem, but as long as someone has not completed within the time of scheduling, then it is deep. "Progress" replaces project objectives and software quality, which has become a primary, and everyone is crazy.
Developing application software in this way, in theory, it seems reasonable but in fact, this progress control method, although the product can be shipped on time, but the developer has a very psychological pressure, the programmer has to seek progress Abandon quality. At that time, there may be a significant problem, but several years later, Microsoft tasted the terrible consequences of excessive progress.
This is caused by the fact that the progress is too unusual, it is based on the following assumptions:
* That all tasks-for a two-year project-were known and listed on the schedule * That each week each programmer would complete 40 hours' worth of the tasks listed on the schedule * That all task estimates were completely accurate * That all features Would Be Implement Perfectly, WITHOUT BUGS
If the schedule is set out so, even the best programmers cannot hold progress. The planned work is very difficult to prior, may develop to half of the discovery of a very important job, although each week is 4 0 hours (above), but not always Write procedure; a program takes more time is difficult to accurately estimate, especially when editing the schedule, it may not be a function of determining this program; the program does not need to be modified? That is impossible, not only may have a choice, but also the possibility needs to increase.
So Microsoft has made some modifications to this method:
Make Sure Your Schedules Are Attainable But Aggressive Enough To Keep Team Members Focused on Steady Progress. It is necessary to give all people a certain pressure from the beginning of the project. In most cases, in the early days of the project, everyone's mentality is very relaxed, always feeling there is still a lot, everyone always scattered in the morning, lifting the two-lang legs, while watching the white cloud outside the window, slow down Slowly think about the project. The later time is always very urgent, so everyone will start working in the pressure of the deadline. And the pressure of time is large, you must give up the quality of the program. If a project is too long, it makes everyone a psychology that is relaxed in the early days, then such a large project should be cut into some small projects, and the segment is completed. This will generate an incentive utility when you complete each small item.
