如果您最终遇到您正在从事的项目的主要开发人员决定离开的情况。
他拥有所有知识，从一开始就参与项目。如果你很幸运，你可能会得到他两个月的时间，如果没有，可能只是一个月的休假通知。
知识流失、转移的最佳实践是什么？
过去证明什么对你有用？配对、演示、文档？
7 回答
6
我认为配对开发人员之间定期安排的知识共享会议效果很好。确保至少有 2 名编码人员对代码库的每个部分都有一定的经验。
我们制作了一个知识共享图表，其中在页边空白处列出了每个开发人员的姓名，在顶部列出了每个项目。我们在方框中放置了一个绿色符号，将主要开发人员与他们的项目对齐，并在第二个开发人员和同一项目中放置一个黄色符号。
那时很容易，顺着每个项目的路线，确保它至少有 2 分。如果不是这样，那么在我们的下一次重大会议上，我们会让开发人员决定他们是哪个项目的辅助开发人员，但他们都必须是至少一个项目的辅助开发人员。通过这种方式，他们可以了解他们感兴趣的项目，并与他们选择的开发人员合作。
一些大型或系统关键项目有 2 或 3 个辅助项目。每个月我们都会安排两个小时的知识分享时间。你会在去你的次要项目和人们来你的主要项目之间切换。
于 2009-02-03T10:06:09.297 回答
3
如果您有足够的时间，请让他完整记录系统，然后与他一起阅读系统和文档以确保您了解两者。
不要依赖于你会记住细节的事实。记下他在转会会议上所说的一切。
于 2009-02-03T10:03:53.683 回答
3
我在录音机会话中与一位同事配对。他正在给我详细的解释，带我浏览代码并用代码映射应用程序的功能。他离开后，我花了几天时间转录这些录音并制作技术文档，这些文档在我离开公司一段时间后使用
于 2009-02-03T10:06:00.060 回答
2
文档是必不可少的，但它应该在任何人离开之前存在。但是，有人离开应该触发编辑/审查/更新的循环。
然而，仅文档本身就非常枯燥，而演示文稿只是让你即将成为前同事的无聊的一种更生动的方式，所以根据我的经验，唯一真正有价值的是由学习者推动的动手代码演练不是尽可能小团体的离开者。学习者必须看到正在运行的代码，包括断点、异常、单元测试和最终结果。
（而且 FWIW 我相信所有项目都应该记录 UML 类图 - 框和线是我在学习架构时想要看到的）
于 2009-02-03T10:06:06.503 回答
2
如果可能的话，我会说带另一位可能正在做同样事情的高级/同事参加传递会议。如果可能，请让该人员先对业务逻辑进行演练，然后再编写代码。另一个人提供第二意见很重要，因为他们可能会抓住您由于经验等原因错过的一些要点。
我赞同 Galwegian 的观点，将所有内容记录下来。只需确保您的文字清晰易读 :) 如果可能的话，在会议结束后对材料进行审查，就像中间的休息时间一样，1-2 小时让材料潜入您的脑海。然后在下次会议上再次询问该人您不了解的任何内容。
我了解到，如果您在查看材料之前离开太久，那么到那时对您来说几乎是希腊语。
只是我的两分钱。
于 2009-02-03T10:12:56.303 回答
2
不要相信文档会购买该开发人员积累的知识。
我认为获得真正知识转移的唯一方法是让某人与他一起在项目中进行实际工作。然后，他将发现在项目中工作所需的小技巧。我记得一个例子，我们的模拟器不能一步一步地正常工作，但你可以使用断点让它工作。这是一个典型的例子，你只能通过实践来学习。
在其他开发人员对项目及其使用方式更加熟悉后，只需查看所有代码、文档即可。但最好的办法是，对于项目的每个部分，他们都可以做一个小的改进来使用所有的工具并发现所有的怪癖。
于 2009-02-03T10:15:59.807 回答
0
除了关于当前项目是什么的静态文档外，我还制作了一份关于执行了哪些演示/实验以及做出了哪些决定的记录。项目的轨迹很重要，要知道哪些已经尝试过，哪些失败了，哪些部分存在技术债务以及原因。
于 2009-02-03T10:14:09.280 回答