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