改变，对任何人来说都很难，对团队来说更是难上加难。

同理，敏捷转型带来的重大变革也会很艰难。甚至，有时候敏捷转型反而会带来短时间的产能下降。为了帮助更多研发团队顺利过渡到敏捷，我们以十余年的管理实践，整理了这份：

敏捷转型之路的 6 大误区

01

从培训开始

在转型开始之前，让整个团队参加敏捷培训是一个很直观的选择。然而在团队真正做好准备前就去上课，也许会导致一些问题。

缺乏足够的心理认同或不能代入工作场景，可能让团队在培训后只能消化小部分敏捷知识；少部分团队成员甚至可能因为不认同敏捷概念而不断提出挑战， 从而影响整个团队的积极性。

任何转型，成功的最关键步骤都是了解为什么需要改变。每个人都需要了解敏捷带来的好处。如果应用得当，敏捷能使团队更快地交付，立刻为客户提供部分价值和更早地获得客户反馈。在传统的瀑布式项目中，团队也会和客户定期沟通。但由于缺少客户的实时反馈，团队难以快速适应需求的变化，最后交付的产品自然无法满足客户的需要。

当团队成员理解需要敏捷转型的原因及其对每个人工作的意义，并且产生认同感后，正式的培训就变得很重要。团队会在对敏捷的理解和沟通上保持一致，这是成功转型的基础。

这里需要强调的是：敏捷转型成功的团队必需是一个自驱动的团队，而不是一个强管制的团队。

02

敏捷就是 Scrum？

No! 敏捷是一种方法论，而 Scrum 是敏捷最主流的框架之一。

敏捷正式诞生在 2001 年，17 位开发者一起发表了“敏捷软件开发宣言”。在这之前，很多大家今天熟知的框架如 Scrum，XP，FDD 等已经存在。这些框架和后来诞生的 Kanban 都大量借鉴了制造业的先进理念，并将其应用于软件开发领域。在敏捷转型中，了解并选择适合您的框架至关重要。

图源：https://www.systemsvalley.com/getting-better-at-agile-using-kanban-principles/

03

敏捷项目不需要计划…

对于传统的瀑布型项目，在项目开始前就有详细计划的任务分解甘特图。然而真实的项目过程中，需求总在不断地变化，甚至一些需求或潜在问题在项目开始时是不可预测的，因此起初制定的详细计划就会显得鸡肋。

但这并不表明敏捷项目没有计划，其计划的过程是一个持续且变化的过程。

在敏捷项目开始前，团队应制定项目的总体目标；之后，在每个迭代开始前制定迭代计划（细化到此迭代的需求和相应的工作任务）。随着迭代的持续交付和客户的反馈，敏捷项目的计划在不断地调整，一切以实现对客户交付价值的最大化为主。

帮助团队适应项目的不确定性及基于变化的计划，才能让团队更快地转型。

04

轻易地回退

很少有人喜欢变化，在面临压力时，人们往往会恢复到他们习惯的工作方式。在每次敏捷转型中，团队向敏捷转型的决心都会受到考验。当一个正在转型的项目遇到麻烦时，不要轻易地放弃，进而收回对一个自组织团队的控制权。

当程序和项目遇到困难时，请相信流程，并利用敏捷框架的持续改进机制来反思哪些需要调整，在下一次迭代中改进。这可能在短期内降低团队的产能，但会带来敏捷转型的长期成功。

麦肯锡曾经对许多世界 500 强公司的敏捷转型做过调研。其中就有一个亚洲电信巨头的例子。该公司的业绩是由上市时间和绩效目标的实现来衡量的。在公司高层决定采取敏捷工作法之后的 3 个月内，业绩有所下降。但三个月后，其业绩开始快速增长，最终远远超过了公司实践敏捷之前的水平。

05

敏捷适用于任何项目任何团队

团队的规模越大，灵活性就越差。按照康威定律的结论：“设计系统的组织受限于生产设计，这些设计是组织沟通结构的副本”。敏捷的最佳实践是：把较大的团队按照产品或项目划分为不同的敏捷小组，充分发挥沟通成本低的优势。

对于周期长，需求明确且不会变更的项目，在项目开始前能够清晰地定义出目标范围和工作任务，由于在项目的各个阶段团队高度聚焦，瀑布可能是一个更好的选择。但从长远的考量出发，敏捷的团队能够得到更多的价值驱动，从而更好地完成交付。

06

敏捷≈更快地写代码？

如果一个团队把加快开发速度作为敏捷转型的目标，他们很可能会失望。让我们重读一下敏捷的 12 条原则，不难看出，敏捷关注的是更早地交付部分价值给客户，基于反馈快速调整并持续交付价值。

对于相同工作量的产品开发，由于敏捷项目会将开发工作分到多个迭代中，假设需求没有变更，开发速度甚至会比瀑布型慢。也许选择敏捷不一定等同于选择了高速度，究其本质，敏捷不一定能保证产品的交付速度，但它能让团队实时调整，创造出更符合客户需求的产品。

关注价值而不是速度，是敏捷转型的精髓。

直到今天，敏捷诞生已有 20 年，传统项目管理模式更是有超过 50 年的历史。这两者并没有绝对的对或错，对于不同类型的工作，不同的团队，如何在高速变化的时代里找到最适合自己的工作方式才最重要。

最后附上敏捷的 12 条原则，希望对大家有所启发：

1.我们的最高优先级，就是尽早和持续交付有价值的软件来满足客户。

2.拥抱需求变更，即使在开发后期。敏捷利用变化来为客户创造竞争优势。

3.用数周到数月的周期，持续交付可工作的软件，交付周期越短越好。

4.在整个项目周期，业务人员和开发人员必须每天在一起工作。

5.围绕积极进取的个人建立项目，给他们需要的环境和支持，并相信他们会完成工作。

6.信息传递最有效的方式是面对面的沟通。

7.可工作的软件，是衡量进度的首要标准。

8.敏捷倡导可持续发展。赞助者、开发者和用户应该能够一直保持恒定的速度。

9.对技术卓越的持续关注和良好的设计可以提升敏捷性。

10.简单，即最大程度减少不需要的工作，是敏捷的根本。

11.最好的构架、需求和设计来自自组织的团队。

12.团队定期反思如何提升效率，并相应地调整其行为。