整体迭代/增量软件生命周期原则解析
在软件项目管理中，整体迭代/增量（HI/I）软件生命周期遵循着一系列通用原则，这些原则对于实现有效的项目管理至关重要。下面我们将详细探讨这些原则及其在项目管理中的应用。
1. 管理需求而非任务
在 HI/I 生命周期中，项目经理对项目需求的关注度远高于瀑布式生命周期。因为需求是项目调度和团队分配的基石。
在瀑布式项目中，项目经理可能会给团队分配“设计信用评级计算组件”这样特定的设计任务，该任务仅涉及设计环节，与分析、编码、测试等环节相互独立。而且团队的工作范围仅限于业务问题中的信用评级计算部分，不涉及客户服务、利率计算、月度报表等。然而，这种任务分配方式会导致各活动之间存在大量接口，团队之间需要频繁沟通和传递信息，增加了项目的复杂性。
而在 HI/I 生命周期中，团队会被分配实现一组特定需求的责任。例如，团队可能负责实现“输入新信用卡客户 - 基本路径”这一用例路径。团队需要确保在迭代结束时，该功能能够得到演示。虽然用户界面可能不够精美，错误处理功能可能尚未完善，但从业务人员的角度来看，整个流程是可以完成的。
这种规划方式与瀑布式任务分配有很大不同，具有诸多优势：
- 业务人员可以在每次快速迭代（1 - 3 周）结束时看到切实的进展。
- 团队在迭代过程中能够灵活应对变化，因为设计并非一成不变。
- 团队的积极性能够保持在较高水平，因为他们能够定期产生实际成果，获得即时满足感。
- 团队之间的接口比瀑布式任务分配更少，主要与架构团队和业务分析师进行交互。
- 团队由跨职能的人员组成，有助于减少不同专业之间的矛盾，并且能够促进方法和实践的创新。
