Software process management today too often falls to one of two extremes. No doubt you've experienced one of them: 1) Highly structured and rigid processes with an oftentimes religious fervor for documentation and adhering to the prescribed process. These processes are often communicated through reams of printed documentation or hours of training/online reading material and may have their origins from deep within academia. 2) Ad hoc processes. Perhaps too dignified a term for what usually occurs, which is little more than seat of the pant: survival by responding to the crisis du jour. These processes are exemplified by their battle-scarred heroes and are often born out of frustration or fear of approach #1. It is this state of affairs that makes software process man-agement a generally unwelcome topic in many development organizations. In the first case, developers can't handle one more demand from the process, or the production of code will grind to a complete standstill - if it hasn't already. In the second case, the haggard organization is afraid that stopping to even consider process management will derail them from extinguishing the current blaze, resulting in everyone being out of a job.
展开▼
