Scrum 四个会议及正确召开方式
敏捷开发有一些重要的实践方法，可以帮助团队更快地适应敏捷开发框架。这些方法不能简单照搬执行，比如，只在瀑布开发模式下中加入 Scrum 的四个会议，这无法让瀑布团队转成敏捷团队。敏捷转型需要深入理解概念和思维，团队才能更好的进行实践。
下面我们了解一下 Scrum的四个会议，并思考它们如何正确打开并推动敏捷研发。
Tips： 有一些方法来自 Scrum， Scrum 是一种持续迭代、且有固定时长的敏捷框架。这些方法背后的概念也可以应用于其他形式的敏捷，如 Kanban 等。Sprint（迭代）是一个特定于 Scrum 的术语，通常是在几周的固定时间，来达成增量目标的研发节奏。迭代时长也会影响每种敏捷实践方法的使用时长。
1、迭代计划会（Sprint Planning）
参加者： 研发团队、Scrum、Product Owner
时间： 在迭代开始时
时长： 通常一个迭代为期两周，计划时间两小时左右
适用敏捷框架：Scrum
目的： 迭代计划会议的召开可以让团队清晰了解工作内容，是整个迭代工作方向的指导。会议的最开始，Product Owner （产品负责人）会提供一个有优先级排序的待办事项列表，同时与研发团队讨论每个工作事项，让团队成员能够具体了解工作内容。然后，研发团队将进行工作量估算，讲述团队可以从产品待办事项中完成多少工作。然后，这些工作会成为 Sprint Backlog （迭代待办事项列表）。
Tips：迭代计划的制定会议上需要充分讨论需要完成的工作细节，团队成员需要将本次迭代要完成的所有用户故事、缺陷和任务进行拆分，并以这种方式来了解工作内容并达成共识。有效的迭代计划会可以使团队更有机会交付承诺的工作。
2、每日站会
参加者：研发团队、Scrum master、Product Owner
时间： 每天一次，一般安排在早上
时长： 不超过15分钟，不需要定会议室坐着进行报告，团队可以围在一起站着快速进行
适用敏捷框架：Scrum 和 Kanban
目的： 站立会议是让每个成员快速了解团队工作进度的会议，并不是一个正式的工作会议。整体气氛应该轻松有趣，会议内容也是较为丰富。每个团队成员在会议中快速阐述以下内容：
- 我昨天完成了什么？
- 我今天计划做什么？
- 我当前的工作有没有被阻塞？
在工作中，与同事交流完成的工作、遇到的问题、如何解决或改进等等是一种隐含的责任，没有人愿意加入一个只知道工作却没有任何进步的团队。
Tips：每个团队都是独立的，所以站立会议也会不同。一些团队会使用计时器来控制会议时长。一些团队在会议中利用乒乓球使成员集中注意力。一些远程分布团队使用视频会议来弥补距离带来的不便。团队需要持续探索发现适合成员的会议方式。
3、迭代/增量评审会（Sprint Review）
参加者：研发团队、Scrum Master、Product Owner（项目相关者可以选择参加）
时间： 迭代或里程碑结束时
时长： 通常在两周的迭代完成后，进行两小时的演示会议
适用敏捷框架： Scrum 和 Kanban，其中 Kanban 团队的演示应与团队里程碑保持一致，并不是固定的节奏
目的： 迭代评审是展示团队工作成果的时间。可以采用一些休闲的形式，也可以采用较为正式的会议结构。团队展示迭代中完成的工作，项目相关者可以进行即时反馈，演示使成员可以获得工作成就感。注意，在演示中的工作应该是完全可证明的，并且符合团队的质量标准，这样才能被认为是完整的迭代交付。
Tips：评审会关注业务功能实现，而不在意技术细节。注意力放在“我们做了什么”，而不是“我们是如何做的”。
4、迭代回顾会（Sprint Retrospective）
参加者： 研发团队、Scrum Master、Product Owner
时间： 在迭代结束时
时长： 通常两周的迭代时长需要进行一个小时的回顾
适用敏捷框架： Scrum 和 Kanban。Scrum 团队根据固定的迭代时间进行回顾，Kanban 团队也可以偶尔进行回顾来提高效能
目的： 敏捷方法目的之一就是利用快速反馈和改进，使产品和研发文化变得更好。回顾会有助于团队了解哪些工作做得好可以继续保持，哪些做得不好需要改进。进行回顾会时，不能只提出问题而不探讨解决方式，团队需要找出有效的方法并制定行动计划。持续改进是维持和推动敏捷团队发展的重要因素，而回顾会是其中的关键部分。
Tips：即使团队进展顺利，也不能停止回顾。回顾会为团队提供持续的指导，保证工作顺利完成。
一些人错误地认为只利用敏捷的实践方法可以使团队变得敏捷。实际上，敏捷性需要扎实的技术积累、随时优化的战略战术以及高效的团队协作，而敏捷实践方法只是其中促进团队高效协作的一部分，我们需要从更多角度关注团队持续地进步与成长。
以上就是对敏捷开发四个会议内容的介绍，希望对你有所帮助。