瀑布式开发总结

各类大中小型企业所运用的传统软件构建方法，即是众人皆知的“瀑布”型开发方法。此模型存在很多变体，其典型性是在开发初期制定详细的计划，在计划中最终产品已被仔细研究，设计，并且一切详细资料都记录在案。任务已设计制定，并且在工作中使用如根特图表等工具和microsoft project项目管理软件进行项目管理工作。开发团队预计开发项目的时间是以累计其相关每一步骤而得出的。当项目管理者(stakeholder)全面审核开发计划并表示赞同，开发团队即时开始工作。团队成员完成他们所专长的部分工作，即刻转交给其他成员，形成生产流水线的形式。当全部工作都已完成，成品将转交给产品质量控制部门，在这里将会进行在产品到达客户手中之前的全面检测工作。在整个流程中，所有相对于原始计划的分歧都将受到严格的控制，以保证生产的成品与原始设计保持一致。此种模式优缺点明显。有点是非常有逻辑性，在构建之前思考，并全部记录下来，按照计划实施，保持各项食物尽可能的有组织性。弱点是人的参与。比如，要求所有的建议和想法都要在开发周期的最初阶段提出，此时建议和想法将可以被溶入到开发计划中，但是众所周知，好的想法和建议的出现会贯穿整个开发过程，在开发最初的阶段，在开发中期，也可能在产品交付前一天，如果整个开发过程中不容许变化的产生，那么将会遏制创新的产生；另一点就是诸如定型老产品用新技术重新替换之类项目，由于需求分析阶段的盲从性及时间紧迫等等因素的干扰，导致分析出现偏差，最终带来的后果是预估时间不够，项目进展达不到预期的目标，对整个产品开发带来危机。瀑布式开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我们可以把想法尽可能地记录在案，这样将会使信息更可靠地传输到团队的每一个成员的头脑中，但是很多情况下没人会大量阅读文档，即便阅读了也会有产生误解的可能性。

当人参与时，还有一种情况会发生――“实际应用中产生的灵感”――实际开发过程中很多创意是到开发的最后阶段才被提出并且实现的。在项目最初阶段无法准确判断开发的走向。

人的预知未来的能力是有限的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们对于未来作出长远计划的能力的欠缺也导致了你无法估计出未来数月内每周你的工作安排。

另外，瀑布式开发由于成员经常改动想法或不能对不能控制的东西负责等等此类容易促使团队成员产生敌对的关系，让工作毫无兴趣可言。事实上，进一步说，瀑布式开发是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。

另外，一个拒绝变革的流程也会造成低劣产品的产生，最原始的需求未必和最终的产品相一致，拒绝开发团队在实践中不断发现可能性而是其尽善尽美的计划也会是一个失败的计划。

许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是如此具有逻辑性的方式，因此第一的自然反映就是对内部工作的谴责：“如果我们尝试更好的使用它，如果我们的计划更加详尽，记录更加仔细，拒绝任何变革，一切将会很顺利地进行。遗憾的是，许多开发团队只得到的相反的效果；结果越差。”