首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

十年经验帖 | 敏捷转型6大误区

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

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

敏捷转型之路的 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.团队定期反思如何提升效率,并相应地调整其行为。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/ed0788263a62edb54e306c6a9
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券