会议，或“仪式”是敏捷开发的重要组成部分。作为重要元素之一，会议不应该脱离其他元素独立存在。（很多人倾向于在瀑布流项目中添加类似仪式，然后将其称为“敏捷”，这种做法根本就是无稽之谈。）
下面，让我们来看看敏捷的这些仪式，了解它们如何实现团队赋权并推动敏捷的发展。
注意：其中一些仪式来自Scrum。Scrum是一种需要在限定时间内，以迭代的方式实现敏捷的方法。这些仪式背后的概念也可以应用于其他形式的敏捷，如kanban或精益。Sprint是一个仅用于Scrum的术语，而其他形式的敏捷则使用更通用的术语“迭代”来表示在限定时限内进行的开发。
Sprint规划
与会者：开发团队、Scrum Master、Product Owner
召开时间：Sprint启动时
持续时间：时限为一周的迭代，会议持续时间通常为一小时——例如，为期两周的Sprint将在启动时进行两小时的规划会议。
敏捷框架：Scrum（当然，Kanban团队也有计划，但他们没有采用正式的Sprint规划会议来制定迭代计划）
目的：Sprint规划会议为整个团队制定计划，以确保团队在整个Sprint中取得成功。会前，Product Owner将准备一个按优先级排列的Product Backlog。他们与开发团队共同讨论每个列表，并预估工作量。 然后，开发团队将进行Sprint预测，大概估计团队可以完成Product Backlog中的哪些工作，而这部分工作也就是Sprint Backlog。
专家提示：团队通过Sprint规划会议来充实需要完成的工作的具体细节。鼓励团队成员为Sprint中的所有用户故事、错误和任务勾画工作任务。会议的目的在于促进讨论，并就行动计划达成共识。有效的规划能提高团队达成Sprint目标的概率。
每日站会
与会者：开发团队、Scrum Master、Product Owner
召开时间：每天一次，通常在早上。
持续时间：不超过15分钟。不要让大家坐着在会议室开会。站着开会可以缩短会议时间。
敏捷框架：Scrum和Kanban。
目的：站会的目的在于让团队成员快速了解当前进度。这不是一个详细的状态汇报会议。会议整体氛围应该轻松有趣，但信息丰富。会议上团队成员应该回答以下问题：
• 昨天完成了什么？
• 今天要做什么？
• 遇到了什么障碍？
向团队同伴汇报自己昨天的进度是一种非常隐蔽的问责方式。没有人愿意成为团队中那个拖后腿的人——每天重复同样事情，且毫无进展。
专家提示：有些团队会使用计时器，确保每个人的发言都言简意赅、言而有物。还有一些团队可能会选择让队员一边开会一边互相传球，以此保证团队的注意力集中。而许多存在地理差距的团队则会选择使用视频会议或群聊来完成每日站会。每个团队都有其独特性，因此每日站会也会有所不同！
迭代评审会
与会者：
必须参加：开发团队、Scrum Master、Product Owner
建议参加：项目利益相关者
召开时间：sprint或里程碑结束时
持续时长：30-60分钟。
敏捷框架：Scrum和kanban。与规划会议一样，kanban团队的评审应该与团队里程碑保持一致，而不是以固定的节奏召开。
目的：迭代评审是展示团队工作成绩的时候。它们可以采用“周五demo演示会（demo Fridays）”等相对比较轻松的形式，也可以采用更正式的会议形式。不管采用何种形式，评审会都是团队庆祝工作成就，演示在迭代中完成的工作，并从项目利益相关者那里获得反馈的机会。记住，只有符合演示要求，且满足团队的质量标准的成果，才可以被认为是完整的，才可在评审会上进行展示。
迭代回顾会
与会者：开发团队、Scrum Master、Product Owner
召开时间：迭代结束时
持续时长：60分钟
敏捷框架：Scrum和Kanban。Scrum团队会定期召开回顾会议。Kanban团队也可以从偶尔举行的回顾会议中受益。
目的：敏捷的核心是要从快速反馈中不断优化产品和开发文化。回顾会议可以帮助团队了解哪些方面做得好，哪些方面需要提升。
回顾会议不是只抱怨没有解决方法的嘴炮会议。团队可以利用回顾会议来找出哪些是行之有效的方法，是团队可以持续关注和使用的。以及哪些方面需要做出改进，并在会议上讨论出创造性的解决方案并制定行动计划。持续改进是支持和推动敏捷团队发展的动力，而回顾会议是实现持续改进的关键行动。
专家提示：即使整个团队的工作进展顺利，也不要停止进行回顾会议。因为回顾会议能为团队提供持续的指导，以保持良好的运行状态。
一个团队的敏捷性需要扎根于实实在在的开发实践，依赖于战术和战略性的变革方法和出色的团队写作。敏捷仪式只不过扮演了简化整个团队沟通过程的角色。
文章来源：Worktile敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。
