快速和肮脏的需求收集工具和技术与设计重叠

Question

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

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

以上的一些后果：

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

这似乎与我们遇到的问题相同。我们使用问题跟踪器（bugzilla）来解决问题和要求。这在新模块的初始开发期间非常有效。 但是，如果您需要在半年后更改某些功能或扩展模块的功能，那么您所拥有的只是一个完全非结构化的问题和要求的大量列表。

此外，在问题或要求的讨论主题中给出了大量信息。这意味着要阅读的大量文本大部分都是信息。

因此，到目前为止，在结构化文档（单词）中重写需求似乎是我唯一的解决方案。