【摘要】：对于软件开发而言，大多时候都是等价于要去一个陌生的地方，因此完美的开发模型大多是混合式的，既有不停确认路线的成分，也有确认好路线便马不停蹄前进的成分。而混合的程度会根据人员状况以及工作的特质做调整。开发模型的选择本身是在追求最佳平衡点，而非是在瀑布或迭代之间做出选择，这比很多人预想的要更麻烦一些。
让我们首先回到前文提到的那辆车：若想让这辆车尽快从苏州赶到北京，那么是一路马不停蹄跑过去好；还是走走停停过去的好。
影响这个决定的关键因素之一是认不认识路。如果对路线很熟悉，当然是马不停蹄跑过去更快；如果不认路，又从来不停下来看看地图，问问别人，那就很可能误跑到别的地方去，然后再走回头路。
对于软件开发而言，大多时候都是等价于要去一个陌生的地方，因此完美的开发模型大多是混合式的，既有不停确认路线的成分，也有确认好路线便马不停蹄前进的成分。
如果以项目特质和人员特质为输入，那么瀑布和迭代的尺度将会连续变化，对不同团队而言，完美状况是一个变动点。这种完美状态也可以简单表述为：对于已经有人比较熟悉的，可知的部分用瀑布；对于未知，也不可知的部分用迭代。而混合的程度会根据人员状况以及工作的特质做调整。为找到最佳平衡点，需要考虑的因素其实很多，具体如下。
●人员相关的领域经验。
●项目先例的程度。(www.xing528.com)
●人员流动程度。
●时间限制。
其中，人员相关领域经验越高，项目先例程度越高，人员流动率越高，时间限制越严，越适合倾向于瀑布，反之则倾向于迭代。事实上，这提示我们当人员平均水平较差的时候，敏捷类方法并不适合。
开发模型的选择本身是在追求最佳平衡点，而非是在瀑布或迭代之间做出选择，这比很多人预想的要更麻烦一些。而最佳平衡点的进一步描述将在“完美需求开发之解构”和“完美设计和编码之解构”中进行具体展开，为避免重复，这里就不进一步论述了。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
