敏捷过程：应如何记录以及记录什么？

不久前，我工作的公司将开发项目外包给了第三方。他们在开发解决方案时采用了敏捷实践。但是，当要求提供文档时，他们只会说这是必需的，因为它已合并到Wiki或作为其冲刺的一部分。

他们确实在项目完成时离开了，除一个项目团队外，其他所有人都离开了。年度订阅到期后，该项目Wiki网站现在已关闭。

当他们离开时，他们掌握了与他们一起发展的大部分知识和理解。

所以我有两个主要问题；

1. 这对于敏捷性来说是正常的，还是只是不想写它的借口？
2. 在敏捷项目中记录开发需求，设计，关键决策和环境的文档的行业规范是什么？

这对于敏捷性来说是正常的，还是只是不想写它的借口？

我的理论是，这就是为什么敏捷如此之快地传播，尤其是scrum的原因。我已经看到太多团队想要敏捷来保护自己（而不是整个公司）。问题在于，在很多情况下，管理人员会使用这种方法来对付他们（因为他们也想保护自己！）。

这是否意味着敏捷根本不起作用？当然不是，这仅意味着敏捷可以帮助您解决一些常见问题，但是您仍然负责其他所有问题。在很多情况下，敏捷不适合该公司的团队。

在敏捷项目中记录开发需求，设计，关键决策和环境的文档的行业规范是什么？

简而言之：

团队应该定义他们需要多少文件

他们知道领域，他们是专家，更重要的是，他们制造东西！

这就是敏捷宣言中包含全面文档的工作软件的含义。

他们是否给您留下了一组TDD测试，验收测试或其他单元测试？他们很好地记录了应用程序的工作方式和预期的工作方式，并提供了如何使用所开发内容的示例实现。

虽然我无论如何都不是敏捷专家，但这是我的尝试：

1. 是否有故事/要求提供特定文档的要求？如果没有，那么这就是问题的一部分，因为您在某种程度上会得到要求。这是一个借口，我想知道您在这里所说的“正常”是什么意思。遵循敏捷原则的仅仅是大多数使事情正常化的东西，还是应该作为整个流程的一部分？这些是我可以看到的两个视图。编辑：我怀疑大多数团队所做的任何事情在文档方面都是一样的，但这只是我的猜测。

2. 我可能在此方面可能会做的最好的是，可能会有一些有趣的链接：

   • 敏捷/精益文档的最佳实践
   • 敏捷和技术文档

敏捷宣言中有一些具体要点，我将在其中指出并注意：

工作软件胜于完整的文档

也就是说，尽管右侧的项目有价值，但我们更重视左侧的项目。

他们太可怕了。我认为敏捷根本就没有文档。他们至少应该跟踪应用程序描述。导出他们的Wiki会很好，或者允许其他人收取服务费。

它可能不像某些尝试那么详细。从理论上讲，在时间紧迫的情况下，规范不再与代码匹配。因此，您有足够的文档来编写代码，而不是尝试详细定义它（类似于以某种伪语言文本/图表代码编写代码，然后以实际代码编写代码）。

您的问题与敏捷无关。他们应该已经制作了您要求的文档。该项目管理不善。

至少应该在某处对功能，用户案例和测试用例进行一些描述。IT可能在项目的ReadMe文件中，可能在源代码注释中，可能在设计文档中；可能是以上所有...或者可能是MIA！

根据我的经验，总是有很多人需要文档（我曾是其中的一员），但实际上没有人真正有时间或渴望创建它们。有时需要付出一些努力，但是创建的文档通常会很快过时并且与系统的实际功能不同步。这会导致一种情况，即使您确实有文档，也没有人真正打扰检查它，因为他们根本不相信它的准确性。

为了获得真正的准确性和可靠的信息，几乎可以归结为能够读取代码和测试。想要（重新）发现其系统功能的客户可以随时采访并查询程序员，然后程序员可以提出（经过调查）有关系统的事实。

创建良好的文档并非易事，而且成本很高。其次，人们可能会想知道听众，谁提供了文档，它打算提供什么？