敏捷工作法最早起源于软件行业，现在已经深入推广到其他的各个领域。大到美国宇航局的一次火箭发射任务，小到家里的一次室内装修，都可以应用敏捷工作法来成倍地提高工作效率。

而敏捷工作法成功的关键，则在于突破传统死板的先做好全部规划再开始行动的模式，积极去拥抱变化，在每一次变化面前随机应变，最终实现小步快跑，快速迭代。

我所在的公司最近从研发部门开始，在全球范围内推行敏捷工作法。经过一段时间的接触和学习，包括与身边有过敏捷工作经验朋友的交流，总结了以下学习心得与大家分享。

作者 | 范珂

来源 | “行走的帆”（ID：sailing-fan）

（1）FBI与敏捷工作法

先从一个真实的故事开始讲起。

在911事件发生之后，美国联邦调查局（FBI）发现组织内部缺乏一种有效的文件管理机制，导致大量有价值的情报和信息被人为的耽误和忽视。于是，FBI决定上马一套文件管理系统，在投资了1亿美元并又追加了7000万美元投资之后，该项目搞了3年，最终不了了之。

后来，FBI决定重新上马这套系统，将项目命名为“Sentinel”。这次预计投资4.5亿美元，计划2009年交付项目。这次FBI找来了大名鼎鼎的国防承包商洛克希德-马丁公司作为项目总包。

让我们把时间快进到2010年3月：此时，项目已经耗资4.05亿美元，而原定进展仅仅完成了一半。根据承包商洛克希德马丁的估算，该项目还需要6-8年以及再追加3.5亿美元投资才能最终完成。

如若继续将项目按原定计划推进下去，那整个项目将沦为一个天大的笑话。此时，一位名叫Jeff Johnson的联邦调查局IT部副主任接手了项目，后来的结果让人难以置信：

他接下来只用了1年多的时间和几千万美元，最后让项目于2012年7月正式完工上线。

Jeff完成项目的方法，正是“敏捷工作法”。

（2）敏捷团队的各个角色

为什么敏捷工作法有如此巨大的威力？

敏捷工作法有一个专门的英文单词叫“Scrum”，来自于橄榄球运动中的一个专业用语，翻译成中文就是“争球”的意思，它用来形容整个团队团结一致，为了完成一个共同的目标而饱含热情、同心协力。

敏捷工作法最早应用于软件开发行业，利用小步快跑、迭代开发等原则，来实现软件产品的迭代更新。

再后来，敏捷工作原则逐渐扩展到了其他高科技及传统工业领域，比如，今天我所在的企业从事整车开发和制造，也在开始倡导敏捷工作法。甚至，在伊拉克战争中的美军特种部队，也使用了敏捷工作法来管理特种部队的作战任务。

要成功地实施敏捷工作法，就离不开敏捷团队里的几个关键角色：

角色1：敏捷工作小组成员

既然敏捷，那么团队人数就不能太多。在软件行业里，有一条布鲁克斯定理，其内容大致是：如果一项软件产品出现推迟交付，此时往开发团队里增加人手只会加剧最后交付的推迟。

为什么会这样呢？其一是，一个新人加入后，帮助其上手熟悉项目工作的过程会滞缓其他团队成员的工作速度；其二是，多余的人会增加我们大脑的信息处理频道数量，导致沟通效率的降低。

亚马逊的创始人贝佐斯对有效的工作小组规模有一个定义：团队人数以一顿午餐够吃两块披萨饼为上限。以此为标准的话，一个团队要保持高效灵活，有效的人员上限就是不超过7-9人。

这7-9个人也不是随随便便组合在一起，按照敏捷工作法的要求，小组再小，必须满足3个条件：

（1）超越平庸的信念：团队成员靠着同一个崇高的理想而凝聚在一起，人人都希望超越平庸，追求优秀；

（2）获得充分授权：团队可以自主做出重大决策，享有充分的自治权；

（3）跨职能：团队角色人人分工不同，可以形成一个闭环。比如，某个产品的规划、设计、制作、销售和交付均由同一个小团队内不同的成员担当。

角色2：产品负责人（Product Owner）

产品负责人也是整个团队的灵魂人物，具体负责团队的工作目标、产品的功能和需要达到的标准。此外，Product Owner还负责排定团队工作的优先顺序，也有权拒绝与团队无关的工作任务。

产品负责人身上需具备4个基本特点：

（1）对该产品领域非常了解，所以他往往出自本领域资深的专家；

（2）被充分赋予权力，有权在团队内就产品开发做出决定；

（3）随时可以被其他团队成员找到，以便向他们阐明工作任务的方向和原因；

（4）负责人需要为工作的价值负责，有相关的量化指标来衡量最终的工作价值。

角色3：敏捷大师（Scrum Master）

敏捷大师的身份在团队内更像是一名团队教练，如果说产品负责人解决的是做什么的问题，那么敏捷大师解决的就是怎么做的问题。

他随时为团队里其他成员提供辅导和指导，负责组织日常的会议和协调，并移除阻碍团队前进方向的障碍，帮助团队可以顺利开展工作。

这里要注意一点，无论是团队负责人或敏捷大师，他们本身与团队其他成员之间并没有传统的那种上下级汇报关系。团队里三种角色有各自平等的责任，这也是敏捷团队区别传统团队的一个地方：团队内部实行人人平等的民主制，每个人的能力都被信任，更加自主，能发挥出更高的效率。

（3）敏捷工作流程

团队具体在开展敏捷工作时，流程如下：

第一，建立任务需求列表（Product Backlog）

这个相当于按照优先顺序排列的任务需求表。产品负责人根据需要的产品特性制定出产品需求列表（Product Backlog），该列表提交全体团队成员讨论，最终确定下来团队的工作任务路线图，帮助团队成员了然于胸哪些任务是接下来需要去完成的。

第二，任务分解，制订Sprint

传统的解决任务办法是用一种瀑布式流程法，先就项目作出全面规划，然后再推进、测试、重审和实施。这种方式是一开始就把所有的计划准备完毕，然后按计划逐步去实施。

（下图：传统的瀑布式流程图）

但是，很多时候，我们都知道，计划赶不上变化，计划最后的结果就是等于没有计划。很多事情到最后就变成了重新规划。

在敏捷工作方式下，把任务分解为可以控制的每一个小段，每一段叫Sprint，在每一段的Sprint里面，完成该段工作的规划、建设、测试和审核的全过程，然后完成交付，之后再进入下一个Sprint的任务迭代。

在制订Sprint的时候需要遵循的原则：

（1）每段Sprint必须相等，比如每两周或每个月为一个Sprint；

（2）每个Sprint里的任务一旦锁定，不能随意地增加或减少工作任务；

（3）所有的工作任务必须在该段时间区间内全部完成，之后才能进入下一个Sprint。

第三，工作进度可视化

敏捷工作小组通常会设定任务的可视看板来实现工作进展的可视化。典型的可视看板，根据每个Sprint的任务情况，分别列出待完成、完成中和已完成的工作任务，用看板展示出来，可以让所有团队成员对工作的进展一目了然。

当然，今天也不一定非要在办公室墙壁上通过贴大白纸和小黄帖来做可视化看板，类似Teambition这样的团队软件中已经内嵌入了工作任务看板功能。

第四，通过Scrum团队会议开展工作

Scrum团队会议分为4种：

（1）Sprint Planning （Sprint计划会）

产品负责人组织全体团队成员一起讨论，在本次Sprint中将要完成那些工作任务，具体如何推进工作，最终形成待办任务列表（Product Backlog）。

（2）Daily Stand-up（每日站会）

每天在同一固定时间，全体小组成员聚在一起，开一个小会，讨论工作的进展。但是这个会有几个特点：

第一，所有成员需站立，不能坐着，这样保证每个人注意力的高度集中，以及让会议开得更高效；

第二，会议时长严格控制在15分钟以内；

第三，会议上只讨论3个问题：（1）我昨天都做了哪些工作来帮助团队完成本次Sprint？（2）我接下来准备做什么工作来帮助团队完成本次Sprint？（3）目前团队工作进程中还存在哪些障碍？

（3）Sprint Demo（Sprint演示会）

在Sprint进展过程中，团队成员利用这个会议的机会，向其他团队成员展示自己具体都完成了哪些工作，同时向其他成员寻求反馈和意见，并做出相关改进。

（4）Sprint Review（Sprint回顾会）

在一个Sprint结束之后，所有团队成员聚在一起，讨论本次Sprint过程中，大家团队工作的成效，检讨还哪些需要改进的地方，以便下一次Sprint能够做得更好。

------------------------------END-----------------------------