敏捷产品开发中的瀑布需求

要点

• 业务需求文档本质上就意味着“契约性”，因此，不应该用于迭代开发
• 业务需求文档经常由“中间人”来完成，很难代表最终客户的观点和期望
• 业务需求文档由特定的组织层完成，经常导致局部最优化
• 在敏捷开发中，业务需求可能导致产品负责人和特性团队之间的关系恶化
• 在敏捷开发中，业务需求文档的使用导致拿到错误的预期并减少了最终客户的参与

每个人都很熟悉传统的业务需求文档（BRD）。

通常，业务需求文档由业务分析师来写，他们是代表职能专业的组织层，该层通常处于最终用户和软件工程师之间。业务需求文档明确讨论客户想从系统中得到“什么”，包括功能性和非功能性需求。业务需求文档是全面的文档：内容详实并具有许多支持细节。业务需求文档基于深远的未来计划，该计划跨多个产品的开发阶段和发布。通过规划，一个单独的业务需求文档可以表示一系统要履行的工作，跨度从几个月到许多月。

从历史的观点上来说，业务需求文档常用于连续的、基于阶段的产品开发，用此做法时，会在全面的系统设计和架构之后事先进行十分周详地设计和文档化，然后是组件化的编码或编程，接下来是质量保证，最终是用户验收测试。在这个过程中（即通常所谓的瀑布式），业务需求文档一旦创建就会在组织中一层一层传递下去，用于签字批准。

正因为如此，业务需求文档代表不同组织单位间（同一组织结构内）的正式契约，其中主要是客户和技术人员之间。此类契约（或协议）通常包含相关的硬性假设：“什么”必须交付，它必须“何时”交付以及为此将花费“多少”成本。

* 备注：请注意，本文的重点并非讨论业务分析师的角色在敏捷软件开发中会成为什么，或者业务分析师能为 Scrum 团队工作带来什么贡献。这是一个单独的主题，需要专门来讨论。

业务需求文档所具有的常见缺点

业务需求文档意味着结论性

针对软件开发创建一份全面的规格说明书意味着事先已知所有最好的解决方案。这同时还假定客户在开发周期内自始至终都不会改变他们的想法，他们想要的东西不会变，也不会提出更好的、更明智的想法。变更通常都是迸发出来的，众所周知的“变更需求过程”就是处理范围蔓延的标准协议。在这个过程中，业务分析师或其他类似的人编写大量的文档，这些通常是在真空里写就的，最终需求未直接听取技术的意见。

实际上，如果开发阶段有条不紊地开展，那么最好的想法和解决方案往往在这个过程很靠后的时候才会得到，而且这种情况极为常见。客户在开发开发之后又改变了最初的想法，这一点儿也不稀奇。在像此类的情况下，为将业务需求文档的范围蔓延辩个清清楚楚，实施了极其繁琐的官僚过程，有些事需要花费额外的时间和工作量。原本，业务需求文档意味着要限制变更；任何事需要更新都需要在业务需求文档定稿并签署之后，带有拒绝变更的涵义。最后，在技术方面没有最初参与意见的情况下写出了业务需求文档，里面是大量“一厢情愿的想法”和客户不切实际的预期，而他们有时寻求的解决方案其实非常复杂和昂贵。

业务需求文档由“中间人”完成

通常，业务需求文档由业务分析师完成，他们代表了特别的职能，由他们的直属领导管理。因为业务分析师不是真正的客户，所以他们未必充分地理解了实际的业务需要。无论业务分析师还是软件开发人员，他们可能都无法了解技术选择、依赖或约束的所有细节。实际上，业务分析师是位于业务和技术之间的“中间人”或翻译，有时会融入到组织的任何一边，但仍然代表一个特定的职能层。虽然经常见到业务分析师融入到组织的任何一边（客户或 IT），但他们仍然代表一个特定的职能层。这种额外的翻译层经常导致错误传达、错误理解、交流反馈环的延长和工作周期的增长。

由业务需求文档导致的契约行为

本来，业务需求文档代表业务和技术间的契约。这种非官方的内部契约把组织按“我们”和“他们”把同一组织分成了两个不同部分。每个组织层关注于它自己的承诺，经常忽略大图和共同的、共享的战略目标。经常由于金钱激励和其他自由决定的津贴和特权驱动，每个组织层都试图把“他们那块儿”做到最好，然后把它递交给其他组织层，它们负责签署一个应收物，然后交出他们自己的交付物，即下一层的应收物。

业务需求文档的产出导致局部最优化

因为每个组织层仅关注于它自己的交付物，它仅为了自己去优化它们自己的内部过程和动力，局部是成功的。这被称为“局部最优化”。至于业务需求文档的编写，它经常看起来就是在开发开始之前编写一个厚重的文档。这是一个组织层为文档编制负责的方式，声称完成和他们“局部的”成功：“业务需求文档最终完成并已签字”。这了做到这一点，一个组织层单纯追求他自己的完成、局部的目标、不对称地扩展，在这种情况下为使业务需求文档在最终期限前完成会雇用越来越多的人。之后文档被签字并交由另一支下游组织层（例如架构师、设计人员、开发人员、测试人员等）使用，为厚重文档负责的团队则闲置起来。由于之前雇了过多的人，该层规模显著扩大，为了看起来忙得其所，他们开始忙于业务优先级不高的工作，如额外的文档和分析，他们“局部最优化”自己以证明规模和行为适得其所。否则，就应该自己缩编，辞退自己的人员。这种现象可以当作组织级浪费加以限制（精益术语为“muda”，即浪费）。

有一般规则之外的特例吗？

但话说回来，可能会有些特例，在这些特例中预先完成很复杂的文档是合理的。为便于讨论，我们举一些极端的特例，如下：

• 组织已经与第三方合作伙伴（供应商）签了一个额外的协议，里面清楚定义了工作清单（SOW），并依法定义了合作关系。像这种情况下，工作将按顺序方式来完成（瀑布式），可能更加需要更详细的文档以规避双方的责任。在此，编制重量级的需求文档是可以接受的。然而，预先限定每件事看起来总不太明智：范围、成本和时间。最有可能的情况是，范围和成本将限制死（与敏捷开发相反，它通常保持范围的灵活性），但如果这样的话，时间就应该灵活一些。

• 组织、团队、部门就预期要在非常短的时间内完成的事承担有限的范围。在像这种情况下，脱离跟踪的风险和典型瀑布生命周期会遭遇的挑战将显著下降。

• 组织想要抛弃一个遗留系统，用另一个系统（更新的技术）来替代它，而且因为保留或复制了大多数已有的功能，所以预计没有多少新的开发（优先级不是必需的而且时间限制也不严格）。这虽不切实际，但确有可能性。在此，文档被用于记录做遗留系统逆向工程期间的研究发现。

观察在敏捷软件开发中使用业务需求文档的异常情况

众所周知，当团队和他们的产品负责人尝试将业务需求文档用于敏捷开发（Scrum 或看板）时，主要有两种情况值得探讨，在这种情况下错误会极其昂贵：

团队试图基于“整个业务需求文档的理解”进行迭代和增量开发。

事实上，业务需求文档是一种面面俱到的、整块儿的文档，通常会囊括很多周或月的工作，把它分解成较小的、独立的需求是个巨大的挑战。结果，因为需求不是独立的，团队就不能安全地评估和提交在短时间内要完成的小的、独立的工作范围。不用说，产品负责人也不愿意面对剪不断理还乱的需求，不愿意去指定各部分的优先级。随后，团队就随便选一块需求来做，用上流或下流依赖来描述功能，无法作为垂直的、跨组件的切片按最小市场特性（MMF）或潜在的团队可独立交付的可交付产品增量来分类。结果，产品负责人和客户在每个迭代末无法看到可运行的产品。这进一步给团队在每个迭代末交付独立的、垂直切片的、跨组件的特性（即：最小市场特性或者 MMF）带来了挑战：产品负责人和客户在每个迭代末无法看到可运行的产品。最终，当交付违背业务需求文档时，团队和产品负责人会中止磋商和权衡，因为业务需求文档代表全或无的合同约定：团队不再“假装”增量开发。经常看到的是，团队开始会有很多迭代把精力放在个别系统组件上（比如只是数据库，或者只是中间层，或者只是界面层），后面的迭代专门进行大量的集成和缺陷修复。这就导致团队没有能力在任何指定迭代为产品负责人和客户交付任何完成的交付物。在一个迭代内缺少跨组件、以特性为中心的工作也会阻碍团队成员间的知识共享和协作。

产品负责人持续用业务需求文档与最终客户交流，以业务需求文档庇护团队

在这种情况下，与团队在一起的产品负责人试图拥抱增量开发的原则。如此，维护的待办事项支撑着产品负责人与团队间的交流。这包括持续的待办事项细化、工作优先级排序和迭代承诺。迭代末的展示试图去交付小的、独立的、跨组织切分的、潜在的可交付功能块…这想法很好…然而…

然而在交流链的另一边：产品负责人和客户之间仍然在以业务需求文档的形式交流。这实际意味着什么？这意味着产品负责人不断与他的客户混迹在瀑布世界的生活中，从他们那里以厚重的、静态的、确定的文档形式接受需求，给他们（即客户）硬性的、全或无的、不可协商的承诺…同时，产品负责人仍然试图与交付团队一起安排工作的优先级并进行协商。产品负责人花了大量的时间和精力，尝试把厚重的业务需求文档分散成小的独立的工作填到待办事项中。这通常封闭来完成，未邀请团队参与以节省他们的时间，这造成许多错误的假设和错误的预期。这还使产品负责人忙于双重转变的工作。

尽管表面上，这是愿意去庇护团队，产品负责人挺身而出“吸引火力”的举动看起来可能高尚而勇敢，但从更深一层来看这种方式是瀑布式的，甚至还很危险。实际上，产品负责人做出承诺并代表交付团队给出承诺。产品负责人站在技术的立场幻想客户欣赏透明度，准备增量地接收工作，如果需要，愿意重新协商范围和 / 或微调主要工作。产品负责人还站在客户的立场幻想技术将在确定的日期、在成本预算内交付完整的需求（按照每一个业务需求文档）。由于产品负责人的错误传达，两边同时产生错误预期。这个问题可能在开发迭代初不那么明显，但在发布日期来临时将暴露出来。这种机能异常通常伴随着错误的报告：比如速度和发布预计之类的敏捷度量（团队和产品负责人在交流时会用到它们），而产品负责人和客户之间的交流会用到 RAG（Red Amber Green），但这两者之间完全就不同步。更进一步来看，这会降低客户对技术的可信度，而且不仅恶化了产品负责人与客户之间的关系，也恶化了技术与产品负责人之间的关系。最终，人人都是输家。

更为有效和安全的方法是，在产品负责人忙于他的关键角色的同时把客户和技术聚到一起，共同来教育。期待教育产品负责人（们）和团队（们）掌握了敏捷原则、形式和框架就能解决业务和技术之间错误传达和不信任的问题是不切实际的。产品负责人以外的组织其他部分也不能置之不理，他们也必须接受敏捷产品开发的核心价值和原则的教育。

虽然产品负责人的关键角色仍然是代表客户发声，但他们不能把自己放到一个制造冲突承诺的位置，制定不切实际的承诺，对参与其中的其他相关人员造成伤害。

关于作者

Gene Gendel是敏捷教练和组织变革代理人。他主要专注于帮助组织和团队在系统设计和组织架构以及整体效率上的提升。Gene 参与所有组织层：高管、中层管理、团队和个人。为成为高效的教练，他会因地制宜使用各种辅导工具和技术，同时还利用训练和指导元素来支持我的辅导。

查看英文原文： WTF requirements in Agile Product Development