SCRUM 说明

在工作中灵鹞软件认可并使用 Scrum 的价值观作为团队的核心价值观，并使用敏捷开发方法(Scrum)作为日常开发工作的主要方法，在日常工作中基于自身和客户的实际情况进行适当的调整，以达到最佳的执行效果。

敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。敏捷开发主张由 Robert C. Martin 等人在 2001 年提出如下主要原则:「持续不断地及早交付有价值的软件使客户满意。」、「欣然面对需求变化，敏捷过程掌控变化。」、「经常地交付可工作的软件。」、「业务人员和开发人员必须相互合作。」、「每个人都有相同的核心目标，和所需的环境和支援。」、「信息传递沟通是敏捷工作中重要的组成部分。」、「可工作的软件是进度的首要度量标准。」、「产品负责人、开发人员和用户共同维持持续开发步调稳定延续。」、「坚持不懈地追求技术卓越和良好设计，借此增强敏捷能力。」、「简洁为本，减少不必要工作量是一门艺术。」、「最好的架构、需求和设计出自自组织团队」、「定期地反思如何提高成效，依此调整自身的举止表现。」

敏捷开发的价值观

  • 个体和互动 高于 流程和工具

  • 工作的软件 高于 详尽的文档

  • 客户合作 高于 合同谈判

  • 响应变化 高于 遵循计划

Scrum（2017/11 版本）

Scrum 是遵循敏捷开发原则和价值观的一个框架，人们可以用其解决复杂的适应性问题，同时富有成效和创造性地提供最高价值的(软件)产品。 -- scrum.org

Scrum 的理论简介

Scrum 基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。Scrum 采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。

透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

透明

团队中的所有(包括客户)人都会对观察到的事物有统一的理解。

  • 所有参与者谈及过程时都必须使用统一的术语。

  • 负责完成工作和检视结果增量的人必须对「完成」的定义，有一致的理解。

检视

经常检视 Scrum 的工作内容和完成 Sprint 目标的进展，以便发现不必要的差异。

适应

如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整以减小偏离。

Scrum 团队组成

产品负责人 Product Owner

产品负责人是一个人(不是一个团队)，决定构建什么样的产品， 职责是将开发团队开发的产品价值最大化。让产品与开发团队的工作价值最大化，产品负责人是管理产品代办清单的唯一责任人，产品代办清单的管理包括：

  • 清晰地表述产品待办列表项；

  • 对产品待办列表项进行排序，使其最好地实现目标和使命；

  • 优化开发团队所执行工作的价值；

  • 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及

  • 确保开发团队对产品待办列表项有足够深的了解。

产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定

开发团队 Development Team

开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且「完成」的产品增量。在 Sprint 评审会议上，一个「完成」增量是必需的。只有开发团队成员才能创建增量。开发团队具有以下特点：

  • “自行组织”，没有人告诉开发团队如何把产品代办清单项目变成可发布的功能增量。

  • “跨职能”，开发团队是一个整体，具有开发产品增量所需要的全部技能。

  • “开发人员”，团队中只有头衔”开发人员“。

  • 开发团队没有子团队，如：没有测试和业务分析团队。

  • 开发团队中每位成员可以有特长和专精领域，但是责任归属于整个团队。

敏捷大师 Scrum Master

敏捷大师负责按照 Scrum 的定义引导、促进和支持 Scrum。通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

Sprint

Sprint 是 Scrum 开发流程中的一个最小循环的工作时间单位，其长度（持续时间）为一个月或更短的限时。在这段时间内构建一个「完成」、可用的和潜在客发布的产品增量（也称为一次迭代）。在整个开发期间，Sprint 长度一致，前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。

Sprint 的组成

Sprint 计划会议 （不超过 8 小时）

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共同协作完成的。每一次机会会议讨论如下内容：

  • 接下来的 Sprint 交付的增量中要包含什么内容以及内容的优先级？

  • 要如何完成交付增量所需的工作？

  • 根据筛选的增量内容，确定本期 Sprint 的目标。

Sprint 每日站会 （不超过 15 分钟）

每日站会是开发团队自己每日召开一个时间限定在 15 分钟的活动，在 Sprint 的每一天举行。

开发团队籍由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。

在站会上开发团队讨论以下问题：

  • 昨天，我为帮助开发团队达成 Sprint 目标做了什么？

  • 今天，我为帮助开发团队达成 Sprint 目标准备做什么？

  • 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。

每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。是一个进行检视与适应的关键会议。

Sprint 评审会议 （不超过 4 小时）

Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。

这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

评审会议包含如下内容：

  • 参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关( Stake Holders )者；

  • 产品负责人说明哪些产品待办列表项已经「完成」和哪些没有「完成」；

  • 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；

  • 开发团队演示“完成”的工作并解答关于所交付增量的问题；

  • 产品负责人讨论当前的产品待办列表的情况。并根据到目前为止的进度来预测可能的目标交付日期（可选）；

  • 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的 Sprint 计划会议提供有价值的输入信息；

  • 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变； 同时，

  • 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场(可选)。

Sprint 评审会议的结果是一份修订后的产品待办列表，阐明可能进入下个 Sprint 的产品待办列表项。产品待办列表也有可能因为新的变更而进行全局性地调整。

Sprint 回顾会议 （不超过 3 小时）

Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

Sprint 回顾会议的目的在于：

  • 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；

  • 找出并加以排序做得好的和潜在需要改进的主要方面； 同时，

  • 制定改进 Scrum 团队工作方式的计划。

Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，如果适用并且不与产品或组织标准相冲突，Scrum 团队计划不同的方式通过改进工作过程或调整“完成”的定义来提高产品质量。

Sprint 的工件

产品待办列表 BackLog

产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和优先级。

产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。

产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更新。产品待办列表项通常包括测试描述，将在“完成”时证明其完整性。

产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精化过程中，产品待办列表项被重新评审和修改。

优先级越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。

开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。

Sprint 待办列表 To Do List

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到「完成」的增量中所需工作的预测。

Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中清晰地看到。开发团队在 Sprint 期间修改 Sprint 待办列表，使得 Sprint 待办列表在 Sprint 期间涌现。

当新工作出现时，开发团队需要将其加入到 Sprint 待办列表中去。随着工作的执行或完成，剩余的工作量被估算并更新。

在 Sprint 期间，只有开发团队可以改变 Sprint 待办列表。

Sprint 待办列表是高度可见的，是对开发团队计划在当前 Sprint 内工作完成情况的实时反映，该列表由开发团队全权负责。

增量 Increment

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。

在 Sprint 的最后，新的增量必须是「完成」的，这意味着它必须可用并且达到了 Scrum 团队「完成」的定义的标准。

增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

Scrum 价值

勇气、专注、承诺、尊重和开放五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum 团队成员通过 Scrum 的角色、事件和工件来学习和探索这些价值观。

Scrum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队的目标。Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于 Sprint 工作和 Scrum 团队的目标。Scrum 团队及其利益攸关者同意将所有工作和执行工作上的挑战进行公开。Scrum 团队成员相互尊重，彼此是有能力和独立的人。

Scrum 的角色、事件、工件和规则是不可改变的。虽然只实施部分的 Scrum 是可能的，但这样就不是 Scrum 了。Scrum 只以整体形式而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。

参考文献

Previous分工协作[原型]NextSCRUM 实践规范[试行]

Last updated

Was this helpful?