玩转敏捷系列之「敏捷山头知几许」

敏捷已经不是一个新鲜的话题，业内关于敏捷的交流及培训也是五花八门种类繁多，对于新人来说有些显得信息过于丰富无从下手。本文将结合敏捷的历史来讲一讲敏捷的门派，看看到底有哪些山头以及这些山头都是唱的什么山歌。能力有限，不敢妄加评判，所以本文讲述介绍为主，至于哪个更好，建议因地制宜根据团队具体情况选择最适合的。

一、敏捷的诞生

      首先科普一下，敏捷宣言http://agilemanifesto.org/，支持多种文字显示，包括敏捷四条价值观和十二条原则等。2001年雷鸟雪场，经过17位当时著名的软件开发专家两天会议商讨，最终提出Agile敏捷这个词概念，并签署宣言。

在介绍敏捷各山头之前有必要纠正一些关于敏捷的常见误会。

    (一)错误的以为敏捷就是scrum。其实正确的翻译，敏捷指的是Agile。scrum是敏捷中的一个分支。

    (二)新接触敏捷，往往容易陷入方法论，以为学会了表面上这些方法工具，就已经掌握了敏捷的套路，可以依葫芦画瓢去实践。但笔者认为敏捷更适合被理解为一种思想或者一种精神，而不是仅仅作为一个套路工具去使用。最可怕的是，自以为学会了所谓的敏捷方法套路却不知道敏捷的价值观和原则，沉迷在危险的自high中。

    (三)陷入孰优孰劣的纠结中甚至山头门派之争，却忘记了背后的初衷和原因。

二、敏捷方法介绍

      接下来我们重点介绍下SCRUM和KANBAN，然后将挑几个敏捷山头做简要介绍，其他的山头则一笔带过了。

SCRUM。

      把初识敏捷比作是推开山门走出去看世界的话，那么这推开山门映入眼帘的第一座大山必当属SCRUM无疑了。对于初学敏捷同仁，笔者建议至少去参加一下CSM等的课程认证培训，它适合作为探索敏捷之旅起步阶段的必经之路。SCRUM创始人Jeff Sutherland和Ken Schwaber，词语来源于橄榄球术语，争球。用几个词来形容SCRUM，快速迭代、小步快跑、积极主动等。

      SCRUM里最重要的三个角色，SM、PO、SCRUM TEAM。SM是整个小组负责人，沟通引导等，但绝对不等于传统意义上的项目经理，千万不要误会。PO 是产品负责人，交待清楚交付产物交付日期交付标准等，是对产品成果有认可与否权利的人。SCRUM TEAM则是具体执行者，人数5-10人，不建议超过12人。最重要的几个会议，每日站会、计划会、回顾会、评审会议-交付验收等。另外还有产品待办事项列表、冲刺列表、燃尽图等。

在网易杭研项目管理部提供的系统解决方案中，jira工具支持SCRUM方案实行。

      笔者曾经部队服役，以亲身经历来看，关于SCRUM的小团队组织形式还有另外一种团队跟它神似，那就是部队的班一级单位组织形式。在这个讲究高效的组织里，几乎世界通用的规矩，一个战斗集体最小建制集合就是一个班，一个班一般不会超过12个人，并且也包括类似SM、PO和SCRUM TEAM的角色，分别是班长、副班长、战士。而且也有类似的会议形式，有计划，诸事皆有回顾小结的习惯（常用语：稍息、立正，讲一下）等，绝对严格执行每日站会，并且绝对高效和时间可控，相对范围内有高度的自主和主观能动性。总之相似点非常多，有各种有趣的神似巧合，妙不可言。

KANBAN。

      往旁边走一走，看下KANBAN这座大山。

      看板方法，由David Anderson创立，受启发于丰田生产方式、约束理论（TOC）并结合其他多个领域的知识而成。在看板方法里也能看到精益的影子，不断改善，持续的系统性变更优化生产系统。常用词汇有，拉动、在制品、前置时间、阻塞等。

      看板方法有一条比较重要的可参考，强调渐进式的变革，主要改变在制品数量、上下游衔接、交互方式等。从David Anderson的书名中就可以看出端倪《KANBAN-Successful Evolutionary Change for Your Technology Business》中文名《看板方法-科技企业渐进变革成功之道》。看板方法的实施包括，价值流映射、使用看板进行协调、建立交付节奏、建立输入节奏、设置在制品限额、建立服务水平协议、度量和管理报告、使用两层系统扩展看板、运营回顾和启动看板变更等部分。当然最终还是少不了持续改进。在网易杭研项目管理部提供的系统解决方案中，jira工具同样支持看板方案实行。

      看板系统的首要目标，最小阻力启动变革。目标1优化现有流程。次要目标，目标2高质量交付、目标3提升前置时间的可预测性、目标4提升员工满意度、目标5为改善流出富余时间、目标6简化优先级排序、目标7使系统设计及运作透明化、目标8设计能够打造高成熟度组织的流程。

      小福利：非常有幸在Scrum Gathering 2016 China 大会上现场聆听了KANBAN创始人David Anderson的演讲《Kanban-follow your own path agility》，大师风采，历历在目。你可能错过了机会没能亲临现场，没关系，参加网易云课堂同名课程《Scrum Gathering 2016大会》即可如身临其境一般全程参与一番。

XP。

      再继续，有一座瘦高瘦高像是两个人抱在一起的山，XP。

      XP（极限编程）的思想源自 KentBeck和WardCunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈、尊重和勇气。它强调程序设计团队与业务专家之间的紧密协作、面对面的沟通（比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队等。包括结对编程、重构、持续集成、小型发布等。XP里还有一个有意思的点是强调每周40小时工作制度哈。

      远处还有两座肩并肩的山，分别是LeSS和SAFe。

LeSS。

      咱们先看看左边山头，LeSS。LeSS是大规模Scrum的一种模型。Bas Vodde和Craig Larman共同推出。

      Bas Vodde先是在北京诺基亚电信网络业务组延续之前工作经验尝试极限编程，后来到杭州电信产品开发组，接下来开始了两年瀑布式开发但发现对大型产品并不是特别有效，于是他又回到敏捷极限编程上来，同时诺基亚网络尝试组织内部寻找敏捷开发经验的人是否有兴趣领导变革项目。Bas Vodde后来搬到了芬兰又有机会和Craig Larman一内一外在诺基亚电信内部领导一个变革项目。Bas Vodde后来在新加坡创建了传说中的Odd-e，成就另一段佳话，这里就不展开了，感兴趣的朋友可自行了解下。

      LeSS实际上包含了两个框架，一个就叫LeSS，另一个叫LeSS Huge。感兴趣的朋友可阅读《大规模Scrum（LeSS）》一书。

SAFe。

      右边的山头是SAFe，基于大规模的敏捷框架（Scaled Agile Framework）实践，它是企业层面的SCRUM。SAFe创始人是Dean Leffingwell。Linkedin中他的自我介绍提到他已经有四十多年软件行业从业经历了，花了整个职业生涯在帮助软件开发团队实现自己的目标。

      在SAFe中，管理者还有架构师和专家有了一席之地。SAFe是借鉴了精益、敏捷和瀑布流开发方式的细致、重量级的方法。Scrum之后，团队需要给项目和文件添加代码，这需要管理和协调。SAFe有几个概念需要知道，大规模的敏捷火车、SCRUM火车工程师、SCRUM主管等。还有 SAFe 从团队（Team）、计划（Program）和投资组合（Portfolio）三个层面清晰定义了敏捷的框架。感兴趣的读者朋友可以参阅来自王红英和付伟强的《基于大规模的敏捷框架（Scaled Agile Framework）实践》一文，写的非常详细全面。

DAD。

      还有众多山头，咱们挑一座讲下，看起来方方正正的像个框架一般的，DAD。

      “规范敏捷交付（Disciplined Agile Delivery，DAD）是 IBM 提出的一组实践，旨在帮助较大型软件开发团队像较小型团队一样成功实现敏捷开发。DAD 并不只是另一种敏捷方法，它提供了一个混合框架，将来自各种现有的成熟敏捷实践的最佳指南结合在一起。DAD 还通过企业指南为常见的敏捷方法提供了补充。因此，它可帮助具有超过 20 人的项目团队的组织充分利用敏捷开发技术。”-摘自《成功组建规范敏捷交付团队的 5 大技巧》。

DevOps。

      继续往前走，百转千回，柳暗花明又一村，不，是柳暗花明又一座大山，DevOps。DevOps是Development和Operations的组合。

      在认识DevOps研发运维一体化之前，先要知道几个概念，持续集成（Continuous Integration）、持续交付(Continuous Delivery)、持续部署(Continuous deployment)。DevOps是一种文化，一种观念。如果你仅仅想通过招聘一个DevOps编程来搞定DevOps，那么笔者只能对你说Goodluck！ DevOps也不等同于全栈通才。常见误区，一种误区是依赖于敏捷转型以为实现了文化就可以了，还有一种误区是把相关满足配套的工具等部署起来就以为可以玩转DevOps了等。

      DevOps有几个关键点，高度自治的小型团队、可靠的全流程工具布局、监控度量等。有人觉得DevOps太难了，在已经有了一定其他玩法的团队里很难展开，阻碍重重无从下手。笔者认为这也很正常，毕竟，不应该为了DevOps而DevOps，得先弄清楚为什么，为什么需要，真的需要的话这个需要又有多强烈等。后面的就自然而然了，可以用敏捷的思想，小步快跑，多次迭代。

精益-LEAN。

      这是最后一座要瞧的，是一座充满异域风情，你中有我我中有你的一座特殊的山，精益-lean。有的人说精益是敏捷的一部分，有的人说精益和敏捷并列，也有的人说敏捷是精益中的一部分。笔者在本文中不去争论这个，既然都是山头，又何必在意谁是谁的，谁大谁小呢。哪怕有个主峰侧峰，那又如何。

      先说下精益思想，精益思想起源于精益制造，慢慢地精益生产开始演变到精益企业。敏捷基本脱胎于软件相关行业，而精益则是脱胎于制造业，精益牵扯涉及的在企业中会更广更深入一些。精益的一个重要的思想就是通过及时反馈把浪费转化为价值。精益思想的关键出发点在价值，而价值最终只能由客户来确定。精益思想的原则，定义价值、识别价值、价值流动起来、拉动实施、尽善尽美等。精益追求的是可持续的最短前置时间，可持续又涉及质量和成本的合并要求。

      精益软件开发，讲精益思想以一种新的形式呈现，由Mary和Tom夫妇提出。它的几个原则。尊重一线人员、消除浪费、增强学习、尽量延迟决定、嵌入质量、快速交付、整体优化。有必要解释下什么叫尽量延迟决定，因为软件开发通常具有一定的不确定性，基于多种选择的方法能够达成更好的结果，尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。系统越复杂，那么这个系统容纳变化的能力就应该越强，使其能够具备推迟重要以及关键的决定的能力。

其他

      笔者能力水平有限，其他的山头诸如特性驱动开发-FDD/Feature Driven Development、动态系统开发方法，DSDM/Dynamic Systems Development Method、AUP（Agile Unified Process）、探索性测试、测试驱动开发等等，就不一一赘述了。

三、结束语

      我们一起走过了SCRUM、KANBAN、XP、LeSS、SAFe、DAD、DevOps、精益-LEAN等这些敏捷相关的山头。山头虽多，但每个之间又不是那么的绝对孤立存在，相互之间或多或少有一些牵连，或是奇峰峻岭或是山长水远。总之，敏捷这些山头是风光无限好，是值得去探索的。愿各位看官能在敏捷的青山绿水中寻得自己的一片天地一份乐趣。

*文末小福利*-推荐书籍：

关于敏捷：《敏捷教练-如何打造优秀的敏捷团队》、《敏捷回顾-团队优秀到卓越之道》、《看板方法-科技企业渐进变革成功之道》、《看板实战》、《精益思想》、《敏捷软件开发工具-精益开发方法》、《用户故事地图》等。

关于互联网项目管理，网易出品：《网易一千零一夜》。

本文来自网易实践者社区，经作者吕广川授权发布。