(第5空)So it is today.Schedule disaster, functional misfits,and system bugs all arise because the left hand doesn't know what the right hand is doing.As work ( ),the several teams slowly change the functions, sizes, and speeds of their own programs, and they explicitly or implicitly( )their as sumptions about the inputs available and the uses to be made of the outputs.
For example, the implementer of a program-overlaying function may run into problems and reduce speed relying on statistics that show how( )this function will arise inapplication programs. Meanwhile, backat the ranch,his neighbor maybe designing a major part of the supervisor so that it critically depends upon the speed of this function. This change in speed it self becomes a major specification change, and it needs to be proclaimed abroad and weighed from a system point of view.
How, then, shall teams( )with one another?In as many ways as possible.
•Informally. Good telephone service an daclear definition of intergroup dependencies will encourage the hundreds of calls upon which common interpretation of written documents depends.
•Meetings. Regular project meetings, with one team after another giving technical briefings, are( ) . Hundreds of minor misunderstandings get smoked out this
way.
•Work book.A formal project work book must be started at the beginning.