概念解释

Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。

图解敏捷开发

关键词

三个角色，三个工件，四个流程（五个事件），四大支柱，五大价值观

三个角色

Product Owner

产品负责人负责的事项：

清晰地表达产品代办事项列表条目
对产品代办事项列表中的条目进行排序,最好地实现目标和使命
确保开发团队所执行工作的价值
确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作
确保开发团队对产品代办事项列表中的条目达到一定程度的理解

Scrum Master

Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。 Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

Scrum Team

开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产品增量。只有开发团队的成员才能创造增量。

开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化开发团队的整体效率和效力。开发团队有以下几个特点:

他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品代办事项列表变成潜在可发布的功能。
开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。
Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。
开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队
开发团队不包含如测试或业务分析等负责特定领域的子团队。

三个工件

分别指的是产品待开发项，冲刺待开发项（开发角度），可交付软件（文档）

四个流程

四个支柱&&五个价值观

四个支柱

迭代开发
自组织团队
高优先级的需求驱动
增量交付

五个价值观

承诺 – 愿意对目标做出承诺
专注– 把你的心思和能力都用到你承诺的工作上去
开放– Scrum 把项目中的一切开放给每个人看
尊重– 每个人都有他独特的背景和经验
勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

前置条件

敏捷的团队

敏捷团队要求其成员具有以下的一些基本特点。

具有多年工作经验，在自己的负责领域有专业的认知和独立完成能力
有较好的执行力，对自己允诺的事情能完整的完成
有较好的沟通反馈能力，对敏捷本身的正确理解，在遇到问题、风险、不确定性、协作等时能快速的通过沟通完成沟通的目的
对其他技术栈或者专业领域有一定的认知，有较少的认知壁垒，较快达成共识
团队在此之前有至少半年到一年的磨合

比较固定的流程，文档，需求

需求是控制稳定性的根本，对于需求一定是整体可控的，并且是可以由迭代内进行调整的，而不是定死的
流程是指什么时间什么人该做什么事是高效的，明确的
文档是指每个流程阶段具有可交付或者可查阅参考文档，不是口头或者个人评定

可灵活调整，允许试错

检查

检查是指在每天的站会中检查每个人的工作状态，是否能完成自己的任务，存在什么问题，完成效果如何。另外就是保证整体在每天的进度，是否有有整体效果，如果没有完成今天的整体效果，需要检查是否符合整体迭代。

调整

调整是指检查发现迭代的进度或者外界环境发生变化时，及时调整当前迭代的开发任务，保证迭代最终产物的准确及时性变动。当然，这种变动是不允许太多的，一般情况下在需求没有做详细分析时，不接受；在当前有风险的情况下，撤销某些需求；其他情况不做描述。

试错

正是由于检查以及调整的策略，保证了迭代的灵活性，我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点，如果实验成功则可以对外拓展；如果不行，可以快速切换方案。

适用场景

不确定的开发流程，技术方案
不成熟的产品
产品快速多方面优化
产品新特性研发
技术重构

问题场景&&错误认识

一个团队闭关开发一个项目就是敏捷

正确理解：敏捷不等于闭关，只是可能坐一起效率更高，其倡导的是何时都可以发生沟通，并准备一白板可以随时讨论方案；敏捷团队质量以及效率高于一般团队；敏捷团队开发的是以迭代为单位，不是项目；

有了任务细分，开发白板，站会就是敏捷

正确理解：任务细分、白板、站会都是其形式，关键还是其将迭代的内容进行细化，可执行化，用高频的沟通反馈提高开发、沟通、理解的效率。

把最好的成员都攒一起了就是敏捷

正确理解：这些成员除了各自的专业水平还需要各自的磨合，沟通水平，对其他职能的一定的了解。

开发很快，快速交付的是敏捷

正确理解：开发快、快速交付产物只是敏捷的一个特点，也要深刻理解其交付的只是一个迭代的，并不是一个完整的产品。

只有软件开发团队才有敏捷

正确理解：符合可以将任务明细，具有一个可执行团队，一个监督者，都可以尝试敏捷的管理。

敏捷团队没有特殊前置条件

正确理解：前面有讲到敏捷对团队，需求，文档，流程，调整等都有比较完整的规定。

敏捷团队做的事情没有差别性

正确理解：敏捷完成的任务具有明细化，分阶段性，可调整性。所以在开发相关任务时，也具有类似的特点。

敏捷团队会完整完美的交付产物

正确理解：敏捷在迭代结束只交付该阶段的可交付产物，很可能不完整不完美，对于可交付也有不同的理解。

更多

有兴趣可以持续关注的后续讲解，会针对用户故事、需求管理、跟踪反馈等多角度分析执行敏捷的要点。

参考文档

《火星人敏捷开发手册》
scrum中文官网