我知道用户故事在敏捷世界中占主导地位，但是如何存储这些工件，以便加入团队的新开发人员可以赶上需求？
如果用户故事稍后更改，该如何更新并将其保留为工件呢？我已经看到许多团队只是打开一个新的票证/功能请求/错误报告，而不是跟踪原始故事。
Answers:
首先，@ DXM的答案中几乎没有任何内容与我在敏捷（尤其是Scrum）方面的经验不符。
在敏捷宣言指出，虽然全面的文档是有价值的，可工作的软件更有价值。因此，文档当然不是一件坏事，但是它确实应该在创建有效软件中起作用。
个人与流程和工具之间的互动
工作软件超过全面的文档
客户合作而非合同谈判
响应计划变更
也就是说，尽管右侧的项目有价值，但我们更重视左侧的项目。
事实证明，在开始编写代码之前先细化每个细节都是浪费的，因此通常以JIT（及时）方式处理文档。也就是说，您记录了实际要编写的代码。
执行Scrum的一种流行方法是使用用户故事，该故事由产品负责人维护，并保存在产品待办事项列表中。产品待办事项列表是解决方案需要完成的所有工作的相当高级的列表，而用户故事通常是描述列表中每件事的一种合理大小的方法。用户故事不是强制性的，但似乎确实是避免过度使用细节并激发协作的一种好方法。
因此，无论如何，当一个故事完成时（团队已经创建，测试并部署了符合验收标准的内容），该故事就不会被取消，只是在待办事项列表上将其标记为完成了，因此待办事项列表中确实有一些指示每个Sprint所做的工作-故事以及与之相关的要点。这就是您可以计算速度的方法，它本身就是有价值的文档。
综上所述，用户故事可能是理解需求所需的全部文档，但更有可能的是，它可以引起客户与开发团队之间的对话。因此，围绕该对话您可以执行许多操作。如果是经常面对面的临时工作，那么分析人员/开发人员可以（并且可能取决于您的组织）写下所做出的决定并将其保存在某个地方，例如Wiki或文档资料库。如果是电子邮件对话，则可以保存电子邮件。如果是白板会议，请用手机为白板拍照并保存。关键是，这些都是帮助您完成代码的事情，如果您需要弄清楚如何或为什么以这种方式进行操作，那么稍后可能会为您提供帮助。
捕获需求的另一种方法是立即将其嵌入到测试用例中（我相信这就是DXM的目标）。这确实非常有效，因为无论如何您都需要测试每个需求。在这种情况下，您可以有效地将需求存储在测试工具中。
如果故事完成（并被接受），然后用户改变了需求，那么，您可能需要创建一个新故事。如果您使用Wiki作为文档，则可以将新故事重新链接到原始故事，也可以将该原始故事向前链接到新事物，以便查看它的人知道事情已经改变。这对Wiki来说是一件好事-链接内容很容易，而且很轻松。如果您采用的是测试驱动的方法，则可以更新测试用例以应对更改，或者如果新旧对象不是互斥的，则可以为新故事创建新的测试用例。
最后，这取决于您的需求。如果主要目的是使人们快速入门，那么对于某个人来说，编写一份入门文档来帮助他们可能是个好主意。所以有人来做。正如我提到的那样，Wiki是保持此类事情的好工具，因此您可以考虑使用Atlassian的解决方案，该解决方案可以将Confluence Wiki与Jira和Greenhopper集成在一起，以跟踪您的故事/任务/缺陷并总体上管理您的项目。还有很多其他工具可供选择。
[更新＃1]正如@MatthewFlynn所指出的，他在敏捷以及其他许多方面（包括我自己）的经验与我在此处提供的答案有很大不同。答案是基于我对自己团队过去的成就和不成就的观察，结合我所读过的许多书籍和博客...
敏捷开发的大部分驱动力都专门针对消除需求文档。
敏捷试图废除大多数文档，我同意他们的想法，但是在所有文档中，需求是迄今为止最大的牛逼。之所以这样做（IMO），是因为需求文档离实际的工作代码和所有文档都不远，这使得它们
为了指导团队下一步应该开发什么，敏捷用故事的待办事项替换了需求文档，这些故事确定了您应该处理的下一个工作以及通常优先考虑的事情（首先是当前和将来的工作），而这些工作是最有价值的。在那个列表中。
但是，不应将积压订单与需求文档混淆：
故事完成后，该故事将从积压订单中删除，并被删除（1）。同样，故事不是必需的。他们只告诉团队下一步该做什么。它们不用于历史记录。
但是，在适当的敏捷过程中，每当您交付工作时，交付的一部分都应该是单元/集成/验收测试。这些测试非常有价值，因为它们有许多用途。我不会进入完整列表，但是这些目的之一是当前生产软件的文档。
测试记录了在特定输入和前提条件下软件应如何运行。它还记录了如何使用代码的公共（和内部）API。它还可以用作安全网，以便当新开发人员进入团队并无意间破坏了某些内容时，只要将其签入，就会立即发现该错误。
显然，敏捷过程促进了尽可能多地利用自动化单元测试的优势，但是我们都知道并非每件事都可以实现自动化。您的软件套件将始终具有一组必须手动执行的测试。但是，a）您的开发人员应该积极地努力使自动化尽可能的自动化，并且b）您的质量检查团队应定期执行手动测试集，以便尽快发现任何功能中断。
（1） -由于我对“被卡住”的部分有几个回应。自敏捷开发以来的5年间，我的团队再也没有丢掉一个故事，即使计划的30％，然后推迟然后又遗忘了。我的老板想让他们“参考”，但没有人看过这些故事。
人们通常会依附于他们的数据，我知道一旦拥有就很难想出一些东西，但是手头的库存（无论是物理的还是电子的）并不是免费的，我想得越多，我就越同意与“夹头”。这摘自“敏捷软件需求：团队，程序和企业的精益需求实践”（第190页） -“用户故事可以在实施后安全地丢弃。这可以减轻用户负担，保持团队友好性，并且促进谈判，但是验收测试在应用程序的生命期内一直持续……”
如果用户故事稍后更改，该如何更新并将其保留为工件呢？我已经看到许多团队只是打开一个新的票证/功能请求/错误报告，而不是跟踪原始故事。
无论您使用的是敏捷故事还是大型的前期文档，管理任何文档都可能很困难，并且为了减轻负担，文档应尽可能少，并且应进行增量更新以与测试和实现方面的工作相匹配。正如OP所暗示的那样，仅更新文档可能会丢失软件随着时间的演变的历史。
这真的很重要吗？有时可以。在大多数情况下，您只是希望查看当前的故事/ UML /所有内容以及测试和代码本身，但是，当有人质疑为什么以特定方式实现功能时，通常可以查看历史记录以了解功能随时间的变化很有用，以更清晰地描绘出为什么选择了实现选项X而不是选择选项Y的原因。
您可以通过两种方法来跟踪此类工件。更好的选择之一是将故事保留在一个工具中，该工具使您可以以与源代码版本化类似的方式对故事文本进行版本化。Wiki往往擅长于此，因此某些项目/问题管理工具也是如此，例如Trac或Redmine其中记录了问题本身以及这些系统中Wiki页面的更改历史。但是，可以通过确保新的故事或问题以某种方式链接到较旧的相关问题和故事来提高追踪问题之间的变化的能力，这可以走得更远。这可以像在较新的问题/故事的文本中添加较旧的问题/故事ID一样简单，但是只要在对版本控制系统进行更改时，只要在签入注释中包含任何问题或故事ID，就可以大大改善该问题。但是，如果您的提交频繁且仅限于单个故事或问题，则此方法具有最大的价值。
当然，最大的困难是，这种方法需要每个团队成员认真注意并作出承诺，以保持一致，并使他们的承诺小而又频繁，并使管理故事和/或问题/项目跟踪系统的人员保持一致。在提供实现的当前状态与以前发生的所有更改之间链接的工件上。
之前已经说过，但我想要点是：
需求可能涉及多个方面，通常会导致一个以上的故事。
故事将团队的工作组织成足够小的块，以适合冲刺的时间范围。
通常，为了使某些特定功能正常工作，需要定义许多细节。在这种情况下，将这些定义保存在单独的需求文档中变得很有用-为了清晰，共识和以后的参考。
考虑传说中的在线宠物店示例：