Scrum和需求

Question

你不能只有用户故事，程序的功能必须以某种方式记录下来。你最终会得到一个scrum的规范文档吗？如果你这样做了，你最终会分配时间来完成这项任务吗？

一个例子就是复杂的工作流程。

另一个例子是加入团队的新成员。

Answer 1

在这个问题上会有很多好的想法。我的个人经验告诉我：

1~工作产品本身就是一种文档形式:假设产品被接受，那么询问它在特定条件下应该做什么相当于询问它在这些条件下实际做了什么-登录并尝试获得您的答案。

2~测试，无论是手动的还是自动的(或混合的)，都是一种文档形式。当然，单元测试可能与技术倾向较低的团队成员(例如：“业务专家”或客户)所使用的领域语言相去甚远。验收测试可能更接近于某种“中间地带”。毫无疑问，BDD风格的测试似乎最有可能构建一种所有人都能理解的通用语言(请参阅这方面的Gojko's Bridging the Communication Gap)。尽管如此，所有这些形式的测试都是一种文档形式，可以用来确定产品应该做什么。

3~根据你的项目在光谱中的位置，你的文档(以及，通常，所有的辅助工件)可能需要更高或更低程度的仪式。较小的产品，较小的团队，在上市时间至关重要的地方，可能会发现与其增加的价值相比，非常正式的需求文档成本太高了。另一方面，跨越多个团队和多年开发的超大型项目将发现正式文档的ROI非常不同。

4~在完美的世界中，我们可能不需要以工作代码(在象牙塔中也是不言而喻的)和测试(主要用于回归测试和-on边缘-以驱动新功能的开发)的形式来记录需求。因此，需求文档的问题是关于完美世界/象牙塔和真实世界/战沟之间有什么不同的问题。当然，答案在每个案例中是不同的，这取决于项目和团队。例如，我们可以说“所有需求都应该保存在这个wiki中，并以最小心的方式维护，等等……”但是，如果团队对wiki不熟悉和不熟悉，这是行不通的。

5~说到底，利益相关者是你应该问的人。当然，应该以协作的方式处理这个主题，因为团队中的每个人都必须在整个项目中与需求进行交互，但您必须找到一种满足利益相关者需求的文档形式。

话虽如此，下面是我在应用Scrum时看到的一些需求文档(为什么我觉得这个词后面总是应该有一个星号？)：

document

• Bulletin Boards

• Wiki

• Wiki +自动化验收测试(阅读: FitNesse)

• Unit Tests

• Manual Test Plans

• User Stories，Use Cases diagrams )(阅读: Enterprise Architect models)

• Whiteboards around

• notes

而且，老实说，我不能说任何一个系统与一个成功的项目有更高的相关性。我想，确实，我们没有什么灵丹妙药。

HTH，谢谢你发人深省的问题！

Answer 2

在每个用户故事中添加“文档”作为一个任务肯定会对你的目标有很大的帮助。

Answer 3

Scrum说你应该在你需要的时候记录你需要的东西；它并不是说你不应该有文档。

因此，如果成品需要一个文件(例如，帮助文档)或生产成品(例如，需求文档)，那么在您的产品待办事项中应该有一个文档任务/用户故事。

然后，应为该任务分配适当的优先级。

对于文档来说，关键点是；

• Document only what need ，only when you need。