29、Scrum 敏捷开发全解析

Scrum 敏捷开发全解析

1. Scrum 基础概念

Scrum 开发过程涉及多个关键概念，理解这些概念是掌握 Scrum 方法的基础。
- 原材料（Raw Material） ：Scrum 的原材料是需求陈述。通过分析阶段，这些需求陈述被转化为产品待办事项列表（Product Backlog）中的条目，此分析阶段的成本应视为获取库存的一部分投资。
- 库存（Inventory） ：严格来说，Scrum 文档中未直接跟踪库存（客户看重的功能），而是一系列任务。这些任务并非都直接与客户看重的输出相关，因此可能无法准确反映真实的库存水平。推荐的跟踪方法是基于时间，但给定 Sprint 的小时数不能视为库存。跟踪库存有两种选择：一是将与客户看重功能相关的任务子集视为库存；二是将整个任务列表视为库存。若采用第二种方法，与 XP 的方法不一致。当 Scrum 与其他方法（如 XBreed 中的 XP）结合使用时，采用 XP 的故事库存跟踪方法更佳。

库存跟踪选项	说明
与客户看重功能相关的任务子集	包含产生吞吐量的差异化非功能需求
整个任务列表	可能与 XP 方法不一致

• 吞吐量（Throughput） ：Scrum 中的吞吐量是交付的版本或 Sprint 的价值，与版本待办事项列表或 Sprint 待办事项列表中的任务数量无直接关联。选择 Sprint 待办事项列表时，假定商定的任务列表已优化，以在 Sprint 结束时最大化交付价值，此交付价值即为吞吐量。
• 生产率（Production Rate） ：Scrum 提供了燃尽率（burn - down rate）机制，即 Sprint 待办事项列表中完成任务的速率，但这并非本文所定义的真实生产率（R）。要确定 R，必须跟踪客户看重功能的交付速率，可通过完成的故事或用例等方式进行跟踪。

2. Scrum 中的指标与管理

Scrum 有其独特的指标和管理方式，这些对于项目的顺利进行至关重要。
- 指标（Metrics） ：Scrum 在每个 Sprint 开始时报告版本预期剩余工作量。在 Sprint 内，每日主要报告的指标是任务的燃尽情况和问题日志的状态，这与项目管理指标兼容。
- Sprint 规划与项目管理 ：Scrum 的 Sprint 中没有传统的规划。开发人员以自组织、自愿的方式每日领取任务，任务分配无委派或管理控制。团队在每日站会中报告任务完成情况，从而了解燃尽率。其潜在假设是无需以正式方式规划 Sprint 待办事项列表中任务的顺序，关键是在 Sprint 结束前完成所有任务。所有任务在 30 天内都会成为关键路径，必须迅速消除阻碍任务完成的问题。可通过问题日志的大小、问题数量趋势和问题解决时间（问题前置时间）来衡量 Sprint 的健康状况。

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([开始Sprint]):::startend --> B(开发人员自组织领取任务):::process
    B --> C{任务是否完成?}:::decision
    C -->|是| D(继续下一个任务):::process
    C -->|否| E(消除阻碍问题):::process
    E --> B
    D --> F{所有任务完成?}:::decision
    F -->|否| B
    F -->|是| G([结束Sprint]):::startend

3. 时间相关概念

Scrum 中的时间概念对项目的进度和资源管理有重要影响。
- 前置时间（Lead Time） ：在小规模项目中，Scrum 采用快速应用开发（RAD）方法处理前置时间，即交付日期固定，范围和预算围绕商定的交付日期进行调整。对于单个 Sprint，前置时间为 30 天。在大规模项目中，Scrum 更具灵活性，可固定产品待办事项列表的范围，所需 Sprint 数量会相应变化；也可商定版本的交付日期为固定数量的 Sprint，范围则会有所变化。
- 过程步骤时间（Process Step Time） ：
- 版本过程步骤时间 ：队列时间是任务在版本待办事项列表中等待分配到 Sprint 待办事项列表的时间；设置时间是每个 Sprint 开始时的 1 天；处理时间严格为 30 天（1 个 Sprint）；等待时间是 Sprint 结束后到版本完成的时间。
- Sprint 过程步骤时间 ：队列时间是任务在 Sprint 待办事项列表中等待开发人员在每日站会中认领的时间；设置时间是开发人员审查任务、阅读需求和进行分析工作的时间；处理时间是为任务进行设计和编码的时间；等待时间是任务完成后到 Sprint 结束的时间。

过程步骤	版本	Sprint
队列时间	任务在版本待办事项列表等待分配到 Sprint 待办事项列表的时间	任务在 Sprint 待办事项列表等待开发人员认领的时间
设置时间	每个 Sprint 开始的 1 天	开发人员审查任务等的时间
处理时间	30 天（1 个 Sprint）	为任务设计和编码的时间
等待时间	Sprint 结束到版本完成的时间	任务完成到 Sprint 结束的时间

4. Scrum 规则与风险

Scrum 有一些重要规则和独特的风险哲学，这些规则和哲学保障了项目的稳定进行。
- 禁止加急（No Expediting） ：Scrum 禁止在 Sprint 期间向 Sprint 待办事项列表添加任务。因为加急会增加前置时间，根据利特尔法则，在制品库存的增加会直接导致前置时间延长。由于 Scrum 中前置时间是固定的，任何导致其延长的操作都不被允许。
- 库存上限（Inventory Cap） ：Scrum 严格控制系统中的库存，总库存由版本或 Sprint 中可承担的任务数量限制。但由于需求未充分分析为任务并估算工作量，难以提前确定准确的上限。不过，有经验的 Scrum 团队应能较好地进行估算，系统中的库存水平能在可接受的不确定范围内得到有效控制。若团队高估，未完成的范围会被添加回版本或产品待办事项列表，并在下次 Sprint 规划会议中重新考虑。
- 投资（Investment） ：获取库存的成本包括获取传统需求文档的成本以及创建产品待办事项列表和定期扩展待办事项列表的分析成本。这虽超出了 Scrum 文档的范围，但使用 Scrum 的组织必须衡量需求收集工作，以便展示财务指标。
- 风险哲学（Risk Philosophy） ：Scrum 的风险哲学与 XP 相似，不规定软件构建方法，认为软件开发困难，因此采用不超过 30 天的小批量开发方式。Scrum 将批量处理时间固定为 1 个月，从而固定了任何迭代的运营费用。若 Sprint 失败，客户仅损失 30 天的运营费用。Scrum 还允许在 Sprint 未完成时放弃，但这只是一种成本会计技巧，实际上运营费用是固定成本，项目已浪费了时间。

5. 测试、流水线与重构

Scrum 开发过程中的测试、流水线和重构环节对软件质量和项目进度有重要影响。
- 测试（Testing） ：Scrum 中的测试在 Sprint 期间进行，由 Sprint 团队执行并在 30 天内完成。与 XP 一样，验收测试时间应计入前置时间，因为只有在验收后才能记录吞吐量。Scrum 建议在 Sprint 输出演示时用一天进行验收，但专业组织可能需要进行适当的验收测试，这可能会使前置时间增加 1 个月。
- 流水线（Pipelining） ：在进行验收测试时，开发人员会开始下一个 Sprint。Scrum 原则上不希望在 Sprint 期间修改 Sprint 待办事项列表，但实际可能会发生，这违反了加急规则。若验收测试中发现的错误需安排到后续 Sprint 修复，会引入错误修复的队列时间延迟，可能在当前 Sprint 修复更好。严格遵循禁止加急原则会使系统中的在制品库存从一个 Sprint 增加到至少两个 Sprint，因此准确计算库存很重要，不能将处于验收测试的代码视为成品。
- 重构（Refactoring） ：记录的错误和重构任务可添加到 Sprint 待办事项列表，这会减少从版本待办事项列表中提取的任务数量。由于错误修复和重构任务作为任务添加到 Sprint 待办事项列表，难以看到正在进行的返工情况。这些任务不在版本待办事项列表的客户看重功能列表中，本质上是过程中产生的“幻影”任务。因此，采用跟踪客户看重功能而非 Sprint 待办事项列表任务的方法很重要，即跟踪版本或产品待办事项列表的完成率。

6. Scrum 中的人员角色与会议

Scrum 中有几个重要的角色和会议，它们在项目的不同阶段发挥着关键作用。
- Scrum 主管（Scrum Master） ：Scrum 主管负责实施 Scrum 方法，确保其有效引入和正常运行，兼具教练和协调员的角色。可将其比作体育教练，不仅观察运动员技术并提供改进建议，更重要的是关注运动员的心理状态，激励运动员发挥最佳水平。Scrum 主管通过确保 Scrum 过程正确执行，充分利用和提升开发人员这一受限资源的能力，从而提高生产率和吞吐量。
- Scrum 会议 ：在 Scrum 中，会议是信息交流和决策的重要方式。例如每日站会，开发人员在会上报告任务完成情况，分享遇到的问题和计划，这有助于团队保持同步，及时解决问题。

7. 版本与 Sprint 相关要点

版本和 Sprint 是 Scrum 开发过程中的重要阶段，它们的特点和规则影响着项目的整体进度和质量。
- 30 天 Sprint ：30 天的 Sprint 限制了实际处于开发和测试阶段的原材料。Sprint 旨在最终发布可工作的输出，但只有将其发布给用户或付费客户，才代表真正的吞吐量。Sprint 为开发到测试周期的库存提供了有效的本地上限，降低了投资和运营费用。Sprint 还锁定了 30 天周期内要构建的功能，开发团队能确定 Sprint 期间需求不会改变，消除了不确定性，使软件开发能以最佳速度推进。Sprint 消除了加急的可能性，避免了加急带来的生产率损失。Sprint 开始时有 1 天的规划会议，这一设置时间的开销占比不到 5%，且可能通过“无干扰”的 Sprint 提高的效率弥补。不过，如果 1 天的规划和分析不足以确定一个月的工作，项目将面临风险，团队可根据实际情况决定是否延长分析周期。
- 版本（Release） ：版本是多个 Sprint 成果的整合，版本待办事项列表描述了版本预期的任务。版本的交付涉及多个 Sprint 的协同工作，其前置时间、过程步骤时间等受到多个因素的影响，如任务在版本待办事项列表的队列时间、Sprint 的设置时间和处理时间等。

8. Scrum 向上管理的指标

要向高级管理层展示 Scrum 的实际成果，使其相信 Scrum 是有价值的软件开发方法，并能与其他方法进行客观比较，就需要收集与 Scrum 方法学家倡导的不同指标。
- 指标收集 ：敏捷经理必须收集吞吐量、库存和前置时间等指标，去除“幻影”任务，准确反映交付的价值，而不是报告 Scrum 中剩余的小时数。使用基于输入的指标（如工作量水平）进行报告可能会导致奇怪的结果，例如在不增加项目范围的情况下，预计完成时间可能会增加，但这至少能为管理层提供项目的新见解。
- 财务论证 ：为了说服首席信息官（CIO）和其他高管，必须以财务术语进行论证。收集与 Scrum 项目吞吐量相关的适当指标，并使用财务指标创建基于净利润和投资回报率（ROI）的财务论证，以展示 Scrum 项目相对于其他项目的有效性。

综上所述，Scrum 是一种灵活且高效的软件开发方法，通过合理运用其各种概念、规则和管理方式，能够有效提高软件开发的质量和效率，降低项目风险。但在实际应用中，需要根据项目的具体情况进行调整和优化，以充分发挥 Scrum 的优势。

Scrum 敏捷开发全解析

9. 待办事项列表的作用与特点

待办事项列表在 Scrum 中扮演着核心角色，它是整个开发过程的任务来源和规划基础。
- 产品待办事项列表（Product Backlog） ：产品待办事项列表就像是软件生产系统的库存储备，它包含了任务和活动，不仅仅是可交付成果。但它不能像其他一些方法那样清晰地指示库存，更侧重于反映生产输出所需的努力程度。产品待办事项列表会被分解为版本待办事项列表和 Sprint 待办事项列表。
- 版本待办事项列表（Release Backlog） ：描述了一个版本预期要完成的任务，是产品待办事项列表在版本层面的细化。它与版本的交付直接相关，影响着版本的范围和质量。
- Sprint 待办事项列表（Sprint Backlog） ：是针对单个 30 天开发迭代所商定的任务列表。它明确了 Sprint 期间团队要完成的具体工作，是 Sprint 执行的依据。

待办事项列表类型	描述	与库存关系
产品待办事项列表	软件生产系统的库存储备，包含任务和活动	较难直接反映库存
版本待办事项列表	版本预期任务的细化	与版本交付相关的库存体现
Sprint 待办事项列表	单个 30 天 Sprint 的商定任务	直接影响 Sprint 内的库存和工作

10. Scrum 与其他方法结合的考虑

在实际项目中，Scrum 常与其他方法结合使用，如与 XP 在 XBreed 中的结合。
- 与 XP 结合（XBreed） ：XBreed 是一种混合方法，Scrum 为 XP 提供管理框架。在这种结合中，库存跟踪可以采用 XP 的故事跟踪方法，而忽略 Scrum 待办事项列表作为库存跟踪的来源。这样做的好处是能更准确地跟踪客户看重的功能，避免 Sprint 待办事项列表中包含的“幻影”任务（如错误修复和重构任务）对库存跟踪的干扰。

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{选择方法}:::decision
    B -->|Scrum + XP (XBreed)| C(采用 XP 故事跟踪库存):::process
    B -->|仅 Scrum| D(考虑任务子集或整个任务列表跟踪库存):::process
    C --> E(进行开发):::process
    D --> E
    E --> F([结束项目]):::startend

11. Scrum 中的团队协作与自组织

Scrum 强调团队的自组织和协作，这是其高效运作的关键。
- 团队自组织 ：在 Sprint 中，开发人员以自组织、自愿的方式领取任务，没有传统的任务委派和管理控制。这种方式让团队成员能够根据自己的能力和兴趣选择任务，提高了工作的积极性和主动性。
- 团队协作 ：每日站会是团队协作的重要体现，开发人员在会上分享任务进展、问题和计划，促进了信息的流通和团队的同步。团队成员之间相互支持，共同解决遇到的问题，确保 Sprint 目标的实现。

12. Scrum 对项目变更的应对

在软件开发过程中，变更不可避免，Scrum 有其独特的应对方式。
- Sprint 内变更限制 ：Scrum 禁止在 Sprint 期间向 Sprint 待办事项列表添加任务，以保持 Sprint 的稳定性和可预测性。这是因为变更会增加不确定性，可能导致前置时间延长和生产率下降。
- 版本和产品待办事项列表的变更 ：对于版本和产品待办事项列表的变更，团队可以在 Sprint 规划会议等合适的时机进行调整。未完成的范围可以添加回相应的待办事项列表，在后续的 Sprint 中重新考虑。

13. Scrum 中的质量保障

质量是软件开发的重要目标，Scrum 通过多个环节保障软件质量。
- 测试环节 ：测试在 Sprint 期间进行，由 Sprint 团队负责。及时的测试能够发现和解决问题，确保每个 Sprint 交付的功能质量。验收测试时间计入前置时间，保证了只有经过验收的功能才能计入吞吐量。
- 重构工作 ：记录的错误和重构任务可以添加到 Sprint 待办事项列表，通过不断优化代码结构，提高软件的可维护性和可扩展性。但要注意跟踪客户看重的功能完成率，避免被重构任务掩盖真实的交付价值。

14. Scrum 项目的持续改进

Scrum 鼓励团队通过快速反馈进行持续改进。
- Sprint 回顾会议 ：每个 Sprint 结束后，团队会召开回顾会议，总结本次 Sprint 的经验教训，讨论哪些方面做得好，哪些方面需要改进。通过这种方式，团队能够不断优化工作流程和方法。
- 经验积累与调整 ：随着项目的推进，团队积累了更多的经验，能够更准确地估算任务工作量和规划 Sprint。例如，如果发现 1 天的 Sprint 规划时间不足，团队可以根据实际情况延长分析周期。

15. Scrum 与财务指标的关联

为了向管理层展示 Scrum 项目的价值，需要将 Scrum 与财务指标关联起来。
- 指标收集与分析 ：敏捷经理需要收集吞吐量、库存和前置时间等指标，去除“幻影”任务，准确反映交付的价值。通过分析这些指标，能够了解项目的进展和效率。
- 财务论证 ：使用收集到的指标，结合财务指标（如净利润和投资回报率），为 Scrum 项目提供财务论证。这样可以让管理层更直观地看到 Scrum 项目相对于其他项目的优势，从而支持 Scrum 方法的应用。

总之，Scrum 是一种综合性的软件开发方法，涵盖了从需求分析到版本交付的各个环节。通过合理运用其概念、规则和管理方式，注重团队协作、质量保障和持续改进，并与财务指标相结合，能够有效地提高软件开发项目的成功率和价值。在实际应用中，团队需要根据项目的特点和需求，灵活调整 Scrum 的实施方式，以实现最佳的开发效果。