前言
今天，几位同事带着我先过了一次Scrum 实践，走了一个流程，感觉内容很多，一时估计没法消化，做个笔记。
Scrum简介
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.
角色
“猪”角色
产品负责人（Product Owner）
通常由市场部门的人担任敏捷教练 (Scrum Master)
通常由开发组组长担任开发团队 (Scrum Team)
包括开发,需求,测试
“鸡”角色
用户
软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者 (客户，提供商)
影响项目成功的人, 但只直接参与冲刺评审过程。管理者
为产品开发团体架起环境的那个人
流程
启动会议
->每日站会
->show Case
->迭代总结会议
有的地方也写成如下名字：
冲刺规划会议（Sprint Plan Meeting）
->每日站立会议（Sprint Daily Meeting）
->冲刺复审会议（Sprint Review Meetion）
->冲刺回顾会议（Retrospective Meeting）
启动会议
1.需求
需求需要和PO沟通 主要有如下几点：
- 工作来源：这份工作是谁安排的，要求达到什么目的
- 细节问题：这部分需要做好功课，你需要站在一个开发者的角度，来思考这些细节，这也是为你的开发团队向PO提问。
- 工作量预估
2.用户故事拆分
As For Do 原则
As（用户角色）： 该功能是为谁设计的，预期用户是哪些人？
这一点必须收敛和明确，如果某一功能的预期用户太过复杂，说明这一部分的设计是有问题，需要拆分。For（价值、目的） : 该功能的实现目的是什么
- Do （过程、行为） : 该部分涉及真实进行的场景
3.故事点
这一部分，涉及到分发任务，最好由开发人员回答，要引导（压榨）开发人员，发掘故事点。
- 全员预估、发现坑、技术教练指导
- 和PO 沟通实施先后顺序
- 用户故事优先级别
每日站会
严格按照Story 的故事点来汇报。Master 需要汇报整个项目进度。
- 昨天做了什么
- 今天准备做什么
- 有什么问题
要求每个人发言简洁，明确。如果有细节的问题，注意打断然后私下讨论。确保每个人都能集中其工作在某个点上。
show case
As 对象 必须在场
ST 成员各自演示功能
迭代总结会议
- 计划投入、实际投入、延时
- 把大家的想法总结
- 大家反馈完成度
- 谁做的最好？谁有待改进？ why？ 做个记录，有利于成员管理和考核，对好的予以表扬。不足的设法改进。Master 也需要借此对团队成员有一个考量。
- 每个人提建议。
1.不足的可以改进的地方（注意分类，在逻辑层次需要在一个层面，例如 外部问题，团队管理问题，个人问题，有的问题可以及时和甲方沟通）
2.好的，可以延续的地方。（如重构）
杂七杂八
- 第一次接触团队，大家互相不熟悉，第一个迭代（冲刺）可以制定工作量70% 这一部分需要和甲方商榷。
- 作为Master 要保持自身的机动性。
- 每个故事点，要尽可能的发掘开发人员的思路。
- 用户故事，或者故事点过大时，要及时切分。
- 纸上得来终觉浅