Sprint 规划会议——第一部分（上午）

 

　　会议目的

　　•该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。

    •产品负责人在会前准备：条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。

 

　　基本要求

　　•迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。

　　•只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

　　构成部分：

　　•经过估算和排序的 Product Backlog。

　　•挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。

　　•假期计划表、重要人员的详细联系信息。

　　•参会成员：团队成员、Scrum Master、产品负责人

　　持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。

 

　　会议输出

　　•选择好的 Product Backlog 条目。

　　•各个 Backlog 条目的需求。

　　•各个 Backlog 条目的用户验收测试。

 

　　会议过程

　　•从第一个 Product Backlog 条目（故事）开始。

　　•讨论该 Product Backlog 条目，以深入理解。

　　•分析、明确用户验收测试。

　　•找到非功能性需求（性能、稳定性...）

　　•找到验收条件。

　　•弄清楚需要“完成”到何种水平。

　　•获得 Backlog 条目各个方面的清晰了解。

　　•绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕 UI 设计等。

　　•回到步骤1，选取下一个 Backlog 条目。

　　流程检查：询问团队能否快速回答下列问题，只需要简要回答即可：“我们能在这个 Sprint 中完成第一个 Backlog 条目吗？”如果能得到肯定的回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。——接下来，休息一下。在休息后，对下一个 Backlog 条目展开上述流程。

 

　　结束流程：

　　•在 Sprint 规划会议第一部分结束前留出 20 分钟。

　　•再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，...第二个，...？”

　　•如果团队认为他们不能再接受更多的 Backlog 条目，那就停下来。

　　•现在是非常重要的一步：送走 Product Owner，除了团队和 Scrum Master 之外的所有人，都得离开。

　　•当其他人都离开后，再询问团队：“说真的——你们相信自己可以完成这个列表？”

　　•希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。

　　•将结果与 Product Owner 和最终用户沟通。

　　注意事项：不要改变 Backlog 条目大小，不要估算任务。

　　Sprint 规划会议——第二部分（下午）

 

　　会议目的

　　•该会议的工作以设计为主，产品开发团队可以为他们要实现的解决方案完成设计工作，在会议结束后，团队知道如何构建他们在当前 Sprint 中要开发的功能。

 

　　基本要求

　　•只有产品开发团队才能制定解决方案，架构师或其他团队之外的人只是受邀帮助团队。

 

　　构成部分：

　　•能够帮助团队在该 Sprint 中构建解决方案的人，比如厂商或是来自其他团队的人员。

　　•选择好的 Product Backlog 条目。

　　•挂图......

　　注意事项：不要估算任务，不要分配任务。

 

　　会议输出

　　•应用设计、架构设计图、相关图表

　　•确保团队知道应该如何完成任务！

 

　　会议过程

　　•从第一个 Backlog 条目开始。

　　•查看挂图，确定对于客户的需求理解正确。

　　•围绕该 Backlog 条目进行设计，并基于下列类似问题：

　　◦我们需要编写什么样的接口？

　　◦我们需要创建什么样的架构？

　　◦我们需要更新哪些表？

　　◦我们需要更新或是编写哪些组件？

　　◦......

　　当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。

　　持续时间：在 Sprint 规划会议第一部分完成后，召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分，在 Sprint 中，每周该会议占用时间为 60 分钟。

 

　　估算会议——根据项目情况合并到 Sprint 第二部分会议

 

　　会议目的

　　•要做好战略规划，你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作，这个数据也是必须的。

　　•团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

 

　　基本要求

　　•只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事

　　构成部分：

　　•Product Owner 根据业务价值排定 Product Backlog 各项顺序。

　　•需要参加的人员：Team、Product Owner、User、Scrum Master

 

　　注意事项：

　　•不要估算工作量大小——只有团队能这么做。

　　•Product Owner 不参与估算。

 

　　会议过程

　　•Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。

　　•团队使用规划扑克来估算 Backlog 条目。

　　•如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog 条目使用规划扑克进行估算。

　　•重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

　　持续时间：该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适。

 

　　会议输出

　　•经过估算的 Product Backlog。

　　•更小的 Backlog 条目。

 

　　扑克牌估算（Planning Poker）

　　具体步骤：

　　•每个人各自估算后独立出暗牌，听口令一起开牌。

　　•数值最大者与最小者PK，其他人旁听也可参考。

　　•讨论结束后重新出牌和开牌。

　　•重复上述过程，直到结果比较接近

 

　　常见问题

　　1、为什么任务要分给组而不是个人？

　　答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。

　　2、为什么不让最后领任务的人自己估算？

　　答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

　　3、为什么不让师傅估算大家采纳，他不是最厉害吗？

　　答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

 

　　Sprint 评审会议（Review Meeting）——根据项目需要举行

 

　　会议目的

　　•Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。

 

　　基本要求

　　•Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

 

　　构成部分

　　•有可能发布的产品增量，由团队展示。

 

　　会议输出

　　•来自最终用户的反馈。

　　•障碍 Backlog 的输入。

　　•团队 Backlog 的输入。

　　•来自团队的反馈为 Product Backlog 产生输入。

　　持续时间：90分钟，在 Sprint 结束时进行。

 

　　会议过程

　　•Product Owner 欢迎大家来参加 Sprint 复审会议。

　　•Product Owner 提醒大家关于本次 Sprint 的目的：Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。

　　•产品开发团队展示新功能，并让最终用户尝试新功能。

　　•Scrum Master 推进会议进程。

　　•最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

 

　　注意事项：

　　•不要展示不可能发布的产品增量。

　　•Scrum Master 不要负责展示结果。

　　•团队不要针对 Product Owner 展示。

　　•Sprint 反思会议（Retrospective Meetin）——根据项目需要举行

 

　　会议目的

　　•该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。

　　构成部分

　　•参与人员：团队成员、Scrum Master

 

　　基本要求

　　•从过去中学习，指导将来。

　　•改进团队的生产力。

 

　　注意事项

　　•不要让管理层人员参与会议。

　　•不要在团队之外讨论找到的东西。

 

　　会议输出

　　•障碍 Backlog 的输入。

　　•团队 Backlog 的输入。

　　持续时间：90分钟，在 Sprint 评审会议结束后几分钟开始。

 

　　会议过程

　　•准备一个写着“过去哪些做的不错？”的挂图。

　　•准备一个写着“哪些应该改进？”的挂图。

　　•绘制一条带有开始和结束日期的时间线。

　　•给每个团队成员发放一叠即时贴。

　　•开始回顾。

　　•做一个安全练习。

　　•收集事实：发放即时贴，用之构成一条时间线。每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。

　　•“过去哪些做的不错？”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。

　　•做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。

　　•“哪些应该改进？”：像“过去哪些做的不错”那样进行。