敏捷流畅度：找到适合需求的敏捷方式-InfoQ



 写点什么

“从本质上说，所有的模型都是错的，但有些模型还是会起到作用。”这段话来自 George E.P.Box，他是来自美国威斯康星大学的一位统计学家，并且是该大学的“质量与生产力改善中心”的创始人。

坊间一直存在一种说法，即 James Shore 和 Diana Larsen 共同设计了一种敏捷成熟度模型（AMM），它推出了一套敏捷的标准与级别的提议，该提议同时还包括了参与者评估与认证方案的内容。

事实并非如此！原因在于：我们只是在经过实地的测试后，推出了一个专注利益和交换的模型，我们并没有为这个模型定义任何成熟或者不成熟的标签。

大约 3 年以前，我们（James Shore 和我）对于我们之前教授和指导如何在团队工作中吸收敏捷原则与实践的方法与技术进行了一次认真的评审，经过一系列的尝试之后，我们得到了一个模型的草稿。

经过了多位评审者的审查以及持续不断地修正之后，我们认为这个模型已经足够实用，可以将它推广开来了。在 2012 年 8 月，Martin Fowler 在他的个人网站发布了我们的文章“ Your Path through Agile Fluency ”，其中对敏捷流畅度模型进行了描述。

“我们观察到敏捷团队的成长会经历 4 个不同阶段的流畅度，流畅度是指某个团队在面临压力时开发软件的方式。如果有足够的时间待在课堂里，每个人都能做到遵循一系列良好实践，但真正的流畅度是一种有技巧的日常实践，即使当你为其它事分心的时候，这种流畅度也不会离你而去。

对于敏捷来说，我们更关注于团队的流畅度，而不是个人或整个组织的流畅度。敏捷开发从本质上来说是一个团队任务，敏捷能否在整个组织中取得成功，要取决于团队的流畅度。

而团队的流畅度则更多地取决于团队中每个成员的能力，也取决于管理结构、关系、组织的文化等方面。请别误会，这并不是说团队的流畅度低下要归咎于个人，也不是说一个高水平成员的存在就能够保证整个团队的流畅度。

简单的来说，按照我们在多个组织中的观察来看，敏捷团队的敏捷流畅度会通过 4 个不同的阶段演进。我们这样命名这 4 个阶段：关注价值（一星级流畅度）、交付价值（二星级流畅度）、优化价值（三星级流畅度）和优化系统（四星级流畅度）。经验告诉我们，不同的组织在每个阶段似乎已找到了团队与商业需求之间的匹配度。我们也注意到，追求达到二星、三星或四星级流畅度的团队似乎在试图以一种可预测的模式获得流畅度，首先是获取在团队工作中所需的技能、专注于业务与客户价值，随后建立起足够的工程技术知识，根据市场节奏进行交付。

人们问：通住流畅敏捷之路是否是一种成熟度模型？

从那时起，一方面我们从同事中获得的正面反馈让我们非常高兴，另一方面，对于我们创建了一个敏捷成熟度模型的断言又我们非常困扰。对于一个新的成熟度模型的观点各不相同，有批评，也有掌声！我们是否无意中创建了一个成熟度模型呢？你可以想象我们的沮丧，因为这一点从来都不是我们的初衷。

软件开发中最为人熟知的“成熟度模型”（MM）大概是能力成熟度整合模式（CMMI）了，它是 CMM 和其它成熟度模型的一种集成。有些人断言它是一种商业过程改进的框架，甚至是一种建立商业过程改进系统的模型，包括开发、采购和服务等过程。这些人在网站中问道：“如果某个公司对它们的内部商业过程缺乏洞察力和控制力，这个公司又怎能够了解它们做的是否足够好呢？也许等它们发现问题时一切都已经太迟了”。

嗯，或许原因在于：“最值得去做的项目，是那些足以将你的商业过程规模降低整整一个级别的项目。”（DeMarco & Lister，来自 Peopleware）。此外，对于整理后的最佳实践的专注也遭到了抨击，它被认为试图建立一种可以适应所有情况的解决方案。毕竟，在业界不可能存在两个完全类似的开发项目或部门，可以用一种相同的一揽子方案来解决它们的需求。

某一个认证团队（也是各种认证的提倡者）说道：“成熟度是由每一个‘成熟度级别’的奖励所体现的”。我们很怀疑他们是否注意到这种说法有多么荒谬和自私？

综合我们能够找到的所有对成熟度模型的定义，我们认为成熟度模型有以下特点：

专注于流程改进系统
对于行为、实践和过程等指标的“最佳实践”的一种结构化分级
对它的使用包括了对各种比较结果的评估，并且有助于理解这些比较的结果

从定义来看，我们的模型并不是一种成熟度模型。首先，我们并非结构化地按照级别顺序描述好的、更好的、最好的团队，而是对整个流畅之路的每一阶段都同等地进行描述。这个模型并没有对流程改进的评估，而是反映了团队的注意力和组织的投入的调整情况。其次，虽然这个敏捷流畅度模型会对可观察的行为，包括实践和流程进行描述，但我们并不打算将这些观察结果作为事后比较评估的依据。这并非我们的本意，天哪！

我们绝对不想把这个模型作为一个工具，以作为打击某些团队“缺乏成熟度”的理由，而是希望把它作用一种技术，让它能够设立和实现专属于你的团队的前进动力，无论你的团队当前处于什么状况，它们都是最适合于你的目标。

找到你的目标

在维也纳举办的 XP2013 大会上，Diana 说道：“不能说因为威尼斯更远，就认为它比慕尼黑要好，尤其是如果你要参加慕尼黑啤酒节的话！另一方面，如果你想参加一个盛大嘉年华的话，那威尼斯就是你的选择，即使去威尼斯要消耗你更多的汽车燃烧，这一选择也是明智的。”在俄勒冈，她又说道：“从波特兰沿着州际高速公路开 1 至 5 公里就能到达阿什兰，那里有着历史悠久的盛大的莎士比亚戏剧节。但如果你的目的是去国会大厦做生意，那么塞伦才是你应该去的地方，虽然它没有阿什兰那么优美。”

与之类似，一个二星级团队并不代表它比一星级或三星级团队要做得更差或者更好。这取决于许多环境因素，尤其是取决于它对于实现目标的合适度。或者如果我们把流畅敏捷之路的每一点用公园中的某个位置来命名能够更清晰地表达我们的意图（不过在图标库中更容易找到星星就是了）。我们或者可以选择这样的名称：停车场团队、操场团队、运动场团队，以及登山道团队。选择公园中的哪个位置完全取决于你想做些什么活动。在去操场的路上，你可能需要在停车场放下自行车，或者从穿梭巴士上下车。或者你必需先到操场去，才能找到去运动场的路。而如果你很想留在操场上荡秋千或是玩跷跷板，那就没必要往登山道前进了。

为了有效地使用我们的敏捷流畅度模型，我们建议你首先抛弃团队成熟度这种思想，也别让交付商业价值之外的任何思想来评判你的团队。你要做的是花一点时间去理解以下这两点：

你需要从团队中获得什么价值，并希望你的团队创造什么价值？
你愿意为此投入多少精力和交换代价？

是星级还是公园里的位置？

一颗星（或者说停车场）—— 你真的需要某个专注于创造商业价值和客户价值的团队吗？你是否需要能够与其他人协作进行计划、优先级安排、并且为了实现目标能够踏实工作的人？你是否希望能够很快指出团队是否在向交付目标的方向前进？如果能够满足你的目标，那么一个一星级的熟练团队对你来说就是最合适的。你需要投入一定的精力来建立一个强大的、互信的、有协作意愿的团队，以及一个专注于将工作内容按照交付价值进行优先级排序的工作流程设计方法（例如 Scrum、Kanban 或 Scrumban）。

如果这正是你需要的，那么就为建立一个团队文化做些计划和投入。你已经找到的正确的目标，因此请停在那里。但如果这并非最适合于你的情况，那么请考虑一些不同的投入。

两颗星（或者说操场）——你是否需要一星团队所拥有的专注于价值的特点，而且你的客户要求交付的产品的缺陷率为 0、或者非常低，并且期望你能够按照一个常规的预定义节奏进行交付？如果是的话，那么你需要投入精力去招聘人才，而更可能的是你需要团队成员的成长，他们需要掌握各种工程技术能力，例如持续集成、TDD、结对编程（或结对工作）、持续部署以及集体所有制（这些概念来自于极限编程、软件工艺、DevOps 等等）。虽然一开始时会以团队的生产力下降作为代价，但当团队成熟后就能够完全弥补这些投入，毕竟对于业务来说高收益是非常关键的。

我所合作过的大多数组织都会从二星团队中获得充分的价值。不过，许多敏捷教练、思想领袖和一些商务人士（包括我们）都希望看到一种更有抱负的实现，这对团队和组织来说可能会更好，也可能不会。

如果这正是你需要的，那么就为建立一个团队文化、并且开发团队成员的技术能力做些计划和投入。你已经找到的正确的目标，因此请停在那里。但如果这并非最适合于你的情况，那么请考虑一些不同的投入。

三颗星（或者叫运动场）——除了二星团队的价值之外，你是否期望了解你的开发团队是否已经抓住了产品的所有价值？你是否期望你的团队（或多个团队）对你的业务和客户需求有着良好的理解，因而能够贡献出创造性的产品开发思想呢？你是否愿意让团队能够持续地了解业务知识，并且在软件开发者、产品开发者和业务策划专家之间建立信任关系呢？你是否为了发现不断发展的客户与产品而给每个团队都配备了专门的产品经理 / 负责人专家（可以是个人或小组的方式）呢（精益创业的思想对此有所帮助）？三星流畅度的价值通常可以称为“对敏捷的承诺”，无论是不断变化的组织结构、重新定义的管理角色、还是不断变化的行政管理与运营过程，面对这些令人生畏的挑战都能从容应对。这些都是实现三星敏捷流畅度所不可或缺的（提示：千万别相信那些组织发展顾问或者敏捷教练所说的，他们会告诉你实现这些很简单快速，而且只要一个 Scrum Master 就能办到了）。

如果这正是你需要的，那么就为建立一个团队文化、开发团队成员的技术能力、并且调整你的组织设计做些计划和投入。你已经找到的正确的目标，因此请停在那里。但如果这并非最适合于你的情况，那么请考虑一些不同的投入。

四颗星（或者叫登山道）——你是否希望某个开发团队成为整个组织商务动作的重要一环，为新产品交付有创造性的思想，并且积极参与设定前进方向的对话？你是否希望团队能够为了对整个公司来说更重要的价值而暂时停下他们手头上优先级最高的工作？你是否迫切希望在决策会议上为团队成员保留一个座位，只因为你相信他们很清楚每个决定是如何影响到公司中的每个关系人的？如果你的公司并不是一家小型初创企业，你是否愿意投入精力进行一次全盘的企业文化改变？有些人将此称为“超越敏捷”，我们则建议敏捷最终往这个目标前进，因此整个社区在持续地推进它对敏捷的各种可能性的理解。

这些公园里位置的名称能够更好的表达我们的意图，但我觉得星更容易记住，只要你能明白星数越多并不一定代表对你、你的组织和你的处境越好就可以了。最适合你的目标、你的能力、以及你对改变现状所愿意投入的时间、精力、资产和社会资本的，就是最好的流畅度。

计划你的团队投入

成熟度模型将我们指到了错误的方向，它是对人们的活动进行评估，而不是对结果进行评估。敏捷本身强调的是为客户和商业提供价值，它让我们将目光投入在有价值的东西上：即创造并维护高质量的、有用的、市场驱动的软件。我们看到许多公司能够指出适合他们需求的各种敏捷流畅度，并且为改变文化、员工培训和结构调整方面做出了投入，而这些公司都获得了巨大的回报。我们希望敏捷流畅度模型将证明它是一个贡献出其作用的模型之一，尽量它未必完全正确。敏捷流畅度模型是一种思考与计划敏捷投资的方式，它能够帮助你创建最适合于公司的开发投入、商业需求和客户价值的敏捷环境。

关于作者

Diana Larsen是 FutureWorks Consulting 公司的合伙创始人之一，她的工作专注于敏捷软件开发、团队集团和敏捷转型。她是以下几本书的共同作者之一：《Agile Retrospectives: Making Good Teams Great》、《Liftoff: Launching Agile Teams and Projects》和《QuickStart Guide to Five Rules for Accelerated Learning, and the article》，此外还撰写了一篇文章：“ Your Path through Agile Fluency: A Brief Guide to Success with Agile ”，这些书籍与文章深入地讲述了工作团队如何成长、适应与进步。