敏捷开发方法需要为最后阶段定义最小需求。换句话说，所创建的任何需求细节都必须是对整个团队有关键性质的。那么，怎样确定最小需求，又由谁来负责呢？协作式或分布式团队有什么不同？如何应付这些需求在细节和优先级上的变化？下面是关于这些问题所做的解答。
如何确定最小需求？
确定最小需求是一项既简单又复杂的工作。简单是指如果作对了就会一切顺利；而复杂是指这里牵涉到许多元素，比如团队的规模大小、团队成员的融洽度、所构建的软件版本的复杂度、所开发的是插件模块还是全新系统或产品，以及在业务上广度与质量哪一方面更为重要。因此，你可能需要一些如何为团队确定需求的建议。本文将就这方面提供了一些简单的建议。
选择细节等级
首先要确定需求细节要做到什么程度。下面的表格提供了一些参考，但在最后阶段仍然要随时做好更改的准备。
细节较多 细节较少
新系统 对现有系统进行简单到中等程度的修补
分散或分布式团队 处于同一位置的团队
大型复杂的方案 小型简单的方案
新组成的团队 有过协作经历的团队
“需求卡片”不能满足要求时
需求卡片是一种敏捷开发团队中常用且很有价值的方法。这些需求卡片描述了“哪些人需要做哪些事，以及为什么要做”，有时也会用来提供一些关于屏幕样图和测试方案的信息。这种方法或许足以应付小规模的开发，但如果涉及比较大型或较复杂的对其它部分有较强依赖性的模块时，就会略显不足。
不要勉强使用不适合的方法
有许多已经经过实践证明的需求采集的方法。但适时选择合适的方法是需要技巧的。比如，有时只需要在需求卡片上用文字简单地概括出“哪些人、做什么、为什么这样做”即可。而有些时候为这些描述添加一些图片可能会更好，比如模拟屏幕截图，或者再加上些脚注。
有时，要了解一个很复杂的需求的流程，可能要用到“用例流程（use case flows）”和/或“模拟过程（simulations）”来确定最小需求。但我认为，用“用例”来描述复杂的逻辑或业务规则（比如验证逻辑）却不是一个好方法。通常文字或表格更适合用来描述这种需求。比如，一个简单的2x2的表便可以用行列分别表示验证规则的功能及其作用，这比用“用例”来表示之间的选择关系要有效得多。
同样，在做模拟过程的时候也有可能因为做得过于细致而浪费与所得价值不成正比的精力。虽然模拟过程在“生动地描述一个概念”方面有不可估量的价值，但要将每一个细节都考虑进去却需要时间。并且很显然，对于开发人员来说，还要反向剖析这些模拟过程并从中抽取出离散的需求来，而这项工作有时会很困难。还以业务的验证规则为例，开发人员通过阅读一个2x2表格便能很快明白要做哪些事，但运行一个模拟过程并反向剖析出同样的信息来却要复杂的多。
此文章共有2页 1 2 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
