在与会议和讲座的同事交流中，已经有好几次我遇到了这个问题：
似乎是时候修复问题的答案，并偶尔进行参考了：）
那么， 在人与人之间传递信息的地方 ， 敏捷知识管理是否必要？ 实际上，当答案包含在问题本身中时就是这种情况。 信息是在人与人之间传递的，也就是说，存在着知识的交换 。 口头传统是知识管理的工具之一。 非常不可靠，但肯定最受欢迎。 知识管理负责人的任务是创建一个方便共享知识的环境。 当然，在敏捷团队中，环境将不同于经典的组织结构。 但基本上，答案当然是“是的，这是必要的”。 让我们更详细地了解。
让我们从敏捷清单本身开始。 它的作者直接说
“也就是说，我们在不否认右边的重要性的情况下，仍然对左边的内容给予更多的重视”
敏捷宣言没有告诉我们“什么都不做”！ 他说，客户为工作产品付费。 如果他收到了它，则在没有精美文档的情况下，他可以闭上眼睛，反之亦然。 清单有助于确定优先级，但不设禁令。 即使您没有时间去大型码头，在工作过程中也会创建大量的知识管理工件，然后您可以在做出新的决定时对其进行操作：工单，变更日志等。
“人与交互比流程和工具更重要。”
在 IT工作者之间进行的
一项研究中，很明显，IT行业的
人们将知识共享（即
交互 ）放在软件开发中现有挑战中的第二位。
总体而言，这项研究的结果证实了宣言的第一篇论文。 在我看来，这个问题的根源来自以下事实：开发人员对知识的管理被理解为文档，而不是经验转移中人与人之间的相互作用。
是的，顺便说一句， 在之前的一篇文章中，我已经说过， 知识不是文档，而是特定员工在实施特定项目中获得的经验 。 即使您尚未创建产品文档，您在项目过程中也一定会获得一定的经验。 而且，敏捷工具间接地导致了这种体验不断被修改的事实。
例如， 回顾 。 如果不是知识共享过程，这是什么？ 团队收集，共享现有问题（在KM领域中，这是“经验教训” ），并制定变更计划以解决这些问题。 就是说，人们通过彼此的经验翻阅，讨论，制定了在不久的将来克服不便的策略，并将这种变化计划固定在某个地方（知识管理工件）。 通常，这些会议的结果存储在某个地方。 我不确定是否有有效的命令可以在完成迭代后删除所有过去的数据。
或配对编程 。 甚至Wikipedia也告诉我们有关此工具的以下信息：
优点：
***
指导
每个人，甚至是新手程序员，都知道其他人不知道的东西。 结对编程是一种轻松传播这种知识的方法。
***
培训课程
程序员不断交流知识。
两位经验丰富的程序员利用自己的经验互相交流。 主打水罐，充当导师。 团队指导通常是软件开发中最流行的知识管理化身之一。 相同的Yandex甚至开始向外传授此艺术。
或在使用看板时注意这种情况。 假设测试人员每月测试10个功能，而开发人员设法实施20个功能。这将导致质量检查人员的工作量增加，从而对其工作质量造成风险。 在这种情况下，例如，您可以重新分配资源并将开发人员连接到自动测试的创建。 迭代的结果是，团队获得了负面的计划经验，并且可以基于此经验制定新的计划，以确保在相同资源下管道的最大吞吐量。 也就是说，在开发过程中，获得了知识（=经验），在分析了这些知识后，团队开始进行过程的优化。
好吧，这是一个非常表面的问题：在进行其他项目时，团队会不会利用在项目中获得的经验吗？ 也就是说，通过实验，对于当前项目，他们发现他们每个月平均可以测试15个功能。 他们会不会再次加入最初定于20岁的新项目？
知识是围绕项目进行的所有工作。 开发过程不是在真空中进行的。 协调，有用的链接，与其他团队的互动，初学者的入职等。 任何团队都要经历这一过程。 有了一套经验，就会出现各种工件，例如针对初学者的适应性检查表或有用链接的数据库。 这是固定的知识或理解所获得经验的结果。
我们每个人每天都参与知识共享过程（嗯，实际上，我们一直在相互交流！），而敏捷方法论的工作并没有将我们排除在这个过程之外。 而且，它已经包含了非常有效的知识管理工具。 剩下的只是组织团队的工作，以使这些工具发挥最大的作用。
在一篇博文中，我仅举了几个例子。 让我们在评论中讨论其他哪些敏捷工具也是知识管理工具。 好吧，或者讨论为什么我错了:)