Как получить новых членов команды в курсе проекта? [закрыто]

Мы собираемся нанять 1-2 новых инженера для команды разработчиков программного обеспечения (состоящей из 3 разработчиков, 1 тестировщика).

Какие шаги для их интеграции в команду?

Мои идеи:

• читать документацию (стандарты кодирования, документы в используемых нами методологиях разработки)
• заставить их читать существующий код
• назначить им несколько простых задач
• в конце сделайте их ответственными за часть кода

Что еще мы можем сделать?

Проект находится в медицинском секторе (ультразвуковая система) и продолжается уже 5 лет. У нас есть ежегодные выпуски, и мы собираемся закончить один выпуск, когда мы хотим добавить 1-2 инженеров.

Проект находится на стадии сопровождения (рефакторинг устаревшего кода, плюс добавление новых функций). Вещи в значительной степени по графику (более или менее).

Исходя из того, кто должен был быстро освоить множество различных кодовых баз в моей карьере, я бы предложил следующее:

1. Потратьте короткое время (возможно, день или два) на действия, связанные с использованием продукта, чтобы они могли ознакомиться с тем, что делает продукт. Это может быть проверка ошибок или выполнение планов тестирования QA или прохождение обучения пользователей.
2. Работайте над небольшими локализованными ошибками. Это знакомит инженера с тем, как создавать и отлаживать приложение, не занимаясь изучением архитектуры.
3. В идеале, написать небольшую новую функцию, которая локализована. Это позволяет им писать кусок кода, и, когда они пишут его, они знакомятся с окружающими фрагментами кода, с которыми их новый код должен работать.

Оттуда расширяйте объем и сложность заданий с течением времени в зависимости от уровня опыта и способностей инженера. Это позволит разработчику естественным образом расширить свои знания о кодовой базе.

Я бы избегал чтения только задач (документация или код). Чтение документации становится действительно скучным и очень быстрым, а чтение случайного кода бесполезно, поскольку у них не будет контекста для работы. Достаточно сложно прочитать код для обзоров кода, когда вы уже знаете продукт и кодовую базу. Я не вижу ничего полезного в том, что новый инженер просто читает код.

У меня такое ощущение, что у большинства людей терпимость к чтению документации довольно низкая (хороша на день или два, но помимо этого им, вероятно, будет не терпится сделать что-то более практическое).

Я не думаю, что вы действительно сможете понять код приложения без разумного понимания самого приложения. Программное обеспечение, по-видимому, обладает множеством функциональных возможностей, с которыми они могли бы «играть» как пользователь; в конечном итоге им потребуется возможность его протестировать, поэтому я ожидаю, что очень важно, чтобы они знали, как его установить, настроить и выполнить с ним общие задачи

Я лично нахожу, что обзор архитектуры высокого уровня обычно очень удобен для того, чтобы получить общее представление о том, как все работает - может быть, выделите час или два времени старшего инженера (или себя, если необходимо?) В течение их первой недели, чтобы просто пройти через основные гайки и болты основного применения. например, понимание всех подсистем и того, как вещи связаны друг с другом, знание того, какие биты обрабатываются сторонним программным обеспечением / библиотеками и какие биты должны храниться внутри компании. (Если у вашей организации нет современной документации действительно исключительного качества, я бы предположил, что они никак не смогут справиться с подобными вещами, если кто-то не объяснит им это непосредственно с помощью доски: - ))

Что касается того, чтобы дать им что-то «практическое», задачи по обслуживанию / поиску ошибок могут быть хорошим способом для их ускорения на некоторое время (пару недель / месяцев?) - они будут в ситуациях, когда определенные области функциональности нужно понимать, тестировать и отлаживать; помогая накопить знания о коде, требованиях, инструментах, используемых компанией, процессах разработки и продукте (ах) в целом, и, надеюсь, не нужно отнимать слишком много времени у остальной команды разработчиков

Как ведущий, я провожу как минимум 2 дня с новыми разработчиками. Я обнаружил, что развивая отношения, в которых удобно задавать неизбежный вопрос «как ты продвигаешься?» является обязательным. В любом новом сообществе есть страх, в который можно вписаться ... мы скрываем ошибки, действуем идеально, делаем вещи лучше, чем они есть, уменьшая трудности. Менеджер, проводящий 2 дня с кем-то, даст им понять, что это не то, чем его культура, и позволит им подавать пример. Новым программистам нужен урок истории о том, откуда вы пришли и как далеко вы продвинулись. Документы просто не делают задачу справедливой.

Я работаю в промышленности всего 10 месяцев (на месте), но я обнаружил, что мне помогло следующее:

• Объединиться с другими разработчиками и наблюдать, как они решают проблемы.
• Тестирование программного обеспечения помогло, мне нужно было протестировать функцию x, что означает, что я читаю документацию по функции x. Я сделал это много, это помогло.

Оба из них помогли мне немного. Удачи.

Я бы пошел с высокого уровня на низкий.

Демо приложение как можно скорее

Одна из самых важных вещей заключается в том, что разработчик имеет представление о том, над чем он будет работать. Во время демонстрации укажите некоторые вещи, которые были в стадии разработки, и направление, в котором движется приложение.

Объясните архитектуру высокого уровня

Это тоже очень важно. Разрешить новому разработчику слушать и задавать вопросы. Сделайте это как групповое упражнение с другими разработчиками, которые, надеюсь, помогут вам и помогут. Это позволит новому разработчику понять, что говорить открыто и честно можно.

Иметь большой готовый документ

Наличие отличного документа на борт не только помогает новым разработчикам, но и старым. Он может содержать ожидания, полезные ссылки и информацию о настройке среды. (Я не могу сказать вам, сколько раз я использовал нашу готовность к работе, чтобы настроить свою среду, когда я получаю новый компьютер ...) Это должно быть хорошо структурировано и точно, а не задерживаться и не быть свалкой для каждого маленькая деталь

Поощряйте его / ее задавать вопросы (и будьте готовы ответить на них)

С ответами направляйте их, но не говорите им, что делать. Дайте им подсказки, но позвольте им наконец понять это сами.

Помогите другим членам команды приветствовать новичка

Есть две стороны медали, когда кто-то присоединяется к команде. Команда должна иметь инструменты, чтобы приветствовать нового разработчика.

Пусть они возьмут небольшое задание или два

Позвольте им добавить что-то новое и видимое для проекта, которое можно использовать для демонстрации. Когда это будет продемонстрировано, отзовитесь, кто это сделал и какую хорошую работу они сделали. Это действительно может повысить самооценку. Чем быстрее они чувствуют, что они добавляют ценность, тем быстрее они чувствуют себя частью команды. Чем быстрее они почувствуют себя способными сделать все возможное.

Поощряйте их выполнять более сложные задачи, когда они чувствуют себя все более и более комфортно

Хорошие кандидаты будут делать это естественно.

Один «ориентационный» поток, через который я прошел (и нашел полезным), был чем-то вроде:

1. Краткая презентация, представляющая «общую картину», каковы компоненты, как они вписываются и какова общая архитектура.
2. Обзор кода, введение в функции, которые обрабатывают основную логику для компонента (ов), назначенных мне. Покрыты некоторые вещи, связанные с соглашениями и стилем кодирования.
3. Была назначена куча открытых вопросов и ошибок с низким приоритетом (которые были в основном локализованы для назначенного мне компонента и довольно просты).
4. Я должен был отлаживать приложение и просить помощи с вещами, которые я не мог расшифровать.
5. После того, как исправление было внесено, я прошел через процесс (проверка кода, тестирование уровня разработки и т. Д.) Перехода к интеграции.
6. Повторите для оставшихся задач / выделенных ошибок.

Я чувствую, что этот подход (и его варианты) будет полезен, потому что:

• Это было более практичным и относительно независимым (постоянный, не держась за руки и т. Д.). Таким образом, он предоставляет достаточно места / времени новому человеку, чтобы привыкнуть к коду и тому, как все делается в команде.
• Это также полезно для команды в целом, так как может быть решена пара задач / ошибок с низким приоритетом. У человека, помогающего новым людям, также есть больше времени для решения поставленных перед ним задач, так как постоянное удержание руки не требуется, и время может быть специально запланировано для решения проблем / проблем, с которыми может столкнуться новый человек.

Начальные сотрудники должны иметь небольшую, но не слишком маленькую и четко определенную задачу для работы. Таким образом, они могут начать понимать, как структурирован код, пытаясь понять, как выполнить свою задачу. В процессе возникнут вопросы, и в этот момент вы можете направить их к документации или другим ресурсам, которые они могут использовать, чтобы помочь им усвоить базу кода. Это также помогает, если цикл разработки, фиксации и развертывания короткий, и они могут увидеть плоды своего труда в действии как можно быстрее.

Вот как я хожу

1. Дайте им несколько задач, связанных с проектом (например: если ваш проект является приложением базы данных, попросите их просто создать приложение для соединения с базой данных и выполнить простую операцию).
2. Когда вы обнаружите, что они поняли идею работы, дайте им демонстрацию проекта
3. Попросите их прочитать документацию.
4. Познакомьте их со стилями и стандартами кодирования
5. Позже дайте им некоторые упражнения по отладке (чтобы узнать ход проекта).
6. Попросите их исправить точку, которую вы уже исправили (просто чтобы выяснить их логику).
7. Наконец, сделайте их частью проекта.

Помните: независимо от того, сколько вы пытаетесь, до тех пор, пока участник не поймет полностью проект, вы не сможете выполнить работу наиболее эффективно из него.

Номер один - сначала научитесь использовать программное обеспечение, чтобы выяснить, какие проблемы оно решает с точки зрения пользователя. Если у него нет пользовательского интерфейса (например, это бэкэнд-сервис или что-то еще), пусть они используют любой доступный интерфейс для его использования. Всегда полезно по-новому взглянуть на ваше программное обеспечение с точки зрения пользователя, и это может помочь новому сотруднику увидеть то, чего вы не можете, поскольку вы уже встроены в проект.

После этого хорошим первым проектом может быть что-то вроде дополнения или нового модуля, добавляемого в программное обеспечение, что сводит к минимуму объем знаний, необходимых для существующей кодовой базы. Написание чего-то нового всегда будет проще, чем исправление ошибки, которая может потребовать большого количества изменений во многих исходных файлах. По моему мнению, если дать новому сотруднику задачу исправления ошибок, это, вероятно, отключит его в вашей компании.

Ваша схема ознакомления новых с проектом кажется разумной. Но имейте в виду, что в начале им будет чему поучиться. Это обычно подавляющая ситуация. Вы должны быть терпеливы и отвечать на одни и те же вопросы неоднократно. Это нормально, новые разработчики должны многому научиться, не стоит недооценивать это. Если вы разозлитесь из-за этих повторяющихся вопросов, вы рискуете, что они не будут задавать вопросы и попытаться выяснить в одиночку вещи, которые в лучшем случае могут быть очень медленными, но зачастую невозможными. Также им придется выучить жаргон. Большинство командных проектов развивают свой язык. При объяснении сознательно старайтесь избегать жаргонных слов. Объясни это так, как ты бы объяснил своей маме. Опять будь терпелив.

Кроме того, вы можете попытаться интегрировать их с другими членами команды, выполнив некоторые задачи в стиле центра оценки, например, построить мост за 45 минут из 4 листов бумаги, поддерживающих кофейную чашку. Мы используем эту технику в практическом курсе по разработке программного обеспечения, чтобы группа из 8 студентов сломала лед, прежде чем они будут работать над одним проектом в течение 3 недель. Это помогает ускорить этапы формирования команды.

1) Дайте им объяснение правил и рекомендаций вашего кода. Также дайте общее объяснение того, как работает ваше приложение, и общую структуру кода.

2) Найдите небольшие ошибки или проекты, которые в значительной степени не зависят от другого кода. Объясните, что нужно сделать, где в коде и регулярно проверяйте их.

3) Медленно начинайте давать им все больше и больше проектов, проверяя их все реже и реже.

4) Сядьте рядом с ними время от времени. Вы можете многому научиться, просто посмотрев, как кто-то еще решает проблему. Такие мелкие вещи, как «о, вы можете искать функции в своем коде, нажимая ctrl-». очень полезны.

Теперь я обнаружил, что есть две крайности :

• Кто-то, кто задает вопрос каждые пять минут. «Что делает этот Path.Join?». Сначала они должны получить ответ от Google, и приходят к вам только тогда, когда не могут найти ответ.

• А другая крайность - тот, кто работает полдня, не задавая ни единого вопроса. Они должны чувствовать, что задавать вопросы - это хорошо. Я просто хочу, чтобы они сначала попробовали сами.

Это были мои формулы, которые использовались с несколькими новичками - эти шаги оказались очень эффективными.

а) Всем новым разработчикам будет предоставлено некоторое представление о требованиях проекта и процессах разработки в течение 2 дней.

б) Назначение 3-недельного задания по написанию тестов Junit для кода, который не имеет достаточного покрытия.

в) Как только 3 сделано, назначьте небольшие задачи

г) Назначить сложные задачи и сделать.

Я думаю, просто назначить несколько небольших задач, попросить их написать несколько модульных тестов, заставить их отлаживать некоторые неудачи регрессии. Ничего слишком большого или требовательного, но достаточно, чтобы они встали на ноги.

Вам также следует назначить старшего разработчика, желательно на каждого нового разработчика, который мог бы помочь наставнику кандидата.

И да, заставьте их задокументировать, что они узнают о системе. Я предполагаю, что у вас есть какие-то внутренние вики-страницы. Если нет, то это определенно необходимо как в долгосрочной, так и в краткосрочной перспективе - удивительно быстрый способ заставить людей нарастить. Вики-страницы должны содержать не только документацию по коду, но и такие вещи, как известные ограничения (это программное обеспечение: D), обходные пути, показатели производительности времени / памяти и т. Д.

Не объясняйте только хорошие практики и стандарты кодирования, но объясните, как структурирован код чтения. Объясните, что должно делать программное обеспечение и как оно будет или будет достигнуто.

Они не поймут, пока не будет выполнено какое-либо задание, поэтому я предлагаю разделить завещание на две части: одну до начала реальной работы, а вторую - после начала работы. Они заглянут в какой-нибудь код или документацию и подумают « WTF !? ». Когда это произойдет, кто-то будет сопровождать их и объяснять мелкие детали.