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

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

?

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

?

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

?

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

?

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

?

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

?

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

?

?