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

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

　　在博文《谁说敏捷项目不能更快一些》中，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