向敏捷迁移的成本优势何在?

  • Shane Hastie
  • 郑柯

2009 年 5 月 8 日

话题:敏捷技术管理治理架构文化 & 方法

公司们正在尝试敏捷方法,研究它能带来的好处。然而来自高层的声音却在高声叫道:“我要见到真金白银。”要改变大型组织交付软件的方式,就跟让油罐车转向一样,有这个可能,但是要花不少时间和力气。管理层要确认:对于驱动每个组织的两个基本战略目标——降低成本、增加收入,改变要可以实现二者之一。

在一篇 2008 年的文章中, Scott Ambler 点明了提出成本问题背后的动机, 并指出多个来源,展示出:

  • 敏捷方法比传统技术更为成功。
  • 敏捷团队比传统团队更为高效。
  • 敏捷项目比传统方法开发的产品质量更高。
  • 敏捷项目的产出能让业务干系人更加满意。
  • 敏捷项目比传统开发项目成本更低。

Ambler 还提供了原始数据,这些数据引用自另一篇文章

在 LinkedIn 的Agile Alliance 讨论组中有一篇很长的帖子谈到了该话题,并提出了一些观点:

  • 很多时候,要度量知识工作者的工作效率是很困难的。
  • 因为不可能将同一个项目在不同的方法论指导下完全做两次,所以要想做比较基本上是不可能的。
  • 尽早反馈的价值,经常体现在没有犯错而节省的成本中。
  • 敏捷项目会鼓励创新,从而产生能更好满足业务需求的产品,同时“将竞争对手远远抛在后面”。

Steve Gordon 在讨论中指出:

在呼唤度量行为的背后,人们其实担心这样一个问题:以敏捷方式工作的知识工作者,他们的行为种类变化多样,很有可能不受控制。    

人们可以指望敏捷来推动更快、更早的需求改进活动,这在传统的方式中很难做到(原因在于敏捷可以让人们对工作产出[working artifact]做出尽快、尽早的反馈,而且愿意做出改变)。改进需求,就能改进产出的东西。

仅仅度量原始的工作效率,这就完全丧失了上面提到的敏捷的重要效应。即使原始的工作效率数据有所下降(特别是在转换期),如果因为频繁而具体的反馈,使得产出的东西更能发挥作用,更贴近产品目标,那么交付给客户的价值就很有可能大大增加。

不过接下来的问题就是:如何度量交付给客户的价值呢?我想你的客户对此的了解要远胜于其他人。这也要看市场的情况。在真正的垄断市场中,交付的数量也许要比产品是否合适或质量更重要。在另一些市场中,创新会让你把竞争对手远远落在后面,而不光是在性能对比表格上打打勾什么的。

有意思的是,CNN 将敏捷看做对软件开发管理层面的影响,并在《影响未来商业世界的 50 个人、产品、趋势和想法》这篇文章中进行了报道: 

敏捷团队行动非常迅速,他们创建很小块的代码,工作周期有时甚至只有一周时间。完成某个组件后,就会添加新功能,这个过程会一直重复下去。敏捷在帮助管理层按时按预算交付产品方面也享有盛名,这也解释了为什么像 Google 和洛克希德•马丁这样的公司会选它作为方法论。

这样的宣传和支持,是否有利于敏捷实践在商业世界中推广和实施呢?

查看英文原文:Cost Justifying an Agile Migration

敏捷技术管理治理架构文化 & 方法