4个仪式/事件的对比

一个迭代/冲刺，是已经包含如下的所有活动，不存在所谓，迭代/冲刺之前或之后才举行如下的活动
通常情况：

• 迭代的第一天，会举行迭代/冲刺计划会
• 代/冲刺倒数第二天，举行评审会
• 迭代/冲刺的最后一天，举行回顾会

迭代/冲刺计划会议 Sprint Planning Meeting

进行迭代规划:

• 阐述产品愿景，确定迭代目标和迭代合约

  上半部分：

• 前4个小时，PO向团队介绍产品待办事项

• 细化产品待办事项

• 与团队讨论优先级最高的需求特性

  下半部分：

• 后4个小时，PO协助团队了解产品待办事项

• 团队规划好冲刺蓝图并定义任务层面的细节
• 创建迭代/冲刺待办事项，Sprint Backlog

关键要素：

• Sprint冲刺
• 迭代优先级
• 分析和评估Product Backlog每个项目
• 选择一些作为迭代目标，决定如何实现迭代目标
• 从产品Backlog中选择一些创建迭代Backlog（任务）
• 以小时为单位评估迭代任务的工作量
• 团队成员名单
• 迭代/冲刺待办列表 Sprint Backlog
• 确定好Sprint演示日期
• 确定好时间地点，供举行每日Scrum站会会议

每日站立会议 Daily Scrum Meeting

• 站立会议，是团队自发组织，并不是Scrum Master责发起这个会议。
• 固定时间、地点，团队选择。Scrum Master需要引导团队确保15分钟搞掂每日站会
• 3个题：昨天做了什么？今天计划做什么？遇到什么问题（障碍）？
• 信息沟通，不解决实际问题（可以会后再另起会议再详细沟通实际问题）
• 不向任何人汇报（Scrum要主动发现障碍）

注意事项：

• 有负责工作的人就必须参加
• 只有那些负责工作的人有发言权
• 讲话时要对团队说，不要对敏捷教练说
• 不可以在下面交头接耳
• 为新的工作做一个新的可黏性贴纸
• 会议结束后再讨论问题
• 不会有Scrum Master或者其他任何人来指派任务
• 团队成员不是向Scrum Master汇报情况，每日站立会是团队自己组织的会
• 团队成员不会在会上讨论或者解决问题，大家会把问题记录下来，会后找相关的人讨论或召开具体的讨论会议
• 团队之外的人可以参与，但不得发言或干扰会议

迭代/冲刺评审会议 Sprint Review Meeting

• 团队需要演示所完成的迭代工作
• 典型的做法是使用演示形式展示新功能或者底层架构的实现
• 非正式的，注意不是汇报进度
  • 不需要过分正式演示文档，更重视：原型图、Demo、可体验的产品..
• 整个团队都需要参加
• 邀请所有关注产品的人参加，为了获取反馈并促进合作。

注意事项：

• 确保清晰阐述了Sprint目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
• 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿仍一边去，集中精力演示可以实际工作的代码。
• 节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
• 让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么” 而不是“我们怎么做的”
• 可能的话，让观众自己试一下产品。
• 不要演示一大堆细碎的bug修复和微不足道的特性。

迭代回顾评审会议 Sprint Retrospective Meeting

• 哪些做得好
• 那些做得不好
• 哪些可以改进

• 会议目的：持续改进开发过程，最大化团队价值交付能力，提高团队（绩效）生产力。认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致
• 参与人：主体是团队、PO或SM也可以参与
• 会议时间：一个月的迭代，4个小时，比迭代计划会议的持续时间更短
• 会议内容：对前一个Sprint周期中的人、过程和工具进行总结。哪些做得好；那些需要改善（不太好的）；需要在以后尝试的事情（今后迭代中改善）；要上报的问题（向管理者）
• 会议益处：来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键，细节包括：什么进行顺利，缺少什么，需要改变什么等等