我对Scrum的洞察

Posted 2021-04-25 DevOps社区

新媒体管家

Scrum相关的书和文章已经有很多了，我并不想在这里重复。学习Scrum的基础，有两份资料推荐。

• Scrum指南（中文版），它是由Scrum创始人Jeff Sutherland和Ken Schwaber写的定义了Scrum的文档，自然具有权威性。

• Scrum简章（中文版），它在社区里存在演进的时间也已经很长了，其实践的视角和细节程度对Scrum实践者提供了很好的指导参考。

在此基础上，我想说说我对Scrum的理解。我会从两方面阐述，一是Scrum基于迭代的活动设计；二是Scrum对角色的选择定义。

 Scrum活动设计

Scrum是基于经验型过程的流程框架。

敏捷价值观的第一点就是“个体和互动高于流程和工具”，强调的是让做事的人拥有自己的流程。因此，Scrum定义的只是一个流程框架，留给做事的人充分的空间去制定并演进自己的流程。

经验型过程是基于目标的检查适应。Scrum的活动设计基于经验型过程，在两个层次，一个是每天，另一个是每个迭代，分别对应到每日站会（每天发生），迭代评审和回顾（每个迭代发生）。

活动	目标是什么？	检查什么？	如何适应？
每日站会	迭代目标 范围 （需求完成） 价值 （为什么）	任务完成的进展 （基于任务的迭代燃尽图） 需求完成的进展 （基于需求的迭代燃尽图） 障碍和风险	团队自身的适应 任务的调整 分工的调整 时间的调整 团队和PO一起的适应 调整范围 异常终止迭代
迭代评审	产品目标 价值 （为什么）	交付的产品增量 （接受或拒绝） 需求完成的进展 （基于需求的发布燃尽图） 价值完成的进展 障碍和风险	需求的更新 优先级的改变 下一迭代目标的形成 发布计划的更新 产品开发的终止
迭代回顾	改进目标 迭代做到完成 改进愿景	过去迭代发生的 工作得好的和需要改进的 改进的进展	改进行动 （协作、工程、组织等） 更新工作约定 扩展完成定义

上面的表格总结呈现了经验型过程的要点，我们来详细阐述两个关键点：“以终为始”和“检查适应”。

以终为始

目标的定义是经验型过程控制的前提，我们分别来看对应不同活动的目标。

1. 迭代目标

每日站会是围绕迭代目标的检查适应。迭代目标的定义发生在迭代计划中。当团队和PO一起定义迭代目标后，团队通过每日站会的检查适应来达成目标。迭代目标可以定义成在迭代结束时需要完成相应的需求交付，也可以定义成更为抽象更接近价值的目标，比如实现某个用户场景（需要完成一系列的需求）。无论如何，我们不应该把迭代目标定义成完成任务，因为任务会在迭代过程中随着检查适应而改变。

2. 产品目标

迭代评审是围绕产品目标的检查适应。产品目标的定义通常发生在产品计划中，从最初的产品展望到持续的发布计划。产品周期可能很长，所以通常指导迭代评审检查适应的产品目标是阶段性的，比如发布目标或者季度目标。交付需求不应该是产品目标，定义产品目标的关键是回答为什么要交付这些需求，希望改变什么用户行为或者获得什么收益。这样一来，交付需求就成了达到产品目标的途径。产品目标是由PO定义的，他通过迭代评审的检查适应来达成目标。

3. 改进目标

迭代回顾是围绕改进目标的检查适应。Scrum中内置的一个重要改进目标是在迭代结束做到完成。完成的定义是考虑了现状确实可行的，最终是要达到潜在可交付。如果我们已能持续做到完成，而完成的定义还没有达到潜在可交付，就应该考虑扩展完成的定义。如果我们已能做到潜在可交付，还可以考虑缩短迭代周期。无论如何，改进目标必须能产生适度的挑战，以驱动改进。改进目标由整个Scrum团队来拥有，他们一起通过迭代回顾的检查适应来达成目标。

很多时候我们发现Scrum的经验型过程工作得不好，是因为没有做到以终为始。没有目标的指引，就无从检查适应。

检查适应

在目标明确后，每天（针对迭代目标）或者每个迭代（针对产品目标和改进目标），我们都会做检查适应。

1. 每日站会

团队通过每日站会来检查离迭代目标有多远，在接下来这天该如何调整。

如何理解每天的进展是个有趣的话题。传统的迭代燃尽图基于任务完成，我们从中可以知道任务的进展。但是任务的进展并不意味着需求的进展，因此我们也可以基于需求来画迭代燃尽图。除此之外，我们也会关注任何影响迭代目标达成的障碍和风险。

理解了现状后，团队决定接下来的调整。缺省情况下由团队自己进行调整，包括添加／修改／删除任务、改变任务优先级、重新分工、甚至加班。如果团队自发加班，并且不影响可持续开发，我个人觉得这只是团队对迭代目标和现状检查后作出的适应。如果团队发现即使做了最大限度的调整，达成迭代目标还是危险，那就应该叫上PO一起来调整了。需求的范围会被重新协商，通常当前迭代范围中最低优先级的需求会考虑放弃，团队在接下来时间专注于完成高优先级的需求。如果可能，最低优先级的需求会被拆分，以使部分需求仍然可以完成。需要注意的是，部分需求的完成，而不是需求的部分完成（比如编码完成而测试没完成）。极端情况下，PO会决定终止当前的迭代，重新开始一个新的迭代计划。

2. PO通过迭代评审来检查离产品目标有多远，在接下来这个迭代该如何调整

如何理解每个迭代的进展是个困难的话题。整个迭代评审会有团队、用户／客户、各种干系人参加，PO会听取大家对产品的反馈。验收是迭代评审中检查的一部分，如果PO和团队在迭代中紧密协作，通常完成的需求都能被接受。发布燃尽图能帮我们理解当前迭代结束后相对于整体的发布情况如何。因为发布燃尽图是基于需求完成的，这里有个重要的假设，我们大致知道整体的发布范围，那样就可以知道大概完成了多少比例，根据速率就可以导出大致还需要多少个迭代。这个假设只有在需求的不确定性相对较小的上下文中才成立。当不确定性较大时，究竟做哪些需求能够帮助我们达成价值目标是PO工作的最大挑战，也是他给产品成功带来的最大贡献。PO会关注任何影响产品目标达成的障碍和风险。

理解了现状后，PO决定接下来的调整。最直接的调整反映在对产品待办列表的更新，包括添加／修改／删除需求、改变需求的优先级。发布计划和发布燃尽图也会相应更新，发布的范围／时间／成本可能会做调整。下一迭代的目标开始涌现，PO选取最能够帮助达成产品目标的需求进入下一迭代的计划活动。极端情况下，PO和管理层会一起决定终止该产品开发。

3. Scrum团队通过迭代回顾来检查离改进目标有多远，在接下来这个迭代该如何调整

Scrum团队包含团队、PO和SM。做事的人拥有自己的流程并对之加以改进，为此我们需要整个Scrum团队一同来检查适应。在回顾中，SM引导大家检查过去迭代中发生的重要事件，产生的过程数据和趋势，尤其是与改进目标相关的部分。《敏捷回顾》书中提供了很多的方式帮助团队全面有趣地收集“数据”，而最重要的问题和改进机会从中逐步涌现。

当对需要改进的问题达成共识后，回顾的重点转向接下来如何调整。对问题的深入分析为采取行动奠定了坚实的基础。常见的质量流程改进方法在这时可以得到应用，比如鱼骨图、5个为什么、因果关系图等。当可能的根源显露出来后，Scrum团队一起设计行动实验在下一个迭代尝试。改进行动可能涉及协作方式、工程实践、组织结构等，也可能会更新工作约定或者扩展完成的定义。

在我看来，理解经验型过程的应用原则，并关注每日站会、迭代评审和回顾中检查适应的效果，是实施Scrum的精髓所在。

 Scrum角色选择

Scrum中只定义了三个角色，理解其背后的考虑是实施Scrum的另一个重点。

唯一的PO

唯一的优先级可以有效避免多头管理的困境。Scrum中对于团队来说，工作的入口是唯一的，都通过产品待办列表输入。这样说来其实也可以由一个产品委员会来统一定义优先级，理论上也可行，但是实际上容易带来决策效率低下等一系列问题，所以Scrum选择了PO是一个人的做法。PO和团队及干系人还是需要协作，尽量达成共识，但他拥有最终决策的权力。

PO负责产品的成功，什么是产品是个重要的问题。通常来说你的产品需要面向最终客户，这使得PO通常来自于产品业务部门，而非技术研发部门。这对打破传统的合同游戏至关重要，产品业务人员和技术研发团队在整个产品开发过程中紧密协作。

团队是个角色

团队中每个人都是团队成员，也就是说在Scrum中并没有开发或测试这样的角色定义。这是个有意的选择。团队共享职责是Scrum的核心概念。每个人都要有意愿互相帮助来一起达成目标，即使那样意味着有时需要跳出自己的舒适区去工作在一些不熟悉的领域。当某个开发人员在说我的工作已经做完了，尽管测试还没完成，很有可能他还没有对团队成员这个角色形成正确的认识。同样的情况也发生在前端开发人员不觉得后端工作的进展与他有关。

要特别说明的是，这并不是忽视团队成员技能上的差异，或者以此促进每个人技能的同质化。当然每个人都是全栈工程师会让团队没有瓶颈，Scrum真正要求的是团队通过协作能够跨职能跨模块地按价值优先级交付需求。当团队长期稳定存在时，动态的工作总是会带来技能不匹配的情况，Scrum希望团队成员以此为契机拓展自己的技能，从而发展成为多面手专家。

SM是教练

有很多的误解以为SM接近项目经理的角色。事实上，SM是个教练，而项目管理在Scrum中由三个角色分工共同完成，更多的项目管理职责落到了PO和团队上。产品发布作为一个大项目，PO承担更多项目管理职责，最重要的是管理发布的范围／时间／成本。迭代作为一个小项目，团队承担更多项目管理职责，这也是团队自管理的重要方面。

教练在传统组织中并不存在，这给大家理解SM带来了困难。SM在引导、辅导、咨询这些既相似又不同的方式之间进行切换，促进整个Scrum团队和组织的持续改进。有些管理者承担了类似的职责，甚至采用类似的方式，最大的不同在于管理者是传统组织层级定义中的问责节点，而SM并不对团队的直接产出承担问责，团队自身会被问责。这点对SM有效地辅导自组织团队大有裨益。

点击“阅读原文”，可访问原文

版权说明  本文内容采编自Odd-e

---

这是DevOps实践社区

长按二维码就可以关注哦~