他们没弄明白。他们做错了。直到他们遵循了所有的准则和实践，他们才是真正的敏捷。”你之前有没有听过这类评论？随着敏捷世界中杂交的增长，对不纯粹的敏捷思维的鄙视也在增加。讽刺且自相矛盾的是，敏捷的主要成果就是让我们摆脱了瀑布过程一体适用的哲学。现在，敏捷中狂热的人们在犯同样的错误……把敏捷作为唯一的方法。本文将尝试展现，作为软件专业人员寻求持续创新和更好的方法时杂交不仅是必要的，甚至是我们的首选。
瀑布式开发不起作用
敏捷主义者以说这句话而闻名，事实上他们有大量支持他们观点的证据。但如果他们的雄辩言辞换种说法或许会更准确些：“敏捷往往对在特定类型的组织内使用特定类型技术的特定类型项目效果更好。”并不是说瀑布过程绝无效果，只是它并不是对所有项目都有效。你能找到许多业界老手，他们会告诉你他们用瀑布过程效果不错。他们在撒谎？他们在拒绝变化？
事实是这两种技术都能依赖于各种因素而发挥作用。我将在下面探讨其中一些因素，除此之外还有些其他因素。我强调这些是为了展示在软件开发投入的付出和被感知的过程中情境在其中有着怎样重要的作用:
1. 项目类型
这是个固定投入的软件产品还是个符合当前策略并将形成核心业务的软件产品？固定投入软件产品通常更适合于传统的瀑布过程，而史考特证券会发现使用敏捷会更有帮助。为什么呢？第一种情况下，项目被视作一种开支来管理、跟踪和监控。在史考特证券，他们的在线交易平台“就是”他们的业务。可以在我之前的一篇文章：为什么有些公司敏捷实施不成功？中找到对这一区别的更复杂的解释。
2. 使用的技术
与传统的复杂客户端应用程序相比，基于web的技术通常需要较少的开发时间。由于浏览器遵循（大部分）行业标准，因此基于web的技术更易于实现。它们是最适于应用敏捷方法论的技术。如果你正在部署一个复杂客户端产品，要安装在公司中15个部门的16,000台笔记本电脑、台式机上的各种操作系统（或虚拟机）上......你的开发过程将更具瀑布式特征。你或许仍会在以一定时长的迭代周期中进行开发，每两周一次把代码部署到测试环境中，但这一产品以两周为一个迭代交付一次是复杂且充满风险的。这需要更多的规划。每30天就安装些新东西到每个人的台式机上可不是个好主意。到第一次安装相关的问题都得到解决的时候，就要准备另一个30天的安装了。这个产品会处于持续的变动状态。功能性的交付非常重要，但稳定性、一致性和性能也同样重要，这需要在所用的各项技术和产品的定位间进行权衡。如果更多的变更和快速交付功能很重要，当前的技术组合是否能提供支持？如果想要的是一个稳定的、可信赖的几乎不会当机的系统，那么可能就不必重做整个软件交付过程了。
3. 项目复杂度
当项目是个新的社交媒体创业项目时，敏捷与之乃是天作之合。项目的复杂度很可能包含在开发者/创立者的脑海，并且他们对信息的需求的澄清就在附近（甚至可能就在同一个房间中）。他们的开发投入可能不需要任何集成的硬件。他们有自己的开发/发布周期，不会与公司其他部门打交道。他们可能不会把他们的软件与其他软件团队整合，并最终可能在能获得反馈和信息的业务过程改进上也没有任何投入。
将其与一个横跨公司六个部门的一个六西格玛黑带业务过程重组项目相比较。这一项目的软件开发部分也许只是全部投入的一小部分。他们对信息和需求的澄清的需要将由一个“指导委员会”决定，这个“指导委员会”可能一个月会谈不超过一次。可能还有其他外部软件需要他们提供接口并从中获取信息（或者发送信息给对方），因此对集成的谈判和时间的安排是很关键的。
有一点要弄清楚：项目的复杂度越高则更有可能需要更深入的规划......甚至是必须的。复杂度的情境给了我们机会停下来思考我们的方法。
4. 文化
公司是否易于接受新想法和新思维方式？他们是否想探索敏捷软件开发？他们通常如何适应变更？如果公司是保守的，那你对敏捷的引入也许不会有大量追随者，也许还会由此产生敌人。谨慎是必需的。更自由的组织很可能会把变更视作自由和授权。但另一方面，组织可能会过于狂热。在这种文化下，新的思维方式会快速流行起来，并在洞察力和深思有机会决定行止之前快速找到富饶的土地扎根下去。
第三条路
在敏捷和瀑布之间是实用主义。这就是一些车间，在其中把敏捷和瀑布的零部件拼凑在一起，成为自己的过程/行动。关注技术和结果，跳过教条和浮夸之词。
实用主义者通常被他们的敏捷同仁们奚落为“不愿意坚持到底”。相反，我总是会争辩道，他们所做的才正是最初敏捷创始人们所做的：在如何开发和构建系统上来试验新的想法。考虑到上面提到的情境，实用主义者明白，没有灵活性的教条的软件开发方法是注定要失败的。
的确，新想法来自实用主义者。
远不是“没弄明白”，他们正在寻找那些始终工作良好的甚至可能对所有项目都有效的部分。这种试验、调整和不随波逐流的意愿是创造力最纯粹的形式。这种意愿应该被鼓励和被照看。根据历史经验，这会孕育出某种变革。
下面有一些实用主义的方法，是我所看到和听到的似乎有些道理的：
1) 在棘手的问题/缺陷或关键架构系统上运用结对编程 —— 与其把这一项极限编程技术作为规范供起来，实用主义者更愿在需要时使用它。此外，我曾见到过一个团队，他们在一个房间里，一起讨论代码和关键集成部分以消除分歧，从结对编程演变成了群体编程。
2) 在Scrum方法之上附加更多的传统项目管理实践 —— 热切的敏捷人士会告诉你这从来都行不通。但以我的经验来看并非如此。例如，一个有着繁杂业务流程组件的项目中软件开发项目只是全部投入的一部分。你也许能用scrum来开发软件，但这样的scrum过程会需要与整个业务项目及它的实践、程序、时间表、风险和预算紧密地结合起来。多数企业不会选择scrum方法来进行一个业务流程项目。
另一个例子是一个采用离岸供应商的项目。由于时区不同和供应商有限的资源这类项目会很难以协调。另外，除了项目成本，供应商也许会要求你为每日的15分钟站立会议，迭代回顾时间和迭代规划时间付账。你不得不权衡额外的沟通是否值得在项目成本中增加额外费用。通常你能够通过每周的碰头会和详细定义的规范来达到同样的质量。此外，供应商通常有交付客户所求的合同义务。否则，就没人付款。这种情形下对“正确理解”的鼓励是非常高的，这也许使得瀑布方法更合意
3) 敏捷中的变更管理 —— 敏捷拥抱变化，但拥抱任何和所有变化会导致团队走向失败。我们都曾参与过这样的项目：客户在整个开发过程中频繁地改变主意，多次修订一组故事，甚至是修订在数个迭代之前就已经开发出来并测试通过的原始需求。这么做也许有很好的理由，但也会有很不好的理由：举棋不定的product owner注意不到或是考虑不到预算的问题并且觉得项目结束遥遥无期，或是需要“亲眼见证”后才会认可。在这些情形中的项目范围蔓延危害整个项目，也许使得领导层对敏捷产生怀疑。由scrum master或更传统些的项目经理精心安排的更强的变更管理技术越来越有必要，用于记录系统的进程、调整预算和进度偏差。
4) 用户故事经理 —— 敏捷方法就是团队和product owner在一个sprint规划期间把这些放在一起。然而，这常常导致故事写的不好，没有说明所有细节。敏捷需求误解是常见的问题。委任一个全职的用户故事撰写者对一个项目来说是昂贵的，也是值得的。清晰的用户故事会使得更容易编码、更好测试和最终更高的质量。
这仅仅是一些我看到过的事情。但是，我很希望能听听大家的经历。你们在敏捷和scrum中看到了什么创新？
总结
实用主义者不会把敏捷或是瀑布这两种方法看成‘要么接受要么放弃’的交易。我愿意把他们看作把世界视为想法超市的独立思考者。
“让我们召开每日站立会议吧，但我仍然需要甘特图来与其他部门结合在一起。”
“我喜欢每30天就向我们的客户展示我们的工作，但我需要一些强有力的变更管理，因为这个客户有些非常古怪的想法。”
敏捷杂交是好事。它会促进实践中的创新。没有敏捷杂交，我们无疑将重复犯前敏捷（pre-agile ）世界中的错误。从某种意义上来说，极端敏捷人士是对的：实用主义者没有正确地遵循方法论。但，这不是坏事。
关于作者
Christopher R. Goldsbury是一名软件开发专业人员，在职业生涯中他担任过各种角色：开发人员、架构师、scrum master、开发经理、项目经理和质量保证经理。Chris把他的经验和想法写在他的博客上。