Optimism
All programmers are optimists. This may be particularly attractive to those who believe in the magic of modern happy ending
People; it could be hundreds or thousands of trivial setbacks get rid of most people, only those who focus only on the result of habit;
Just because a computer may also be very young, younger programmers, but young people are always some optimists - either
What kind of program, the result is undoubted:. "This time it will certainly run" or "I just found out last mistake
error. "
So the first assumption behind the system programming schedule is: everything will work well, each task took only
It costs "should" time spent.
On this permeates the programmer of optimism, deserves careful analysis. Dorothy Sayers in her
"The Mind of the Maker", a book, creative activities will be divided into three stages: conception, implementation and communication. book
Membership, computer, or there is a program, first as a concept or model appears in the author's mind, and it is time
Space and nothing to do. Subsequently, by means of a pen, ink, and paper, or wire, silicon and ferrite, in real time and space
To achieve them. Then, when someone read books, use computers and running the program, he and another author's ideas
Communication, so the creative process to an end.
Very easy to master computer programming based media, programmers by very pure mental activity -
The concept and flexible forms to develop the program. Precisely because tractable medium, we do not expect the implementation process
Encounter difficulties, thus creating a diffuse optimism. Our idea is flawed, so there will always bug. It
It is to say, our optimism should not be as it should be.
System test
In the schedule, the impact caused by the restriction order, which is not part of the subject than the unit debugging and system testing
It involves more thoroughly. Moreover, the time required depends on the error encountered, the number of defects and capture their degree. Reason
The theory, the number of defects should be zero. However, because of our optimism, the actual number of defects usually occur than expected
Much more. Accordingly, the organization system test progress is often the most irrational part of the program.
For scheduling software tasks, the following is a rule of thumb I use for many years:
1/3 plan
1/6 coding
- 10 -
1/4 months early component testing and system testing
1/4 system test, all the components have been completed
In many important respects, with the traditional method of scheduling different:
1. Allocate much time to plan than unusual. Even so, still not enough to produce detailed plans and specifications, said stable
Ming is not enough to accommodate the research and exploration of new technologies.
2. code for debugging and testing completed, spent nearly half the time, a lot more than the usual schedule.
3. easy to estimate the portion, i.e. encoding, allocated only one-sixth of the time.
Through the study of traditional project schedule, I found very few items allowed to allocate half the time for the test, but the
Most of the test project is actually spent half the time in the schedule. Many of them project, before the system test also
To maintain progress. Or, in addition to system testing, progress can basically guarantee 2.
Of particular note is that the test is not sufficient time for the system would be a disaster. Because the delay occurred
When the project is almost complete. Until the release date of the project, we have found problems progress. Therefore, there is no bad news
Any warning, late in front of the customer and the project manager.
In addition, at this moment of unusual delays have serious financial and psychological reactions. Prior to this, the project
We have configured adequate staffing, labor costs per day has reached the maximum limit. More importantly, when the software is used
When to support other business activities (computer hardware arrival, new equipment, on-line service, etc.), these activities delays
Immediately before release, then the business will have to pay a very high price.
In fact, the above-mentioned secondary cost is much higher than other expenses. Therefore, in the early planning schedule, allow for sufficient
System test time is very important.
Vague estimate
Look programmer, you may find, like cooks, schedule a task, may be limited
The degree of urgency required by the customer, but the degree of urgency can not control the actual completion. Like an appointment within two minutes to complete a
Omelette, looks likely to be very good. But when it can not be completed within two minutes, the customer can choose to wait or raw
Eat fried eggs. A similar situation software customers.
There are other options chef: he can open a large fire, but the results are often unable to "save" the omelette - a
Face has been burnt, while the other side still raw.
Now, I do not think inner courage and perseverance as good as chef manager software, or as other engineering manager. but
Unreasonable schedule in order to meet customer expectations caused by the date, than any other in the field of software engineering
Much more common. Moreover, the use of non-stage method, very little data to support, plus complete by software manager
Intuitively, this way is difficult to produce reliable and robust estimates of risk aversion.
Clearly we need two solutions. Development and implementation of productivity charts, defect rates, estimates rules, etc., and the entire
Organizations will eventually benefit from the shared data.
Alternatively, prior based on reliable estimates based on appearance, project managers need to stand up straight, stick to their estimates,
Confident that their experience and intuition derived from the better than expected results to be much stronger.