在Laurent Bossavit的好书The Leprechauns of Software Engineering中，他抨击了软件开发的一些惯式，比如“成本变化”(或“缺陷成本”)“曲线”，这些惯式是许多其它的软件开发方法论知识基础，称开发人员生产率的变化是一个数量级(参照确定性金字塔原理)。Laurent Bossavit说明了相关依据 – 很多人依赖从计算机科学专业学生进行的非正式试验或是从无法被有效控制的项目中收集小量数据。这些研究组织的给出的论调基础往往是不健全的，数据缺乏分析，而且，最过分的是调查结果普遍远远超出了他们的适用领域[2]。

　　因此，不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适，反之亦然。“方法大师”的见解其实也没太大指导意义，就像Kahneman说的，“人们在想法方面的信心，并非是有效行事可倚重的因素…当评估专家的想法，即使在有规律可循的情况下，你也一定要想清楚是否有合适时机可以引入其想法的可能性”。就像Ben Butler-Cole指出的(why software development methodologies rock)，引入一种新方法往往会带来一些影响。

　　你可能会认为当我们决定怎样运作一个团队时，我们就陷入了被动。但细想一下为什么软件开发无章可循?为什么在这个环境里很难进行一些试验以及获取技能?什么实践和决定会导致成功或失败?其中的根原因就是：环境是不规律的，做出变更与理解变更带来的结果之间的反馈过程太长了。这里的“变更”一词是指广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。

　　还是有一些办法帮助缩短周期的，比如当我们应用精益软件开发思想 – 一个很重要的方法。缩短开发周期在大型产品开发中是很重要的：在Bret Victor的精彩视频Inventing on Principle中提到，“如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物”。

　　但对我而言就是这样的：我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。除非我们聚焦于尽可能使反馈间隔时间缩短，以便实际洞察其间关联，以及辨别原因和影响。

　　事实上，从想法到反馈的周期尽可能短的好处是如此明显和重要，应该把其作为商业模式中要遵循的一个重要原则。如果你纠结于要把你的产品创建成一个用户安装式的软件还是SaaS模式(software-as-a-service，软件运营服务模式，软件即服务)，这时的想法会自然而然地推动你强烈考虑 SaaS模式(有感而发)。如果你要重建你的系统(包含硬件)，应该考虑怎样尽快实现原型(how you can get prototypes out as quickly as possible)，以及模块化硬件和软件，以便你可以快速和独立地整合。3D printing(三维打印成型技术)技术看起来在这方面有着巨大的用武之地，因为它可以满足软件开发应用实践朝硬件系统(原型呈现)的演进。如果你想如愿以偿地缩短周期，或多或少按多功能型团队(cross-functional teams)方式运作是需要的。 软件方法论，即使雇用一群牛人并让他们自我组织，也是糟糕的，因为他们时常搞得“cargo-cult”(货物崇拜，敏捷开发里的知名小故事，形而上)：我们在做stand-ups(每日站立会议)，我们有优先顺序的backlog(优先待办事务)，我们甚至看在老天的份上实践了continuous integration(持续集成)。我们的到头来的结果为什么还这么差呢?因为你忘了最重要的事情：建立一个学习能力和适应能力都很好的组织。

　　1.虽然像Laurent Bossavit说的(私下交流)，“一个开发者掌握的技能，受限于他/她所掌握的方法及他/她偏好一种语言甚于其它语言”。

　　2.我并非建议放弃在软件开发中的可行性试验，在这里的上下文中，我这么阐述是对的。恰恰相反的是，我说的是我们并没有努力去做好，做得还远远不够。