敏捷者希望开发高质量和高价值的软件,而开发高价值软件最简单的方法就是首先实现最高优先级的需求。这使他们能够最大化涉众的ROI。因为需求经常变化,您需要一个精简的、灵活的方法来进行需求变更管理:简而言之,敏捷者努力真正地管理变更,而不是阻止变更。这一做法有三个版本:
图1概述了Scrum管理需求的方法,其中您的软件开发团队有一堆需要处理的优先级和估计需求(Scrum将这个优先级堆栈称为“产品backlog”)。有几个要点需要理解:
图1所示。Scrum需求管理。
图1中描述的方法非常简单,反映了我认为敏捷构建级别的思想。图2概述了一种更规范的方法,它扩展了上面描述的管理工作项的方法。这种方法是有纪律的敏捷交付(DAD)所建议的默认方法,两者都反映了敏捷交付团队所面临的现实世界。你应该考虑以下几个有趣的改进:
超越功能需求。我们知道我们做的不仅仅是在每次迭代中实现新的需求,我们经常做与需求无关的工作,比如接受培训,检查其他团队的产品,处理缺陷(我认为缺陷只是另一种类型的需求)等等。重点是,不仅仅需要将需求放在堆栈上,我们还需要工作项。
图2。有纪律的敏捷工作管理流程。
图3描述了一种在看板团队中常见的需求管理精益方法。需求/工作管理的敏捷方法和精益方法之间有几个关键的区别:
图3。精益工作管理流程。
利益相关者可以通过以下几种方式添加选项:
没有一种策略在所有情况下都是最好的,你需要确定并选择最适合你的策略。表1比较了这些策略。
表1。比较的策略。
原文:http://agilemodeling.com/essays/prioritizedRequirements.htm
本文:https://pub.intelligentx.net/node/709