改变，对任何人来说都很难，对团队来说更是难上加难。 同理，敏捷转型带来的重大变革也会很艰难。甚至，有时候敏捷转型反而会带来短时间的产能下降。为了帮助更多研发团队顺利过渡到敏捷，我们以十余年的管理实践，整理了这份：敏捷转型之路的 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.团队定期反思如何提升效率，并相应地调整其行为。
期待大家在实践敏捷的过程中找到价值，也欢迎和我们沟通讨论。后续我们还将分享更多敏捷之道及研发管理实践，不要忘记关注我们哦~ 指路 LigaAI@OSChina 或 LigaAI-新一代智能研发管理平台