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

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

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

  在博文《谁说敏捷项目不能更快一些》中,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个?要求团队步伐越快(或者说是越糟),交付软件时无法预料的事情就会越多,最后交付的软件很可能质量更差。

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

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

原文转自:http://www.infoq.com/cn/news/2013/03/agile-faster

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)