问最小文档敏捷开发与业务流程应该被记录的需求是如何兼容的？

EN

这是对“工作软件而不是全面文档”价值的一种不寻常的解释。敏捷宣言的这一价值是作为对项目的一种反应，在这些项目中，文档包含了数百或数千页没有人愿意阅读的文档；其目标是用更接近开发人员、更容易获取、更易阅读的东西来取代那些收集书架上灰尘的巨大而无用的手册。

当然，一些文档可以被用户故事和自动化测试，以及干净的代码和干净的体系结构所取代--这两个关键的方面你还没有提到。

尽管如此，无论项目是否使用敏捷方法，仍然有文档要做。有些项目只需要几页描述如何安装和使用它们，以及它们的体系结构。其他人仍然需要大量的文档，因为原始开发人员提供了非直观但必要的设计选择，因为该项目依赖于第三方系统的一些怪癖，等等。

因此：

• 彻底记录。
• 不要为了写文档而写文档。
• 仔细选择要记录的信息的最佳格式。有时候这会是个考验。有时它会是一个UML图。有时，它会是一个更好的变量名。如果其他开发人员阅读了您的文档，您就成功了。如果它在架子上收集灰尘，你就做出了错误的选择。

过程文档只需编写一次。如果这是在您的公司内或与您的客户做生意的一个要求，那么这项工作就是sprint 0的一部分(即第一个sprint)。我以前也有过这种情况，并且能够将敏捷过程映射到CMMI级别3，而不需要常规地创建跟踪文档。

敏捷并不是替换需求来做业务，它是一种加强反馈循环的方法，以便能够在问题仍然很小的时候尽早纠正问题。这是一种鼓励实验的方法，这样你就可以找到让你的客户更快乐的方法。

在客户空间中，当您必须在更大的瀑布式流程中适应敏捷时，总是会出现阻抗错配。这就是你必须为其中一个结束和另一个开始设置防火墙的地方。这种环境有利于开发和手动操作，而不是直接的DevOps方法。具体而言，这也是您需要在流程中记录的这些类型的东西。这让您的团队知道，如果客户在某个日期之前想要什么东西，那么您就可以确切地知道您必须拥有一个完整的可发布包才能完成更大的过程。

大多数人不得不处理不太理想的情况。尽管敏捷已经存在了几十年，但它仍然被视为年轻的新兴进程。记录您的过程的目标是制作那些要求您编写流程的人希望看到后续过程的自然副产品的工件。例如，将每个提交都绑定到一个需求或错误报告是很容易的，因为大多数问题跟踪系统都会为您处理这个问题，只要您在提交消息中引用问题号。得到一个报告什么是做和你有多近是一个问题，让该工具生成图表，等等。

坦率地说，如果您需要广泛的word文档样式文档，那么它就不需要了。

但!除了是从大瀑布过程软件开发的一步，也要记住敏捷是从混乱的非过程开发的一步。如果文档是必需的，那么将它们放在待办事项中，按照正常顺序排列、估计和调度。这样，客户就可以看到成本。