Scrum一个非常好的项目管理方式（方法论），我十分喜欢，但是，项目中使用需要很多客观条件支持，例如公司环境，队员素质等等。
无论怎样，个人十分推荐在项目中尝试该管理方式。虽然，我不是Scrum Master（本人只有PMP证书），但是我一直对此深入学习，并尽可能多的将其应用到实际项目中。
今天我说一下Scrum中的五个事件
- The Sprint 冲刺 一个敏捷迭代
- Sprint Planning 敏捷迭代计划
- Daily Scrum 每日Scrum
- Sprint Review 敏捷迭代评审
- Sprint Retrospective 敏捷迭代回顾
The Sprint
英文直译就是冲刺，其实我们可以将项目划分成多个sprint（冲刺），从而依高效、快速的方式完成整个项目。
一个sprint周期一般为1个月（常见可以为2～4周）最终释放产品的增量（increment），在项目执行过程中，一个spring接着另一个sprint
sprint过程中包括什么？ sprint包括下面四个事件，同时还包括具体开发工作。
sprint可以取消吗？ 当然可以，但只有产品经理有权限取消（终止）sprint，当然他要与必要的团队成员进行沟通。但是，
sprint一般不会遇到取消，因为取消一个sprint通常是因为目标已经过时，但是sprint本身周期就很短，目的就是为了更好面对改变，所以一般不会遇到这个场景
另外，一个sprint的取消将对团队和项目都有很不好的影响，甚至需要重新评估产品的Backlog，所以这个应避免出现。
在sprint中，我们应该
- 对sprint目标实现有影响的改变都不应该接受，实际上通常做法是freeze backlog后就不进行修改了，但是现在也有使用弹性冻结的思路
- 质量目标不能下降，降低sprint最终目标质量
- 随着项目的深入，产品经理和开发团队可能需要重新商讨项目范围，可能是因为任务难度超出了之前的预期。这也是弹性冻结的原因
Sprint Planning
冲刺计划，或者是一个迭代周期的计划，通常表现形式为敏捷迭代计划会议，一般需要4个小时（一个小时对应一周）
制定一个迭代周期内的相关工作，根据product backlog中的任务优先级形成sprint backlog。
sprint planning 主要回答两个问题：
- 此sprint结束时将交付什么（increment）？
- 为了正常交付，都需要做什么工作（backlog）？
同时，也要明确，迭代时间、后续工作时间表、团队成员等
会议一般需要包括：
- Scrum Master 宣布迭代时间表
- 阐明、更新product backlog，对业务的价值和优先级，并达成共识
- 选出并确定sprint backlog，团队共识迭代目标
- 拆解sprint backlog形成具体任务，每个任务应该小于2天
- 任务初步分配，可以使用看板进行后续跟踪和管理
Daily Scrum
每日scrum，通常表现形式为 Daily Stand-up Meeting 日站立会，一般需要15分钟
目的就是为了让组内成员互相知道都在做什么，有什么问题需要解决
会议一般包括：
- 我昨天做了什么有利于sprint目标达成的工作
- 今天计划做什么有助于sprint目标达成
- 当前工作是否遇到问题妨碍目标达成
站会的站不是必须的，但一般为站着是为了提高效率，15分钟，大家直接沟通，不要阐述或讨论详细内容。
Sprint Review
冲刺评审，通常在一个sprint周期的最后一天，评审此次sprint交付成果，通常表现形式为敏捷迭代评审会议，一般需要4个小时
展示此sprint阶段的成果，进行评审、检查是否达到了预期的目标，参会人员应该包括项目团队成员和利益相关者，一般又产品经理来邀请
会议一般包括：
- 完成什么，什么没有完成，阐述增量更新
- 开发团队总结哪些正在往好的方向发展，哪些遇到了问题，哪些问题得到了解决
- 后面要实现什么，这个可以作为下一个sprint迭代计划的输入
- 评审项目需求、预算、时间周期等，讨论产品任务清单，是否需要调整product backlog
此会议主要是总结迭代周期内工作完成情况
Sprint Retrospective
冲刺回顾，通常在一个sprint周期的结束后某的一天（在review之后，在下一个planning之前），回顾此次sprint执行过程中的问题和好的经验总结，通常表现形式为敏捷迭代回顾会议，一般需要3个小时
会议一般包括：
- sprint周期内，人员、流程、工具等表现如何
- 哪些做的好，哪些今后可以提升
- 创建后续可以提升的计划
此活动主要是总结团队Scrum经验，便于后面做的更好。 如有有问题，应该是整个团队负责，并寻找解决方法。
先写这些，今后再总结其它关键点