有关敏捷方法的一个最大误解

撰文 Craig Larman
编译 张恂
(c) www.craiglarman.cn

过去几年中，我的工作精力主要花在帮助一些在较大规模项目上（50人、250人 ...）采用迭代方法的客户。现在有关“敏捷方法”实践的一个最大误解是，很多人认为它们是一个新发明，或者只能用在小项目上。形成这种误解的部分原因是因为人们不知道敏捷的许多关键做法（避免瀑布式而采用短迭代、演进式的开发，自动化的每日构建与测试、集成，风险驱动的迭代式计划等等）已经被业内人士所掌握和运用几十年了。您知道美国航天飞机的飞行控制软件项目（绝非一个小项目！）在上世纪 1970 年代中期就采用了这些敏捷做法吗？您知道加拿大全国的新型空中交通管制系统采用的就是迭代式开发，而非瀑布式吗？还有，您知道美国的下一代弹道导弹空间防御系统也在采用敏捷过程实践进行开发吗？当然，还有那些大型的操作系统项目，如微软 Windows 和 Linux。这些都是巨大的、包含多团队、多场址的系统工程项目。如果您希望了解更多的有关自上世纪 1960 年代以来迭代式开发的史例，我推荐您阅读 2003 年 6 月 Vic Basili 博士与我合作发表在 IEEE Computer 上的文章《迭代与递增式开发简史》，以及本人的拙作《敏捷与迭代开发：管理者指南》中的“证据”一章。

当人们问我“我们在大项目上应该采用迭代式开发，还是坚持沿用瀑布式？”，我总是感到很讶异。科学研究表明瀑布做法与更多的风险、失败、缺陷和低生产率有关，而且大型系统构件的延后集成和测试是一个众所周知的重大风险，因此项目愈大，采取短小的、尽早集成的迭代步骤，从用户、测试等那里获得反馈就愈为重要。不过 IMO，请不要相信不成熟的 XP 架构观点，即认为我们可以放弃对早期细致的架构设计的关注。相反的，对于大型项目，早期迭代聚焦于架构要素（通过编程和测试进行验证！），以及通过组织有效协作的核心架构设计会议（让程序员和架构师都参加），花上足够的时间对架构进行建模、思考、交流和编写，这些都是非常重要的。当然，还要结合尽早编程和测试，对实际情况进行检验。我看到过一些大项目，明显受到了避免预先设计建议的影响，因此而失败了；这可是一个业余错误。大系统需要尽早获得坚固的架构！然而，这并不意味着我们必须要用瀑布式，诸如 FDD、UP 这样的方法推荐一种平衡的方式，把某些预先设计与早期的编程迭代结合起来，以便提供和检验设计创意。在《UML 和模式应用：OOA/D 与迭代式开发导论》中，我向大家展现了一个 3 次迭代的案例，对建模和编程就采用了这种平衡的迭代方法。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21682039/viewspace-600236/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21682039/viewspace-600236/