您不仅可以以某种方式记录用户故事，还必须记录该程序的功能。你最终得到了scrum的规范文档吗？如果你这样做，你最终会为这项任务分配时间吗？
一个例子是复杂的工作流程 另一个例子是加入团队的新成员。
答案 0 :(得分：3)
这个问题会有很多好的想法。我个人的经历告诉我：
1~工作产品本身就是一种形式的文件：假设产品被接受，然后询问它在某些条件下应该做什么等同于询问它在这些条件下实际做了什么 - 登录并尝试获取你的答案。
2~测试，无论是手动还是自动（或混合），都是一种文档形式。当然，单元测试可能与技术较少的团队成员所说的领域语言相差太远（例如：'业务专家'或客户）。验收测试可能更接近于排序的“中间地带”。绝对是BDD风格的测试似乎最有可能构建一个每个人都能理解的无处不在的语言（参见Gojko's Bridging the Communication Gap）。尽管如此，所有这些形式的测试都是一种文档形式，可用于确定产品应该做什么。
3~根据您的项目所处的范围，您的文档（以及一般来说，所有辅助工件）可能需要更高或更低程度的仪式。较小的产品，较小的团队，上市时间至关重要，可能会发现需求成本的非常正式的文档与其增加的价值相比过多。另一方面，跨越多个团队和多年开发的超大型项目将发现正式文档的投资回报率大不相同。
4~在完美的世界中，我们可能不需要记录除工作代码形式之外的要求（在象牙塔中也是不言自明的）和测试（主要用于回归测试，以及 - 在边缘 - 推动新功能的发展）。因此，需求文档的问题是关于完美世界/象牙塔和真实世界/战壕之间有什么不同的问题。当然，答案在具体情况上有所不同，具体取决于项目和团队。例如，我们可以说“所有要求都应保留在此维基中，并保持最小心等等......”但如果团队对维基不熟悉并且不熟悉，那么这将无效。
5~最后，利益相关者是你应该问的人。当然，应该以协作的方式处理该主题，因为团队中的每个人都必须在整个项目中与需求进行交互，但您必须找到满足利益相关者需求的文档形式。
所有这一切，这里有一些我在应用Scrum时已经看到要求的地方（为什么我觉得这个词应该总是后面跟一个星号？）：
而且，说实话，我不能说任何一个系统与一个成功项目的关联度始终高于其他系统。我想，的确，我们没有银弹。
HTH，感谢发人深省的问题！答案 1 :(得分：2)
在每个用户故事中添加“文档”作为任务肯定可以很好地实现您的目标。
答案 2 :(得分：2)
Scrum说你应该在需要的时候记录你需要的东西;它并没有说你不应该有文件。
因此，如果成品（例如帮助文档）需要文档或生成成品（例如需求文档），那么产品积压中应该有文档任务/用户故事。
然后应该为该任务提供适当的优先权。
关于文档，关键点是;
答案 3 :(得分：2)
您不仅可以拥有用户故事 某种程度上的功能 程序必须记录在案。你呢 最终得到规范文件 用scrum？如果你这样做，你最终会 分配时间来做到这一点 任务？
为什么你不能只是有用户故事？这些规范文件的用途是什么？生产这些文件的投资有何回报？好处是否会影响成本？如果没有，那么创建这些文件所花费的时间，更重要的是维护是不是浪费了？
我知道我提出的问题多于提供答案的问题，但我认为Scrum和其他敏捷方法的一部分就像精益做法一样，迫使你重新检查当前的做法，看看它们是否仍然有意义。
对于规范，一旦该功能启动，谁将更新和维护这些文档？在我去过的大多数公司中，文档稀疏，过时或很少被引用。
相反，为什么不使用可执行测试或BDD，以便文档成为代码的一部分并且是可执行的。例如，请参阅Ben Mabey's talk on Cucumber
如果由于某种原因，出于法律合规目的需要特定类型的文档，您可以随时将其添加到团队的“完成”定义中，但是，我发现在大多数情况下，故事和测试更多比足够形式的文件。
答案 4 :(得分：1)
也许我对这个问题的理解是完全错误的，但我理解的是OP对用户故事和要求之间的不匹配感到不安。我有理由说。
在我看来，用户故事讲述了如何向产品所有者展示一大块功能。故事的语言可以是产品所有者可以理解的东西，但主要是开发人员。您可能有故事描述业主甚至不直接要求的事情，但这些故事是对事物的细分。
另一方面，要求是域用户使用语言的详细规范，说明系统需要做什么才能有效。在许多情况下，需求文档不是可选的（例如固定价格项目）。
我所做的是两者兼而有之。我有一份需求文档，在我的大多数scrum故事中，我的笔记中都有一些内容将该故事与一个或多个需求项链接起来。它就像“参见FR-042和FR-45”（例如功能要求的FR）
一样简单答案 5 :(得分：1)
我想你在这里要求一些不同的东西。如果您要添加新的团队成员，那么系统的文档应该面向他们在团队中的角色，作为入职流程的一部分。
如果您正在谈论记录系统功能;在我们的组织中，我们的培训团队将功能记录为发布的一部分。他们在Sprint评审（演示）期间参与（作为利益相关者），然后提供培训环境，其中包含新功能，以便在发布之前准备培训材料。
如果您正在讨论提供易处理性的文档，那么您的待办事项可以通过正确的流程和服务进行处理。控件添加。
这些不同项目中的每一项都需要进行规划和深思熟虑的流程开发，以有效地发挥作用并满足团队的需求。我们已经将这些项目中的每一项都包含在我们的回顾中，因为确定了一个问题，然后随着时间的推移开发了我们的流程。
答案 6 :(得分：0)
除了James Kolpack所说的，用户故事地图应该在项目完成后继续存在，因为它也是一种文档形式。我相信我们计划将一些文件转换为生活在Wiki中的文档。
我们的想法是，对于需要维护系统或在将来添加增强功能的人来说，本文档非常有用，因为他们将了解用户的观点。
答案 7 :(得分：0)
我主要同意Todd的观点，但有时我的团队的一部分任务是制作文档：文档是用户故事本身我们的PO要求交付。
在这些情况下，我们遵循以下准则：
根据我的经验，文档更容易编写并启用某种测试（您要求某人（通常是PO）阅读文档并说出考虑目标是否正常）。
答案 8 :(得分：0)
您编写文档以验证您的系统。如果以反映用户与系统交互的格式正确编写，则用户故事的用途相同。我将建议使用BDD并使用Gherkin语法编写故事。最终，您的方案成为您的验收标准，有助于验证系统是否正常工作。
答案 9 :(得分：0)
我们有一个文档团队，负责制作＆＃34;说明手册＆＃34;对于我们的产品本手册围绕产品的主要功能以及用户可以在这些功能中执行的任务进行构建。
每个sprint，Scrum团队都会处理用户故事，为产品功能添加功能。
在sprint计划之后，文档团队会与Scrum团队会面并查看将在此sprint中开发的用户故事。然后，文档团队通过编写初始文档开始增强说明手册。在sprint期间，文档团队会跟踪用户故事的进度，并可以将该产品用于测试环境。在sprint结束时，docs团队完成更新的说明手册并添加最终的屏幕截图等......
使用说明书作为每次冲刺发布的一部分。