【审视】Scrum Master的检查清单

一般情况下，一个Scrum Master如果更多的是做组织会议、确保时间盒以及对流程中的障碍快速响应等事项的话，可以同时引导2-3个团队。在这种情况下，团队会在降低问题发生率的基础上提高一定的绩效。

但如果Scrum Master想要将一个团队打造成让所有人都眼前一亮的敏捷团队，那就需要考虑如何成为优秀的Scrum Master，以及如何更好地引导团队。这时的Scrum Master最好是成为某一团队（尤其是在团队初创阶段）的全职引导者。接下来是一个Scrum Master的检查清单，来看看Scrum Master要从哪些方面入手引导团队吧：

一、产品负责人做得如何？

Scrum Master可以在很多方面提高产品负责人的效率：

• 不论有几个团队，一个产品是否只有一个产品负责人？

• 产品待办事项列表是否根据产品负责人最新想法进行优先级排序的？

• 待办事项列表是不断更新的，新反馈的需求是否已经放入产品待办事项列表？

• 产品待办事项列表的数量是否可管理？为了维护可管理的待办事项数量，需要将高优先级待办事项的颗粒度细化，低优先级的事项可以保持一个粗颗粒度的状态。过度分析优先级不高的待办事项会适得其反，因为需求是在不断变化的。

• 需求（特别是处在高优先级的）是否能表述为独立的、可磋商的、有价值的、可估计的、小的和可测试的用户故事？

• 产品负责人是否在关注并避免技术债务的问题？比如在待办事项的“完成”定义中加入自动化测试和重构。

• 待办列表是否对所有利益相关人可见？

• 团队成员是否都了解如何使用自动化工具来管理待办列表？因为自动化工具的不正确引入往往不利于协作。

• 是否能够通过更为宏观的可视化方式来促进信息传播？

• 有没有帮助产品负责人梳理待办事项的优先级？

• 所有的利益相关人（包括团队）是否知道发布计划与团队现有速率的符合情况？可以尝试在每个Sprint回顾会议上，确认项目已经“完成”后演示产品或发布燃尽图。这会让我们更及时地发现范围和时间的偏差。

• 产品负责人是否会在Sprint评审后调整发布计划？一些产品负责人会在Sprint交付后，及时调整发布计划。因为在这一过程中会不断地发现其他重要工作，一些原有工作会被推迟发布。

二、团队做得如何？

• 团队的状态是否流畅？一般流畅的团队会呈现以下特征：

• 明确的目标（期望和规则清晰可见，目标可以实现，且与个人的技能和能力适当匹配）；

• 全神贯注并全力以赴；

• 在下意识状态中，行动和认知相统一；

• 直接及时的反馈（行为可以随反馈不断地进行调整）；

• 在能力与挑战寻求平衡（不要太容易也不要太难）；

• 控制力：对形势和任务的控制力；

• 存在内在激励，因此工作起来很轻松。

• 团队成员是否相互合作、相互理解，并经常一起庆祝项目成功？

• 团队成员是否相互以高标准监督、相互挑战以促进成长？

• 有没有一些话题因为大家感觉难受，所以在团队里没有进行讨论的？

• 是否尝试过通过不同的形式和地点做Sprint回顾？

• 团队是否在Sprint中一直关注验收标准？考虑一次在Sprint中期检查来重新评估Sprint计划。

• Sprint任务是否反映出团队实际在做的事情？与Sprint无关的工作是Sprint的障碍。

• 团队是否由5－9个跨职能人员组成？能否来构建潜在的可交付的产品增量？

• 团队的任务板是否包含最新信息？

• 团队用于自管理的工件（任务板、Sprint燃尽图等等）是否对团队可见？方便使用吗？

• 这些工件是否受到充分保护，不受外界干涉？团队外部的人对团队日常活动的过度审视可能会阻碍团队内部的透明化和自我管理。

• 团队成员是否会自愿领取任务？在Scrum团队中，应该感觉自己就像得到了报酬的志愿者。如果没有这种感觉，那一定是哪里出问题了。

• 偿还技术债务的需要有没有放在待办列表里？如果没有的话，团队有没有和产品负责人沟通？

• 团队成员能否抛开各自的岗位定义，对约定工作的所有方面（测试、用户文档等）集体负责？

• 管理层是否以集体的成功来衡量团队？

三、工程实践做得如何？

• 团队开发中的系统是否有一个“按下测试”的按钮，让每个人（同一团队或不同团队的）都能方便地检测到系统被破坏了？通常可以使用XUnit框架（JUnit等）来实现。

• 是否自动化的端到端系统测试（或功能测试）与自动化的单元测试之间寻求适当的平衡？

• 团队是否用开发系统的同种语言来写系统功能测试和单元测试（而不是用只有部分团队知道如何维护的专用脚本语言或捕捉回放工具）？

• 团队是否发现在系统测试和单元测试之间存在有用的灰色区域吗？

• 当有人引起回归失败时，是否有个持续集成服务器会在一小时甚至几分钟内自动发出警报？

• 是否将所有测试汇总到持续集成服务器的结果中？

• 团队成员们是否发现了持续设计和不断重构的乐趣？重构有一个严格的定义：改变系统的内部结构而不改变其外部行为，且在存在重复的代码、复杂的条件逻辑、糟糕的命名标识符、对象之间的过度耦合等情况下进行。重构应该连续进行，至少每小时进行几次。只有在自动化测试覆盖的情况下，才可能有信心地进行重构。

• 产品待办事项列表的“完成”的定义是否包括完整的自动化测试覆盖和重构？测试驱动开发（TDD）可以增加实现此目标的可能性。

• 团队成员是否大多数时间来结对编程？结对编程可以显著地增加代码的可维护性，并减少Bug率。

四、团队/组织做得如何？

• 团队之间是否有充分沟通？Scrum of Scrums是实现沟通的一种方式。

• 团队在需要跨越架构边界的情况下是否能够独立交付工作？

• 是否在组织内进行全面回顾以解决跨团队、系统的问题？

• 在适当的时候，是否有将团队障碍有贴在研发主管的办公室墙上吗？这些障碍带来的浪费是否能被量化为失去的钱、投入市场的时间、质量或者客户线索？

• 团队或组织是否是为数不多的能提供和团队集体目标一致的职业道路的组织？如果是以牺牲测试、自动化测试或用户文档为代价来做编程或架构工作，请回答“否”。

• 团队或组织是否被专业刊物或其他独立来源公认为最佳组织或行业引领者？

• 是否在创建学习型组织？

像Scrum Master一类的创造性的工作没有一个标准实践，上面列出的点可能会帮到Scrum Master，也有可能帮不到。不过，一旦Scrum Master开始意识到自己可以做些什么来改变现状，尽管可能不敢去做。但没关系，你已经走上了一条成为优秀Scrum Master的道路。