agile - 用于收集与设计重叠的快速而肮脏的需求的工具和技术

Closed. This question is opinion-based 。它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文来回答。

6年前关闭。



Improve this question




我已经阅读并学到了很多关于正式需求收集的知识，在瀑布环境中:花费数月时间磨练用例，将它们变成规范，并最终交付一个没人想要的臃肿的垃圾软件。

我现在从事的项目有几个特点:利益相关者是学者，开发团队非常小(2-3 个 FTE)，总体时间框架很短(3-9 个月)，利益相关者非常灵活在产品的最终形状上。 (他们要求 A、B 和 C，但得到 A、X 和 Z - 没问题。)我们通常会定期接触利益相关者，如果访问受限:例如每周 1 小时。

以上的一些后果:

我们需要在利益相关者访谈时间的 10 小时内完成编码，通常更少。

我们可以在整个过程中继续收集需求

范围非常灵活。时间和预算是固定的，但范围是我们用完时间后完成的任何事情。

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

在我担任 PM/客户联络员的角色中，我养成了将需求收集电子表格 (Google Docs) 的习惯，其类别如下:

"我们现在可以实现"(我们认为我们已经足够了解它了，它的定义是

"需要更多细节/研讨会"

“低优先级”(通常是一位用户曾经提到过的东西，但我们从那以后就没有听说过)

“要继续讨论的重要功能”(一个重要的新功能集，特别是与其他功能的集成。通常这些会很好，但我们只是不知道我们是否能及时完成 - 在这种情况下，我们不应该t 开始。)

我的“方法论”没有解决的问题我很想听听关于以下方面的建议:

尽早捕获阻碍 - 嗅出严重限制我们选择平台/技术/解决方案/的需求...

构建和安排 future 的需求收集 session ，以便我们知道在遇到不确定性的迷雾之前我们可以在某个功能集上工作多长时间。

知道某件事是否具有足够高的优先级，它肯定会被淘汰(如果没有，就不要再花时间调查它)

管理相互依赖的特征集

管理可以在不同程度上开发的功能(例如，以 30% 的成本获得 80% 的 yield ——我们怎么知道我们是否应该花掉剩下的 70%？)

管理选择(在一种情况下，我们是否实现身份验证机制 X 或 Y - 两者都没有太大好处，但两者都有很大的不确定性)

依赖关系:通常，在我们看到用户对 X 的 react 之前，开始实现 Y 是没有意义的。

问题跟踪器中“需求”和“问题”之间的关系。您是否只是将所有内容都放入跟踪器中，并在您了解更多问题时不断更新问题，可能会拆分或合并它们？

所以 - 我很想听听其他人如何处理这些问题。搜索“需求工具”没有发现任何有用的东西——只是一堆企业级桌面 CASE 工具。

最佳答案

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

灵活的范围是可以的，只要你能说有一组核心功能是必不可少的，并且会让用户满意。你说时间用完了，项目就完成了。那么为什么还要做任何事情呢？也许您可以缩小范围，直到您知道绝对必要的功能是什么，如果用户对此感到满意，就不要再添加更多了。

关于agile - 用于收集与设计重叠的快速而肮脏的需求的工具和技术，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9170807/