32、软件敏捷开发方法的比较与分析

软件敏捷开发方法的比较与分析

1. 理解已知领域

可以将惠勒图重铸为一个连续的二维空间，其中 x 轴衡量过程成熟度，y 轴衡量对已知领域的理解程度，也就是当前模型与现实的契合度。

在物理和化学领域，分析模型高度发达，属于效应 - 原因 - 效应科学。利用物质已知的化学性质和化合物相互作用的思维模型，能够预测新材料的特性。例如，开发具有防水、轻便、透气、高强度和闪亮外观的运动面料时，科学家可依据化学知识进行预测。随着对化学领域的认知不断深入，模型也在持续改进。

在软件开发中，y 轴被称为“分析和建模成熟度”，代表软件开发理念概念模型的成熟度，包括模型中概念的数量和准确性。

2. 提高分析和建模成熟度

多数敏捷方法认为软件开发过程无法控制，因为软件开发的基本要素未知且不可知，其依据是一些先前的模型失败了。例如，用例驱动开发及其相关工件可能过于繁琐而无用，这引发了对交付软件灵活性和可维护性的质疑，有人认为雅各布森的软件模型是错误的。

然而，一些研究正在逐渐揭示软件的真实模型，如 Coad（1999 年提出的特性、原型、领域中立组件）、Palmer（2000 年扩展原型和领域中立组件）等。以使用状态图设计技术构建 Web 应用的用户界面为例，状态图模型能精确描述待实现的代码，并与设计精确映射，可准确衡量用户界面开发的复杂性和工作量。同时，控制器和视图的开发工作量具有统计一致性，UI 设计和开发是可定义、可预测和可重复的。彼得·科德关于特性的研究也表明，特性与业务需求直接相关，可准确预测其开发情况。

综上所述，用户界面和业务逻辑开发是可重复和可控制的，并非混乱不可知。

3. 提高过程成熟度

在图表中，x 轴上箭头向左移动表示过程成熟度提高，这里的过程改进是指敏捷过程改进，它是一种自组织、以人为本、注重心理因素的过程。过程改进能使软件开发系统在图表上向左移动，意味着软件生产系统能提供更高质量的产品，即具备约定功能、在规定缺陷和进度容忍范围内。

但不能忽视图表的另一个维度（y 轴）。如果过程能在 y 轴上提升，控制和预测能力将得到改善，因为对测量和跟踪的内容有了更清晰的认识，从而提高了准确规划的能力。

大多数敏捷方法声称对分析或设计方法不做特定要求，认为只要有快速反馈和响应能力，分析和设计方法就不重要。一些敏捷方法因此局限于单一维度（x 轴），只能处于混沌边缘状态，这让专业成熟组织的管理者思考，单纯的反应式反馈机制是否足够，是否需要一定程度的规划和可预测性。

4. FDD 方法的特点

FDD（特性驱动开发）强调通过前期分析进行预测性规划，Stephen Palmer 称之为 JEDI（初始阶段足够的设计）。FDD 的前期工作方法和“一次做对”原则，结合架构分区，旨在减少设计和构建阶段的噪音和不可预测性，在建模和架构阶段消除系统开发中的未知因素，使设计和构建阶段处于阈值状态。

FDD 使用领域中立组件建模技术，产生了可重复性高、方差低的结果，如“1 周的建模可带来 12 周的开发”这一经验法则被证明非常准确。如果目标是基于准确预测进行商业投资决策，FDD 能在正确执行时提供准确预测。而其他一些敏捷方法采取务实的态度，询问企业愿意承担多少风险，无法确切承诺交付的内容。

FDD 试图通过改进技术和理解软件开发机制来控制过程，被一些敏捷主义者认为“不够敏捷”，但它可能更符合精益生产方法，注重减少方差、保证质量和控制库存，可能更适合六西格玛公司。

5. XP 方法的特点

XP（极限编程）方法学家认为 XP 能驯服混乱。仔细研究其最佳实践，如将小故事写在卡片上，根据业务价值分解和优先级排序，评估风险和复杂性并估算工作量，表明 XP 具备可控性的核心指标。近期 XP 趋向于更短的迭代周期（最初为 1 天，现在为 1 周而非 2 周），表明 Kent Beck 试图利用基于经验的预测性控制优势。

通过采用 XP 的所有最佳实践，有可能使 XP 过程达到阈值状态，产生与 FDD 相当的控制效果。这需要以可重复的方式编写故事并广泛使用故事点进行复杂性、风险和规模评估。

6. 不同方法的比较

理论	重点	控制方式
Scrum	交付时间和加速	反馈
XP	质量和交付时间	反馈
FDD	库存、交付时间、质量和方差	反馈和前馈

FDD 是一个更复杂的过程，使用反馈和前馈控制，关注质量、库存、交付时间和方差；XP 专注于交付时间和质量，仅使用反馈控制；Scrum 更简单，仅关注交付时间和消除加急情况，同样依赖反馈控制。

7. 追求过程成熟度

仅仅宣布采用敏捷方法并不意味着改进，系统可能仍处于混沌状态。正确使用敏捷方法能迅速提升系统成熟度，如 XP 提升质量的方法可使组织在图表上向左移动到混沌边缘状态。要达到阈值状态，系统必须采用方法论中的所有最佳实践，并采用能减少软件不可预测性的分析和设计方法，使实证观察成为可能。

敏捷方法认识到不能仅依赖反应式控制，试图在图表的 y 轴上提升，因为预测性控制器在控制工程中能产生更好的结果。没有能提供准确指标的过程控制，管理层将难以做出正确的投资决策，而良好的过程控制是实现卓越财务成果的直接要求。

8. 生产指标的比较

8.1 FDD 的指标测量

FDD 按天、周、月和季度测量完成的特性。特性粒度细、易评估复杂性且具有可重复性。一个典型的 3 个月的 Web 开发项目，10 名开发人员可能有 500 个特性，包括用户界面、业务逻辑、数据管理和系统接口特性。一名程序员每周可能完成 5 个特性，每个特性的工时估计为 4、8、16、32、48 小时或更多。通过测量每个特性，可确保整体交付率达标、特性权重准确、开发时间在允许范围内。每个特性在六个转换阶段都被跟踪，每天可获得 40 - 50 个数据点，能快速判断项目处于阈值状态还是混沌边缘状态，以便采取措施。

8.2 XP 的指标测量

XP 的控制单位是故事点，故事代表客户价值功能，可作为库存的衡量指标。XP 项目的跟踪器应能提供故事点排队、进行中和完成的每日数据，以及迭代中通过测试的故事点数据。XP 团队用“速度”衡量故事点完成率。

目前，编写故事的方法缺乏足够定义，难以在团队间进行标准化比较。随着团队成熟，故事编写风格会趋于一致，可根据“速度”设定准则。在当前阶段，XP 更易展示产品符合度而非生产速率，控制故事是否通过测试可衡量质量，质量指标对生产速率有重要参考价值。XP 可能无法提供与 FDD 相同数量的数据点，因为 XP 故事比特性大，且由于其极端性，对转换阶段的可见性较低，但如果能跟踪与故事相关的任务，也可产生类似数量的数据点。

综上所述，不同的敏捷开发方法各有特点和优势，在实际应用中，需要根据项目的具体需求和特点选择合适的方法，以提高软件开发的质量和效率。同时，不断提高分析和建模成熟度以及过程成熟度，对于实现更好的项目控制和财务成果至关重要。

9. 软件开发管理指标的关键要点

软件开发过程的可管理性可通过对吞吐量管理指标的研究进行比较和预测。Shewhart 的统计过程控制工作以及 Wheeler 对控制状态的分类提供了一些线索。关键在于要测量过程的输出，即系统中交付的客户价值功能片段，同时测量系统的方差与可接受范围的对比。测量单位相对于输出越小，提供的反馈就越多，测量的灵敏度就越高，从而能更灵敏地调整过程并提高前馈预测能力。

9.1 指标测量的重要性

• 反馈灵敏度 ：小的测量单位能带来更多反馈，使测量更灵敏，有助于及时调整过程。
• 预测能力提升 ：高灵敏度的测量能提高前馈预测能力，让管理者更好地规划和控制项目。

9.2 不同方法的指标表现

方法	测量单位	数据点情况	控制特点
FDD	特性	每天可获得 40 - 50 个数据点	反馈和前馈控制，关注多方面指标
XP	故事点	目前数据点可能较少，故事编写待标准化	主要依赖反馈控制，注重质量和交付时间

10. 敏捷方法的选择与应用

在选择敏捷开发方法时，需要综合考虑项目的特点、团队的能力以及企业的目标。以下是一些选择的参考因素：

10.1 项目特点

• 项目规模 ：大型项目可能更适合 FDD，因为它能通过前期分析和架构分区减少复杂性和不可预测性；小型项目则可以考虑 XP 或 Scrum，它们更灵活、简单。
• 项目复杂度 ：复杂度高的项目需要更精确的控制和规划，FDD 的预测性规划可能更合适；而复杂度较低的项目，XP 或 Scrum 的快速反馈机制可能更能满足需求。

10.2 团队能力

• 技术能力 ：团队技术能力强，能够快速适应新方法和技术，那么可以尝试更复杂的 FDD；如果团队技术能力一般，选择简单易实施的 XP 或 Scrum 可能更合适。
• 合作能力 ：强调团队合作和沟通的项目，Scrum 的团队协作模式可能更有效；而注重个人能力发挥和创新的团队，XP 的自我组织方式可能更适合。

10.3 企业目标

• 质量要求 ：对产品质量要求极高的企业，FDD 或 XP 可能更符合需求，因为它们都注重质量控制；而对交付时间要求紧迫的企业，Scrum 可能更能快速交付产品。
• 成本控制 ：需要严格控制成本和库存的企业，FDD 的库存和方差控制优势可能更明显；而对成本控制要求不高的企业，可以根据其他因素选择更适合的方法。

11. 敏捷方法实施的流程建议

无论选择哪种敏捷开发方法，以下是一些通用的实施流程建议：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([项目启动]):::startend --> B(选择合适的敏捷方法):::process
    B --> C(制定项目计划):::process
    C --> D(组建团队):::process
    D --> E(进行需求分析):::process
    E --> F(迭代开发):::process
    F --> G{是否达到项目目标?}:::decision
    G -->|是| H([项目结束]):::startend
    G -->|否| F

11.1 项目启动

明确项目的目标、范围和约束条件，为后续的开发工作奠定基础。

11.2 选择合适的敏捷方法

根据项目特点、团队能力和企业目标，选择最适合的敏捷开发方法。

11.3 制定项目计划

制定详细的项目计划，包括迭代周期、里程碑和交付物等，确保项目按计划进行。

11.4 组建团队

选择合适的人员组成开发团队，明确各成员的职责和角色。

11.5 进行需求分析

与客户沟通，明确项目的需求，并将其转化为可执行的任务。

11.6 迭代开发

按照迭代周期进行开发工作，不断交付可运行的软件版本，并根据反馈进行调整。

11.7 项目结束

当项目达到预定目标时，进行项目总结和评估，为后续项目提供经验教训。

12. 持续改进的重要性

在软件开发过程中，持续改进是提高项目质量和效率的关键。无论是分析和建模成熟度还是过程成熟度，都需要不断地进行优化和提升。

12.1 分析和建模成熟度的改进

• 学习新的方法和技术 ：关注行业的最新发展，学习新的分析和建模方法，如 Coad、Palmer 等人提出的理论，不断完善软件开发的概念模型。
• 总结经验教训 ：在项目结束后，对项目进行总结和反思，分析哪些地方做得好，哪些地方需要改进，将经验教训应用到后续项目中。

12.2 过程成熟度的改进

• 优化流程 ：根据项目的实际情况，对敏捷开发流程进行优化，去除不必要的环节，提高流程的效率。
• 加强团队协作 ：通过培训、团队建设等活动，提高团队成员之间的协作能力和沟通效率，减少团队内耗。

总之，软件开发是一个复杂的过程，不同的敏捷开发方法为我们提供了多种选择。在实际应用中，要根据具体情况选择合适的方法，并注重持续改进，以提高软件开发的质量和效率，实现更好的项目控制和财务成果。