参考this buddy question，我想知道如何管理Scrum流程中的规范？我在为sprint分配任务时遇到了这个问题。不用说 - 我是Agile / Scrum的新手。
目前，我们正在使用自己的规格表将StoryId映射到SpecId，反之亦然。我对Scrum的关注更多的是关于项目管理[按时完成工作]，你需要一个单独的流程来管理规范和要求。
我们如何管理Scrum流程中的规范？
答案 0 :(得分：5)
简短的回答是，你没有。
在编写这些规范时要问自己的重要问题是我们为什么要这样做？规范中的值是什么？
规范中的价值通常在于与开发团队沟通业务的想法。 Scrum旨在将业务（以产品负责人的形式）带到开发团队。通过经常与团队互动（记住，个人和流程与工具之间的互动），以及经常查看工作软件，企业可以与开发人员携手合作，生产出能够更好地解决业务问题的软件，而不是试图指出整体在你尝试之前的事情。
这就是敏捷项目如何更好地交付业务所需的产品，而不是他们所要求的产品。
尽管如此，还是有一些基本标准需要满足。我们可以测试这个，就像任何好的测试一样，我们可以自动化它。
看看BDD和Cucumber。除了您的用户故事之外，最好还有一套基本的满意条件，最好是“Give / When / Then”格式。这些条件是最低标准，可以将故事视为完整。
例如，“鉴于我已登录，当我退出时，我将被带回主页”。
如果您要接受验收标准，那么您将希望自动化它。大多数规格中最糟糕的部分是它们经常会在项目完成时过时并收集灰尘。
此外，您不应该将任务分配给团队。 Scrum团队是自我组织的，任何人都应该能够抓住任何他们认为可以工作的任务，同时尊重故事的优先级。群集是Scrum性能优势的重要组成部分。
您可能需要考虑聘请外部教练来协助您的过渡。
答案 1 :(得分：1)
我认为最简单的方法是将规范作为任务中用户故事的一部分。清楚地列出每个验收标准（或者如果您的问题跟踪软件允许您，将它们创建为一流的工作项类型）。让用于工作项跟踪的任何问题都成为活文档。
存在一些缺点，例如在规格随时间变化时发现相关问题，但这通常可以在工作项跟踪工具中进行管理，假设您可以将问题相互关联。
我们这样做的方式是，我们（实际上是一名BA，而不是开发人员）为产品所有者创建一个签署套牌进行审核，我们通过协作创建任务。如果我们无法创建任务，或者存在未解决的问题，我们将返回产品所有者，并将这些问题和更新到套牌中。我们所有的套牌都是有组织的（在SharePoint中），以便我们以后可以轻松找到它们。
答案 2 :(得分：1)
对我而言，规格在用户故事中。我们定义了初始Scrum会议以及产品所有者的规范和任务。规范和任务仅适用于scrum迭代的生命周期，因为在下一次迭代中一切都可能发生变化（在最坏的情况下，但肯定会有变化）。
我们通常会在电子表格中跟踪规格和任务，以便每个人都知道他们正在做什么。我也尝试了一些软件来做这个，我遇到的最有趣的一个是[VersionOne] [1]和[Rally] [2]。
但我仍然发现使用简单的电子表格是最快最简单的解决方案。
答案 3 :(得分：0)
据我了解SCRUM，它并不关心规格管理。您必须单独打破/映射规范或规格更改到故事和任务。但你可以有一个任务：）。
答案 4 :(得分：-1)
Scrum与其他敏捷开发方法和规范编写之间存在着真正的紧张关系。我认为有两个紧张的重点：
因为敏捷说一切都应该 在索引卡上，这意味着你 必须有计划的东西 足以在索引卡上适合。 （例如，你必须知道它是怎么回事 去上班。）
有些事情没有意义 隔离（什么是使用 上传文件页面没有管理 例如，上传的文件页面。）
您不必一次性设计整个应用程序，但您必须拥有整个应用程序的愿景。然后，特别是如果你将设计师和程序员分开，你就可以一次为sprint大小的块进行功能设计。然后，这些设计必须分解为故事大小的块。
这是很多前期功能设计，我认为在很多关于敏捷方法的讨论中都忽略了这一点。也许一些商店让开发者做更多的设计。此外，我认为使用scrum / agile对现有应用程序进行更改/错误修复要比使用新应用程序更容易。
我发现最有帮助的是回击故事大小。很多组织都疯了，说故事只需要几个小时。最初的scrum书说我认为16小时，通常大到足以适应整个网络应用程序的屏幕。因此，“实施管理我的帐户”可能是一个故事（与“实施用户名”，“实施密码”等数百个小故事方法相反）然后参考您的设计文档“管理我的帐户”并制作一定要有完美的截图/原型/模型，这样开发人员可以查看它们并将文本直接复制/粘贴到他们正在编写的代码中，并且他们确定哪些字段需要在那里（或哪些链接，或者哪些图片，或其他什么）。