敏捷迭代开发：管理者指南（英文影印版） 计算机畅销书每日10本68折特价!减运费!

Larman: 另一个常见的敏捷误解是认为：敏捷 = XP。No，这是错的。事实上 XP 只是当代一打迭代演进式方法中的一种，其他方法还包括 DSDM、FDD、UP、Crystal 等等许多种。这些其他的敏捷方法与 XP 大有不同。当然我喜欢 XP，XP 之中充满了许多伟大的想法和做法，Kent Beck 和 Ward Cunningham 也相当聪明，然而请不要把 XP 与敏捷或迭代简单地划上等号，后者是一个更为广阔的领域。举例来说，与 XP 不同的是，DSDM、FDD、UP 等一些其他方法，都要求在早期迭代中尽早地关注一些与建模、架构核心有关的工作和开发。在这些方法中，在每次迭代开始编程之前花上几天时间开展小组需求、设计活动，既很正常，也符合预期。只有 XP 在这方面采取了比较“极端”的观点，几乎避免任何在编程之前进行的分析或设计活动。请不要把孩子同洗澡水一起抛掉，尤其对于那些大项目 —— 有一些小组协作的设计建模（敏捷建模）技术还是相当有效的！

转自 www.craiglarman.cn

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

转自 www.craiglarman.cn

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

转自 www.craiglarman.cn

我想买一本，可是对鸡公出版社这一系列书采用草纸印刷表示强烈反对，还不如给电力出版