本周公司正式开工，我也尝试了一周远程办公，从个人感受讲，我感觉这周的工作效率以及和团队同事沟通，比在公司的时候更高。一个重要的原因是，我们基于TAPD（Tencent Agile Product Developmetn）进行了更好的工作协作和沟通，这里不是为这个工具宣传，因为类似工具很多。我重点想说的是，我们歪打正着地使用了一些TAPD背后的原理，而核心就是Agile（敏捷）。
以前也听过“敏捷开发”的名字，并认为是互联网软件行业用的方法，和我关系不大。出于好奇，我阅读了一本相关的书籍《敏捷革命》，觉得挺受启发，分享与你 。
这本书的作者是杰夫.萨瑟兰，Scrum公司（专门传授敏捷开发方法）的联合创始人，应该算是这套方法大神级人物。他的经历也非常传奇，他毕业于美国西点军校，作为美军战斗机飞行员，完成过100多次飞越北部越南的作战任务，退役后进入斯坦福大学，于1972年获得统计学硕士学位，又于1980年获得科罗拉多大学生物统计学博士,他先后担任了11家软件公司的首席执行官和首席技术官，积累了丰富的项目管理经验，并于2006年，他成立了自己的公司公司Scrum，提供Scrum管理方法的培训服务。本书就是作者基于多年的实践和思考，总结形成的关于敏捷开发的系统性的总结。
本文会从三个方面进行分享：什么是Scrum或敏捷开发？为什么它会有效？如何应用它提供我们的工效率和价值？
1 敏捷开发
1.1 瀑布开发VS敏捷开发
作者在书中提到，开发方式常常可以分为两种：一种是瀑布式，一种是Scrum式（敏捷式）。所谓的瀑布式就是它的示意图如下图所示，它像一个瀑布一样，一层一层的泄而下，也就是在项目启动后，收集所有的需求，后规划一整套能够满足所有需求的系统，通过复杂的图表（如常见的甘特图）的方式，规定项目中的每个步骤、每个里程碑事件以及每个交付日期都详细列出来，然后按照这个计划去执行就好了。
对于一个持续几年的大项目，常常需要好几个月规划所有的细节，确保不会出现任何的疏漏，不会超出预算，而且每件事情都按计划完成，这种方式很具有诱惑力，因为它让项目看上去很可控。但问题是，这种美好的设想，常常不会成为现实，因为常常高估了自己的预测能力，低估了外在潜在的变化和风险，比如书中提到法国沙塔尔大教堂用了57年才建成，如果在建教堂才开始，石匠肯定说最多25年，15年就建好了。
如果你觉得建设大教堂的例子不具备说服力，作者还提到书中的一个例子。就是当时联邦调查调查局，它2005年宣布了一个名为"哨兵计划"的项目,而承担方是著名的洛克希德.马丁公司，他们吸取了过往类似项目当中的教训，制定了详细的计划，并预算4.5亿美元，在2009年全面投入使用。而实际情况是，2010年3月，这个项目已经花掉了4.05亿的开发经费，但开发进度只完成了一半，而且时间比原来延误了一年，并且分析评估，如果要完成整个项目的开发，预计还需要6~8年，而且不得不再砸进去3.5亿美元。
后来，通过将开发方式切换为敏捷开发，才得以挽救和收尾（使用了5%的预算和20月的时间）。那什么是敏捷开发？
"敏捷"这个词可以追溯到2001年的一场秘密会议，在那次会议上，作者和另外16位软件开发工程师，共同拟定的众所周知的《敏捷软件开发宣言》，并且主要包括了以下几种价值：人胜过流程，可以使用的软件胜过面面俱到的文件，客户合作胜过合同谈判，应对变化胜过遵循计划，当时的这个宣言其实只是一个价值的架构，还谈不上是个方法论。
后来经过演化，在软件行业，形成了所谓的“迭代式增值软件开发过程”，它把一个复杂开发周期长的任务分解为很多短期可以完成任务，这样一个周期就是一次迭代的过程，同时，每一次迭代都能看到一个可以交付的结果或产品。这个产品可以展示给那些关心这个产品的人（客户），从他们获取反馈，而且更重要的是，让团队也能近乎实时地看到反馈，从而检查自己在做的事情是不是在往正确的方向前进？结果是不是大家希望看到的？如果改善目前做的事情？如何能更快更好完成？有哪些潜在的障碍？
这也是我们常常听到的“小步快跑，快速迭代”。
1.2 Scrum
敏捷的英文应该是Agile，所以在前面我们的提到的TAPD（腾讯的敏捷开发工具）中的A，就是Agile。为什么作者把这种理念称为Scrum呢？这个词原本是橄榄球运动当中的一个专业术语，愿意是团队通力合作，场内传球，这个过程需要认真的配合，信念一致和目标明确，而这个过程完美的体现了作者对于一个敏捷开发团队的所有要求，因此他把这种开发方式定义为Scrum，寓意大家要像一起打橄榄球一样，动作要快，激情澎湃。
在阅读中，我理解作者提到了Scrum的两个重要思想源头：一个是在空军服役期间的OODA（观察-导向-决定-行动），这个后面详说；另一个是丰田生产方式，也就是我们在《精益工作法》:去掉不创造价值环节提到的精益生产和精益工作法。
而后一个来源也挺搞笑，因为它开始是源于美国，二战后，美国派出了麦克阿瑟驻扎日本，并带去了一些管理专家帮助日本，当时就有提出PDCA循环的戴明，后来日本企业就将戴明的PDCA提倡的持续改进发扬光大， 形成了具有代表性的丰田生产方式（TPS），而Scrum又是借鉴TPS，也就是说是从PDCA-TPS-Scrum。
在书中，我还读到一层意思，就是在复杂的环境中，根据环境和反馈，快速判断和调整，要优于对自上而下事无巨细的计划的执行，而这种调整可能只需要一些简单的规则。作者提到他在中洲计算机服务公司工作时，认识了MTI的人工智能教授罗德尼.布鲁克斯，后者正在研究机器人，而且他发明了一个6条腿的机器人，每条腿上分别安装了一个大脑，只给它设定简单的规则：“前进、后退，不要撞到其它腿”，有趣的是，启动后，机器人开始是摇摇摆摆，然后撞到什么东西后，就根据环境建立数据库，让部件自动配合，调整行为，而不是提前设定好行动的路径。而这个和作者在越南接受训练时的原理是一样的，就是通过OODA，从环境中获取数据，采取果断行动，获取反馈，再行动。
2 为什么Scrum会有效？
为什么Scrum可以提高效率？书中提到了很多原因，其中也包括我们在《精益工作法》:去掉不创造价值环节中提到的流动，可视化等，下面我选择我认为启发最大的3个：OODA循环，聚焦团队，冲刺。
2.1 OODA
OODA是作者在空军服役期间学到的一种训练方式，下面这张图很好的展示了OODA的基本思路：
① 观察（Observe）
观察指的是我们要看清外部的情形，听起来容易做起来难，因为观察意味着要摆脱自身的局限性，看到周围所有情况的变化，而不仅仅是从自身的角度去看。
②导向（Orient）
导向指的是，在观察到的环境的情况下，你能够采取哪些行动的方向。它不仅取决于你所处的位置，还跟你看到什么有关系，你能够给自己创造出多少行动的选项？这受到了多重因素影响，如基因遗传，文化传统和先前经验等。
③决定（Decide）
观察和导向结合在一起就产生了决定，也就是说我们准备采取什么样的行动。
④行动（Act）
接下来就是实际的行动，这个行动会产生新的结果，这个结果可以用于让我们的客户进行判断，根据反馈进行下一轮的循环。
Scrum要求团队定期进出一定新成果，就是为了看一看这些新成果能够产生多少价值？人们的反应如何？这些反馈就可以调整在下一个冲程的阶段，从而建立一个循环的反馈回路，有助于使得整个的活动是往着价值增值方向前进。
而这个循环的迭代，就类似于前面的机器人依据简单的原则，形成自适应进化的过程。
2.2聚焦团队
团队力量大于个人，书中提到，个人之间产生的价值差距最多10倍，而不同团队的产出可能相差成百上千。关于Scrum方法的中团队，有两个重要启发：团队规模和信息饱和度。
①团队规模
团队一般7个人比较好，可以多2个，或者少2个。如果超过9个，效率反而下降，为什么？这和如何突破我们处理信息的瓶颈——7±2？提到的人的处理能力有关，本书也引用George Miiler 1956年的研究，人们的信息处理带宽和短期记忆都和神奇的数字7有关，而后来研究表明，这个研究是错的，因为2001年密苏里大学的Nelson Cowan表明，人的短期记忆不是7样，而是4样。
②沟通饱和度
书中提到了一个案例，在20世纪90，贝尔实验室的吉姆.考尼斯应邀前往宝蓝软件公司研究该公司产品开发中的问题，他发现有个团队，8个程序员花了31周总共完成的1万多行程序代码，也就意味着他每个成员每个星期平均写了1000行代码，这样的记录远远超过了其它的团队，他很好奇他们什么之做到。后来通过详细跟踪不同团队内部之间的沟通情况以及信息流向，从中找出一个非常重要的指标——沟通饱和度。
而在Scrum中共享工作清单和每日立会，刚好能很大程度提高沟通饱和度。而这和我一周的远程办公体验也相符，因为远程，我们通过TAPD共享了每个人的工作内容，而且每个人都可以看到对方的工作，并通过早会（早上半小时沟通一天工作）和晚报（晚上半小时，沟通一天进展），每个人更加知道如何去获取支持，和帮助别人。
为什么这样有效？我想到了系统！在系统架构1：系统架构-对系统的抽象和分析，我们提到系统的一个重要特征是涌现，而这种涌现源于系统中要素的连接和互动。团队是个系统，团队的产出就取决团队成员之间的互动，而沟通饱和度越高，就意味着这种互动越强，自然协作更容易促成，效率自然就高。
2.3 冲刺
冲刺指的是在一个固定的周期内（通常是1~2周），围绕着一个可交付的成果，大家一起努力。作者是受到麻省理工学院媒体实验室启发，这个实验室涌现了很多创新成果，包括机器人，电子墨水，新型的音频解码等。他们产出高的，其中一个重要的规则是：每三个星期每个团队必须公开展示自己的成果，如果这个成果既不实用也不酷，它就会被就会被毙掉，通过这样的方式，学生们就不断地做出新东西，更重要的是，通过展示可以获得反馈的意见。
可以设想，如果一个项目，你在完工之前你得不到任何反馈，甚至要得好几个月，甚至几年才能得到反馈，如果方向错了，调整的代价会很高。如果能够把这个反馈的时间调整到以月，甚至以周为单位，这样就能够快速调整，和OODA形成配合。
3 如何实施？
前面介绍了什么是Scrum以及它的有效的原因。我们具体如何实施呢？作者在书中给出了很多建议，并且在最后也给出了10条，为了便于记忆，我把总结成6条，同时也穿插一些我在工作中的实际体验。
3.1 选人
Scrum的人是包括三类：
①产品负责人，也就是必须知道自己的客户和需求是什么，团队需要做什么，不做什么，需要完成什么产品或取得什么成果？并全面考虑风险与回报；
②团队。真正完成产品和成果的人，是实际落地的人；
③Scrum主管。就是负责培训成员，并确保Scrum得到正确应用的人，帮助团队消除障碍。
在实际工作中，我理解①和③很多是兼任的，且同时也是②中的成员。
3.2 拟定和评估清单
虽然前面提到瀑布式开发的不足，但这也并不意味着Scrum开发是完全不需要计划，Scrum强调的是不能盲目遵循规划。如果没有规划，只会陷入短期的行动中，只不过Scrum强调的是要在开始拟定完成产品和成果，所需要完成所有事项清单，而且这个清单贯穿项目的从头到尾，相当于一个产品研发的"路线图"，无论任何时间，如果想要知道一个团队所有事项，这个清单是唯一具有参考的依据，而且它只有一份，但是会在执行中动态调整。
而调整的前提就是要评估优先级，书中提到了一个三环模型，评估待办清单的优先级，他推荐优先去做能够快速带来80%价值的那些20%的事情。此外还需要评估事项的完成难度，不是用所需小时数，因为人们很难精准评估，而是要用相对难度，比如高、中、低，更好的方式，作者推荐用斐波拉契数列（1,2,3,5,8,13……）去衡量难度点数，并用所有条目的点数相加衡量团队的工作量。
在我的工作中，我们是用开发计划进行长期的规划（整个项目周期），用OKR进行中期的规划（1~3个月）。
3.3 冲刺规划会
冲刺规划会也就是在一个冲刺周期内（通常是一周），我们团队需要完成的任务数，而且是按优先级来的。在目前的工作中，我们是每周一上午，用2-3小时确定我们一周要解决的问题、达成的结果和需要做的事情。
3.4 工作透明化
工作的透明化，看板其实是一个很好的方式，其中表明你的待办事项、进行中和已完成的事项。目前有很多工具都能够满足这一点，比如我们现在所使用的TAPD，还有Teambition，它能够让每一个成员看到彼此之间的工作条目以及进展，很好符合了“沟通饱和度”的概念。
3.5 每日立会
这是Scrum的一个重要活力源，每天早上15分钟，团队成员沟通要每日工作，书中给出的三个建议问题是：
①你昨天做了什么帮助团队完成冲刺？
②今天你打算做什么来帮助团队完成冲刺？
③什么因素阻碍了团队的前进之路？
而我们现在是通过早会（今天要做什么？需要什么支持）和晚报（今天有什么进展？）来进行每日的例会，而且相对在办公室，我发现通过远程虚拟会议，更容易组织。
3.6 展示和回顾
展示就是冲刺结束，看看达成了什么结果，解决了什么问题。要展示给用户看，从而获取反馈，支持下一次改善。
回顾，就是我们反思冲刺中，哪些做的比较好？哪些是比较顺利的？哪些事情应该做的更好？在下一个阶段当中就可以做出改善。非常重要一点，不要将团队中某一个人当做是责备对象，而是要把注意力放在流程上，认真分析为什么会发生这样的事情？当时忽略了什么？怎么样才能够加快工作进度？作为一个团队，大家可能需要对自己的流程和结果负责，集思广益，共同去解决解决之道，这一点非常重要。
4 总结
以上就是结合工作，和你分享阅读《敏捷革命》的一些感悟，敏捷革命的一些关键内容主要包括如下几点：
① Scrum(敏捷开发)软件行业，也适用于其它的行业，核心是快速交付可用产品/结果，获得反馈，进行调整；
②它的核心理念源于空中训练的OODA循环和精益思想；
③Scrum团队最好控制在3~9人，并利用工作透明化、每日立会等方式，提升“沟通饱和度”；
④Scrum冲刺周期最好固定（通常1周），并通过展示和回顾，持续提升效率。
