如何使新团队成员了解该项目的最新动态？[关闭]

我们将为软件团队雇用1-2名新工程师（由3名开发人员和1名测试人员组成）。

将他们整合到团队中的步骤是什么？

我的想法是：

• 阅读文档（编码标准，我们使用的开发方法学中的文档）
• 让他们阅读现有代码
• 给他们分配一些简单的任务
• 最后，让他们负责代码部分

我们还能做什么？

该项目在医疗领域（超声系统），已经进行了5年。我们每年发布一次，当我们要增加1-2名工程师时，我们将完成一个发布。

该项目处于维护阶段（重构旧代码，并添加新功能）。事情几乎按计划进行（或多或少）。

来自一个在我的职业生涯中必须精通许多不同代码库的人，以下是我的建议：

1. 花一些时间（也许是一两天）进行与使用该产品有关的活动，以便他们可以熟悉该产品的功能。这可能是验证错误，执行质量检查测试计划或接受用户培训。
2. 处理小型的本地化错误。这使工程师熟悉如何构建和调试应用程序，而无需学习大量的体系结构。
3. 理想情况下，编写一个本地化的小新功能。这样一来，他们就可以编写大量的代码，并且在编写代码时，他们将熟悉新代码需要使用的周围代码。

然后，根据工程师的经验水平和能力，随时间扩展任务的范围和复杂性。这将使开发人员自然地扩展他们对代码库的了解。

我会避免只读取任务（文档或代码）。阅读文档变得非常无聊，阅读随机代码也无济于事，因为它们没有任何上下文可使用。当您已经知道产品和代码库时，很难阅读代码以进行代码审查。我看不到让一位崭新的工程师来阅读代码会带来任何有用的帮助。

我的感觉是，大多数人对阅读文档的容忍度很低（可以使用一两天，但除此之外，他们可能会渴望做一些动手的事情）。

我认为，如果不对应用程序本身有一个合理的了解，您将无法真正理解该应用程序的代码。该软件可能具有许多功能，可以作为用户“玩弄”这些软件。他们最终将需要能够对其进行测试，因此我希望它非常重要，因为他们知道如何安装，配置它以及执行其常见任务。

我个人发现，高层架构概述通常对于了解事物的工作原理非常方便-也许在他们的第一周就花了一两个小时的高级工程师的时间（或者如果需要，您自己）？主要应用程序的基本功能。例如，了解所有子系统以及如何将事物捆绑在一起，知道哪些位由第三方软件/库处理，以及哪些位需要在内部维护。（除非您的组织拥有真正卓越品质的最新文档，否则我猜想如果没有人直接使用白板向他们解释这些东西，他们将无法控制这类东西：- ））

至于给他们“动手做”的东西，维护/错误跟踪任务可能是使它们加速一段时间（几周/几个月？）的好方法-它们将处于特定功能区域的情况下需要被理解，测试和调试；帮助建立有关代码，需求，公司使用的工具，开发流程和整个产品的知识，同时希望不需要花太多时间与开发团队的其他成员

作为负责人，我至少与新开发人员呆了2天。我发现，发展一种关系，可以轻松地问一个不可避免的问题：“你的进展如何？” 是必须的。任何新社区都存在适应的恐惧……我们隐藏错误，表现完美，使事情变得比实际更好，减少了困难。与某人共度两天的经理会让他们知道这不是他们的文化所在，并允许他们以身作则。新的编码人员需要历史课程，以了解您来自何处以及您走了多远。文档只是不能使任务公正。

我在行业工作了10个月（在职期间），但发现以下内容对我有所帮助：

• 与其他开发人员合作，观察他们如何解决问题。
• 测试软件很有帮助，我需要测试功能x，这意味着我阅读了功能x的文档。我做了很多，这很有帮助。

这些都对我有所帮助。祝好运。

我会从高水平到低水平。

尽快演示该应用

最重要的事情之一是，开发人员对他们将要从事的工作有所了解。在演示过程中，请指出最近开发中的一些事情，以及应用程序的发展方向。

解释高级架构

这也很重要。允许新开发者听和问问题。与其他开发人员进行小组练习，希望他们能够为您提供帮助。这将使新开发人员知道可以公开诚实地发言。

准备好入门文件

拥有一份出色的入门文档不仅对新开发人员有帮助，对旧开发人员也有帮助。它可以包含期望，有用的链接和环境设置信息。（我无法告诉您，当我获得一台新计算机时，我使用入门软件设置环境的次数是多少...）这应该结构合理并且切确要点，不要拖延，也不应该成为每个人的垃圾场。小细节。

鼓励他/她提出问题（并可以回答这些问题）

给出答案后，指导他们，但不要告诉他们该怎么做。给他们提示，但让他们最终自己弄清楚。

帮助其他团队成员欢迎新来者

有人加入团队时，硬币有两个方面。团队还需要拥有欢迎新开发人员的工具。

让他们承担一两个小任务

允许他们向项目添加可演示的新内容。降级后，请指出是谁做的，以及他们做的出色。这确实可以提高自尊心。他们感觉自己增值的速度越快，他们感觉自己成为团队成员的速度就越快。他们会感到越快被授权去做自己能做的最好的事情。

鼓励他们一旦感到越来越舒服就开始艰巨的任务

好的候选人会自然而然地做到这一点。

我经历过（并发现有用）的一种“定向”流程类似于以下内容：

1. 简要介绍一下“大图”，其中包括什么是组件，如何配合以及总体架构。
2. 代码概述，介绍处理分配给我的组件的主要逻辑的功能。涵盖了一些与编码约定和样式有关的内容。
3. 分配了许多未解决的问题和低优先级的错误（这些错误主要定位在分配给我的组件上，并且非常简单）。
4. 我应该通过应用程序进行调试，并寻求有关我无法解读的内容的帮助。
5. 修复之后，我逐步完成了发布到集成的过程（代码审查，开发人员级别的测试等）。
6. 重复剩余的任务/错误分配。

我认为这种方法（及其变体）将很有用，因为：

• 这是一个更加实际的操作，并且相对独立（持续不动手等）。因此，它为新人员提供了足够的空间/时间来适应新的代码和团队中的工作方式。
• 这对于整个团队也是有益的，因为可以解决几个低优先级的任务/错误。帮助新人的人也有更多的时间来处理分配给他们的任务，因为不需要持续的手持操作，并且可以专门安排时间来解决新人可能遇到的问题/问题。

最初的员工需要完成一个任务，但任务不要太小，而且任务要明确。这样，他们可以通过尝试弄清楚如何完成任务来开始了解代码的结构。在此过程中会出现问题，此时您可以将其定向到文档或其他资源，以帮助他们内部化代码库。如果您的开发，提交，部署周期较短，并且他们可以尽快看到自己的工作成果，那么这也有帮助。

我就是这样

1. 给他们一些与项目有关的任务。（例如：如果您的项目是数据库应用程序，请他们仅创建一个应用程序来与数据库连接并执行一些简单的操作。）
2. 当您发现他们了解工作的想法时，请给他们演示该项目
3. 要求他们阅读文档。
4. 让他们熟悉编码样式和标准
5. 稍后给他们一些调试练习（以了解项目流程）。
6. 要求他们修正您已经修正的一点（只是为了找出他们的逻辑）。
7. 最后使它们成为项目的一部分。

记住：无论您付出多少努力，除非并且除非参与者完全理解该项目，否则您将无法最有效地完成工作。

第一-首先学习如何使用该软件从用户的角度发现解决了什么问题。如果没有UI（例如后端服务等），则让他们使用可用的任何界面来使用它。全面了解用户对软件的看法始终是一件好事，这可能有助于新员工看到由于您已经嵌入到项目中而看不到的东西。

此后，一个好的第一个项目可能是要添加到软件的附件或新模块之类的东西，从而最大程度地减少了现有代码库所需的知识量。编写新的东西总是比执行错误修复要容易得多，这可能需要在许多源文件中进行大量更改。我认为，给新员工一个错误修复任务可能会关闭他们的公司。

您熟悉新项目的大纲似乎很合理。但是请记住，他们从一开始就要学习很多东西。这通常是一个压倒性的情况。您必须耐心等待，并反复回答相同的问题。这是正常现象，新开发人员必须学习很多东西，不要小看这一点。如果您对这些重复出现的问题感到生气，您将冒着风险，他们不会问，而是试图独自找出事情，这些事情充其量是很慢的，但常常是不可能的。他们还将不得不学习行话。大多数团队项目开发自己的语言。有意识地解释时，尽量避免使用术语。像向妈妈解释一样解释这些东西。同样，请耐心等待。

另外，您可以通过尝试一些评估中心风格的任务来尝试将它们与团队中已有的其他人集成，例如，用4张纸支撑咖啡杯在45分钟内搭建一座桥梁。我们在软件工程的实践课程中使用此技术，让8名学生打破僵局，然后再在一个项目上工作3周。它有助于加快团队形成阶段。

1）给他们解释您的代码规则和准则。还提供有关您的应用程序如何工作以及常规代码结构的一般说明。

2）找到一些基本上独立于其他代码的小错误或项目。解释需要做什么，在代码中的什么位置，并定期检查它们。

3）慢慢开始为他们提供越来越大的项目，同时越来越少地检查它们。

4）不时坐在他们旁边。您可以通过看别人如何解决问题来学到很多东西。诸如“哦，您可以通过按ctrl-在代码中查找函数”之类的小东西。非常有用

现在，我发现有两个极端：

• 每五分钟有人问一个问题。“此Path.Join有什么作用？”。他们应该首先在Google上找到答案，只有在找不到答案时才找您。

• 另一个极端是，一个人工作半天而没有问一个问题。他们应该觉得问问题是一件好事。我只希望他们先自己尝试一下。

这些是我的公式，并与一些新手一起使用-这些步骤被证明是非常有效的。

a）为期2天的所有新开发人员都将获得有关项目要求和开发过程的一些介绍。

b）分配3周的时间来编写没有足够覆盖范围的代码的Junit测试。

c）完成3个任务后，分配小任务

d）分配复杂的任务并完成。

我认为只是分配一些小任务，请他们编写一些单元测试，使它们调试失败，使回归失败。没什么太大的要求，但足以让他们站起来。

您还应该分配一位高级开发人员，最好是每位可以帮助指导候选人的新开发人员。

是的，让他们记录他们对系统的了解。我在这里假设您有某种内部Wiki页面。如果不是这样，无论从长远还是短期来看，这绝对是必须的-令人惊讶的快速增长方式。Wiki页面不仅应包含代码文档，还应包含已知限制（这是软件：D），解决方法，时间/内存性能指标等内容。

不要只解释编码的良好做法和标准，而要解释读取代码的结构。说明该软件应该做什么以及如何实现或将要实现。

他们需要做一些工作才能理解，所以我建议将工作分为两部分，一是开始真正的工作，二是开始工作。他们将查看一些代码或文档，并认为“ WTF !? ”。发生这种情况时，会有人陪同他们并解释一些次要细节。