Scrum敏捷开发中的会议有那些？该怎么开？

Question

最近在学习scrum，发现有很多具仪式感的会议对项目研发起到了很大作用。
比如Scrum计划会议、站立会议、验收会议、回顾会议，这些会议究竟怎么开，对项目研发有什么具体的帮助呢？有没有具体的实践的例子可以参考下呢？

Answer 1

以前我们的实践中，会有计划会，站立会，回顾会。

计划会，迭代周期开始进行，每个人参与任务分配与时间预估，并且将任务贴入任务图，绘制燃尽图；
站立会，每日进行，描述本日工作，接下来的计划，工作内容，更新进度图和燃尽图。最重要的是，如果某团队成员因为某些原因未按计划完成任务、或者提前完成计划任务，要进行任务调整。每个人应该关注团队目标，而不仅仅是自己分到的任务。
回顾会，每次迭代结束进行，通常我们以周为单位，周五会开回顾会和计划会。回顾本周推行工作不顺利的地方，本周有问题的任务，总结原因。

---

最重要的就是 关注团队目标。

Answer 2

Scrum 会分多个 Sprint（迭代周期）。

有了这个概念就好办了。

• 计划会（Plan）：每个 Sprint 的第一天开，评估任务，计划工时；
• 每日例会（Daily）：Sprint 期间每天开始工作前开，轮流陈述 “三个问题”。因为要站着开（强调不要找专门会议室，人到全了随时随地就开，尽可能迅速结束），所以又名“站立会”。
• 评审会（Review）：每个 Sprint 结束前开，展示成果，接受评价。
• 总结会（Retrospective）：每个 Sprint 的最后一天开，回顾项目过程，总结经验教训。

其中评审和总结两个会议也可以合为一个。因为 Scrum 这套流程不单单仅针对软件开发，所有涉及到流程式、阶段式的工作都可以用上 Scrum。因为软件工程的特殊性，评审会这个会议也可以被软件工程生命周期里的测试阶段所取代，所以可以不用单独开。

还有一个会，需求评审会，Scrum 里对此还提出了一个新概念 “Backlog”，你可以简单地理解为需求池。但本质上需求评审这件事跟 Sprint 的周期没啥关系，甚至跟 Scrum 都没啥关系，你用啥项目管理方法不都得需求评审？

---

P.S. 开什么、开几个会不重要，重要的是会议上传递了什么内容。

---

P.S.P.S. 敏捷开发（Agile Development）是敏捷开发，Scrum 是 Scrum，二者是交集的关系，不要把后者当作前者的中文翻译。敏捷还有其他实践理论，比如极限编程（Extreme Programming）、水晶方法论（Crystal）等等。只不过因为 Scrum 这种模式在国内最火，某种程度上就成了敏捷开发的代名词。

Answer 3

敏捷管理中，我们使用用户故事地图和待办事项进行需求和冲刺管理。明确需求和冲刺管理的目标后，我们会有四个敏捷会议贯穿整个开发过程，需要开发团队的每个成员参与其中，此时也可以使用Choerodon敏捷管理进行会议的管理支持来达到团队的开发目标。

标准的敏捷流程包含了四个会议，即计划会、每日站会、评审会和回顾会。在实际开发中会结合Choerodon猪齿鱼平台来管理支持团队中的敏捷会议。

计划会

在每个Sprint进入开发之前，团队将会召开Sprint计划会议。

在会议之前，产品负责人会在Choerodon敏捷管理中使进行需求和冲刺的规划，并且排列好Backlog的优先级，为计划会议做准备。

在Sprint计划会议的前半段，根据Choerodon敏捷管理计划冲刺中的Backlog，产品负责人会从优先级最高的功能依次为开发团队进行讲解。然后，团队成员针对Backlog中的待开发功能提出问题，团队就该问题进行展开讨论，直到这个功能相关的问题全部解决，再进入下一个功能的讨论。

如果Backlog中的待开发功能在此迭代中已经饱和，或者有阻碍需要在进行重新计划的，产品负责人会把它从迭代计划拖动至待办事项列表进行重新规划。

在Sprint计划会议的下半段，开发团队会讨论这些确定开发的功能问题，这时可以使用Choerodon敏捷管理的报表：迭代速度图。

迭代速度图可以看出每个开发团队在每个迭代中完成任务的情况，大致可以得到一个团队迭代中任务的饱和点，然后开发团队根据这个数据决定下一轮迭代能够完成的工作量。

之后，团队成员对计划中的Sprint列表中的故事进行拆分，将每个故事拆分成一个一个的任务，并估算每个故事的故事点。一旦迭代开始，这些迭代任务将不会发生大的变化。

通过敏捷的计划会议，开发团队和产品负责人可以确认共同的迭代目标和价值。

每日站会

Choerodon敏捷管理中的活跃冲刺看板可以用来进行开发迭代任务可视化管理，每个任务下的子任务、经办人、任务状态、任务类型都在看板中显示，每一个开发人员都可以看到团队开发的流程进度。

每日站会是敏捷开发中用于开发团队沟通了解进度的会议，可以把看板泳道切换为经办人泳道，这样可以清楚每个人身上的任务进度。

每日站会中，开发团队成员根据看板中自己的任务进度和大家进行交流：我昨天做了什么，今天要做什么，我有遇到什么困难。可以一边交流一边拖动看板上的卡片（或者在站会开始前就已经根据自己情况进行卡片拖动完成），团队成员可以对大家的各种任务状态和受阻问题进行了解。

在每日站会拖动完团队成员的卡片后，会切换到Choerodon猪齿鱼敏捷管理看板中的工作台页面，团队会共同维护一张“燃尽图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，用以观察和预测所有任务是否会按期完成。

每日站会中展示燃尽图，也是向团队成员展示一个迭代开发的任务或者时间的总体完成情况，可以指导团队随时调整迭代计划与速度。

评审会

每个Sprint结束时，都会有一个Sprint评审会议。评审会议最重要的工作是演示功能和成果，验证用户故事的实现场景，并接受评价。

所以在评审会开始之前，开发团队会检查Choerodon敏捷管理活跃冲刺看板中的故事完成情况，根据完成任务后的测试情况拖动卡片到看板已完成的列，把未完成的任务进行整理。

团队成员整理好看板中的已完成和未完成的任务时，我们就可以完成Sprint。这个迭代中未完成的遗留问题我们可以移动到待办事项中进行重新计划，对于已完成的任务，则会在评审会中进行演示验收。

评审会中，团队成员会对本次迭代中已完成的功能进行演示，产品负责人进行验收。团队成员需要接受产品负责人的评价，再针对已有的功能进行优化或者直接验收成功。

评审会后产品负责人会根据验收成果在Choerodon敏捷管理的待办事项中进行下个Spring的优先级调整，重新规划将要进行的新的Sprint。

回顾会

在评审会之后，开发团队会进行回顾会。回顾会的重点是团队检视与调整，进行工作问题和改进点的反馈。回顾会可以提供一个很好的机会给开发团队，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。

在进行敏捷回顾会议时，开发团队会使用Choerodon猪齿鱼Wiki管理中进行会议记录，创建时使用“敏捷回顾会议记录”的文档模板，可进入已经设置好的回顾会议文档编辑页面。

回顾会议中，开发团队会提前根据本迭代的达成目标、产品功能、敏捷流程、需求管理等方面进行准备，针对开发团队在实施敏捷开发中的各种进步和问题进行讨论。可以指派一位团队成员进行会议记录，在已有的Wiki文档模板中记录大家提出的各种问题。

然后，团队成员会共同讨论找寻这些问题出现的根本原因，提出大家认同的解决方案，统一在下一个Sprint中改进，并在下一个回顾会议上评审改进问题的结果。

在Choerodon猪齿鱼知识管理中的回顾会文档，可以记录开发团队关于每个迭代的各种问题的思考，帮助团队不断调整敏捷实施方案，突出敏捷开发的效果。

关于敏捷会议的具体内容，可以查看《Choerodon猪齿鱼敏捷管理实践（三）：敏捷会议》。