在传统的瀑布中，需求是按照深奥的模板收集的 - 通常在MS-Word文档中。 在"严格"瀑布模型中，此文档在需求阶段之后被冻结，变更控制/变更管理流程负责引入受控变更。(**)[通常，文档会变成"活文件"，最终变成"活的噩梦"]
目前，我必须领导一个项目，该项目将现有桌面应用程序重写为 Web（从 VB 6.0 到 ASP.Net）。 客户端具有他想要重写的应用程序的基线版本。[所以要求被冻结了...无范围蠕变]。 要按原样重用的数据模型。 仅迁移前端/业务规则。查看应用程序，我觉得它最多是 3/4 个主要屏幕，仅此而已。
一些团队成员希望在开始新开发之前记录（在我看来是旧思想流派）整个事情。 我和其他一些人认为，将UI转换为Web，查找旧代码，编写业务逻辑，进行自动化单元测试，进行集成测试并逐屏（或逐个功能）交付相对容易。
我的问题是：在敏捷开发中，如果我不优化这一点，我该怎么做，我就会保持"敏捷"。 我的观点是编写详细的文档是反敏捷的。 你觉得怎么样？ 敏捷大师将如何处理上述问题（将现有的VB 6.0应用程序重写为 ASP.Net）？
免責聲明： 创建一个1000页的功能规范可能是为了履行合同义务，一种政治需要，系统可能真的很复杂（现在，"复杂性"的定义是一个通往阴暗之地的旅程）。
首先，如果客户或产品负责人要求拥有（阅读已准备好付费）文档，您可以生成文档并保持敏捷性。
以增量和迭代方式扩展文档，就像处理代码一样。测试一点，编码一点，然后...记录一点。
我看到三种方法可以做到这一点：要么在任务估计中包括编写文档的时间，创建特定于文档的任务，要么有文档积压项目/故事。
文档故事的风险在于，它们可能计划得很晚，在实施很久之后，所以我不建议这样做。
文档任务的优点是在迭代规划中可见，因此不应忘记或忽视它们。
敏捷并不意味着"没有规范"。这意味着尽早和经常（但不一定是生产环境）进行测试和发布。
Scrum中的积压工作是"规范"。如果您实际上没有写下和管理功能列表，您将失去功能，并且您将永远无法确定产品何时发布（无法估计剩余的工作量，因为您不知道自己在哪里或还剩下多少工作要做）。功能列表必须由某人管理。最简单的方法是写下产品应该做的所有事情（你可以根据需要在措辞和定义上尽可能复杂），并跟踪已经完成的内容和还有什么要做。您还将如何将工作分配给开发人员并将状态报告给"管理？
我在这个问题上花了很多心思 - 我们在Scrum环境中工作，最终在组织文档方面遇到了困难。
我现在要去的，虽然现在还为时过早，所以我不知道它是否会通过长期测试，但要使用 wiki 作为文档。
基本上，工作流程如下：
- 故事出现在积压工作中
- 故事被程序员拾取
- 程序员负责代码，在DoD（完成的定义）中，还必须针对新功能编写一些测试，并且必须编辑wiki以添加新功能性页面。
维基是用mediawiki模板组织的，灵感很大程度上来自mediawiki扩展文档页面，功能名称，引入的版本，任何有用的东西。该模板添加了图形以区分不同类型的要素（及其状态）。
归根结底，wiki 有一个很大的优势，那就是让你添加文档页面，而不必担心在哪里或如何放置它，但显然你经常需要有人来组织混乱。
要记住的重要一点是，无论您使用什么工具，开发人员都应该在开发发生后（包括技术方面）编写一些文档 - 而不是之前，而不是几个月之后......
在我看来，功能规范是必要的，这取决于技术团队对产品的参与程度以及团队的级别。如果技术团队参与产品定义，您肯定需要更少的文档，因为假设的空间会更小。如果你有一个初级工程师团队，你需要一个更强大的文档，否则事情将无法按照冲刺结束时定义的方式完成。
还要注意，远程团队需要更多功能规范形式的文档，因为不接近利益相关者和产品远见者是自然障碍。拥有前期功能规范是敏捷的一个功能。我看到很多技术团队的任务完全由用户故事描述，而且我经常看到这些团队未能实现发布并满足利益相关者的期望。
这个主题非常广泛，有很多意见，但在我看来，这可以简化为开发人员不必猜测需求的事实。
事实上，我相信可交付成果的成功和质量与开发人员需要做出的猜测/假设的数量成反比。我认为敏捷性随着指定的好坏而增加，因为你会有更少的错误，并且会花更少的时间来纠正这些错误。
如果创建函数规范是合同上的必需品，你应该仔细考虑其中的内容。如果您未能兑现功能规范中的承诺，您可能会被拒绝付款。
不幸的是，如果你采用这个过程，你不会保持非常敏捷。客户端是否真的希望为重写的应用程序使用相同的函数？如果是，那么为什么要重写它？我敢肯定有一个功能从未使用过。
我不会费心去记录旧版本。您已经有一个引用，即应用程序本身。软件中没有歧义。
文档编写不是反敏捷的。设计一些东西而不优先考虑并从客户那里获得反馈是。敏捷的一个重要方面是获得客户的支持。如果他们不相信，那么这个项目将比它应该的更难。
正如已经指出的，敏捷并不意味着几乎没有文档 - "工作软件超过全面的文档"。
我处理文档的方式几乎是颠倒过来，并将文档的几乎所有内容都视为文档的一部分（包括代码和单元测试作为技术规范）。因此，描述业务/用户需求的故事（或你用来分配工作的任何其他机制）应该足够详细，以便由做这项工作的团队估计;否则，它是不完整和模糊的。此外，我在自己的实践中所做的一些事情，如果故事（或其他什么）估计需要超过一个工作日才能符合团队对"完成"的定义，那么它很可能应该被分解（这种原子化然后编译最终会导致相当广泛的文档，但不会假设像不这样做那样多的未知数 - 并且可能导致非常有趣的重用和模式启示）。
使用 BDD 样式要求的示例：
Given I am working on a document
When I select "Save As..."
Then a menu should appear allowing me to choose a name,
and a file type,
and a location in the file system,
and a file should be created in the file system
我们可能需要/想要添加 UI 元素来完成此操作，菜单项、情节提要、键盘快捷键等（我们可能对"保存文件"的同一主题有多种变体）。等等。
所有这些相关的工件都可以附加到基本情景/需求上;从而产生更完整的文档。但是，仅将您实际实现的那些故事添加到软件的Web版本文档中。
在这里，事情变得有点颠倒过来，变得更加"敏捷"。在开发期间和开发之后，将重新访问记录的需求并添加团队编辑所做的更改/修改/改进（无需通过仅文档 CCB）。编辑/更新文档和相关资产的能力，而无需通过所有审查委员会等等 - 或者当我们在开发过程中发现文档以某种方式不完整时将文档"扔回墙上"，使我们能够适应未知 - 因此，敏捷。
该文档应该具有某种形式的版本控制或历史记录，这使我们能够描述我们想要的系统，但也描述了实际实现的系统 - 注意有关文档是完成定义一部分的另一个答案/建议（我也这样做）。（Wiki 对此有好处;但是，完全集成的概念更可取 - 例如，能够将票证与版本控制系统中主干中的文件相关联会很好。
总结一下。预先创建详尽的文档，在开发工作期间和/或之后不久无法更改，这将使您无法敏捷 - 能够快速适应未知情况。但是，参考领先的精益软件开发，其中他们提到，如果策略不允许正确使用某些实践/流程，那么无论您说自己是精益（或Scrum或敏捷）也没关系。
确保你不会过于详尽的一种方法 - 可能可以在这个答案上使用这种心态 - 是只在需要时编写你需要的内容（类似的概念通常存在于开发中）。另一个方法是让每个人都明白，你不需要尝试预先弄清楚所有事情（从瀑布到敏捷的最大转变） - 我们将记录每个想法，它可能会也可能不会最终发布。最后，弃用（并删除）任何不再适用的内容......我记得有一次看过一个系统的文档，当我查看系统时，有一半的文档实际上不再适用于该系统。
由于您有一个描述产品应该做什么的文档，因此我会将其用作初始积压工作，并开始将工作拆分为从最高优先级到最低优先级的咬合大小部分。然后，每组部分将在迭代期间处理。简而言之，将Scrum与您的初始文档一起使用作为积压工作。
如果不做这个优先级工作，我不会直接进入实施。它不需要大量的写作，但需要更多地参考你想要解决的部分。
我不会预先记录整个事情。
此外，您将有一些与所处理的平台直接相关的任务，这些任务需要被捕获并添加到冲刺积压工作中。
此外，您可能会意识到您不想在几次迭代后实现所有要求。
敏捷有一个功能规范文档，其形式包括敏捷功能列表、产品待办列表，甚至还有冲刺中的任务待办事项列表。它们不被称为文档的事实并没有使它们减少。以及与瀑布中的功能规范的区别?...敏捷功能规范只包含所需的内容（lol），因此体积较小，还记得您的"工作软件而不是全面的文档"吗？