First chapter tariff
On the surface, it seems that there is no separate problem to cause difficulties, each can be solved, but when they are entangled and accumulated together, the team's action will become more and more slower. The degree of trouble of the problem, everyone seems to be surprised, and it is difficult to see the nature of the problem. However, if we want to solve the problem, you must try to understand it first. - Clearly explain the difficulty of system development.
This is the programming. A many people suffering the tar and a creative activities that have fun and distress coexistence. For many people, the fun is more than distressed. The remainder of this book will try to build some bridges and provide some guidance in such tar. - The purpose of this book
Chapter 2 people moon mythology
1. In many software projects, lack of reasonable time schedule is the most important reason for the lag of projects, it is much more affected than all other factors. The cause of the disaster is:
First, we have lack effective research on estimation techniques.
Second, the estimation technology we use is implicitly assumed that people and months can be interchangeable, and the progress is confused with the workload.
Third, since it is lacking confidence in its own estimation, software managers usually do not have patient continuously to estimate this work.
Fourth, the progress lacks tracking and supervision.
Fifth, when aware of the offset of the progress, the reaction of the next awareness (and the traditional) is increasing.
2. During the system development, optimism should not be reasonable.
In a single task, the assumption that "everything will run is normal" has realizable on time schedule. Because the delay encounters is a probability distribution curve, "will not delay" only have limited probability, so the real situation may smoothly be smooth like planned. However, large programming work, more or less contain a lot of tasks, and some tasks have the order before and after, so that all normal probability becomes very small, even close.
3. Cost does have a large change in the number of people developed products, and the progress is not the case. So I think that the use of people as a measure of a work is a danger and deceptive myth. It suggests that the number and time of the person can be replaced with each other.
Because software development is essentially a system work - a practical relationship under intricate relationship - communication, communication is very powerful, it will quickly consume the task to decompose personal time. Thus, adding more people, actually extension, rather than shortening time progress.
4. In the time schedule, the influence caused by sequential restrictions, no part is more thorough than the unit test and system testing.
For the schedule of the task, the following is the author's experience in using a lot of experience: 1/3 Plan 1/6 encoding 1/4 component test and early system test (unit test) 1/4 system test
5. If the actual progress of the project is discovered, the best way for project managers is to rearrange the progress, rather than increasing the project human hand.
6. The time of the project depends on the order limit, and the number of people depends on the number of individual subtasks. From these two values, the progress schedule can be calculated, and the personnel arranged in the table, which takes a long time (the only risk is that the product may be outdated). On the contrary, more people are distributed, and the plan will not be able to get a feasible schedule. In short, in many software projects, the lack of reasonable time schedule is the most important reason for the lag of projects, it is much more affected than all other factors.
