敏捷文档指南

敏捷宣言的支柱之一是工作软件优于文档。尽管它看起来像一个明确的指导方针，就像项目管理中的其他一切一样，它也有多种解释。对于什么是正确的平衡没有达成共识。

许多开发人员在积极开发软件并试图赶上最后期限时，可能认为文档并不比他们交付的软件更重要。

我个人的经验是，一个典型团队想要的文档数量更多地取决于团队/经理。不幸的是，每个团队都能接受的文档数量之间存在很大差距。

根据我的经验，我认为以下是理解给定软件的方法：

这些主题中的每一个都可能占据一两个完整的博客，但我会尝试总结这些。

1. 高层架构图

如果没有高级架构图，开发人员将很难启动项目。显然，在最终确定功能的过程中这会发生很大变化，因此开发人员需要尽职尽责地对其进行更新。敏捷建议在项目中尽可能晚地推送文档，这是有充分理由的。

对此我有一个坦白。十年前，当我听说测试用例可以充当文档时，我认为这只是理论上的。但是现在在处理多个项目模式之后，测试是应用程序的一个重要维度，测试用例是文档的一部分。

有了新的测试工具，并且需要在不同的云场景中部署应用程序，拥有可靠的测试用例是必须的，开发人员除了编写测试之外需要做的就是给它们起有意义的名称，这有助于理解功能的项目。

这对开发人员来说可能并不新鲜。作为开发人员，我们尝试在代码中找到模式/层来理解它。依赖关系没有正确分层的代码变得非常难以理解软件，我们尝试求助于其他形式的文档。

我觉得 PR 是唯一不会造成任何伤害的地方。原因之一是因为记录刚刚完成的代码可能是最晚的。

对于某些团队来说，上述内容可能还不够。团队需要更多文档的一些原因是：

当团队处于早期阶段时，会有很多开发人员流失。如果功能所有权发生了很大变化，并且多个开发人员被分配到一个类似的工单上，那么管理人员就很难对该工单进行知识转移，他们会要求更多的文档。对于企业来说，这可能发生得很少，但我在创业公司中经历过很多这种痛苦。

解决方案：更多地关注团队合作。如果团队进行配对，知识将不仅仅集中在一个开发人员身上，因此新开发人员可以开始与现有开发人员协作。

新开发人员不应该仅仅依靠文档和代码库来获得提升。在一个健康的团队中，他们应该得到所有团队成员的帮助。

我只经历过几次，但是当经理发生变化时，每个新经理都想了解项目的当前状态。他们要求提供更多文档以全面了解现有项目。并非所有经理都愿意通过上述地方了解特定项目，因此他们要求更传统的文档风格。

如果他们从项目一开始就参与其中，他们往往会较少这样做，因为他们会了解项目的历史。

解决方案：经理应该更多地依赖开发人员进行特定项目的KT。经理应该能够从高级架构图中获得系统的概述，但应该能够从团队获得有关特定项目的更多信息

根据我的经验，当另一个团队直接受到代码更改的影响时，似乎有更多关于文档的讨论。如果没有标准，团队将不知道新更改将如何影响他们，因此他们要求提供各种不同的文档以了解项目的不同方面。我已经在更多耦合的代码中看到了这种情况。例如，如果团队边界没有正确定义，并且各个团队正在使用相同的代码库。

解决方案：使用接口或标准语言来定义每个团队之间的边界并记录这些接口。以合理的方式解耦团队和存储库。

这种情况也很少发生，但我见过这种情况。当产品关心他们的功能是如何实现的时，他们开始要求更多的文档。

解决方案：在开发团队和产品团队之间进行更多沟通，公开讨论边界。开发团队可以通过更频繁地演示产品来开始建立信任，以便产品对即将发生的事情感到自在，并就他们的担忧提出问题。

归根结底，当团队开始花更多时间在文档上而不是在工作软件上时，效率就会真正下降。敏捷团队需要警惕他们花在文档和开发上的时间。

当团队开始要求比需要更多的文档时，有时这指向实际的团队问题，例如团队可能已经开始削弱对自己的信任，并且更多地依赖文档而不是直接对话。或者团队成员可能觉得他们被告知不同的事情是不同的时间，他们希望将其记录下来。这些问题可能必须以不同的方式解决，而不是花时间在文档上。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！