90天炼就斯巴达方阵（二）

2.2敏捷培训

这里指的是敏捷基础知识培训。培训很重要，但不是因为通过培训可以告诉大家“做什么”，而是因为要告诉大家“为什么”这么做。做什么是需要你后续在实践中手把手教大家的，这个不难；难的是能得到成员的理解和支持，并且坚持正确的去做，甚至发展出更适合团队情况的定制做法。

从某种意义上说，对“集体承诺”、“自我管理”、“涌现”等概念的理解，比Scrum的框架更重要。游戏是将复杂的工作场景抽象成简单模式的好方法，通过游戏去亲身感受这些抽象晦涩的概念或者理念，会比直接说教的效果好太多了。很有可能在将来的某一天，团队开始质疑回顾会是否还需要继续，或者控制和命令的方式在团队内部又开始蠢蠢欲动。届时，你会感谢之前精心准备的培训或者游戏，因为你只需唤醒大家当时的记忆就能避免一番口舌，甚至化解一场危机。

图6 培训中的七公

2.3商定Sprint节奏

Sprint节奏其实就是5个Event的周期安排，包括Sprint的长度、起止日期，以及各个会议的具体召开时间。这些节奏一旦定下来后，就要求每个人都必须严格遵守，不要轻易改变甚至取消。至少在初期，这些变动都必须经过Scrum Master的批准。而对于Scrum Master来说，任何对Event的干扰，你也有责任和义务进行排除，甚至寻求高层的协助和支持。

寻找固定周期的大段空闲时间不易（包括人和会议室）。节奏定下来后，别忘了赶快预定长期的会议室。英雄有时候真的会被尿憋死。

表1 长度为2周的Sprint节奏安排示例

2.4 生成Product Backlog

Product backlog即为达到产品目标所需完成的事项，要符合Mike Cohn所说的DEEP原则（Detailed Appropriately, Estimated, Emergent, Prioritized）。此时，我们至少要为Sprint1准备好充足的PBI（product backlog item）清单。如果PO不知道怎么做，那就需要你去辅导，也正是体现你价值的好机会。

如果产品比较复杂，那么就有必要召开一场产品梳理会（product grooming或者product refinement）。梳理会不属于Scrum Events，不一定非要召开。而且为了节约人力成本，也不需要所有人都参加。为了公平起见，最好是让大家能够轮流参与，而不是每次都只邀请几个“关键”人员。但如果你想在梳理会上进行估算，根据敏捷的规划原则，此时你最好让所有人员都参会。

梳理会的产出物至少包含下一个Sprint所需完成的PBI清单。对于大而复杂的任务，我们可以从中切取一小块相对来说简单清晰的部分先行入手。然后通过在后续Sprint中不断的学习和反馈（包括技术和业务两部分），渐进明细，让需求得以“涌现”。

每个PBI的大小也要合理。多大才算合理呢？任务太大，不利于流动性，持有成本会增加；任务太小，又会增加处理成本。就像图7中的U型图所示，使得总成本最小的那个横坐标上的点，就是我们理想中的大小。Mike Cohn在《Agile Estimating and Planning》中建议，对于2周一次的迭代，能在大约 2~ 5 天内完成即是合理的。按照Humanizing Work的说法，一个PBI的大小最好在一个Sprint Velocity的1/10到1/6范围之内。如果说我们并不想花太多精力在梳理会上做估算，那么大致差不多就可以了，更细节的工作可以放在Sprint Planning上去完成。

在实际工作当中，“拆分”大PBI的技能应该比“合并”小PBI的技能更重要。因为摆在我们面前的需求通常都是庞大而模糊的，需要我们花费精力去分析、拆解、验证，一点点剥去其上的面纱。想知道一个PO是否富有责任心或者专业，一个很简单的方法，就是去看看到他的product backlog。而这也是你帮助PO提高的一个切入点。

图7 U型曲线（来源于《产品开发流的原则》）

2.5定义DoD

DoD是Definition of Done的简称。在《Scrum指南》中，DoD的定义是“当 Increment 符合产品所需的质量度量标准时对其状态的正式描述 ”。有点抽象，我个人的理解就是完成一个PBI所需执行的所有活动。

为什么DoD这么重要，需要单独提出来？原因有两个。

1，清晰定义的DoD会保障团队在协作过程中的有序和高效。换言之，没有DoD，Sprint会出现混乱。试想下，针对 “完成“的increment，开发A认为只是提交了代码，开发B认为是通过了静态代码检测的，测试认为是通过了单元测试，而PO认为已经通过了功能测试。到最后，这个increment，乃至整个Sprint到底是什么状态，就没有谁能知道真相了。更可怕的是，这种“我以为”的合作方式，如果一直到了发布的那一刻还没被发现，后果将是灾难性的。除非你是故意纵容失败，让成员在教训中成长，明白DoD的重要性（我曾经用这种方法在Sprint1的回顾会上，让大家自发开始了制定DoD。当然前提是这样的失败在当时是能够接受的，比如说产品还没有真实客户使用）。同样的原因，最好把DoR（Definition of Ready）也定下来，至少在初期还是很有用的。

2，DoD是改进的源泉。DoD有宽度和深度两个维度：深度是质量保障的成熟度（比如说单元测试通过率的提高，提交代码前增加通过静态代码检测等等），宽度则代表了工程实践的成熟度（比如说是通过功能测试为止，还是通过生产环境的部署为止）。日常工作中，大家对深度的关注会比较多，因为深度的指标绝大多数也是质量监督部门频繁抽样检测的指标。对宽度的扩展相对来说比较容易忽视。

图8的横坐标展示了DoD宽度的几个常用值，越靠右要求越高。一般情况下，我们都应该把DoD定到通过功能测试（如果不能，多半是组织架构有问题，使得团队里没有身怀测试技能的工程师，或者不能单独拥有一个测试环境）。再到后来，就可以把DoD慢慢扩展到通过集成测试，通过端到端测试，直至到生产环境的成功发布，甚至到终端用户的正面反馈。终极目标的达到，需要强大的DevOps能力，以及完全面向服务和产品的组织和技术架构。同时也需要Scrum Master拥有强大的信念，以及不断进取的学习精神，立足团队的同时，积极和组织层面进行频繁的沟通和互动。

在执行层面，建议用workshop的方式和团队一起来制定DoD。首先，先请团队们头脑风暴，把产品从需求到交付应该要执行的所有活动都列出来；然后，把目前团队可以做到的程度识别出来，达成一致后，这个活动集合就是当前的DoD；最后，团队对下一步应该做到的活动达成一致，并经过讨论，列出改进项。这个过程其实也是价值流识别的过程。

图8 DoD扩展的示例（来源于http://Less.works）

2.6 小结

根据具体情况，启动Sprint之前的准备工作远远不止上面五项。比如说工作协议的制定，技术环境的准备等等。但在打造敏捷团队这方面，这五项准备是万万不能少的。如果条件所限，即使没有正式参与以上五项的过程，起码也应该在非正式的情况下达成一致，并正式的宣布。否则要做好后面以数倍的代价来填坑的准备。“善战者无赫赫之功”，救火英雄的存在往往是管理缺失的症状，而且常被用来当作无能的遮羞布。