在瀑布式环境中,我已经阅读并教授了很多关于正式需求收集的内容：花费数月时间研究用例,将这些用例转换为规范,最终提供一个没有人想要的臃肿的crapware.

我正在开展的项目有一些特点：利益相关者是学者,开发团队非常小(2-3 FTE),总体时间很短(3-9个月),利益相关者非常灵活关于产品的最终形状. (他们要求A,B和C但是得到A,X和Z – 没问题.)如果对利益相关者的访问有限,我们通常会定期进行：比如说每周1小时.

以上的一些后果：

>我们需要在利益相关者面谈时间的10小时内进行编码,通常更少.
>我们可以在整个过程中继续收集需求
>范围非常灵活.时间和预算是固定的,但范围是当我们用完时间时完成的任何事情.

显然我们使用敏捷方法,但由于团队成员资格非常动态,因此没有真正的机会建立一个可靠的scrum流程.

在PM /客户联络的角色中,我养成了一种习惯,即需求收集电子表格(Google Docs),其类别如下：

>“我们现在可以实施”(我们认为我们理解得很好,而且它是defini
>“需要更多细节/研讨会”
>“低优先级”(通常是一个用户提到过的东西,但我们从未听说过)
>“继续讨论的大功能”(一个重要的新功能集,特别是与其他东西的集成.通常这些都很好,但我们只是不知道我们能否及时完成 – 在这种情况下,我们不应该’开始.)

我的“方法论”没有解决的问题我希望听到以下建议：

>早期捕捉showstoppers – 嗅出严重限制我们选择平台/技术/解决方案的要求/ ……
>构建和安排未来的需求收集会议,以便我们知道在遇到不确定性之前我们可以在某个特征集上工作多长时间.
>知道某些事情是否足够优先,它肯定会削减(如果没有,不再花时间调查它)
>管理相互依赖的功能集
>管理可以不同程度开发的功能(例如,以30％的成本获得80％的收益 – 我们如何知道我们是否应该花费其他70％？)
>管理选择(在一种情况下,我们实施认证机制X或Y – 两者都没有多大好处,但两者都有很大的不确定性)
>依赖关系：通常,在我们看到用户对X的反应之前,开始实施Y是没有意义的.
>问题跟踪器中“需求”和“问题”之间的关系.您是否只是将所有内容都放在跟踪器中,并在了解更多有关它们的情况下不断更新问题,可能会拆分或合并它们？

所以 – 我很想知道其他人如何解决这些问题.搜索“需求工具”并没有什么用处 – 只是一堆企业级桌面CASE工具.

最佳答案 在我看来,您需要与利益相关者/业务/客户进行更多交互,以便1.优先考虑功能,2.为UAT创建测试计划,以便您知道何时可以停止添加功能.

灵活的范围是可以的,只要您可以说有一组核心功能是必不可少的,这将使用户满意.你说当你的时间用完时项目就完成了.为什么甚至做任何事情？也许你可以减少范围,直到你知道绝对必要的功能是什么,如果用户对此感到满意,不要费心添加更多功能.