敏捷需求是否源于不同的瀑布收集？

转向敏捷开发是否就不需要前端需求的收集了?这是否意味着开发团队也要负载业务端的需求?

无论是否是敏捷，在努力开发软件产品之前没有收集需求的话，计划都将失败。有效的敏捷需求收集与有效的需求收集是一样的。自从第一天起，开发人员就一直努力编写代码，而没有充足的需求和设计。我们都嘲笑这幅漫画标题，“大伙已开始编码，而我却要寻找需求。”这的确很好笑，但它蕴含的事实却让它变得一点都不好笑。虽然，在某种情况下，敏捷自欺欺人地认为卡通中的方法是聪明的做法。

找出并明确地捕捉到正确的需求确实需要活跃利益相关者的互动，但却不等于毫无节制地绘制不实用的文档，以至于没有人阅读，最终才证明这是错误的。忽视利益相关者，这是愚蠢的做法，但我知道有些人已经在思考他们应用怎么做了。

虽然可能主要由于无知和善意的狂热，但敏捷的公关经常帮倒忙，制作出不加选择地、虚假的非敏捷的方法。因此，大多数的所谓的敏捷人员(Agilistas)把所有非敏捷开发归为成“瀑布式”开发，这很愚蠢。描写瀑布式开发的罪主要有，它可能浪费了大量时间来记录每一个需求细节，而没有做出任何有用的工作(如，编写代码);而且还没有用户的参与。

当然，真理也有点不同。有些项目盲目地使用愚蠢的实践，以符合敏捷的瀑布式的关键看法(然后再把问题归咎于瀑布式)。但是，如果不大部分的非敏捷项目，也是许多项目已经一直在使用大量灵活的迭代概念，这一概念被认为是敏捷产生的。毕竟，50年左右的非敏捷项目创造了基础设施和支柱生产系统，这都使敏捷看起来是更快的开发方法。

经典著作如Fred Brooks的《The Mythical Man-Month》和Steve McConnell的《Rapid Development》的书中指出，为了有选择性地选择正确部分、构建正确的秩序，并确保他们恰当地运行，整体视角很重要。为了看到整体产品，一个人首先必须识别最高级别的真实业务需求。这些是可交付的“什么”,这也是产品必须满足的。

然后，随着每一个组件部署持续的工作，那么相关的、真实的业务需求需要趋向于更具体的细节，这样响应产品需要可以进行定义。这种方法比敏捷，却也是真正的敏捷(作为一个灵活的同义词)和成功，因为第一次定义的合适的高级别需要使随后的需要具有选择性，可即时迭代开发合适的碎片。

相比之下，敏捷需求收集过程往往忽略了这些问题。敏捷项目常常关注于单独的组件功能，这将马上就会构建。这些特性的识别本质往往是独立的，却没有整体的指导上下文。提前跃过明显的架构和设计将会加速这一功能的交付周期，但一般在长期价格上会有一些困难以及一些目光短浅的特性。

另外，有效的敏捷项目克服了这类“零冲刺”的弱点，从而识别出整个史诗/用户故事集合，这是一种业务需求。这一集合提供了整体观点，并对初创企业的冲刺提供了指导流程，帮助构建独立的功能来更好集成他们的的冲刺功能。敏捷和非敏捷方法都区分了业务价格的优先级，这根据利益相关者而定，而不是开发人员。然而，在业务上下文中，开发人员的需求和问题也会影响项目行动的本质和结果，无论他们是否具有冲刺特性。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友