横跨许多大洲和时区，做分布式软件开发是现实的。根据我的经验，在分布式开发环境中，瀑布式和敏捷软件开发方案都有缺点。本文中，我将要演示，如何做一个混合的瀑布式/敏捷模型，并结合敏捷开发模型最好的特性和最好的传统的瀑布式软件中开发生命周期模型。

　　瀑布式模型软件开发，仍然有很多组织机构在使用，它有好处也有弊端。它做的很好，因为在代码开始写之前，它强调建立许多正规的文档——像适当的需求、功能说明书、技术说明书和技术架构文档。然而它做的不好，因为它的项目交付时间一般都非常长。所以，你经常等几个星期或者数月，在软件交付前，从客户或者是远程分布式开发团队的软件开发经理，发现你一直偏离方向，这已经太晚了。

　　敏捷开发发生在短迭代中，并在短时间内发布。如果你有一个工作版本，也就是说，每10天，或者更早一些，结束交流的分歧。客户得到一个发行版本和一个演示版本一起执行，提供流程修改的反馈，这个反馈应该在这个周期的前期提供。你不需要等几周或者数月，就可以发现软件交付一直偏离方向。用户尽早的看到软件，提供一个反馈，告诉开发者是否正确。

　　具有讽刺意味的是,在现实中，敏捷的短迭代允许需求改变被看成一个缺点。项目经理、外包公司、CIO和其他人担心敏捷只会大幅度地增加掌握范围之外的因素，导致范围蔓延。

　　我发现另一个问题就是纯粹的敏捷开发方法，最好是所有的工作人员都在同一个地方。而且，面对面交流比通过视频会议、电话和即时消息产生的分歧要少。瀑布式开发在初始阶段的时间不是很密集，这可以帮助减少在分布式开发项目中的交流问题。

　　混合瀑布/敏捷开发的优势

　　混合的瀑布式-敏捷开发方法可以更好的适合分布式软件开发，尤其是在横跨多时区的开发。这会保证有一个正规的文件流程。也会确保正规的文档流程先有一个主要的预期，但是为了我们更正使之成为好的流程，敏捷开发方法应具有灵活性。最重要的是，我们不能等到项目的最后几周或者几天内，才发现一直在交流上有分歧。

　　在软件开发的工作中，90%的问题是因为客户和开发团队之间缺乏适当的沟通。如果你在早期就沟通，那么开发会更加顺畅。混合的瀑布式/敏捷方法强调沟通方面都要通过它的周期，如这张图所示。

　　混合瀑布式/敏捷开发模型精选

　　上述流程是一个指示性的流程。有些部分可能已经由最终用户的IT组执行了。例如，他们可能已经准备了需求文档、技术说明书和功能说明书。或者，他们可能只有一个需求文档。开发团队最先根据情况来选择适合的流程。

　　混合瀑布式/敏捷流程的关键组件

　　每个项目都需要一个详细的项目计划

　　在这个提示中，项目计划没有显示在流程图里，因为，有时你在项目投标之前就需要去完成它。同样，它有时也可能是交付的一部分。这个流程，我用微软的项目，但是，也有一些其它可用的管理工具。

　　在开发的每一个阶段，为客户列一个问题清单

　　从RFP文档到需求文档，在每一个阶段，开发团队必须生成一个回答客户问题的列表，收集那些他们不清楚或者不知道的问题的答案。更好的得到这些问题，尽早找出答案，而不是对任何事情的一个假设。

　　有些文件是可选的

　　例如，功能说明书、技术说明书和技术架构文档都是可选的，只能根据情况来选择并使用。如果你的团队正在拟订一项短期项目，设计网站的一部分，那么建立这些文件可能有些夸张了。在我们开始编码之前，这个流程展示了我们或者客户可能需要的所有文件的超集。

　　一个高等级的设计文档总是需要的

　　对于每一个项目，一旦通过详细的计划书阶段，开发团队会建立一个高等级的设计文档;即使它只有几页。这只是演示用户接口设计的实体模型等。做这件事可以确保开发团队可以完成各方面的开发工作，并在编码之前有机会提问，并澄清一些事情。

　　必须达到每周、每十天或者定期发布版本的最后期限

　　在混合瀑布式/敏捷模型中，项目计划分解开发和测试的可用时间到每周、每十天 -- 或者最大的期限 -- 每两周建立一个版本的周期。根据这一数据，就会有一个没有错误的版本。

　　这可能会为工作版本增加一些灵活性。的确，开发团队可以开一个没有客户存在的会议，决定建立一个工作版本; 但是这个工作版本的发布不能因为任何理由而推迟。这是建立一个严格的工作和发布版本的原因。每一个工作版本会有一个正规的本地测试。这也保证了软件的测试比瀑布式模型测试的次数多，间接的提高了软件的质量！

　　确保请求改变是否需要一个变更指令

　　当从客户那里得到反馈时，建立一个缺陷或者标签的条目，首先测试的是，查看变更是否需要一个变更指令。一个简单的不需要变更指令就能修复缺陷和一个需要变更指令的漏洞之间有什么不同呢？像字体、颜色或者难以理解的简单事情都可以算作缺陷。如果涉及到超过四个小时的工作，就会考虑改变指令。这只是一个经验法则，可以按照具体项目有所改变。

　　选择敏捷、瀑布式或者混合敏捷/瀑布式

　　软件开发中纯粹的敏捷和纯粹瀑布式模型工作在特定的情况下，其他的情况都失败的很惨。对于分布式软件开发来说，无论它是外包或是内部使用，混合的瀑布式/敏捷方法提供了世界上最好的东西：在一个半正式的流程开始时，增加敏捷方法的灵活性。范围蔓延是许多软件开发方法的最忌惮的事情，在开始的时候提供一个半正式的规范方法，可以限制范围蔓延，在开发周期中，还允许一个超出范围之外的异常流程。