敏捷其实很简单3---敏捷方法之scrum

通过前面两篇文章，我们介绍了敏捷宣言，包括4条宣言和12条准则。可以说敏捷开发的所有理念，思想，方法都来源于敏捷宣言，所有想要实施敏捷，要先理解敏捷宣言。那么经过上面的文章，我们大家都知道了敏捷实际上是一种理念，一种思想的转变，从传统的开发模式进入到新的以价值为驱动的开发模式中。那么有什么具体的方法呢。从这篇文章开始，我们逐一介绍一些主流的敏捷开发方法。

首先，现在敏捷开发中比较流行的方法就是SCRUM了，而且很多人在实际应用中，也把SCRUM和敏捷划上等号。实际上在这里，我们要先分清一点，包括SCRUＭ，还有我们以后要介绍的ＫＡＮＢＡＮ，ＸＰ等都是敏捷理念落实到实践中的一种实际方法而已，它们从不同角度体现了敏捷思想，并且可以根据企业的实际情况，来进行落地和调整。并不是说某种方法是敏捷的，其他的就不是敏捷的了。

好了，言归正传，我们先了解一下ＳＣＲＵＭ的前世今生。

Scrum的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》（The New New Product Development Game，竹内弘高、野中郁次郎，1986）。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性，并概要描述了管理在开发过程中发挥的作用。

当然，SCRUM这个词没有什么标准的中文解释，它是来源于橄榄球中的一个争球的动作，如下图。

竹内弘高和 野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发，他们指出：

传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。

上图是SCRUM的一个典型架构图，我们可以看到里面有很多要素，下面我们一一介绍这些要素。

3355原则：

大家可能很多人都听过3355原则，这个就是ＳＣＲＵＭ框架总结出来的核心要素了。

一　３个角色：

Ｐｒｏｄｕｃｔ　Ｏｗｎｅｒ：产品负责人，能够直接和客户和团队接触，非常了解客户需要什么，并且能够将客户需求分解为合适的ｕｓｅｒ　ｓｔｏｒｙ，在某些公司，该职位可能会和ＢＡ想关联，但是实际上ＰＯ的角色要比ＢＡ重要的多，因为在大部分实际情况里，他是要对产品的交付负主要责任。

Ｓｃｒｕｍ　Ｍａｓｔｅｒ：可以理解为Ｓｃｕｒｍ主管，在团队中保证ｓｃｒｕｍ流程，同时帮助团队解决可能出现的问题，同时也负责团队和ＰＯ的ｃｏａｃｈ功能，最终目标让团队成为真正的自组织团队。

Ｓｃｒｕｍ　Ｔｅａｍ：可以认为是开发团队，但是要是一个跨职能的团队，也就是能够交付一个端到端的真正对客户有价值的产品。很多公司可能无法做到，但是只要少包括开发，测试和一些系统设计人员。

二　３个组件

Ｐｒｏｄｕｃｔ　Ｂａｃｋｌｏｇ：产品开发列表，将需求转变为ＰＢ里面的具体的ｉｔｅｍ，能够使所有相关人看到一张统一的Ｂａｃｋｌｏｇ，这样大家可以对产品开发形成统一的优先级和价值导向。

Sprint Backlog：每个迭代的功能开发列表，也就是每个sprint要从上面的PB中按照优先级获得本迭代要做item。然后原则上在每个迭代中是不能被打断的。

Burndown chart:燃尽图，在每个迭代显示剩余工作时间和任务完成情况的图标。

Sprint Backlog 图

Burndown chart

二 5个价值

专注：每个迭代只专注于迭代要完成的事情，团队和个人的能力和精力是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。

勇气：要有勇气去面对各种挑战。

公开：团队所有的进展，问题，阻碍都是对所有人可视化，透明的。这样的团队才是彼此尊重。同时也能暴露问题。

承诺：作为一个自组织团队，在迭代开始的时候做出承诺，并在迭代中全力完成。

尊重：团队是长期坐到一起，并且稳定的，有助于加深彼此的了解和沟通。

三 5个活动

Sprint:冲刺sprint,一个固定的时间周期（通常为2w-4w）

sprint planning meeting：每个迭代开始之前，PO负责讲解需求，团队进行估算每个user story的大小，以便于决定在该迭代选择哪些user story进行开发。

daily standupo meeting:每日站会，scrum为了加强团队沟通，每天团队都要选择一个时间站在一起，互相交流彼此的进展和问题。

sprint review:评审会议，通常在每个迭代的最后一天，会议上团队交付自己在这个迭代中开发的产品或者软件（一定要可以工作）有PO和团队成员进行评审，看是否符合产品开发要求。

retrospective meeting:回顾会议，通常在reivew会议之后开始，有团队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，这是一个持续改进的过程。

SCRUM的其他一些要素：

user story:用户故事，因为敏捷要求每个特性都是对客户有价值的，所以以用户故事的方式来设计特性，通常是作为客户，我要实现A功能，以至于我可以达到什么目的的结构。

task：每个迭代中为了开发一个user story,将其分解为一些task,比如说我要开发一个协议，其中需要几个task,包括搭建服务器，找一些开源代码，搭建自动化测试框架，编码，测试任务，便于更小粒度的track每个迭代的进展。

release planning：在某些大型组织，可能更关注release级别的产品交付，所以每个release之前要进行整个release的plan,决定这个release的PB。

points：故事点数，代表用户故事的大小，要记住，这里的大小不代表开发时间，只是一个相对的用户故事的复杂度，工作量大小。因为很难理解，所以scrum team要建立一个基准的user story，作为一个points，然后其他的user story和它进行相对比较。这个points大部分时间用来作为评估team的交付能力。

SCRUM开发流程：

Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产 品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求 。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交 潜在可交付的产品增量。

SCRUM各个角色之间的关系和作用：

PO和team的关系：一个人拿到了客户的一个项目，开发一个产品，他就是ＰＯ，他想找一个团队开做这个产品，但是现在有Ａ团队和Ｂ团队，Ａ团队跟PO说，ok,交给我吧，3个月后你过来，我们把产品给你.而B团队说，我们每个月都可以让你看一下我们的产品，但是可能一开始功能不完善，但是可以工作的，然后你可以把我们的产品给客户看，如果运气好的话客户可能先给你点钱呢。

如果你作为PO，你会选择哪个团队呢？对了，A就是传统的开发团队，而B则是我们的scrum team.

scrum master和team还有PO的关系：

个人给SM有以下几个定义：

1　ｔｅａｍ　ｃｏａｃｈ：他可以ｃｏａｃｈ　ｔｅａｍ，不仅是保证流程，主要的是改变大家的思想，让大家接受敏捷开发理念，从而更好的组织团队，交付产品。

２.　ｔｅａｍ　ｄｕｄ：scrum master不是ｌｅａｄｅｒ，他实际上是ｔｅａｍ的伙伴，希望通过自己的帮助，让ｔｅａｍ能够解决在ｓｃｒｕｍ框架下发生的问题，移除障碍，从而让ｔｅａｍ不断的发展，自我组织。

３.　ｔｅａｍ　ｐｒｏｔｅｃｔｅｒ：团队保护者，ＳＭ要根据团队情况，尽量保证团队在每个迭代中不被打扰，如果发现有影响团队迭代的事情，比如说临时增加任务等，一定要站出来保护团队。

４.　ＰＯ　ｃｏａｃｈ：我个人现在发现，SM作为coach，有意无意的往往会忽略了对ＰＯ的ｃｏａｃｈ作用，因为现实环境中PO往往是项目经理或者leader转化而来，具有先天的权利优势，但是一个好的PO往往是决定一个团队的成败关键之一，所以SM 作为team coach的角色，很重要一点就是coach PO，从而使得PO，TEAM能够更好的协作，达到一个共赢团队。

SCRUM大事表：

Jeff Sutherland在 1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。

1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。

2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。

2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。