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

日期: 2014-10-12 作者:Robi F. Goldsmith翻译:christy 来源:TechTarget中国 英文

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

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

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

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

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

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

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

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

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

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

翻译

christy
christy

相关推荐