敏捷方法已经成为主流，但很多组织在推行敏捷后，并没有获得预期中的效率提升、交付改善或业务价值增长。问题往往不在于“是否采用了敏捷”，而在于团队处于怎样的敏捷流畅度阶段，以及组织是否为相应阶段提供了足够支持。

敏捷流畅度模型正是为回答这一问题而提出的。它帮助组织理解敏捷团队如何成长，以及如何最大化敏捷理念的价值。模型将敏捷团队的发展分为四个阶段：聚焦、交付、优化和强化。每个阶段都有对应的收益、能力要求、组织投入和关键指标。

本文你将了解

• 什么是敏捷流畅度模型
• 敏捷团队成长的四个阶段
• 不同阶段分别能带来哪些收益
• 组织需要为每个阶段投入什么
• 如何判断团队是否达到了相应流畅度
• 如何用该模型指导敏捷转型和团队改进

自 20 世纪 90 年代末以来，我们一直在引导和支持团队向敏捷开发转型。在这一过程中，我们见证了敏捷运动从一群程序员和创新者的热情实践，逐渐发展为席卷整个软件行业的主流方法。

敏捷方法取得了广泛成功，但也正因为这种成功，它并不总能达到人们的期待。敏捷领域的一些知名作者曾指出，许多团队采用了表面化的敏捷实践，却没有真正获得敏捷应有的能力。人们也常常抱怨，一些咨询机构通过向组织强行推广僵化、并不敏捷的流程来牟利。与此同时，组织领导者也担心：他们并没有获得本应获得的收益。

多年来，在帮助敏捷团队成长的过程中，我们逐渐理解了敏捷成功的原因，也看清了许多组织无法获得预期结果的根源。2012 年，我们将这些经验总结为“敏捷流畅度模型”，并发布了这篇文章。此后多年，这一模型在实践中持续发挥价值。现在，我们对本文进行了更新，纳入了新的发现和理解。

本文将帮助你理解：敏捷团队能够带来哪些收益；组织需要为这些收益进行哪些投入；当团队无法带来预期收益时，又应该从哪些方面着手改进。这个过程也许会要求组织进行一些坦诚的自我反思。

什么是敏捷流畅度模型

我们观察到，敏捷团队在学习和成长过程中，通常会经历四个不同的流畅度阶段。每个阶段都会带来特定收益：

• 聚焦型团队创造业务价值。
• 交付型团队按市场节奏发布产品。
• 优化型团队引领市场。
• 强化型团队增强组织能力。

每个阶段都依赖一组敏捷能力。这里所说的能力，指的是可以被观察到的行为。例如：“团队与业务代表合作，由业务代表为团队提供业务视角和期望。”这些行为共同构成了该阶段的能力基础，并带来相应收益。

在敏捷流畅度模型中，我们关注的是一种“稳定而熟练的流畅状态”：即使在压力之下，团队也能持续表现出相应能力。任何人只要在课堂上专心学习，都可以掌握一套技巧；真正的流畅度，则意味着团队能够在日常工作中自然、熟练、轻松地运用这些能力。即使注意力被其他事情分散，这种能力也不会轻易消失。

敏捷开发是一项团队活动，因此流畅度是团队整体的特质，而不是某个成员的个人能力。在实践中，有些能力需要所有团队成员都具备；有些能力则可能由少数成员专门承担。无论哪种情况，团队流畅度都来自团队成员的自组织能力：他们知道如何在恰当的时机，将合适的能力用于合适的问题。

当一个团队掌握了某一阶段的全部能力，并且也具备此前阶段的能力时，这个团队就达到了该阶段的流畅度。虽然团队可以按任意顺序发展能力，甚至同时发展多个阶段的能力，但我们观察到，团队通常会以相对可预测的顺序逐步达到各个阶段的流畅度。

敏捷流畅度模型的四个阶段

阶段	核心定位	主要收益	适合团队
聚焦	敏捷基础	提升透明度，明确业务价值	刚开始敏捷转型的团队
交付	敏捷可持续性	低缺陷率，高生产率	需要长期维护和持续交付软件的团队
优化	敏捷的承诺	更好的产品决策和业务回报	希望引领市场变化的组织
强化	敏捷的未来	跨团队学习和组织能力提升	探索新型管理方式的组织

如何选择适合团队的敏捷流畅度阶段

每个流畅度阶段都会带来新的收益，因此，人们很容易误以为这个模型是一种成熟度模型，目标是不断向最高阶段迈进。这种理解是错误的。

与成熟度模型不同，敏捷流畅度模型描述的是一组选择。每个阶段都是一种完整而成熟的选择，每个阶段都能够创造价值。

可以把流畅度想象成乘坐公交车。上车时，你会买一张前往目的地的车票。更远的目的地不一定更有价值，只是票价更高、耗时更长。有时你会买一张去郊区的票，因为你想去大型商店；有时你会买一张去市中心的票，因为你想去看一场演出。两者并无高下之分，关键取决于你当天想去哪里。

同样，每个流畅度阶段都有价值，也各自伴随着挑战。投入过多可能引发组织内部反弹，甚至损害人们对敏捷理念的整体看法。

团队适合哪个流畅度阶段，取决于你的组织。对多数团队而言，“交付”或“优化”通常是较好的目标；但“聚焦”和“强化”也同样可能是合适的选择。

聚焦代表敏捷开发的基本要素。达到聚焦流畅度的团队，能够显著提升透明度和协作水平。虽然聚焦阶段并不包含可持续的技术实践，但它是展示敏捷成效、争取进一步投资支持的绝佳方式。对于不需要长期维护软件的团队，例如某些数字服务团队，聚焦阶段也非常适用。

对于需要在数月甚至更长时间内持续修改和增强软件的团队来说，交付通常是更好的选择。交付阶段代表敏捷的可持续性。交付型团队缺陷率低、生产率高，并且能够快速响应业务需求。对多数团队而言，达到交付流畅度都是一次意义重大的跃迁。

那些希望引领市场变化，或者预见到市场可能发生颠覆性变化的组织，将从优化阶段中受益。优化代表敏捷的承诺：具备创新能力的业务敏捷性。它能够带来显著回报，但也需要对组织结构进行较大的变革。这些变革通常更容易在规模较小、反应灵活的组织中实现。

对于希望革新管理理论和实践的领导者，尤其是中小型企业的领导者，强化阶段可能最适合他们的团队。这个阶段代表敏捷未来的发展方向。许多前沿敏捷实践似乎正在朝这一方向演进。不过，进入这一阶段需要研究前沿管理理论，并创造新的工作方式。

即使在同一组织内部，不同团队也可能适合不同的流畅度阶段。本文后续将详细介绍每个阶段所需的投入和收益。阅读各阶段内容时，请牢记：每个阶段都有自身的成本和取舍。请认真思考哪些取舍适合你的组织，而不是简单地认为“越多越好”。

团队如何达到敏捷流畅度

流畅度更多依赖习惯，而不仅仅是技巧。培训可以教授基本技巧，但真正达到熟练流畅的状态，需要数月持续且有意识的日常练习。它来自对学习和实践的刻意投入。

后续阶段所需能力通常比前期阶段更难掌握，也需要更长时间。团队越早开始练习某一阶段的能力，就越早可能达到该阶段的流畅度。不同敏捷能力之间也会相互促进。因此，最好的做法是选择你希望达到的流畅度阶段，并同时开始练习该阶段及所有前置阶段所需的能力。

当然，你随时可以改变目标。先从一个阶段开始，以后再转向另一个阶段并无不可，只是可能需要更多时间。

在团队练习各项能力的过程中，流畅度的提升会出现起伏。它并不会按部就班地从一个阶段线性过渡到下一个阶段，而是会在多个阶段并行发展。你可能很快看到令人鼓舞的迹象，但真正达到稳定熟练的状态，进展却可能缓慢而令人沮丧。流畅度会停滞，会前进，也会后退，而且不同能力的进步速度并不相同。

影响团队流畅度的最大因素之一，是组织支持。继续使用公交车的比喻：团队必须自己乘上这辆车，才能抵达目标流畅度阶段。没有人能替他们完成这件事，但组织必须为他们买票。如果组织在不提供适当支持的情况下，期待团队达到流畅状态，结果注定会令人失望。更糟的是，支持不足会导致人员流失，并滋生消极的组织文化，阻碍进一步改进。在开启流畅度之旅之前，请确保你的组织已经准备好，能够提供这段旅程所需的全部支持。

组织最大的投入之一是时间。真正达到流畅度所需的时间，通常比人们预期的更长。根据我们辅导团队的经验，一个团队通常需要 2 到 6 个月才能熟练掌握“聚焦”阶段。达到“交付”阶段，还需要额外 3 到 24 个月，具体取决于代码库中的技术债务规模。达到“优化”流畅度可能还需要 1 到 5 年，具体取决于组织中的信任程度，以及组织改变汇报结构的意愿。

阶段	收益	投入	可借鉴方法	达到流畅度所需时间
聚焦	更清楚地了解团队正在做什么，并能够调整方向。	团队发展和工作流程设计。	Scrum、看板、非技术型极限编程实践	2—6 个月
交付	低缺陷率和高生产率。	在技术能力发展期间接受生产率下降。	极限编程、DevOps 运动	额外 3—24 个月
优化	更高价值的交付和更好的产品决策。	投入社会资本，将业务决策权和专业知识转移到团队。	精益软件开发、精益创业、超越预算	1—5 年
强化	跨团队学习和更好的组织决策。	承担开发组织管理新方法所需的时间和风险。	组织设计与复杂性理论	未知

为什么团队会失去敏捷流畅度

稳定的团队很少会自行失去流畅度。根据我们的经验，流畅度下降通常是由外部干扰造成的。

导致团队能力下降的常见原因之一，是新的管理层认为敏捷方法不符合他们的愿景。如果缺乏组织支持，团队又没有机会继续实践已经掌握的能力，流畅度就会迅速下降。这通常还会伴随专业能力流失，因为不满的团队成员会选择离开。

人员流动也是导致流畅度下降的重要原因。团队成员频繁增减，或者一次性发生过大变化，都可能使团队难以保持已经积累的能力。对于那些每个项目都重新组建团队的组织来说，这一点尤其值得警惕。

快速增长和强制性流程也可能导致流畅度流失。成功的初创公司常常遇到这个问题。在规模较小时，初创公司往往会本能地以“优化”甚至“强化”的方式运作。它们未必掌握了所有能力，但其本能会引导它们接近这些阶段。一旦开始快速增长，它们往往会引入官僚制度和流程，而这些流程可能在无意中破坏原本促成流畅运作的灵活机制和文化。

同样，有些公司在单个团队中成功应用敏捷理念后，会把一套规模化框架强加给所有团队。许多这类框架主要只支持聚焦阶段的流畅度；有些框架甚至更多是为了迎合管理层偏好，而不是追求卓越的敏捷实践。这会让后续阶段的流畅度更难培养和维持。

但这并不意味着避免增长或临时性扩张就是正确答案。增长、规模化和流畅度之间的关系非常复杂，值得单独深入讨论。现在，我们只需指出一点：要在规模化层面保持流畅度，每个团队自身都必须具备流畅度。在评估规模化方案时，请思考你的选择会如何促进或阻碍团队获得所需阶段的能力。

组织如何支持团队形成敏捷流畅度

在敏捷型组织中，组织的工作由拥有共同目标、相互协作的团队完成。因此，流畅度源于团队。个人或组织可以为团队流畅度做出贡献，但他们自身并不能“达到流畅度”。

虽然组织本身无法做到流畅，但讨论组织所促成的流畅度是有意义的。团队流畅度不仅取决于团队成员的技能，还取决于管理结构、人际关系、组织文化等因素。不要犯这样的错误：把团队缺乏流畅度归咎于个人，或者认为只要拥有高技能人才就一定能够保证流畅度。组织环境往往更加关键。

当团队在提升流畅度方面遇到瓶颈时，通常会在某些特定能力上遭遇困难。有时问题在于缺乏知识或技能，这时培训和指导正是团队所需要的。

但团队发展也常常受制于组织结构。你可以通过对多个团队进行敏捷流畅度诊断，来检查是否存在组织结构限制。相关模型项目方提供了诊断选项。如果多个团队都在相同能力上遇到困难，这通常说明存在系统性问题，需要组织层面的投入和变革。

在工具层面，研发型团队还需要让目标、反馈、需求、开发、测试、发布和知识沉淀形成连续的数据链路。例如，PingCode 这类覆盖研发全生命周期的智能化研发管理工具，可以帮助组织把研发管理流程自动化、数据化，并让团队更容易观察和改进自身流畅度。

在接下来的章节中，我们将介绍每个阶段所需的能力和组织投入。阅读时，请思考你的组织已经准备好支持哪些阶段，以及目前在哪些方面仍存在阻碍。

聚焦型团队：创造业务价值的敏捷基础

项目	内容
概括	敏捷基础
收益	更清楚地了解团队正在做什么，并能够调整方向。
投入	团队发展和工作流程设计。
可借鉴方法	Scrum、看板、非技术型极限编程实践
时间	2—6 个月

高效聚焦的团队以目标一致、紧密协作的方式工作。他们在思考和规划时，会关注赞助方、客户和用户能够从软件中获得什么收益。这与刚刚开启敏捷之旅的团队截然不同。后者往往关注技术层面的问题，例如软件层级结构，并且通常以个人贡献者身份完成各自分配的任务。

Scrum、看板以及极限编程中的非技术实践，都是能够帮助团队达到聚焦流畅度的敏捷方法。用户故事是团队最常用的技术之一。其他技术包括待办事项列表、回顾会议、时间盒，例如迭代，以及团队任务看板。聚焦型团队也关注互动层面的概念，例如心理安全、团队章程、群体学习和同伴反馈。

达到这一阶段流畅度的团队，至少每月一次展示他们正在进行的工作，以及从业务价值角度来看取得的进展。这是聚焦型团队的核心指标。它并不是团队达到该阶段后唯一能够带来的收益，但却是判断团队是否达到流畅度的一种简单快捷的方法。如果你无法了解团队的业务优先级，或者这些优先级与团队实际工作内容不一致，那么该团队尚未达到聚焦流畅度。

聚焦型团队的预期收益

透明度

核心指标：团队至少每月一次展示他们正在进行的工作，以及从业务价值角度来看取得的进展。

降低风险：管理层能够知道团队何时在做错误的事情，或何时没有取得进展，并有能力进行积极干预。

成果

提高生产率：团队会定期反思、调整并改进工作习惯，以创造更多价值。

提高投资回报率：团队会聚焦于他们被告知对公司而言最重要的优先事项。

提高投资回报率：团队每个月都会在业务优先事项上取得渐进式进展。

协同

提高生产率：协作式沟通能够减少团队成员之间的误解和交接延迟。

团队协作带来的收益，源于有效沟通、高效团队合作和持续的团队改进。掌握这些能力并非技术难题，但对某些人来说，转向团队文化并不容易。团队成员必须学会围绕业务成果而不是技术任务进行规划。他们需要学会对整个团队的成功负责，而不仅仅是对个人贡献负责。管理者也必须学会支持团队合作，而不是奖励个人表现或分派个人任务。

聚焦阶段的关键能力

响应业务需求

团队与一位业务代表合作，由该业务代表为团队提供公司视角和业务期望。

业务利益相关者可以相信，团队会根据业务代表的视角，选择下一步最有价值的工作。

团队会以业务代表能够理解和重视的方式，拆分工作并展示进展。

团队的业务代表至少每月都能看到团队进展，并根据需要调整团队方向。

管理层让团队能够以可持续的节奏工作，从而持续响应业务需求。

高效团队协作

团队根据业务代表的需要，自行制定日常任务和计划。

团队成员认为计划是团队的工作，而不是个人的工作。

团队成员共同承担完成计划的责任。

管理层认为计划是团队的工作成果，而不是把责任归咎于个人。

追求团队卓越

团队坚持并不断改进自身的协作式工作方式。

团队意识到成员关系会如何影响成功，并主动尝试改善这些关系。

团队意识到工作环境会如何影响工作能力，并主动尝试改善工作环境。

聚焦阶段的组织投入与价值权衡

一群独立贡献者通常需要 2 到 6 个月的练习，才能适应协作式团队工作方式。他们的流畅度不仅取决于自身努力，也取决于组织投入。正如前文所说，团队也许能够掌控自身工作的节奏，但组织需要为此买单。

对许多管理者和组织而言，最具挑战性的投入并不是资金。要让团队高效协作，组织可能需要改变管理行为，让团队成员全职投入团队工作，并重新设计物理工作空间。尤其重要的是，管理者必须转变管理方式：从管理个人贡献，转向管理工作系统——引导团队流程、工作习惯、能力和工作环境，使团队能够在无需管理者明确介入的情况下做出正确决策。

我们看到许多组织选择不进行这些投入，却仍然期待团队能够熟练运用敏捷方法。在这种情况下，团队的流畅度提升会很缓慢，也很难真正达到完整的流畅度。如果你的组织无法进行必要投入，敏捷方法最终只会令人失望。

聚焦阶段的常见组织投入

选择具备相应技能、背景和团队合作意愿的成员，并让他们全身心投入团队工作。

创建一个以提升效率为目标的共享工作空间。强烈建议使用实体团队空间。如果实体空间不可行，则提供互动性强的虚拟工作空间，并接受其效率可能稍逊一筹的事实。

如果团队需要更通用的项目协作环境，也可以借助 Worktile 这类项目协作系统，将任务、项目、文档、目标、日历、工时和审批等信息集中管理，从而降低协作成本。

确保有一位在业务优先级和客户价值方面具备专业知识的人担任团队业务代表。

消除阻碍有效团队合作的因素，例如竞争性排名、个人奖励和分散式团队。

对团队成员进行指导和培训，帮助他们提升聚焦能力。

培训管理者，使他们能够创造支持团队合作的环境，并学会管理工作系统，而不是关注个人贡献。

作为这些投入的回报，你将更清楚地了解团队正在做什么，并能够引导他们专注于创造 80% 价值的那 20% 工作。

交付型团队：按市场节奏发布产品

项目	内容
概括	敏捷可持续性
收益	低缺陷率和高生产率。
投入	在技术能力发展期间接受生产率下降。
可借鉴方法	极限编程、DevOps 运动
时间	额外 3—24 个月

高效交付的团队不仅关注业务价值，还能够通过按市场可接受的频率发布产品来实现这种价值。这被称为“按市场节奏交付”。高效交付团队与聚焦型团队的区别，不仅在于能否交付，更在于交付的灵活性。

极限编程开创了许多交付型团队使用的技术，至今仍然影响深远。几乎所有高效团队都采用了它的重要创新，例如持续集成、测试驱动开发和持续重构。

近年来，DevOps 运动将极限编程的理念扩展到现代云环境中。持续交付和持续部署技术已被大多数交付型团队采用。其他有用的技术还包括演进式设计、集体代码所有权，以及结对编程或群体编程。

高效交付团队能够创建缺陷率低、并能根据组织需要频繁发布的软件。如果一个团队无法在需要时发布产品，那么他们还不能称为高效交付团队。

交付型团队的预期收益

透明度

核心指标：团队可以在业务需要时，以最小风险和成本发布最新成果。

降低风险：生产生命周期中的系统性缺陷会更早暴露出来。

提升满意度：团队能够根据管理者和客户的需求，提供有用的发布预测。

成果

提高生产率：团队缺陷率低，因此浪费在修复错误上的时间更少，投入到改进上的时间更多。

提高生产率：团队代码库技术债务低，因此修改成本更低、速度更快。

提高投资回报率：团队按照市场节奏发布产品，以尽可能高的频率获取市场价值。

协同

提高生产率：低缺陷率和低技术债务有助于提升员工满意度和士气，从而提高人员留任率和生产率。

交付阶段对技术流畅度要求最高，需要学习大量能力。有些能力，例如测试驱动开发，属于“入门容易、精通终身”的类型。团队成员可以通过学习和实践极限编程、DevOps 以及敏捷软件质量专家提出的技术而受益。管理者需要确保团队成员具备所有必要专业知识，并与利益相关者合作，形成一种共识：深思熟虑、注重质量的工作，比单纯追求效率更重要。

交付阶段的关键能力

响应业务需求

团队所有与产品相关的代码都达到生产级质量，其最新成果至少每天部署到与生产环境相当的环境中。

团队业务代表可以在需要时发布，或以其他方式启用团队的最新成果。

团队能够应业务代表要求，提供有用的发布预测范围。

团队与业务利益相关者协调，以低成本、可长期维护的方式开发代码和其他产物。

高效团队协作

程序员认为代码和类似产物属于团队，而不是个人；他们共同承担修改和改进代码的责任。

团队能够即时调用设计、开发、交付、监控、维护等日常工作所需的全部能力，从而保障团队工作成果。

追求技术卓越

团队成员在处理代码和类似产物时，会使其技术质量至少比接手时略有提升。

生产发布流程已经自动化，所需人工操作不超过十分钟。

团队编写出的生产级代码不需要单独的人工测试阶段。

所有团队成员都清楚自己的专业技能和技术能力如何影响团队目标的达成，以及维护成本的降低。他们会主动寻求提升这些能力。

交付阶段的组织投入与价值权衡

将团队成员能力提升到流畅水平需要时间和大量精力。通常情况下，在专注提升这些能力后，团队还需要 3 到 24 个月才能真正达到交付流畅度，具体时间取决于团队获得的指导数量，以及代码库中的技术债务规模。对于技术债务极高的大型系统，所需时间可能更长。

培训课程可以介绍实现交付流畅度所需的概念，但学员往往难以将课堂示例应用到实际问题中。在许多情况下，要真正掌握交付流畅度，还需要经验丰富的实践导师指导团队完成真实项目。此外，随着团队学习新能力并偿还既有代码中的技术债务，生产率通常会暂时下降。

交付阶段的常见组织投入

在团队成员学习新能力期间，允许生产率出现阶段性下降。

将质量保证、运维等非编程技术专业纳入团队。

提供敏捷技术实践方面的培训。

聘请经验丰富的实践教练，指导团队开展真实工作。

尽管成本不低，交付流畅度带来的收益也非常巨大。流畅的团队能够开发出缺陷极少的软件，并将技术债务降至最低，这意味着他们有更多时间专注于功能开发。偿还既有技术债务并最终显现收益需要时间，但一旦收益出现，你将看到更快的开发速度、更高的软件质量，以及显著提升的响应能力。

优化型团队：用敏捷能力引领市场

项目	内容
概括	敏捷的承诺
收益	更高价值的交付和更好的产品决策。
投入	投入社会资本，将业务决策权和专业知识转移到团队。
可借鉴方法	精益软件开发、精益创业、超越预算
时间	1—5 年

达到优化流畅度的团队了解市场需要什么、企业需要什么，以及如何满足这些需要。或者，在创业环境中，他们知道自己需要学习什么，以及如何学习。与交付型团队不同，优化型团队不仅具备向市场交付产品的能力，也知道应该向市场交付什么。

大多数敏捷方法旨在帮助团队达到聚焦或交付阶段。要达到优化阶段，首先要建立交付基础，例如 Scrum + XP + DevOps、看板 + XP + DevOps，或简单的 XP + DevOps，然后在此基础上叠加以产品为中心的技术。

精益创业和精益软件开发虽然名称相似，但实际上是不同方法，二者都是很好的入门路径。管理者也会从熟悉“超越预算”相关理念中受益。在此基础上，组织应准备探索和尝试以产品为中心的敏捷技术。有用的主题包括客户发现、持续产品发现、设计思维、故事地图和自适应规划。

达到优化流畅度的团队了解自己的市场。他们不仅知道自己在做什么，也清楚为什么要这样做。至少，当你与达到优化流畅度的团队交流时，会感受到他们对自身产品在市场中的定位有清晰认识。团队会定义自己的指标，或其他进度衡量方式，能够解释这些选择，并制定改善市场地位的计划。

如果一个团队缺乏对自身产品和市场的这种理解，或者其创造的价值低于机会成本，那么他们尚未达到优化流畅度。相应地，达到优化流畅度的团队会与领导层协调，取消或调整低价值产品和项目。

优化型团队的预期收益

透明度

核心指标：团队能够说明其产品在市场中的定位，以及他们将如何提升自己的市场地位。

降低风险：团队会与领导层协调，尽早取消或调整低价值项目。

成果

提高投资回报率：团队交付的产品能够满足业务目标和市场需求。

提高投资回报率：团队会利用市场反馈预测客户需求，并创造新的商业机会。

提高投资回报率：团队拥有广泛的专业知识，能够促进最佳成本/价值决策。

协同

提高生产率：团队广泛的专业知识消除了交接环节，加快了决策速度。

提高生产率：团队与组织之间的相互信任，能够带来快速而有效的协商。

提升优化能力的最大挑战之一，是赋予团队对产品方向的真正控制权。优化型团队与交付型团队的区别在于：在章程规定范围内，优化型团队可以自主决定资金投入和工作重点。管理者需要将这种权力下放给团队，而这通常是组织面临的一项艰难转变。

当然，要真正掌握这些决策，团队需要具备做出正确决策的洞察力；或者至少知道哪些实验能够帮助他们找到正确决策。获得这种专业知识通常需要将非开发人员纳入全职团队。常见角色包括产品经理、业务分析师和领域专家，也可能包括来自市场营销、销售或客户支持部门的成员。

这类结构性变革需要组织高层批准，而获得批准并不容易。你可能会想招聘新员工来填补空缺，但通常更有效的做法，是吸纳那些已经了解公司独特优先事项和约束条件的现有员工。

开发人员和质量保证人员，尤其是资深人员，往往也是产品专业知识的重要来源。在寻找能够为团队带来业务专长的人才时，不要忽视对资深技术人员进行必要业务能力培训的可能性。销售拜访和客户拜访是提供新视角的绝佳方式。

优化阶段的关键能力

响应业务需求

团队根据与管理层共同确定的业务指标结果，来描述计划和进展。

团队会酌情与内部和外部利益相关者合作，判断何时以及是否进行发布预测，才能带来最佳投资回报。

作为值得信任的自主团队开展工作

团队与管理层协调，以理解并完善自身在实现业务战略中的作用。

团队共同承担责任，并对实现与管理层共同确定的业务成果负责。

管理层赋予团队实现业务目标所需的资源和权力，使其能够自主开展工作。

管理层确保团队所有全职成员都具备理解市场和实现业务目标所需的日常能力。

追求产品卓越

团队与客户和市场互动，以理解产品需求和机会。

团队提出关于商业机会的假设，并通过实验验证这些假设。

团队以一种能够在不到一个月内完全改变计划、且不会造成浪费的方式规划和开展工作。

优化阶段的组织投入与价值权衡

赋予团队决策权和相应专业知识，会挑战现有组织结构。这可能需要数年时间，并不是因为必须掌握某项特定技能，而是因为管理者和组织领导者必须先学会信任团队对敏捷理念的运用，才愿意做出影响自身权力、控制权和既有工作方式的改变。

投资这些变革需要积极的组织政治能力，也需要对最终回报的价值有坚定信念。倡导者需要运用自身社会资本推动变革。管理者可能需要接受指导，以支持高效敏捷环境。在这样的环境中，他们的职责会从战术决策转变为定义团队方向，并协调跨组织协作。

优化阶段的常见组织投入

让团队 100% 专注于特定产品或市场。

将业务专家和领域专家纳入全职团队。不要假设一个人就足够。

让团队对自身预算、计划和结果负责；根据结果而不是计划执行情况来评估他们。

鼓励并期望管理者在组织内部协作，消除阻碍团队绩效的障碍。

为管理者提供指导，帮助他们理解高绩效、自组织敏捷团队如何改变管理工作的性质。

优化流畅度能够降低沟通成本，消除繁琐官僚流程，并快速响应不断变化的商业环境。这项投入会打破现状，因此并不适用于所有组织。但对于希望引领市场变化的组织来说，投资优化流畅度值得认真考虑。

强化型团队：增强组织整体敏捷能力

项目	内容
概括	敏捷的未来
收益	跨团队学习和更好的组织决策。
投入	承担开发组织管理新方法所需的时间和风险。
可借鉴方法	组织设计与复杂性理论
时间	未知

优化型团队能够理解并满足市场需求，而强化型团队则在组织中发挥更大的作用。

团队强化可以从三个方面为组织做出贡献。首先，他们了解自身在更大系统中的位置。他们理解自身目标如何与其他团队目标相互配合，从而实现更宏大的战略。他们会主动努力，让这一战略更加成功。

其次，他们会主动在组织内部传播专业知识。他们会寻找机会，将自己的能力贡献给其他团队，也会寻求机会向其他团队学习。

第三，组织会将方向性决策权下放给各个团队。领导者会精心设计组织结构，提炼团队的集体智慧，并将其转化为组织改进的动力。

我们看到，世界各地的一些组织都在尝试强化型方法。一些海外软件公司、服务型企业和互联网企业也曾进行相关探索。我们还看到，一些前沿技术，例如团队自选和开放空间战略会议，正越来越多地出现在敏捷团队领导实践中。尽管如此，这一领域仍处于探索阶段。我们认为这可能是敏捷未来的发展方向，但无法确切知道它最终会演化成什么样子。

虽然我们还不能完全确定这一阶段最终会呈现何种形态，但我们已经看到足够多的案例，可以对流畅团队能够带来的收益作出判断。

强化型团队的预期收益

透明度

核心指标：团队在描述自身工作时，会考虑公司的其他举措，从而使不同产品之间保持平衡。

降低风险：团队能够及早发现并帮助解决跨组织瓶颈和问题。

成果

提高投资回报率：团队参与多团队活动，以优化组织价值流。

提高生产率：团队能够意识到何时可以为其他团队的工作做出贡献；当其他团队的工作更重要时，他们会调整自己的努力方向去提供帮助。

协同

提高生产率：团队与其他团队以及组织其他部门之间，会进行观点、背景、学习和创新的交叉融合。

这一阶段最适合那些希望走在管理理论和实践前沿的组织。它要求领导者在组织理论方面保持领先，并不断探索如何将其应用于敏捷团队。

如果你对这一阶段感兴趣，可以研究复杂性理论，例如 Cynefin 框架和人类系统动力学；也可以研究组织设计的新理念，包括开放空间敏捷、社会技术系统以及合弄制等替代治理结构。

即使你并不追求这一阶段的完整流畅度，其中正在发展的某些技术也值得考虑。正如一个达到交付流畅度的团队也会掌握一些优化技术一样，你也可能从强化技术中受益。我们亲身体验过的两种技术是团队自选和战略性开放空间会议。这两种技术都非常值得尝试。

对多数组织而言，“强化流畅度”也许更适合先观望，至少在“优化流畅度”触手可及之前不宜贸然追求。然而，对于那些已经重视精益原则和系统思维、倾向于将决策权下放给团队，并重视前瞻性方法和创新流程的小型组织来说，强化阶段提供了一个大胆的挑战，也提出了一个引人入胜的难题。

如何应用敏捷流畅度模型

有句名言说：“所有模型都是错的，但有些模型是有用的。”敏捷流畅度模型是对现实世界的简化描述。尽管它有所简化，但我们发现它能够准确反映大多数组织的需求。即使它并不完全匹配你的情况，你也可以把本文所描述的收益、能力和投入，作为值得讨论的话题。

你可以从三个方面应用这个模型。

首先，用它来理解你的组织需要在敏捷方面进行哪些投入。投入不足不仅会导致进展缓慢，还会造成持久的怀疑、冷嘲和怨恨。我们已经见过太多这样的失败案例。运用这个模型，可以帮助你确保预期与投入方向保持一致。

其次，如果你没有看到预期中的流畅度，该模型可以帮助你发现问题所在。你可以进行诊断，找出团队在哪些能力上遇到困难，然后提供相应培训和支持。相关模型项目方提供了诊断选项。如果多个团队都在相同能力上存在困难，问题很可能出在系统层面，因此需要考虑组织变革。

最后，该模型有助于引导关于敏捷方法的讨论。关于敏捷理念的讨论很容易陷入对具体方法、工具和实践的争论。相反，你可以利用该模型，促进大家讨论真正想达成的目标，以及如何实现这些目标。

敏捷流畅度模型图可供参考，也可以根据你的演示文稿进行调整。你也可以分享本文，以引发关于团队能力和组织需求的讨论。如需进行衍生创作，例如重新发布能力列表，请联系作者获取许可。

如果你在应用该模型或诊断流畅度挑战方面需要帮助，可以联系相关模型项目方，获取更多资源。

常见问题

敏捷流畅度模型是什么？

敏捷流畅度模型是一种帮助组织理解敏捷团队成长路径的模型。它将团队发展分为聚焦、交付、优化和强化四个阶段，用于判断团队当前能力、预期收益和所需组织投入。

敏捷流畅度模型和敏捷成熟度模型有什么区别？

敏捷流畅度模型不是成熟度模型。它并不要求所有团队都追求最高阶段，而是帮助组织根据自身目标选择合适的流畅度阶段。每个阶段都有价值，也都有相应成本和取舍。

敏捷团队一定要达到强化阶段吗？

不一定。对多数团队来说，交付或优化阶段已经能够带来显著价值。强化阶段更适合希望探索新型管理方式、强调跨团队学习和组织创新的企业。

如何判断团队是否达到聚焦流畅度？

一个重要判断标准是：团队是否至少每月一次展示正在进行的工作，以及从业务价值角度取得的进展。如果团队工作与业务优先级不一致，通常说明还没有达到聚焦流畅度。

如何判断团队是否达到交付流畅度？

如果团队能够在业务需要时，以较低风险和较低成本发布最新成果，并保持较低缺陷率和较低技术债务，通常说明团队已经接近或达到交付流畅度。

结论

在与敏捷团队和组织合作的过程中，我们发现，团队对敏捷方法的理解，以及组织从中获得的收益，通常会遵循一个循序渐进的过程。我们将这一过程归纳为四个流畅度阶段。每个阶段都有独特收益，也有不同的应用挑战。

第一个阶段是聚焦。它要求团队学会协作，专注于创造业务价值，而不仅仅是完成技术任务。作为回报，组织可以更深入地了解团队的工作，并获得更多机会对团队工作产生积极影响。该阶段体现了敏捷开发的基本原则。

第二个阶段是交付。它要求团队投入时间学习多种软件开发能力。该阶段体现了敏捷开发的可持续性。这些能力并非唾手可得，但随着时间推移，并在充分组织支持下，团队能够根据市场需求，以最快速度创建并交付低缺陷率的软件，从而为组织带来新的机会，使软件开发投资获得回报。

第三个阶段是优化。它体现了敏捷的承诺：团队能够灵活应对不断变化的市场环境，并共同承担责任，打造出你所投资能够获得的最佳产品。要达到这一阶段的流畅度，业务专家必须作为全职贡献者加入团队。虽然这种组织结构变革可能充满挑战，但最终会带来回报，提升团队服务业务的能力。

第四个阶段是强化。它代表敏捷的未来。强化型团队与其他团队协作，以提升整个组织的效率。达到这一阶段需要创新思维和勇于尝试的精神。

所有这些阶段都能带来收益，每个阶段也都适合某些团队。请利用这个模型，引导组织讨论希望支持哪些阶段。一旦选定阶段，就要认真考虑达到流畅度所需的投入，并全力以赴地进行这些投入。

团队需要时间来提升能力。他们的进步会经历起伏，时而前进，时而后退，最终会遇到瓶颈期。从一开始就尽可能多地练习各种能力。这些流畅度阶段代表着自然的瓶颈位置，你会在这里看到明显进步，也会看到需要克服的挑战。

请注意，组织环境可能会影响流畅度。密切关注影响多个团队的系统性问题。这通常表明组织需要进行变革。

我们一次又一次地见证团队经历这些流畅度阶段。通过与你分享我们的经验，我们希望你能更深入地理解敏捷方法可能带来的价值，以及它们所伴随的挑战。祝你和你的团队不断提升流畅度，取得更大的成功。

阶段	收益	投入	可借鉴方法	达到流畅度所需时间
聚焦	更清楚地了解团队正在做什么，并能够调整方向。	团队发展和工作流程设计。	Scrum、看板、非技术型极限编程实践	2—6 个月
交付	低缺陷率和高生产率。	在技术能力发展期间接受生产率下降。	极限编程、DevOps 运动	额外 3—24 个月
优化	更高价值的交付和更好的产品决策。	投入社会资本，将业务决策权和专业知识转移到团队。	精益软件开发、精益创业、超越预算	1—5 年
强化	跨团队学习和更好的组织决策。	承担开发组织管理新方法所需的时间和风险。	组织设计与复杂性理论	未知