现代软件管理的文化转变

　　要成功转移到现代软件管理过程就必须克服几个文化转变。对其中的某些调整来说，将难以区分客观的反对和顽固的抵制。然而，向现代文化的成功转变有一些具有普遍性的迹象。本节讨论几个这种大致的迹象以便区分已经完成了名副其实的转变的项目和那些仅仅虚有其表面的项目。很多指标都直接从前面章节中描述的过程框架得来；其他的是二级影响。
　　底层和中层经理是执行者。在只有25人或者更少的组织或子组织中应该没有“纯粹的经理”。只有当人力资源数量超过这个级别时才需要纯粹的经理。实际管理技能是多样的，但是有能力的经理通常花费大部分时间来履行职责，特别是了解直接经手的项目的状态并制定计划和估计。最重要的管理工作的人应该计划这个工作。这并不是说经理应该批准计划，而是说经理应该参与到计划的制定中。在我做过的独立项目评估中，将会出麻烦的一个好标致就是经理不亲自制定计划也不获得计划的所有权。受这个转移影响的项目相关人员是软件项目经理。
　　需求和设计是易变的和有形的。传统过程效力于生成文档来努力描述软件产品，而很少效力于生成产品自身的切实增长。主里程碑仅仅以特定的文档来定义。为了满足里程碑的要求并得到进展报酬，大的合同项目的开发组织被迫生成大量文件，而不能把他们的精力花在可以减少风险和生产高质量软件的任务上。迭代式过程要求实际构建一系列逐渐变得完整的系统，以这些系统来证明构架的正确性、实现客观的需求磋商、验证技术方法和专注于对关键风险的解决。理想情况下，所有项目相关人员都应该致力于这些“真实”的里程碑，它们具有增量式的有用的功能性的交付产品，而不是对最终构想的推测性的书面描述。向更少受文档驱动的环境的转移将被工程群组接受，同时它可能会受到传统的合同监管人员的抵制。
　　野心勃勃的演示是受到鼓励的。生命周期的前期演示的目的是揭露设计缺陷，而不是走走形式。项目相关人员不能对前期的错误、偏离和不成熟的设计反应过度。前期发布计划中的进化标准是项目目标而不是需求。如果过分强调前期的工作障碍，开发组织将会带着更少的雄心去构件将来的迭代。另一方面，项目相关人员不应该容忍在解决问题时缺乏坚持到底的态度。如果负面趋势没有被积极的解决，他们能够引起后续活动的严重混乱。坦率而又专心地坚持到底是解决问题所必需的。因为这个转移将揭露任何使用传统过程容易掩饰的工程和过程问题，所以管理群组最可能抵制它（特别是项目被吹嘘过度时）。客户、用户和工程去怒将因为几乎一样的原因接受这个转移。
　　好的和坏的项目性能在生命周期的前期变得更加明显。在迭代式开发中国，成功孕育着成功，同时前期的失败特别容易导致项目逆转的危险。实际的项目经验已经反复展示了是前期阶段促成或者破坏一个项目。所以确保由最好的群组来执行计划和构架阶段具有高于一切的重要性。如果由好的群组正确地完成了这些阶段，就能够通过一般的群组来将应用进化最终的产品以成功地完成项目。如果计划和构架阶段执行得不够，那么世界上所有的专家程序员和专家测试员都可能无法取得成功。没有人会反对在前期就按照正确的人员结构组织项目团队。然而，多数组织对于这种类型的生命周期前期角色缺乏足够的资源，同时对于必须进行的人员分配也犹豫不决。