敏捷教练是干啥的？敏捷教练的职责是哪些？问十个人，会有十一种答案。之所以会这样，大概是因为它的工作内容正在不断被定义中。敏捷方法论正随着企业对IT技术与精益创新等理念的重视，逐渐从IT技术管理层面进入到组织管理变革层面中。有人给敏捷教练戴上六顶不同的帽子。它们分别是：向导、教练、教师、导师、伙伴、唤醒者。不管怎么样我更希望知道他怎么工作。所以找来材料供大家参考：
牢记 10 个最佳实践：
1. 具备清晰且好记的愿景。
2. 拥有维护良好的 Product Backlog。
3. Product Backlog 依照业务价值进行排序。
4. Backlog 项目的大小由团队决定。
5. 举行每日 Scrum 例会。
6. 使用燃尽图。
7. Sprint 不能受到管理层以及客户的干扰。
8. 团队交付的软件必须符合“完成（Done）”条件。
9. 举办协作式的 Sprint Review。
10. Sprint 回顾（Retrospective）的重点要放在改进团队和组织的工作流程上。
通用会议规则
<基本要求>
每次会议都要准时开始，准时结束。每次会议都采取开放形式，所有人都可以参加。
<会前准备>
1. 提前邀请所有必须参会的人，让他们有时间准备。
2. 发送带有会议目标和意图的会议纲要。
3. 准备好会议所需的全部资源：房间、投影仪、白板、主持设备，以及此次会议需要的其他东西。
4. 会前 24 小时发送提醒。
<会议推进>
1. 展开讨论时，会议的主持人必须在场。要注意讨论进程，如果讨论参与者失去重点，要将讨论带回正规。
2. 主持人展示会议的目标和意图。
3. 有必要时，主持人可以商定由某个人撰写会议记录。
4. 主持人可以记录团队的意见，或是教授团队如何自己记录文档；而且主持人可能会在白板上进行记录，将对话 可视化。
5. 主持人会使用类似“停车位”之类的工具来记录与会议无关的议题，供此后讨论，从而保证会议围绕重点进行。
6. 主持人会对会议进行收尾，并进行非常简短的回顾（不超过 5 分钟）。
<会议输出>
文档记录或修正后的文档、白板内容； 必须传达会议记录和大家对会议结果的明确共同认知。
加粗 每日 Scrum 例会
<会议目的>同步信息、增强沟通、项目进度可视化、相互承诺。
<构成部分>白板、即时贴、马克笔
<基本要求>必须是整个团队在场。无法出席的团队成员要由同伴代表。
<持续时间>每天 15 分钟，同样时间，同样地点。
<会议输出>团队彼此明确知道各自的工作。 为障碍 Backlog 产生输入。 为团队 Backlog 产生输入。
<会议过程>
1. 团队聚在故事板旁边，可以围成环形。
2. 从左边第一个人开始，向团队伙伴说明他到现在完成的工作。
3. 然后该成员将任务板上的任务放到正确的列中。
4. 如果可以的话，该成员可以选取新的任务，并将其放入“进行中工作”列。
5. 如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。
6. 每个团队成员重复步骤 2 到步骤 5。
<注意事项>
1. Scrum Master 不直接提出问题，但要引导。
2. 不要向 Scrum Master 或管理层人员报告。
3. 不要转变会议话题。
4. 不要迟到。
5. 不要超出限制时间。
6. 不要讨论技术问题。
7. Scrum Master 不要替团队成员移动任务卡片。
8. 要及时更新燃尽图。
9. 不要在没有准备的情况下参会。
Sprint 规划会议——第一部分
<会议目的>
该会议的工作以分析为主，目标是要详细理解最终用户到底要什么。产品开发团队可以从该会议中详细了解最终用 户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。
<基本要求>
只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。
<构成部分>
经过估算和排序的 Product Backlog 。 即时贴、白板、马克笔 假期计划表、重要人员的详细联系信息。
<持续时间>
在 Sprint 中，60 分钟/每周。在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。
<会议输出>
选择好的 Product Backlog 条目。 各个 Backlog 条目的需求。 各个 Backlog 条目的用户验收测试（User Acceptance Test, 简称 UAT）。
<会议过程>
1. 从第一个 Product Backlog 条目（故事）开始。
2. 讨论该 Product Backlog 条目，以深入理解。
3. 分析、明确用户验收测试。
4. 找到非功能性需求（性能、稳定性……）。
5. 找到验收条件。
6. 弄清楚需要“完成”DoD 到何种水平。
7. 获得 Backlog 条目各个方面的清晰了解。
8. 绘制出所需交付物的相关图表，包括流程图、 UML 图、手绘草图、UI 设计等。
9. 回到步骤 1，选取下一个 Backlog 条目。
<流程检查>
询问团队能否快速回答下列问题，只需简要回答即可：“我们能在这个 Sprint 中完成第一个 Backlog 条目吗？” 如果能得到肯定回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。接下来，休息一下。在休息之后：对下一个 Backlog 条目展开上述流程。
<结束流程>
1. 在 Sprint 规划会议第一部分结束前留出 20 分钟。
2. 再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，……第二个，……？”
3. 如果团队认为他们不能再接受更多 Backlog 条目，那就停下来。
4.再询问团队：“你们相信自己可以在当前迭代中完成这些功能列表吗？”
6. 希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。
7. 将结果与 Product Owner 沟通。不许再讨论了！
Sprint 规划会议——第二部分
<会议目的>
该会议的工作以设计为主。产品开发团队可以为他们要实现的解决方案完成设计工作。在会议的结束，团队知道如 何构建他们在当前 Sprint 中要开发的功能。（ 请参考 Sprint 规划会议第一部分）
<基本要求>
只有产品开发团队才能制定解决方案。架构师或其他团队之外的人只是受邀帮助团队。他们不能为团队做出设计决 策。这些人在会议中的角色只能由团队成员定义。
<构成部分>
能够帮助团队在该 Sprint 中构建解决方案的人，比如资深技术。 选择好的 Product Backlog 条目。 马克笔、即时贴、白板
<会议输出>
应用设计的实现讨论及相关 Task。
<会议过程>
1. 从第一个 Backlog 条目开始。
2. 查看每个条目，确定对于业务的需求理解是正确的。
3. 围绕该 Backlog 条目进行设计讨论，主要集中在技术实现方面
4. 当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。
5. 在会议的最后 20 分钟，团队成员使用即时贴写出初步的任务。
6. 将这些任务放在任务板上。不要估算这些任务。
<持续时间>
在 Sprint 中，60 分钟/每周。在 Sprint 规划会议第一部分完成后，召开该会议。要在同一天完成 Sprint 规划 会议第一部分。
Sprint 评审会议
<会议目的>
展示当前迭代完成的情况，得到 PO 或业务部门的反馈。并以之创建或变更 Backlog 条目。
<基本要求>
Sprint 评审会议允许所有的参与者尝试由团队展示的新功能。
<构成部分>
有可能发布的产品增量，由团队展示 白板、即时贴、马克笔
会议输出： 来自 PO 或业务部门的反馈。 障碍 Backlog 的输入。 团队 Backlog 的输入。 来自团队的反馈为 Product Backlog 产生输入。
<持续时间>45-60 分钟/周.
<会议过程>
1. ScrumMaster 欢迎大家来参加 Sprint 评审会议。
2. ScrumMaste 提醒大家关于本次 Sprint 的目的：Sprint 目标、 Scrum 团队在本次 Sprint 中选定要开发的故 事。
3. 产品开发团队展示新功能，并让最终用户尝试新功能。
4. Scrum Master 推进会议进程。
5. 最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。
Sprint 回顾会议（Retrospective）
<会议目的>发现哪些方面需要改进、好的继续发扬。
<构成部分>白板、马克笔、即时贴
<基本要求>从过去中学习，指导将来，改进团队的生产力。
<注意事项>
1. 不要对找到的事物妄下结论。
2. 不要让管理层人员参与会议。
3. 不要在团队之外讨论找到的东西。
<会议输出>障碍 Backlog 的输入。团队 Backlog 的输入。
<持续时间>45-60 分钟/周，在 Sprint 评审会议结束后几分钟开始。
<会议过程>
1. 让团队成员在即时贴上写下“过去哪些做得不错？”、“哪些应该改进”。每个即时贴写一点。
2. 在白板上画分 3 个区域：做的好的、需要改进的、解决方案
3. 将做的好的、应该改进的放到对应的区域内，并对内容进行分组、分类
4. 针对改进项，采用投票的方式获得 Top3 需要改进的内容
5. 针对 Top3 需要改进的内容，找到根本原因，团队制定出其对应的解决方案
6. 将 Top3 问题对应的解决方案，贴在白板上，让团队成员都清晰的知道接下来如何做。
