敏捷是如何使你跑得更快?

  • Ben Linders
  • 雷慈祥

2013 年 3 月 11 日

话题:重构文化 & 方法

对于为何采用敏捷软件开发这个问题,企业经常提到的原因之一是希望能够更快地交付软件。研究表明敏捷项目能够进行地更快,例如《敏捷项目的成功证据》一文中描述的哥伦布市敏捷工作效率基准项目。

在博文《谁说敏捷项目不能更快一些》中,Matthew Heusser 分享了他在 Agile Testing Days 大会上的讨论:

2012 年 11 月在德国波茨坦举行的 Agile Testing Days 大会上,《敏捷测试:实用指南》的作者 Lisa Crispin 和 Janet Gregory 大胆声称“敏捷意味着更快”是无稽之谈。

会后,Janet Gregory 向 Matthew Heusser 解释了她这么说是什么意思:

她说,敏捷的关键不是速度。速度的提升可能是附带产生的结果,但是不是一开始就会这样。向敏捷转型这个过程会托你后腿,至少短期内如此。并且这个期限不是一两个礼拜,它可能有一两年之久。

Matthew 提供了为何他认为敏捷可以更快的几个论据。他讲解了如何构建正确的事情,忽略那些不值一提的需求以便节省时间。使用敏捷的另外一个原因是“老办法也不快”。

对比敏捷团队和传统团队,前者一年中无法完成的事情,后者可能能够完成,但这么比较他们不合适。一年中,传统团队也许能够完成 12 个半需求,但却搞得一团糟最终啥也没有发布。

他在博文结尾解释了为何不同意这个观点,并阐述了对敏捷能够帮助团队更快交付软件的看法。

还遗留一个问题:是否是更快了?Crispin 和 Gregory 可能认为这个无所谓,如果只关注短期的进度,长远看来这么做只会导致过度简化,带来的是痛苦和低效。我认为团队能够在流程改进过程中尽量杜绝浪费,工作效率也会随之提升。

《让敏捷跑得更快》一文中,Chris Turner 讨论了敏捷项目可能变慢的一些原因。他描述了经常遇到的四个原因,并给出了一些处理意见。

  • 不合适的人:从团队中剔除那些不遵循良好工程规范或是正在把事情搞复杂的人。
  • 先定义流程:建立可以开放的沟通、自组织、授权的团队。
  • 使用了不当的技术:让团队有权决定使用什么技术,如果该技术妨碍了发布,允许团队重新做选择。
  • 架构太复杂:重构,使软件尽可能保持简单。

Neil Killick 在他的博文《交付软件最快的方式是保持可持续的节奏》描述了为何让敏捷团队加快交付速度会给软件开发拖后腿。他讲诉了关于敏捷团队的一个故事,在为期两周的 Sprint 中该团队平均能够交付 10 个用户故事,但待交付的用户故事却增加了。

现在想象一下,我们让团队每个 Spring 只完成一个用户故事。那么,即便不能打包票,我们也能相当确信能够交付这个用户故事。我们还能相当肯定可以完成得很出色。

现在我们要求这个团队每个 Sprint 交付两个用户故事。即使该团队极有可能能够交付这个 2 个用户故事,成功的概率也要比只要求团队每个 Sprint 交付一个用户故事时要低一些。所以我们就有了一点不确定性。

现在再想象一下,合同大限将至,我们还在努力赶工,是不是该加把劲了。所以我们要求预计能够交付 10 个用户故事的团队交付 12 个用户故事(现在我们超负荷了)。甚至是 14 个?要求团队步伐越快(或者说是越糟),交付软件时无法预料的事情就会越多,最后交付的软件很可能质量更差。

他建议允许团队保持一个可持续的节奏:

让团队找到一个合适的平衡点、在他们能力范围内交付高质量软件,那么就创建了一个成功的软件开发周期。

查看英文原文How can Agile make you Faster?

重构文化 & 方法