SCRUM MASTER检查单

转自：http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-18

一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议，控制时间盒以及处理团队成员提出的障碍的话，你可以将这个角色当作成兼职来对待。在这种情况下，团队仍然有可能达到预期的目标，而且有可能不会发生什么重大事故。但是如果你展望团队能够做到你之前无法想象的事情的时候，你就成为了一位出色的ScrumMaster。

一位出色的ScrumMaster一次能够负责一个团队。

我们推荐每个7人左右的团队都有一位专职的ScrumMaster，尤其是刚开始实施Scrum的时候。

如果你还没有发现你能够做的事情的话，尝试聆听Product Owner，团队还有团队以外的公司成员的想法。下面我列出了一些ScrumMaster常忽略的东西。

Product Owner干得怎么样？

• 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。（需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。）
• 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗？是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了？要记得待办事列表是涌现的。
• 产品待办事列表的大小是否还能够维护呢？为了使列表更容易维护，应该将细粒度的项目放在靠前的位置，而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间，效果只会适得其反，因为你的需求会在团队和客户/股东的持续谈话中发生变化。
• 需求（特别是在产品待办事列表最顶端的需求）能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗？
• 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗？其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。
• 待办事列表是不是能让所有股东都能够看懂？
• 如果你正在使用自动工具来管理你的待办事列表，想一下它真的能够帮助你吗？自动化的管理工具有可能成为ScrumMaster了解信息的障碍。
• 你能够通过有效地把信息打印出来然后传达给其他人吗？
• 你能够通过制订可视化图表来传达足够的信息吗？
• 你有曾经帮助过Product Owner整理待办事列表项目，然后分配到不同的版本中去吗？
• 是否所有人（包括股东和团队）都知道目前的团队速率是否能够赶上发布的计划呢？
• Product Owner有根据上次Sprint评审会议来调整发布计划吗？通常Product Owner应该至少在个Sprint之后调整发布计划，一般来说会把一些工作放到后面的版本中，原因是发现了一些更重要的工作要做。你可以在每个Sprint评审会议的时候给大家展示Mike Cohn的产品和版本燃尽图，这样就可以更早地发现当前的进度是不是能够符合预期。

团队做得怎么样？

• 团队成员是否在大多数时间里都能够进入“流”的状体？下面是这种状态的一些特征（摘录自Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi）：有清晰的目标（）；集中且专注，高度集中在某个特定的领域或事物上；失去自我意识，完全沉浸在动作和兴趣中；扭曲的时间感受，只能感受到主观世界的时间；直接和立即的反馈（无论是成功还是失败都能够马上感知到，以马上对行为进行调整）；在能力和挑战之间保持平衡；自我的控制能力；行为能够从本质上有所回报，所以感觉毫不费力。
• 团队成员之间相处得怎么样？气氛融洽吗？有为彼此的成功感到高兴吗？
• 团队成员之间会以高标准要求对方吗？会互相挑战来促进成长吗？
• 有没有一些事情团队会觉得不舒服而避免讨论的？（详见：Crucial Conversations: Tools for Talking When Stakes are High）或者引入专家来缓解不安的谈话情绪。
• 有没有试过以不同方式或者在不同地点举行Sprint回顾会议？详见：Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen)
• 团队在开发过程中有没有集中在验收标准上？也许你应该在Sprint当中举行一次会议来评审当前Sprint所承诺的产品待办事列表项目的验收标准。
• Sprint待办事列表能够真正反映出团队正在做的事情吗？所有对Sprint的目标的打断和干扰都应该被视为障碍。
• 团队有保持更新任务版吗？
• 团队的任务版和燃尽图都能够很容易地被团队看见和使用吗？
• 团队成员都能够自己领取任务吗？
• 团队能够被保护得足够好而避免微管理吗？
• 用于解决技术债务的事项都能够在待办事列表里面反映出来吗？还是需要和Product Owner另外沟通呢？
• 团队成员会在团队的房间外忽略自己的职称吗？
• 是不是整个团队都将团队看作一个整体，对测试和编写文档共同担当责任呢？

工程实践进行得怎么样？

• 你们正在开发的系统有“开始测试”按钮能让每个都很容易地察觉到自己是否破坏了某些功能呢？通常这个是靠xUnit框架来实现的（JUnit，NUnit等等）。
• 你们能够在自动化端对端系统测试和自动化单元测试之间保持平衡吗？
• 团队在开发系统功能测试和单元测试的时候使用的是同一种语言吗（而不是使用团队里只有部分成员懂的脚本语言）？这个是可能的。
• 你的团队能够发现系统测试和单元测试之间的灰色地带吗？
• 你们的持续集成服务器能够在回归测试出现错误的一个小时（或者一分钟）内自动发出警报吗？
• 所有的测试都能够在CI服务器的测试结果报告中反映出来吗？
• 团队能够发现持续设计和无情的重构，而不是一开始就进行详细的设计带来的乐趣吗？重构拥有一个严格的定义：改变系统的内部结构而不改变其外部行为。重构需要在每个小时内进行多次，每当有重复代码，复杂的条件逻辑（通常表现为过量的缩进和冗长的方法），糟糕的命名，对象间的过度耦合，一个对象的职责过多等等问题出现的时候就需要进行重构。要在重构的时候有充足的信心，就要有足够的自动化测试覆盖率。测试覆盖率的漏洞和推迟的重构被称作技术债务。
• 在你的每个产品待办事列表项目的验收标准中都包含了完全自动化测试和代码重构这两项吗？如果不学习使用极限编程的工程实践，你就不可能在每个Sprint都能完成潜在可交付的产品（正如Kent Beck, Ron Jeffries等人所说的）。
• 团队成员多数时间都在结对编程吗？结对编程可以大幅度提高代码的可维护性，也可以大大降低bug出现的机率。但是有时候结对编程实在挑战大家的极限，有时候甚至会使完成任务的时间变长（如果我们更重视数量而不是质量的话）。所以，比较推荐的做法是和团队成员先讨论以选择在一周内大家愿意尝试使用结对编程的时间，而不是从一开始就强迫团队使用结对编程。然后慢慢地，部份人会开始喜欢结对编程的。

整个公司的做得怎么样？

• 团队之间有没有适当地交流合作呢？Scrum of Scrums是唯一的解决方案。也可以考虑在团队中选出代表参加别的团队的每日站会。
• ScrumMaster之间有互相交流吗？
• 来自公司内部的困难会在适当的时候被贴到开发总监的办公室的墙上吗？成本能够以金钱、丢失市场的份额、损失的质量或者损失的客户来量化吗？
• 你的公司的职业发展道路和你的团队的集体目标相符吗？如果以测试、自动化测试或者开发文档为代价来鼓励编程或者设计架构，那么答案就是否定的。
• 你能够帮助公司成为一个学习型企业吗？
• 你的公司已经被外界认定为最好的工作场所或者业界的领头羊了吗？

恐惧是你的朋友, 一旦你开始意识到你能够做些事情来改变现状，你可能会感到恐惧而退缩。然而，这正是你走上正轨的标志。