本质上来看，开发模型很像是一种流程。在第3章中，我们推导出，流程之关键在于同现实需要的契合程度，而契合度本身又可以进一步分解为同“人”的契合程度以及同“事”的契合程度。开发模型的目标正是寻求一种在限定环境下，最佳组合“人”与“事”的方法，所以其对生产力的影响要大于Review Process这样的环节，大多时候需要单独进行考虑。这里所说的与常说的软件工程中讲述的不同，也许会难以理解，我们来看一个例子：
谈到开发模型时必然会谈到的是瀑布。瀑布模型下，把软件构建的活动分解为需求、设计、编码、单元测试、集成测试、系统测试等环节，并期望逐步推进。这一开发模型似乎从诞生那一天起，就开始饱受批评，比如，被指摘不能很好地应对需求变化等。但这一模型根基是工作分解间的时序和因果关系，其本身并无错处。
其成立的前提和适应场景如下。
●有人能够预先了解要开发产品的各种细节。
●成员能力差异明显，构成明显的金字塔结构（少量极其优秀的人和较多能力较弱的人）。
简单来讲就是在“想的人”对问题域非常清楚的情况下，比较彻底地分离想和做，最终“做的人”不用想。虽然敏捷类思想不太考察这个维度，但事实上当组内一个人极度优秀，而其他人员平均水平比较差的时候，从项目的角度看，比较适合偏向瀑布，而不太适合导入敏捷类的迭代。这个时候使用瀑布，可以获得更佳的生产率—当然你不能走极端，把瀑布绝对化。
但同样是使用瀑布模型如果上面的条件不具备，就会导致灾难性后果。
如，没有合适的人确定需求，大部分勉强决定的规格可能完全没有意义。
设计如果只是纸上谈兵，编码的人又无法修改，那么就会发生无休止的讨论，加剧内耗。
也就是说，假如说团队中的成员A，在经过一定的思考后可以预见到当前的实现方法会导致性能问题，那么就比较适合预先把应对措施定义下来（即使是Big Up Design Front），而不能等迭代出问题再进行解决，后者的内耗明显是高的。
从上面的例子里我们可以得到两个彼此关联的结论。
●人和项目特征决定了开发模型，而非根据开发模型来调整人员配置等。这是因为在特定时空背景下，调整人和项目特征的可能性小。
●假如人和项目的变化是连续的，那么绝对的瀑布和迭代之间程度的变化也是连续的。作为结果，最优的开发模型既不是绝对的瀑布，也不是绝对的迭代，而是一种具体情境下的选择，可能偏向于瀑布，也可能偏向于迭代。(www.xing528.com)
开发模型的价值就在于，如果我们能够在连续中找到这一最佳平衡点，在这一点上内耗最低。与此同时，开发模型对“个人工程素养”，“个人工作意愿”，“组织所能提供的基础力量”这3个因素影响较小。这里稍有争议的可能是“个人工作意愿”，有的人也许会认为非迭代类开发模型因为等级比较森严，所以对“个人工作意愿”有负面影响，但事实上当人员间差距比较明显时，保持比较通畅的职位调整渠道，可能更为重要。
除上述所论之外，商业因素对开发模型的选择也有比较大的影响。如，软件的发布日期等直接和宣传等活动有关。
姑且不论合理与否，瀑布类模型在日程上表现出的是一种确定性，而迭代类模型则与之相反。如果允许迭代，那么潜在的等价于承认软件内在的不确定性（会具体体现在需求开发、设计编码等阶段），这种不确定性体现在日程上就是无法估算软件的准确发布日期—这在很多场合下是不可接受的。
如果有一堆脏东西，那么是把它遮盖住好一些，还是直接暴露出来好一些，这是一个异常复杂的话题。由于本书中剔除了商业因素，因此就不对此进行展开了。
项目的结果与约束条件
在耗费资源一定的前提下，项目对外界的要求越低，其成功的可能性越大。假设项目管理者运作项目时，预设的前提是：每个人都具有雷锋精神。那么很不幸，你的项目十有八九会惨淡收场。
而把这种假设建立在项目组的不可控因子上（如需求不可变化，员工都要是Google那个水平的），那就更加远离务实之精神，而更类似于一种妄想。
因此从项目管理的角度看：人的特质，工作的特质，开发模型3者之间，可控的只能是开发模型，另外两者在大多时候都不具备成为变量的条件。
在《微软的秘密》一书中，有这样一段文字，可为这一观点的佐证。
微软的某位高管说：
我以为我们的管理过程非常独特，只有微软才是适宜它生长的土壤......但这一切都是基于我们公司拥有众多非常出色而又野心勃勃的员工。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
