敏捷方法怀疑论

敏捷方法可以比传统方法的软件增加10-100倍以上的开发效率？真的是这样的吗？

　　在2009年8月，我用一个星期的时间，与1400名热情的敏捷者参加了芝加哥的敏捷大会。对于他们而言，敏捷将在数年内成为标准开发方法。我同意敏捷社区有很多优点。当然，产品所有者和开发者之间更好的交流始终是可取的，日常会议和打破原有工作，变成短小易于管理工作，我们称之为迭代，这必然会提高任何项目的速率。但我对这种明显提高生产率的观点抱怀疑态度。

　　如果你剖析敏捷的含义，高效率的数字就成为嫌疑点。例如，一个案例研究，涉及第一眼看上去很不错的一家丹麦软件公司，但更加紧密观察方法，每次迭代的工作需要预先举行，以便为它的开发工作做好准备。所有提前准备却奇迹般地不计算在内。通过把工作打破成小块，并与业主紧密合作的产品，在不需要的功能的创建上减少了浪费。但是，调用非生产性的废弃的特点有点虚伪。优柔寡断的管理是一个活生生的事实，而且敏捷不会去解决它。

　　不幸的是，我也看到敏捷软件开发，在本来已经超过负荷的知识型员工创造新途径上，迅速得到了声誉。这很不错，敏捷原则是在40小时工作周的基础上，而且还有的PMI（项目管理协会）的建议。我们都知道如何遵守。Scrum的人们甚至大胆地称为他们的迭代冲刺。你不能把严重倦怠系列马拉松运行作为一个短跑项目，没有那么多燃料。团队中的开发人员参与工作的估计，如果他们未能达到预期，而且那是不现实的开始，因此责怪工人，他们甚至有更大的压力。

　　总之，我认为敏捷开发固然吸引人，但是对于任何夸大的宣传我们应该抱一种怀疑的态度。

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号