混合项目结合了各种方法，以利用两者的优势并最大程度地减少它们的每个缺点。实施成功的混合项目意味着需要两者都有经验。

我将举两个使用混合方法的示例。

具有硬件和软件组件的大型项目可以使用混合方法：硬件组件采用瀑布式设计，软件组件采用敏捷性。

相关文章： 敏捷工作的5个教训& Waterfall

第二个例子是一个更具挑战性的例子：一个复杂的软件项目，其中使用敏捷和瀑布创建GUI，用于功能开发。

混合项目使大多数团队成员紧张，但它对业务分析团队的影响更大，因为他们必须跟踪正在开发的所有内容。

上面的混合项目示例可以视为教会与国家的分离。在硬件部分使用瀑布式开发和在软件部分使用敏捷性并不困难，而且无论如何，BA团队很可能会分开。 “真正的”混合项目很少见，但显然将成为现实。所谓“真正的”混合项目，是指同时使用两种方法开发不同功能的软件项目。

我认为，业务分析师在进行“真正的”混合项目时面临五个主要挑战：

1.去哪里

知道将使用瀑布完成项目的哪一部分以及使用敏捷完成哪些部分可能会很复杂。瀑布任务可以是硬件实施，应用程序安全性功能，企业业务体系结构和关键核心功能。敏捷任务可能是可以更改的GUI设计或业务功能。

从项目开始就确定应该在哪里设置。如果不这样做，以后可能会出现问题。当项目中出现问题时，应与项目经理和团队中的其他任何高级成员进行讨论，并根据情况做出明智的决定。它不仅应该由业务分析师来决定。

2.  需求优先级和集成

在混合项目中，功能优先级划分可能非常困难。业务分析师必须考虑将使用瀑布开发哪些功能，这意味着它们将在项目结束时交付。
敏捷开发的某些功能可能取决于先前的功能，如果先前的可交付成果是在瀑布中开发的，则应在项目结束时重新安排它们的时间。

由于相同的问题，需求集成也具有挑战性：某些功能将在最后交付，而另一些则在交付之前。

3.需求描述和文档

在两种方法中，需求描述的详细程度有所不同。在混合项目中，业务分析师必须准备好同时执行：瀑布部分的需求和敏捷部分的需求。可能出现的问题是文档方面的空白。一些功能将更详细（瀑布功能），而某些更高级（敏捷功能）。

我认为最大的差异将出现在测试文档中，因为在瀑布图中，测试用例是在分析阶段针对所有功能开发的。在敏捷中，在每个迭代中为每个用例开发测试用例。这意味着应用程序测试总体上将非常困难。

4.跟踪/识别缺少的需求

追踪需求，最重要的是，识别缺失的需求将具有挑战性。一个常见的错误是假设将在瀑布中开发某个功能，这意味着在项目的后期，业务分析师可能会继续进行其他任务。

另一个问题是由于零散的分析而确定缺少的功能。在瀑布阶段采取了一些要求，而在敏捷冲刺阶段则采取了其他要求。自然，有些需求可能会被忽略，并且永远不会发展。无论用于开发该功能部件的方法如何，都必须维护一个通用的需求矩阵，并且业务分析师必须参与项目的两个阶段-敏捷的业务分析师和瀑布的业务分析师都必须没有。

5.沟通与协作

在任何项目中，沟通都是非常重要的，但在混合项目中，沟通是失败还是成功之间的区别。广管局的角色必须更多地视为团队的推动者。无论采用哪种方法，BA都将了解整个项目范围内正在开发的所有功能，并且他们将处于独特的位置，可以调解误解，提供澄清，甚至帮助团队理解为什么应使用以下功能开发特定功能某些方法。
我个人认为，“真正的”混合项目还有很长的路要走，大多数混合项目将隔离敏捷和瀑布方法。我认为这种情况将持续数年，因为仍然有一些公司在敏捷方面挣扎。实施敏捷项目的公司仍然难以理解，业务分析师在敏捷项目中可以发挥重要作用，而且这种作用并没有过时。

您认为同时使用两种方法进行软件开发是否可行？

您是否同意未来将会是混合动力？您将在列表中添加或删除哪些项目？

¹ http://www.bridging-the-gap.com/traditional-vs-agile-the-future-is-hybrid/