SCRUM MASTER检查单

一位合格的ScrumMaster通常可以同时处理2到3个团队的任务。如果您愿意将自己的角色限制为组织会议、控制时间盒和处理团队成员提出的障碍，那么您可以将这个角色视为兼职。在这种情况下，团队仍然有可能达到预期目标，并且可能不会发生重大事故。但是，如果您希望团队实现超越预期的目标，那么您就需要成为一位卓越的ScrumMaster。

要想发挥更大的作用，建议您倾听Product Owner、团队以及公司内部的其他成员的想法。以下是一些ScrumMaster常常忽略的事情：

产品待办事项列表做得怎么样？

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

团队做得怎么样？

• 团队成员是否大部分时间都能够进入“流”的状态？这种状态具有以下特征：有明确的目标，全神贯注地专注于某个特定的领域或事物；失去自我意识，完全沉浸在动作和兴趣中；扭曲的时间感受，只能感受到主观世界的时间；直接和即时的反馈（无论是成功还是失败都能够马上感知到并进行及时调整）；在能力和挑战之间保持平衡；具备自我控制能力；行为有所回报，使人感觉轻松愉悦。
• 团队成员之间相处得怎么样？气氛融洽吗？是否为彼此的成功感到高兴？
• 团队成员之间是否会提出高标准的要求？是否会互相挑战来促进成长？
• 是否存在团队避免讨论的不适之处？
• 是否需要引入专家来缓解讨论的紧张气氛？
• 是否尝试过以不同方式或在不同地点举行Sprint回顾会议？团队是否集中关注验收标准？您可能需要在Sprint期间召开一次会议，审查当前Sprint所承诺的产品待办事项列表项目的验收标准。
• Sprint待办事项列表是否真正反映了团队正在进行的工作？所有对Sprint目标的干扰都应被视为障碍。
• 团队是否保持任务板和燃尽图的最新状态？这些工具是否易于团队使用？
• 团队成员是否能够自己领取任务？
• 是否存在微观管理问题？团队是否能够得到足够的保护？
• 技术债务解决方案是否在待办事项列表中得到体现？还是需要额外与Product Owner沟通？
• 团队成员是否会忽略个人职称？是否将测试和文档编写作为整个团队共同担负的责任来看待？

开发和测试进行得怎么样？

• 系统中是否有“开始测试”按钮，让每个人都能轻松地检查自己是否破坏了某些功能？通常可以使用xUnit框架（如JUnit、NUnit等）来实现。
• 团队是否能够在自动化端到端系统测试和自动化单元测试之间保持平衡？
• 在开发系统功能测试和单元测试时，团队是否使用相同的语言（而不是只有部分成员懂的脚本语言）？
• 团队能否识别系统测试和单元测试之间的灰色地带？
• 持续集成服务器能否在一个小时（或者一分钟）内自动发出警报，以便对回归测试出现的错误进行快速响应？
• 所有的测试结果都能否反映在CI服务器的测试报告中？
• 团队是否能够实施持续设计和无情重构，而不是仅在一开始进行详细设计？重构需要在每个小时内进行多次，每当出现重复代码、复杂条件逻辑（通常表现为过量的缩进和冗长的方法）、糟糕的命名、对象间过度耦合、一个对象的职责过多等问题时，就需要进行重构。要在重构时有充足的信心，就需要有足够的自动化测试覆盖率。漏洞和推迟的重构被称为技术债务。
• 每个产品待办事项列表项目的验收标准是否都包含完全自动化测试和代码重构这两项？如果您不熟悉极限编程的工程实践，您将无法在每个Sprint中都交付潜在可交付的产品（正如Kent Beck、Ron Jeffries等人所说）。
• 团队成员大部分时间是否都在结对编程？结对编程可以大幅提高代码的可维护性，也可以大大降低bug出现的机率。但是有时结对编程会挑战团队的极限，并且有时甚至会延长完成任务的时间（如果我们更重视数量而不是质量的话）。因此，相对较好的做法是先与团队讨论并选择一周内大家愿意尝试使用结对编程的时间，而不是从一开始就强制要求使用结对编程。逐渐地，有些人会开始喜欢结对编程。