敏捷爽畅(Agile Fluency)之道

前言

       11月初，参加了Martin Fowler在北京的技术演讲，聆听了大师关于敏捷的一些看法，在谈到团队对敏捷掌握的熟练度方面，提出了星级的概念，有点类似的CMMI的成熟度模型。其中提到的很多观点，我个人非常有共鸣。回来后，就迫不及待的细读了一遍Martin官网的这篇文章。我们知道业界有很多的敏捷软件开发技术，这篇文章很好的为我们做了一个总结，而且将这些技术按照不同的星级进行了分类。这对走在敏捷路上的朋友们，尤其是对一些应用敏捷但实际并没有看到敏捷带来的好处的团队，还是很有帮助的。这里翻译出来，和大家一起分享，如有翻译不当之处，欢迎大家指正。

Martin亲笔签名书

概述

 

     1999年，在”轻量方法论” (Lightweight method) 的旗帜下，一些软件开发方法论像Scrum,极限编程 (Extreme Programming) 和Crystal展露出了头角。那些寻找更快、更简单、更高效工作方法的程序员们是主要的推动力量。在后来的10来年里，敏捷不断成长。在2001年，”轻量方法论”社区的业界领袖们在美国犹他州的会议正式定义了”敏捷” 并且创建了敏捷宣言。在2005年，敏捷和极限编程的阵营与敏捷开发大会合并在一起形成了敏捷联盟的 “Big” 敏捷大会。

       敏捷社区也经历了从早期以程序员为中心，极限编程为主，到21世纪初期几年更包容的方式，到最近几年的项目管理和Scrum为主。曾经是早期草根程序员发起的敏捷方法论如今已经被业界广为接受和应用。

        但敏捷的成长并不是一帆风顺的。曾经是敏捷推动者的程序员们确发现”敏捷”的管理方法变得臃肿和低效率。很多敏捷社区的知名人士也在发表文章指出敏捷的问题，像MartinFowler的 无力的敏捷(Flaccid Scrum, 2009)。企业、组织的负责人也开始抱怨说应用敏捷并没有给我们带来预期的好处。

        过去12年里，我们一直领导和帮助团队过渡到敏捷上来，我们学到很多关于如何去真正获得敏捷所带给我们的好处。这篇文章将讨论一个敏捷爽畅模型来帮助你真正获得敏捷所带来的好处。这个模型可以分为四个阶段，每个阶段有其对应的收益、以及适用它所需要的成本，还有关键度量标准。

敏捷爽畅(Agile Fluency)

       根据我们的观察，敏捷团队一般会经历四个不同的爽畅阶段。爽畅是说一个团队如何在面临压力的情况下开发软件。大家在参加敏捷的培训时，在足够时间内集中精力做一件事都不是问题，每个人都会有自己的一套方式方法。然而，真正的爽畅是指即使你被某些无法预期的事情所干扰，仍能坚持一个熟练、行之有效的方式方法。

对于敏捷而言，我们会更多 的考虑团队爽畅，而不是个人或组织的爽畅。 敏捷开发真正意义在于团队的努力。敏捷开发在组织范围内的成功将取决于组织内团队的敏捷爽畅。

        团队敏捷爽畅不仅取决于团队内个人的能力，还取决于管理结构、关系、组织文化等等。不要因为你的团队敏捷爽畅性低而责怪团队内的个人，也不要假定一个高技能的团队成员就能保证团队敏捷的高爽畅性。

团队会经历四个敏捷爽畅阶段，我们用不同的星级来表示不同的阶段。每一个星级包含前面星级全部的敏捷爽畅性。一个团队完全可以只在某一个特定星级上保持敏捷爽畅，但我们看到团队在敏捷爽畅性的成长是在这些的阶段中顺序进行的。

原图出处 http://martinfowler.com/articles/agile-fluency-diagram.pdf

       每个星级带来特定的好处，同时，做出改变，以适用不同的星级也是一个挑战。在你通读这篇文章时，请记得每个爽畅性等级带来其对应的好处。因为达到的敏捷爽畅性级别越高，需要的投入越大，那就需要我们仔细考虑一个低级别的敏捷爽畅性是否更适合我们目前所在的组织？

实践，实践

       爽畅性更贴切的说是一种习惯，而不是一种技能。虽然培训可以交给我们相应的知识，但达到真正的得心应手，做到心中有敏捷，需要大量的练习。在我们的经验中，达到一星级的敏捷爽畅性需要两到六个月的时间，我们接触到的团队中，有大约45%认为他们达到了一星级的敏捷爽畅。

       达到二星级的敏捷爽畅需要在一星级的基础上再花费3到24个月，这取决于你的代码中有多少技术债务。我们接触的团队中，有大约35%达到了这个级别。

       达到三星的团队就更少了。有大约5%的团队表示他们达到了这个级别。我们听说过一些团队花费一年到五年不等的时间来达到这个级别的爽畅。 延误的主要原因来自于组织内部的阻力。

       即使在已经达到三星级别的团队中，也只有很少的团队说他们在努力达到四星级别的爽畅。除了一些只有一个团队的组织外，我们只知道很少的公司达到了这个级别的爽畅。

有捷径吗？

 

       我们曾看到过一些团队，当他们使用当前所处星级技术的同时也尝试使用高星级涉及的技术，那他们成长的速度会很快。所以，最好的方式是在最开始就选择好最适合团队的敏捷爽畅级别，并尝试使用该目标敏捷爽畅级别涉及的技术。换句话说，如果你的目标是达到敏捷爽畅的三星级别，那么从一开始就使用三星级所需要的技术。虽然你的团队一次只能完成一个级别，但一起使用（前）三个星级的所有技术可以使团队更快速的成长。

       适合团队的敏捷爽畅星级取决于团队所在的组织。两星或三星一般是最好的发展目标。三星级的敏捷爽畅性能带来更大的好处，但他需要对团队所在的组织在结构和文化上做出调整。而这些调整需要在组织内部达成共识、而且需要大量的社会成本(译者注：指团队或个人拥有的诸如信任、人际关系网之类的人际关系的"储备")，而这在较小规模的组织更容易做到。对于在更大的、更官僚的组织内的团队，两星级的敏捷爽畅性可能会是比较好的选择。

失去敏捷爽畅能力

      很少有已经具备敏捷爽畅性的团队再失去这个能力。以我们的经验，有两种情况最有可能让团队失去敏捷爽畅性。第一种，也是最常见的就是新的管理层认为敏捷不再适合他们的管理理念。没有了组织的支持、丧失了继续从事敏捷方式方法实践的能力，团队的敏捷爽畅性会很快丧失。同时可能发生的事情就是不满的团队成员的离职也会丢失原来积累的技术经验。

       人员流动性是另一个导致敏捷爽畅性丢失的主要原因。一个团队如果获得或失去太多的成员，那么就很难保存下原来积累的技术经验。这个问题在一些为每个项目组建临时团队，而不是给将项目分配给一个固定的团队的组织内部尤为突出。

一星团队创造商业价值(Business Value)

• 收益： 更深入的了解团队的工作；有能力对团队的工作作出调整
• 投入：团队建设和工作流程的设计
• 主要衡量指标：团队能定期从商业价值的角度报告进度。

        达到一星级敏捷爽畅的团队能够将精力集中在创造商业价值上，而不是从技术角度去做计划，比如软件层面（译者注：这里并不是说从技术角度考虑的问题都是错的，而是强调换到客户的视角去看问题，用客户的语言来描述问题。比如说我们想给当前系统引入Cluster，以实现Failover 和Loadbalancing 的功能。从技术上来说，我们可能会说增加几个节点，建立几个ManagedServer Instance等等，但这些概念对于用户来说是很难理解的。如果我们从客户角度来描述问题比如增加系统的可用性，使得可用时间百分比由x%提升到y%。系统在峰值时段的吞吐量能提高多少，原来一笔业务处理需要花费多少时间，改进后是多少，能带来多少利润增长等等。还有一种情况就是开发人员感觉该软件代码需要重构，以此换来更好的维护性和可读性，代码更安全，那么在开发人员的角度，这个任务优先级可能很高，但如果客户当前有其他功能需要实施，并认为这些待实施的功能很关键，那么开发人员认为的优先级高的工作就不需要去做，起码当下的优先级不高。）。一星级团队在做计划时总是从发起人，客户，和用户能够在团队开发的软件中看到的价值入手，一般都会附带用户的场景。

       Scrum （译者注：Scrum 是一个迭代、增量的软件开发框架。它把开发周期定义为Sprint，每次迭代周期不超过一个月。客户可以在 Scrum中随时改变自己的想法或需求，这在传统软件开发模式中很难满足。）和Kanban  （译者注：Kanban是一个管理产品生产的方法，保持持续的交付的情况下而不会使开发团队超负荷运作。Kanban通过定义更好的团队工作流程，鼓励持续协作和积极地、不断的学习和改进。）就是两个达到敏捷一星级爽畅度的团队使用的方法。除了用户场景外，一般经常使用的技术还包括backlog （待办任务集）, retrospectives ( 回顾), iterations(迭代)，Sprint ,或Kanban 面板(Kanban Board. 译者注： kanban方法论中的一种工具，可以理解为敏捷中团队作战室中的一块黑板，上面以便签、磁铁片、水彩笔等等方式，记录了当前软件开发中的进度和计划情况。比较典型的Board会包含 Backlog、Ready、Testing、Approval、Done 几列)。

这个星级的团队持续关注创造价值。该星级所带来的好处 包括但不限于

• 透明(Transparency)：管理层知道团队何时在做错误的事情，或者工作没有进展，从而有能力进行积极干预。
• 一致(Alignment): 团队通过合作展开工作，减少误解和任何知识交接所带来的延误。

       一星级团队会定期地从商业价值的角度报告他们的工作和进展情况，除此之外，团队还有很多你能看到的东西能表明他们达到了这个级别，但这个是最简单和直接的指标来衡量团队是否已经达到了这个级别的敏捷爽畅。如果你还没有得到一个定期的商业价值报告，或者这个报告并没有反映这个团队当前的工作重心，那么这个团队还没有达到这个级别所期望的爽畅性。

       为了达到这个级别，团队必须学习和实践一些在Scrum和Kanban中需要的技术。这些技术并不困难。主要的挑战在于团队文化的转变。团队成员必须要学会在从商业价值的角度去做计划，而不是纯粹从技术角度出发。他们还要尝试去为整个团队的成功承担责任而不是只从个人的贡献出发。

       投入/产出平衡:  一般要花费两到六个月的实践才能从一个着眼个人贡献的团队转换为一个合作的，以团队为核心的工作方式。你可能需要花时间寻找具有团队所需要的技能和背景的成员，而且这些成员还要愿意在一起工作。你还需要提供指导或者寻找一个ScrumMaster来帮助团队学习怎么样克服前进中的障碍并将精力放在商业价值上面。在业务优先级和客户价值信息方面，组织也要给与团队更多的关注。

        这样一来，你可以更了解团队现在在做什么，并且能够指导团队把精力放在产生80%价值的20%的工作上面。

两星团队 紧跟市场节奏进行产品交付

• 收益： 低缺陷率和高生产率
• 投入：在提高技术能力的同时，可能影响到生产力
• 主要衡量指标：产品交付能适应市场节奏

       达到两星级的团队不仅要关注于商业价值，他们也意识到当市场需要的时候进行产品交付的价值。这就叫做 “紧跟市场节奏进行产品交付”。两星团队区别于一星团队的地方不仅在于他们有能力进行产品交付，更重要的事他们有能力随时进行产品交付。

       极限编程是两星级团队通常使用的一种敏捷方法。 它经常与Scrum或Kanban方法一起使用。有用的技术包括持续集成(ContinuousIntegration)、测试驱动(test-driven development)、结对编程(pair programming)，和集体所有制（CollectiveOwnership. 译者注：整个团队集体拥有产品、项目计划、设计、代码、和测试。每个团队成员有责任并且有能力对产品的每一部分做改善，同时寻找任何能更快发布商业价值的契机）。

 

达到这个星级的团队能够持续地可预见地交付商业价值。该星级所带来的好处 包括但不限于

• 透明 (Transparency )： 快速的从概念到产品交付周期能够在尽早地发现系统缺陷。
• 一致(Alignment)：较高的技术品质和经常的产品交付带来高涨的士气和更高的工作效率。

       除了一星级团队持续发布业务价值的报告的衡量指标外，对于二星级团队，其核心衡量指标是紧跟市场节奏进行产品交付的能力。如果你不能持续获得低缺陷率的产品，随时根据市场需要进行产品发布，那么你的团队还需要更多的实践。

       这个级别需要掌握的技能比较多，有许多技术工具需要学习。有一些，例如 测试驱动开发(test driven development)，经常是需要 “花一点时间去学习，用一生时间去掌握”。为了达到两星级的敏捷爽畅性，需要学习和实践极限编程、软件匠艺 (SoftwareCraftsmanship. 译者注：软件匠艺是指软件开发方法，它强调软件开发人员的编码能力。在它看来，开发人员才是大型项目成功的关键。强调高质量的软件并不是简单的”制造”出来的，而是被一些为自己的工作所骄傲、追求卓越的软件工匠们创造的)，和DevOps (译者注：一种软件开发方法，强调软件开发人员与IT运营人员的沟通、合作、和集成。组织内部，在采用敏捷开发方法时，往往只是局限在各自的部门内部，比如Dev、QA、IT Operations，部门之间没有一个跨部门的集成过程，DevOps 提倡一套注重部门间沟通、协调的方法和流程。)这些方法论中所包含的技术，对于敏捷软件质量大师们的发起的技术也要多加关注，学习。虽然许多技术的出现已经有一段时间了，但它们并没有被广泛地传播和使用，所以达到这个级别的挑战在于将所有的团队成员带到一个较高的标准上。集体所有制，结对编程，和团队作战室(译者注：一个敏捷团队专有的工作室，不与其他团队共享)都是比较有用的方式来帮助团队成员了解项目整体的最新情况和进展。

       投入/产出 平衡:  将团队的技能提高到该星级别需要很大的时间和精力的投入。培训课程能够将概念性的东西介绍给大家，但学员们很难将课程中的练习与自己实际的工作联系起来。在很多情况下，真正的敏捷爽畅性需要找一个资深的敏捷开发人员来全程指导现实世界中的项目团队。另外，团队在学习该星级所需的新技能和偿还技术债务的时候，生产效率会出现下滑。

       尽管存在大量的投入，这个级别所带了的好处也是巨大的。两星团队能够生产低缺陷率的软件并保持技术债务在较低的水平。这就意味着他们有更多的时间来发布新的功能。在达到这个级别前，偿还技术债务和收益真正出现前都是需要时间的，但一旦做到了，你将看到更高质量的软件和大大改善的响应能力(译者注：从发现市场需求到产品交付的周期大大缩短)。

三星级团队 优化团队价值

 

• 好处： 更高商业价值的交付和更好的产品决定。
• 投入：扩展社会成本(译者注：指团队或个人拥有的诸如信任、人际关系网之类的人际关系的"储备" )将业务专家融入到团队中来。
• 主要衡量指标：团队提供具体的商业(Business)衡量指标

 

        三星级的团队能够为你的投入产出最可能多的价值。他们理解市场真正需要什么，你的业务需求是什么，还有就是如何满足这些需求。或者，如同在一个初创企业/环境中，他们知道什么是需要学习的，如何着手去学习。

        大部分敏捷的方法都是面向一星和二星级别。但  精益创业(LeanStartup) 就是一个适合三星级的例子。它特别适用于新产品的开发。来自于精益软件开发(Lean Software Development) (与精益创业没有关系) 的想法同样很有帮助。敏捷章程(Agile chartering), 嵌入产品管理团队 (embeddedproduct management teams), 客户发现 (customer discovery), 和 适应性计划 (adaptiveplanning) 都是三星团队所使用的技术。

除了一星、二星所带来的好处外，三星团队所带来的好处包括

• 透明(Transparency)：团队使用具体的商业衡量指标来报告工作结果。例如RoI投资回报率，每个雇员产出的净利润和客户满意度
• 一致(Alignment)：团队和组织之间的相互信任使得他们之间的谈判协商更快速有效。团队所具有的广泛的专业知识面加速了决策制定，消除了知识的转移交接(译者注：向其他团队或组织的进行知识学习过程)。

 

       除了前面两个星级的核心衡量指标外，三星团队的核心衡量指标是在工作汇报中使用商业指标。如果你的团队没有把工作重心放在这些商业指标上，或者说他们的产出少于机会成本，那么他们还没有真正达到这个级别。（换句话说，当达到三星级时，团队可以控制调整项目的发展方向或者当发现项目并没有产生足够价值的情况下取消项目）

       要达到三星级，需要团队吸纳业务专家作为全职团队成员。虽然你能够通过雇佣新成员或者培训现有人员来使团队获得业务专业知识，但将现有的已经了解你的业务优先级和约束的人员加入到团队中往往是更有效。这种人员可以是产品开发人员、产品经理、业务分析人员，或者是来自市场运作，销售，也可能是质量保证的人员。将这些人员的专家意见纳入到团队中作为全职人员，往往需要高层的允许。

       三星团队在产品交付方面也需要组织的支持。这需要团队经理与组织内部其他部门进行协调，有时在跨职能的管理团队中，要找到团队绩效的瓶颈，并把它解决。在高效的敏捷环境中，跨职能，自我组织/管理(self-organizing)的团队(译者注：团队成员有高度的积极性，他们朝着一个目标共同努力，一起工作。他们有权利也有能力进行决策，并乐意为不断变化的环境/需求而进行改变)负责对资金的花费和当前工作重点做出决定。工作在这种环境下，团队经理在工作如何进行改变和适应方面还需要辅导。

       投入/产出平衡：上面提到的两个变化对现有的组织结构提出了挑战，导致这些变化有时候很难或者根本不可能去实施。达到三星的敏捷流畅性通常需要几年的时间，这并不是因为所需技能的原因，而是因为组织内的管理层在做出改变之前必须学着去信任团队和团队使用敏捷的工作方式，而恰恰这些改变会影响其在组织内的权利和对组织的控制，同时还有其已经熟悉的工作方式。要做出改变，管理层需要坚信该星级所带来的价值，团队管理者往往需要利用他们的“社会成本”来实现这个转变。

       作为交换，你可以有预见性的通过完成具有更高价值的产品交付来满足业务目标和创建新的商业机会，同时，在制定好的产品决策方面的团队自身能力和和专业知识也会形成和加强。

 

四星团队为优化系统做贡献

 

• 好处：与组织目标保持一致，协同效应（译者注：简单来说就是1+1>2，这里应该指组织内部门之间的协作产生的积极效应远大于单个团队努力的结果）。
• 投入：建立企业文化的投入很大；需要发明新的方法实践。
• 主要衡量指标：团队能够汇报他们的行为如何影响整个组织。

       四星级的团队为企业的整体成功做贡献。团队成员理解组织的优先级和市场方向。四星级的团队往往会为了支持一个对公司业务成功起关键作用的产品而牺牲自己的利益。他们和其他团队合作，和管理者合作去优化组织内整体的价值体系。

       虽然在精益软件开发中(LeanSoftware Development)对于四星级团队的理想目标有描述，但我们还不知道任何能够讲清楚如何达到四星级的方法。我们知道的团队，不管是试图向这个级别努力，还是在正在达到，四星级的敏捷爽畅性对于他们来说都是在bleedingedge(这里特指对于适用四星级的技术方法，业界还没有一个共识说那些是好的，那些不是，应用这些技术，都是在冒险。成功了，则奖赏丰厚，那失败了，代价也是很大的)。团队会采用一些从高级管理理论中来的想法和一些有创新性的产品开发方法。一些技术包含敏捷组合管理(AgilePortfolio Management), 系统思考(SystemThinking),价值流分析(ValueStream Analysis),全系统规划(WholeSystem Planning)，完整团队(Intactteams)，开卷管理(OpenBook Management), 和激进的自我管理/组织（Radicalself-organization）。

除了前面几个星级所带来的好处外，四星级团队所获得的好处包括

• 透明(Transparency)：团队能够结合组织其他新业务或业务探索来描述自己的工作，能做到产品之间互相平衡。
• 一致(Alignment)：团队与其他团队或组织内其他部门就观点、所处情况、和创新广泛交流，互相学习。

      四星级团队的核心衡量标准集中在团队是否理解整个系统并且在报告中阐明其行动对整个企业的影响。如果你的团队不能理解如果工作才能为组织的整体价值流做贡献，那么他们还没有达到该星级要求的为整体系统的成功而进行优化的程度。

      到现在为止，我们更多看到四星级的敏捷爽畅在只有一个团队的初创企业中发生，这种情况本身与三星级的爽畅性差别不大。对于一个信任程度高，沟通成本低，和业务信息广泛共享的组织内，达到四星级会更容易些。

      小一些的组织能够从一开始就形成一种跨职能、跨级别支持敏捷方法的组织文化。这样的组织有利于完整团队 （IntactTeam）的形成，在那里工作会主动来找团队，而不是团队不停的变化来适应工作。在完整团队的氛围中，团队成员很容易表现出高效率和更全面的四星级敏捷流畅性。

我们还没有看到过任何在大的组织中的团队达到四星级敏捷流畅性。这可能是因为组织文化改变所带来的阻力或者是敏捷方法论本身还年轻，随着敏捷的成长，这样的团队最终会出现。

       投入/产出平衡：达到四星级不仅需要改变企业文化从而专注于全局，还需要经常尝试较新的敏捷实践和发明新的方法将系统思考(Systemthinking)应用于敏捷，应用新的，未被公众认可的敏捷实践是需要承担风险的。在企业内所有部门的人都需要学习新的思维方式，改变已经形成的惯有的行为，并且去学习发现新敏捷实践的价值。但如果已经创建了多个具有三星级敏捷爽畅性的团队，并为他们提供支持，那么离这个级别就不远了。

       对于大部分的组织来说，四星级的敏捷爽畅性可能会作为一个努力目标来存在，起码是在三星级敏捷爽畅性即将达成之前。但，对于已经强调精益原则(LeanPrinciples)和系统思考(Systemthinking)的组织来说，或者对于一些注重于鼓励奇思妙想和创新流程的企业，四星级的流畅性是一个大胆的挑战和一个诱人的谜题去迎接。通过对敏捷流畅性的不懈追求，你会拥有不单单着眼自身产品，更重要的是着眼你的整体业务的团队。

结论

       在我们和敏捷团队和敏捷组织共事的过程中，我们看到团队从对敏捷的理解和团队所在企业所得到的好处方面来看，在遵循一个典型的成长过程。我们把这个成长过程分为敏捷爽畅性的四个阶段/星级,每个阶段都具有独特的收益，当然还有适用它所带来的挑战。

       第一个阶段，或者叫一星级阶段，需要团队学着一起去创造业务价值，而不是单纯的完成技术任务。作为回报，组织能更好的理解团队的工作，并且有更多的机会积极的影响团队工作。这个星级反映了敏捷的基本原则。

       达到二星级阶段需要团队去学习大量的开发技能。这个星级反映了敏捷的可持续发展性。这个星级中，技术的学习过程往往不是简单的事情，可能需要会从一些最基本的东西来学，这对于团队成员，尤其是高级的开发人员往往是很让人沮丧的。但随着实践经验的积累和组织的支持，团队能够获得紧跟市场来进行低缺陷产品的发布，这样一来，企业投入软件开发的成本就可能会带来更多的回报。

       三星代表了敏捷的希望：面对市场的不断变化，整个团队可以一起共同负责产出对于你的投入所能得到的最好产品。达到这个星级意味着业务专家必须要作为全职人员加入团队。这个星级所带来的对组织结构的改变需要时间和精力，但得到的收获就是团队服务于你的业务的能力提高了。

       四星级代表敏捷的未来：四星级团队与其它团队合作去从整个组织层面优化产出的业务价值。达到这个星级需要全系统思考(Whole-systemthinking)和敢于试验冒险的意愿。

      所有这些星级的达成都会带来收益，并且每个星级都可能是一些团队的最佳站位。我们需要选择一个最适应自身条件的星级。通常来说，三星级适合小的组织，二星级适合大的组织。无论你的目标是哪个星级，一旦你确定了最适合你团队的星级，请从一开始就实践所有达成你目标星级的所有技术。

      我们一次次的看到团队在这些星级中成长。通过分享我们的经验，希望你能更多，更好的理解敏捷所能提供的可能性，还有理解它所带来的挑战。希望你和你的团队获得更大的敏捷爽畅，获得更大的成功。