实操演示：如何用 ONES 制定 Scrum 迭代计划？

敏捷开发的核心是迭代，每个迭代都包含规划、设计、开发、测试等步骤，通过频繁的发布，以及对前一次迭代反馈的跟踪，推进产品逐步改进。

随着研发实践的深入，敏捷衍生出了非常多的开发方法，包括：Scrum、精益方法、极限编程（XP）、Kanban 等等，其中，Scrum 无疑是目前最为成功的敏捷方法，因为它提供了一套固定的角色分工和工作流程，更容易被大部分团队所接受。

今天，我们将带你深入了解什么是 Scrum，以及如何用 ONES 进行迭代规划，高效落地 Scrum，一起来看看吧～

什么是 Scrum？

Scrum 是一种迭代增量的软件开发过程，覆盖产品的生产、交付和管理，通常用于敏捷开发。

• 第一步：产品负责人负责梳理来自利益相关方的反馈与需求，并按照优先级排序，形成 Product Backlog ，即产品待办事项；

• 第二步：经过迭代规划、会议分析，和对 Product Backlog 进行估算，形成了 Sprint Backlog ，即迭代待办事项；

• 第三步：由团队在固定的开发周期内交付潜在可发布的产品增量；

• 第四步：经过迭代评审和迭代回顾，结束当前迭代，并开始下一次迭代。

• 
  

（1）三大角色

角色 1：产品负责人 (Product Owner)

产品负责人的核心工作是对团队交付的价值负责，他的职责是定义需求、需求优先级、需求验收标准，以及产品发布内容与日期。

角色 2：敏捷教练 (Scrum Master)

敏捷教练的核心工作是帮助团队熟悉和掌握 Scrum 框架，持续改进，又好又快地开展工作。

角色 3：研发团队 (Scrum Team)

研发团队囊括了开发人员、测试人员、业务分析师等开发所需角色，规模通常为 5-9 人，具有自组织、自管理的特征，对交付成果负责。

（2）三大工件

工件 1：产品待办事项 (Product Backlog)

产品待办事项即产品视角的需求清单，由产品负责人进行维护、增减及优先级定义，每项需求都需要描述其外部价值，用户故事是其中的一种最佳实践。

工件 2：Sprint 待办事项 (Sprint Backlog)

Sprint 待办事项来源于产品待办事项，在 Sprint 规划会议上，团队需要对挑选的需求进行讨论、分析和估算，得到相应的任务列表，即 Sprint BackIog，并一起定义「完成」的标准。

工件 3：潜在可交付产品增量 (Increment)

在冲刺结束后，需要在迭代评审会议上展示可对外发布的产品功能增量。

（3）五大事件

事件 1：冲刺 (Sprint)

可以将 Sprint 或迭代视为一个特殊的事件，它的周期通常为 2-4 周。

事件 2：Sprint 规划会 (Sprint Planning Meeting)

Sprint 规划会的核心议题是根据产品待办事项，对产品 Backlog 中的需求进行估算，确定下一次冲刺要实现的目标和范围，形成迭代待办事项。

事件 3：每日站会 (Sprint Daily Standup)

每日站会在固定时间召开，每天 15 分钟，目标是促进信息在团队内共享与透明。

团队成员要简要回答 3 个问题：我昨天做了什么？我今天计划做什么？目前我是否碰到了障碍，障碍是否阻碍我完成目标？不作深入的问题讨论。

事件 4：Sprint 评审会 (Sprint Review)

Sprint 评审会在冲刺末期召开，用户检查本期的成果。它需要团队全体参与，并邀请相关干系人，产品负责人可以拒绝接收成果。

事件 5：迭代回顾会 (Sprint Retrospective）

会议在迭代评审会结束后召开，同样需要团队全体参与，共同复盘本次冲刺，总结经验与教训，并形成切实可行的改进清单。

（4）5 种价值观

• 开放：Scrum 把项目中的一切开放给每个人看，信息透明对提高协作效率帮助巨大。

• 尊重：每个人都有独特的背景和经验，尊重每一个团队成员是项目信任的基础。

• 勇气：成员有勇气做出承诺、履行承诺，接受别人的尊重

• 专注：把心思和能力都用到你承诺的工作上去

• 承诺：愿意对目标做出承诺，全身心投入 Scrum 团队的目标，而不是必须按计划完成

总的来说，Scrum 是一套解决复杂问题的框架，让我们以迭代和增量的方式，在最短时间内交付价值最大的产品。具体的流程要根据团队的实际情况灵活调整，不要生搬硬套。

如何用 ONES 进行迭代规划？

（1）确定迭代目标

树立目标至关重要，这个目标可以是「挣更多的钱」、「打动 CEO」、「完成优先级最高的三个故事」或「把系统做得足够好，作为 Beta 版发布给真正的用户使用」等等。

（2）确定迭代周期

建议在整个项目期间保持稳定的迭代周期，这会让团队遵循稳定的开发节奏，也有利于准确预估项目完工所需时间。

在 ONES 中，我们可以新建迭代，并设定迭代周期和属性，周期建议为 1 到 4 周，可以基于团队情况机动调整。

新建迭代，自定义迭代属性

（3）确定迭代规模

迭代创建完成后，我们需要明确每次迭代能完成多少需求。我们可以基于 ONES Performance 效能管理中的数据，了解团队在历史迭代中共完成了多少个故事点、多少个需求、花费了多少工时，从而准确地规划当前迭代。

可视化展示迭代数据

（4）评估产品需求

对产品 Backlog 中的故事点和工时进行预估，明确需求的边界、范围、验收和完成标准，对于需求不清楚的，由产品负责人进行说明，一旦不符合，团队有权利拒绝需求，不加入本期迭代。

在这个过程中，我们可以利用 ONES 筛选出列表中所有未规划进迭代的工作项，并按照优先级进行排序，形成产品待办事项，利用并通过「规划到迭代」的功能，将选择好的需求规划到已经创建好的迭代内。

将需求批量规划至迭代

（1）将需求拆分任务

借助 ONES Project 迭代下的敏捷看板，我们可以将需求拆分为任务，并分配给不同的负责人。

将需求拆解为任务，指定对应负责人

（2）对任务进行工时预估

除此之外，我们还可以对各自的任务进行工时预估，并通过迭代的剩余工时统计及燃尽图直观把控任务进度。

填写预估工时，查看剩余工时进度

这些工作完成之后，我们的迭代规划会议就结束了。在这个环节，由敏捷教练负责把握会议流程和时间，如果迭代周期是 2 周，建议迭代规划会议的时长不超过 2 小时。

凭借专业的解决方案及服务能力，ONES 已成功帮助浪潮软件、招商基金、贵州茅台、中国电信等多个行业的 20 万余中大型团队实现研发效能提升。