Scrum 是敏捷开发方法中比较流行的一种方法，这里简要的对 scrum 的一些阶段做一定的介绍。
什么是敏捷
敏捷的开发方法包含四个核心价值和十二条原则，是以迭代作为开发周期，以人为中心的软件开发方法。
核心价值
在核心价值中，右边的部分也是非常重要的，但是左边的部分更重要。从实践的过程中看，如果没有做好右边的事情，敏捷通常也是失败的敏捷，可以说右边的内容是敏捷团队的基础，左边是在践行敏捷过程中应该努力做到的提升内容。
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
十二原则
十二条原则常常会在开发的不同阶段产生价值，所以这些应该是每个敏捷团队应该时时注意的内容，建议在每个回顾会议上就这些原则开展会议。
-
通过早期和连续型的高价值工作交付满足“客户”。
-
大工作分成可以迅速完成的较小组成部分。
-
识别最好的工作是从自我组织的团队中出现的。
-
为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。
-
创建可以改善可持续工作的流程。
-
维持完整工作的不变的步调。
-
欢迎改变的需求，即使是在项目后期。
-
在项目期间每天与项目团队和业务所有者开会。
-
在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。
-
通过完成的工作量计量工作进度。
-
不断地追求完善。
-
利用调整获得竞争优势。
Scrum 用户故事
Scrum 中使用用户故事来替代传统需求的概念。什么叫用户故事？就是以用户的角度来描述用户希望得到的功能，通常来说它包含三个要素：
- 角色：谁要使用这个功能。
- 功能：需要完成什么样的功能。
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
一个完整的用户故事如下：
作为一个<角色>，我希望拥有<功能>，以便于实现<价值>
通常在开发团队中会选择一个特殊的用户故事作为衡量其他用户故事的 1，这个用户故事即用户故事的单位——故事点。通常用故事点去衡量一个用户故事的规模，注意这里是规模不是工作量，规模是更偏向价值而非工作量的。
用户故事的 3C
卡片Card ：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈 Conversation ：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认Confirmation ：通过验收测试确认用户故事被正确完成。
用户故事的六个特性
一个好的用户故事应该遵循INVEST原则。
-
独立性 Independent
要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
-
可协商性 Negotiable
一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
-
有价值 Valuable
每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
-
可估算性 Estimable
开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
-
短小 Small
一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
-
可测试性 Testable
一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
Scrum 角色
Scrum 团队中包括三个角色：
- 产品负责人 Product Owner：负责最大化产品以及开发团队工作的价值
- 开发团队 Development team：保证在每个迭代发布高质量的增量
- 敏捷教练 Scrum Master：确保 Scrum 是被团队理解和正确实施的
Scrum 团队需要具备以下的特点：
- 自组织的：由团队决定团队如何最好的完成工作，而非团队外的人来进行指挥
- 跨职能：团队拥有完成工作的所有技能，不需要依赖团队外部的人
- 以增量和迭代的方式进行产品功能的交付，最大限度的优化适应性，创造性和生产力
Product Owner
Product Owner，即产品负责人，负责管理产品待办事项列表，主要责任包括：
- 清晰地表达产品代办事项列表条目
- 对产品代办事项列表中的条目进行排序，最好地实现目标和使命
- 确保开发团队所执行工作的价值
- 确保产品代办事项列表对所有人可见、透明、清晰，并且显示 Scrum 团队的下一步工作
- 确保开发团队对产品代办事项列表中的条目达到一定程度的理解
这些责任可以是产品负责人单人完成，也可以是团队一起完成，但是产品负责人是责任人。任何人无权更改产品负责人已经决定的产品待办列表，开发团队必须听从产品负责人的需求进行产品的开发。
产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。
开发团队
开发团队包含了完成产品功能的所有专业人员，开发团队通过协同工作最大化的开发团队的整体效率。开发团队有以下几个特点:
- 自组织的：没有人能够告诉开发团队如何把产品代办事项列表变成潜在可发布的功能，由开发团队自行完成。
- 跨职能的：团队作为一个整体拥有创造产品增量所需要的全部技能。
- Scrum 不认可开发团队成员的头衔，团队成员是平权的，无论承担哪种工作他们都是开发者。
- 开发团队中的每个成员可以有特长和专注领域，但是责任归属于整个开发团队。
- 开发团队不包含如测试或业务分析等负责特定领域的子团队。
- 一般来说开发团队的规模在 3 到 9 个人之间。
Scrum Master
Scrum Master 负责确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。
- Scrum Master 服务于产品负责人
- 找到有效管理产品待办事项列表的技巧
- 清晰地和开发团队沟通愿景、目标和产品待办事项列表条目
- 教导开发团队创建清晰简明的产品待办事项列表条目
- 在经验主义环境中理解长期的产品规划
- 理解并实践敏捷
- 按需推动 Scrum 活动
- Scrum Master 服务于开发团队
- 指导开发团队自组织和跨职能
- 教导并领导开发团队创造高价值的产品
- 移除开发团队进展过程中的障碍
- 按需推动 Scrum 活动
- 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队
- Scrum Master 服务于组织
- 领导并指导组织采用 Scrum
- 在组织范围内计划 Scrum 的实施
- 帮助员工及干系人理解并实施 Scrum 和经验性产品开发
- 发起能提升 Scrum 团队生产力的变革
- 与其他 Scrum Master 一起工作,帮助组织更有效的应用 Scrum
Scrum 会议
在 Scrum 敏捷实施过程当中，每个 Sprint 有四种会议：
- Sprint Planning 迭代计划会议
- Daily Stand-up Meeting 每日站立会议
- Sprint Review 迭代回顾会议
- Sprint Retrospective 迭代评审会议
迭代计划会议
在每个敏捷迭代开始之初，由 Product Owner 讲解需求，并由 Development Team 进行估算工时的计划会议。
会议内容：
- 排列需求优先级
- 分析和评估产品Backlog并确定该迭代的目标
- 制定迭代计划，包括： 根据 Product Backlog 创建 Sprint Backlog；然后为 Sprint Backlog 中的用户故事做估算；团队成员从 Sprint Backlog 中挑选他们承诺完成的用户故事
参与人员： Product Owner、Scrum Master、团队成员，其他选择性参加的人员（如业务人员）。
会议时长：1 ~ 4 小时
会议进程：
- Scrum Master 公开迭代时间表，明确每日站会，评审会议、回顾会议时间
- 产品经理和 Product Owner 讲述 Product Backlog ，说明对应需求的业务价值和优先级
- 团队针对 Sprint Backlog ，优先级和用户故事的业务价值达成一致，Scrum Master 和团队成员共同确定 Sprint Backlog
- 团队成员针对 Sprint Backlog 共同分解任务，团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间，团队成员共同认领任务
每日站会
团队每天进行沟通的内部短会，因一般只有 15 分钟且站立进行而得名，团队成员通常会在会议上讲述如下 3 点内容：
- 昨天做了什么
- 今天计划要做什么
- 遇到了什么问题，妨碍了我尽可能有效地工作
Scrum Master 记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。
所有成员讲述完毕之后 Scrum Master 和开发团队需要一起更新团队的用户故事燃尽图，团队速率图和风险报告等监控项目运行度量数据。
迭代评审会议
在迭代结束前给 Product Owner 和产品用户演示并接受评价的会议。根据会议的反馈结果，变更 Product Backlog。
会议内容：
- 检验迭代成果，检查迭代计划中的用户故事是否完成
- 鼓励用户参与测试流程，并得到用户对产品的认可
- 鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题
参与人员：Product Owner、Scrum Master、团队所有成员
会议时长：1 ~ 4小时，视演示内容而定
会议流程：
- 由 Scrum Master 来推进会议进程
- Product Owner 记录用户反馈，根据会议结果维护 Product Backlog
迭代回顾会议
在每个迭代结束后召开的关于自我持续改进的会议。
会议内容：
- 本次迭代有哪些做得好
- 本次迭代我们在哪些方面还能做得更好
- 我们在下次迭代准备在哪些方面改进
- 团队确定问题优先级，并根据优先级确定团队能够解决的 Top 问题
- 团队讨论 Top 问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。
参与人员：Scrum Master，Product Owner，团队成员。
会议时长：0.5 ~ 1.5小时
会议流程：
- 针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划
- Scrum Master 将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事
- Scrum Master 按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪
