scrum

1. 起源

Scrum（司克兰）源自日本的“丰田生产系统”（Toyota Production System）和美国空军的 OODA 循环理论。

OODA: 又称为“博伊德循环”，是一种空战理论。OODA 指 observe-orient-decide-act，意为“观察->导向->决定->行动”。该理论认为双方都从观察开始，包括观察自己、环境和敌人，在观察的基础上获取相关外部信息，根据感知到的外部威胁，及时调整系统，做出应对决定，并采取相应行动。

PDCA 循环。PDCA 四个英文字母分别代表计划（Plan）、执行（Do）、检查（Check）与行动（Action）。

敏捷软件开发宣言：人胜过流程、可以使用的软件胜过面面俱到的文件、客户合作胜过合同谈判、应对变化胜过遵循计划。

2. scrum 方法的本质

无论你什么时候启动一个项目（可以运用到各个行业），为什么不经常检验一下自己正在做的事情，看看是否朝着正确的方向前进？结果是不是大家真正希望看到的？是否有什么办法能改善目前正在做的事情？如何才能做得更快更好？存在哪些潜在的障碍？

Scrum 是一种迭代式增量软件开发过程。所谓迭代，是指把一个复杂且开发周期很长的开发任务分解为很多短期可完成的任务，这样的一个周期就是一次迭代的过程；同时，每一次迭代都可以生产或开发出一款可以交付的产品。

3. scrum 实践步骤

3.1 挑选一位产品负责人。

这个人必须知道自己带领的团队需要做什么、制造什么产品以及取得什么成果，必须全面考虑到风险与回报、什么具有可行性、什么能做以及他们对什么富有热情。（参见第八章）

3.2 挑选一个团队。

真正做事的是谁？这个团队必须能够落实产品负责人的愿景。团队规模宜小不宜大，一般 3~9 人较为合适。为一个延误的 IT（信息技术）项目增加人员，将导致更严重的延误。

3.3 挑选 Scrum 主管。

主管为 Scrum 过程负责，负责培训团队其他成员，确保 Scrum 得到正确运用，帮助团队消除一切障碍。

3.4 拟定待办事项清单，并确定优先顺序。

这个清单高屋建瓴地列出为了落实产品负责人的愿景而需要完成的所有事项。在产品的整个研发过程中，这个清单一直存在，并有所演变，相当于产品研发的“路线图”。无论在任何时间，要想知道一个团队要做的所有事项（按照优先顺序排列），待办事项清单都是唯一具有决定性的参考依据。待办事项清单只有一份，意味着产品负责人从头到尾必须不断地对优先顺序加以调整。产品负责人应该与所有利益相关者和团队进行协商，以确保产品待办事项清单既能反映用户的需求，又不会超出团队的能力范围。

3.5 改进和评估待办事项清单。

让负责实际开发工作的团队对待办事项做出评估，是一个至关重要的环节。团队应该审视每个事项，看看是否切实可行。但要完成这些事项，现有的信息足够吗？该项目是否细分到了可以评估的程度？团队是否具有了每个成员都能接受、用于评定一个事项已完成的标准？一个事项能否带来显著的价值？各个事项在完成后必须产生能够用来展示的成果，如果这个成果能交付给客户试用会更好。不要用所需小时数去评估，因为人们根本不擅长做出这么精确的评估。要用相对难度去评估，比如，难度是小、中或大。更好的方式是采用斐波那契数列的数字（1，2，3，5，8，13，21……）。

3.6 冲刺规划会。

这是第一场 Scrum 会议。团队成员、Scrum 主管以及产品负责人坐到一起，规划冲刺的内容。冲刺周期一般是固定的，不超过一个月，大部分是一至两周。团队要从待办事项清单的顶端着手（即从最重要的事项着手），看看一个冲刺阶段中能完成多少。如果团队已经开展过好几个冲刺，那就记录下每一个冲刺完成的事项的“点数”。这个数字相当于团队的速度。Scrum 主管与团队成员应努力在每一个冲刺阶段中提高这个数字。团队成员和产品负责人也可以借助“点数”确保每个人都能了解待办事项对于落实最终愿景的作用。对于冲刺目标，即在这一冲刺阶段完成哪些事项，所有人都应该形成共识。

Scrum 的基石之一在于，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。在冲刺的过程中，没有人能够变更冲刺内容。团队必须在冲刺阶段自主工作。

3.7 工作透明化。

在 Scrum 中，最常见的做法是准备一块白板，上面分成三栏：待办事项、在办事项、完成事项。把待办事项写到便笺纸上，随着进度的推进，将相应的便笺纸转移到其他栏目。让工作透明化的另一个工具是燃尽图。在这张图中，一个轴代表工作量，另一个轴代表时间。每天，Scrum 主管都会记录待完成的剩余点数，而后画在燃尽图上。理想情况下，该图是一条向下的曲线，随着剩余工作的完成，“燃尽”至零。

3.8 每日立会。

这是 Scrum 的活力源泉。团队每天在固定时间进行内部沟通，时间一般不超过 15 分钟，且站立进行，Scrum 主管向团队成员提出下列问题：（1）你昨天做了什么去帮助团队完成冲刺？（2）今天你打算做什么来帮助团队完成冲刺？（3）什么因素阻碍了团队的前进之路？Scrum 主管要问的问题就是这么多！整个会议的内容就是这么多！

如果会议时间超过 15 分钟，那就说明开会的方法存在问题。这样做的意义在于让整个团队清楚地知道在这一个冲刺周期内各项任务的进展。所有任务都能按时完成吗？有没有机会帮助其他团队成员克服障碍？团队的任务都不是自上而下分派的，而是自主决定、自主完成的，也不需要向上司做详细的汇报。Scrum 主管负责消除团队面临的障碍。

3.9 冲刺评估或冲刺展示。

在冲刺结束前，给产品负责人展示成果，也就是展示哪些事项可以挪到“完成事项”那一栏，并接受评价。这是一场公开的会议，任何人都可以是参与者，不仅仅包括产品负责人、Scrum 主管及开发团队，还包括利益相关者、管理人员与客户。团队应该只展示那些符合“完成定义”的事项，也就是全部完成，不需要再做工作就能交付的成果。这个成果或许不是完整的产品，但至少是一项完整的、可以使用的功能。

3.10 冲刺回顾。

团队展示之前冲刺中创造的成果，也就是展示已完成的事项，看看可以为顾客传递哪些价值，并征求反馈意见，大家就会坐下来想想哪些事执行得很顺利，哪些事应该做得更好，以及在下一个冲刺阶段中可以做出什么改善。

那么，如何发现流程中的哪个环节需要改善呢？要让这个冲刺回顾过程有效，团队需要相互信任。必须记住关键的一点，即大家不要从团队中找一个人当成责备的对象，而是要将注意力集中在流程上，认真分析以下几个问题：为什么会发生那件事？为什么我们当时忽略了？怎样才能加快工作进度？作为一个团队，大家要对自己的流程和结果负责，要集思广益，共同寻求问题解决之道。这一点是至关重要的。

与此同时，团队必须有勇气把真正的障碍摆到台面上来，这样做是为了解决问题，而不是为了指责某个成员。团队成员必须能认真探讨问题，并虚心接受他人反馈的意见和建议，以便寻求问题解决之道，而非只想着为自己辩解。然后就进入了关键环节。团队确定一个最值得改善的地方，将其设定为下一个冲刺阶段的首要任务，当然，改善的结果必须通过“验收测试”。你如何证明自己成功地完成了改善？你需要用具体的、可操作的方式界定什么是“成功”，这样，在下一个冲刺回顾会议中才能很快判断出是否已完成改善。

3.11 上一个冲刺阶段结束之后，立即开始新的冲刺阶段。

利用在之前的冲刺过程中，团队在消除障碍、改善流程方面积累的经验。

参考

《敏捷革命》杰夫.萨瑟兰