Переход от одного человека проекта к командному проекту в будущем. Что мне теперь делать при подготовке и что может подождать?

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

Любой, у кого есть опыт в продвижении по этому сценарию, их понимание будет оценено.

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

1. Поместите все в контроль исходного кода. Используйте то, к чему все имеют доступ, и начните прямо сейчас . Без исключений. Никаких задержек. Никаких оправданий.

2. Создайте область QA / Test, полностью отделенную от вашей личной "рабочей" или "среды разработки". По крайней мере, отдельный идентификатор пользователя. В идеале на отдельной ВМ.
   Полностью отдельный. Нет возможности совпадения с вашей текущей рабочей средой.

3. Прекратите тестирование после модульного тестирования в вашей собственной рабочей среде. Код и юнит-тест вы делаете «как сами». Все остальные тесты (интеграция, производительность, что угодно) вы делаете на отдельной виртуальной машине. Никогда не проверяйте себя. Всегда тестируйте как отдельный пользователь QA. В идеале на отдельной ВМ.

   «Работает для меня» - плохо говорить своим членам команды. Очень плохо. Вы должны выяснить, что они делают неправильно. Несколько раз в день.

4. Планирую записать все. Используйте инструмент разметки в виде простого текста (RST или Markdown или что-то в этом роде), чтобы вся документация в репозитории контроля версий была в виде простого текста. Инструмент может создавать HTML-страницы (т. Е. Docutils для RST), PDF-файлы или что-то еще, что кажется лучшим. Не используйте проприетарные форматы документов (например, MS-Word). Они могут не очень хорошо работать с некоторыми системами контроля исходного кода.

5. Первое, что вам нужно записать, это следующее.

   • Как создать рабочую среду разработки. В случае сомнений создайте виртуальную машину и выполните всю операцию на этой виртуальной машине. Убедитесь, что шаги действительно работают и документация понятна . Актуальные строки набираются в фактической командной строке для ясности.

   • Как запустить пакет модульных тестов. Опять таки. Будьте уверены, что инструкции работают и не требуют обдумывания. "Введите это:" "Подтвердите, что:" такие вещи. Дело не в том, что члены вашей команды глупы. Дело в том, что вы не помните, что вы предполагаете, если не запишите все это.

   • Как запустить комплект интеграционных тестов.

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

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

   Вы будете делиться этим. Это идет под контролем исходного кода.

7. В конце концов, вы можете документировать другие 4 вида.

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

   • Представление процесса часто полезно. Зависит от общего применения, насколько это важно.

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

     Помимо того, что это приемлемо, чтобы быть неформальным, это имеет тенденцию быстро меняться.

   • Информация о развертывании. Серверы. IP-адреса. Учетные данные базы данных. Все эти вещи должны быть записаны. В конце концов.

Инструменты и методология

Что необходимо, чтобы успешно сотрудничать и быть продуктивным?

• Определите части / компоненты вашего проекта: четко различайте разные части (база данных, уровень доступа к данным, веб-сайт, сервис, API, тестовые проекты, сценарии сборки, ...) и среды (dev, staging, production) и присваивайте им названия постоянно влияет на ваше устное и письменное общение (документация, названия проектов, ...)
• Используйте систему управления исходным кодом (на тот случай, если вы этого еще не сделали). Подумайте, как использовать ветвление с вашим проектом и настройкой.
• Автоматизируйте свои сборки - максимально упростите настройку среды из исходного хранилища.
• Тестовые проекты необходимы для больших проектов, по крайней мере, для более сложных проектов.
• Используйте промежуточные среды, в которых ваш проект готов к использованию. Кроме того, создайте и сохраните образцы данных для автоматической установки.
• Используйте систему отслеживания ошибок, которая может помочь расставить приоритеты и спланировать разработку, а также послужить памятью о прошлых ошибках и способах их устранения.
• Документируйте каждую часть вашего проекта, некоторые больше, чем другие. Мне лично нравится: Обзор - Архитектура - Зависимости - Конфигурация - Общие проблемы ( отсюда ). Иногда чем меньше, тем лучше - чтобы не допустить устаревания вашей документации, лучше быть кратким и позволить документации стать частью вашей повседневной деятельности.

Управление / работа в команде

... или что-то еще на межличностном уровне

• Определите ваши ожидания от другого разработчика. Будьте разумны, никто не сможет привнести в вас такую ​​же вовлеченность и страсть - по крайней мере, не с самого начала. Сообщите, что вы ожидаете, а что нет, определите свои и чужие обязанности. Не каждый является инженером, архитектором, разработчиком, dba и sysadmin, но если это то, что вы ищете, выберите подходящего человека, иначе вы будете разочарованы.
• На первом , определить задачи точно , а также обзор и обсуждение результатов. Постепенно начинайте все меньше и меньше микроуправлять. Идея состоит в том, чтобы укрепить доверие и повысить ответственность.
• Планируйте свой проект , ставьте цели для своего проекта и для своей команды на следующий год. Запишите это и проверьте это позже, это даст перспективу . Эти цели могут или не могут быть сообщены другим (если они являются целями, которые вы должны достичь, а не другими), это может быть просто ваш собственный контрольный список.
• Потратьте день на подготовку и планирование первого месяца (или двух / трех месяцев) вашего нового разработчика. Я нахожу это чрезвычайно мотивирующим при работе с хорошо подготовленными людьми. Ни у кого не должно сложиться впечатление, что его время потеряно.
• Отпусти . Это твой ребенок, он тоже должен стать чужим. Позвольте другому стать экспертом лучше, чем вы, по крайней мере, в некоторых частях проекта. Это означает, что на самом деле вы добились успеха.
• Послушай - если ты ее нанял, ей есть что сказать. Будьте готовы учиться.
• Будьте готовы поделиться своими знаниями и опытом (а значит, время - наберитесь терпения).
• Будут допущены ошибки , то, как они обрабатываются и что каждый узнает о них, что имеет значение.
• Позвольте времени учиться и экспериментировать

Книжные ссылки

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

Эти книги действительно стоит прочитать в отношении команд, организаций и программных проектов:

• Кадровое
• Мифический Человек Месяц
• Оценка программного обеспечения, демистификация черного искусства

Ни одно из этих практических руководств о том, как реализовать методологию X (кроме оценки программного обеспечения, эта книга поможет вам выбрать подходящий процесс оценки). Конечно, книги, более сфокусированные на самом программировании, такие как Code Complete, также очень обогащают.

Я буду говорить из опыта, но имейте в виду, что все разные. Эти вещи не универсальны.

Одно - отпустить это лично. Этот проект - это то, с чем вы жили и жили в течение 18 месяцев - вы, естественно, хотели бы, чтобы каждое изменение было таким, как если бы вы это делали. Дайте коллеге буфер для ошибок, чтобы учиться. Создайте комнату, чтобы они были полезны. И имейте в виду, что это может произойти не сразу. Также было бы здорово, если есть что-то, часть кода, которую они чувствуют, что преуспевают в улучшении или создании, что похоже на успех за короткий промежуток времени. Терпение и терпимость имеют хорошие показатели здесь. Не пытайтесь заниматься микроуправлением, и если вы хотите критиковать, говорить «вы не правы», убедитесь, что у вас есть заслуга, вы можете доказать это, это не «религиозная» борьба.

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

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

По теме «чистый, быстрый, многократно используемый код» - предлагаю на собеседовании попросить написать небольшого менеджера по микроядрам / сервисам и / или исполнителя работ. Посмотрите, как подключаемые компоненты указаны и настроены. Не нужно заканчивать, это мысль, которая имеет значение. А также вы быстро научитесь людям, которые хорошо знают, как это сделать, захотят приличные деньги ;-) Удачи!

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

Автоматизация сборки: отличная идея, могу я добавить автоматизацию конфигурации для машины разработчика. Легче всего построить, чем больше будет (тем больше / быстрее тестируемое развертывание).

Еще одна идея (однажды она мне очень помогла): попросите нового разработчика выполнить некоторые мелкие задачи по очистке в различных областях вашей кодовой базы, чтобы он привык к инструментам верстки и т. Д. Одна хорошая идея - удалить затемнение областей, которые могут привести к путанице позже (пример: если вы использовали emmm python для двух строк сценария оболочки где-то, а ваш проект основан на java, попросите эти две строки переписать в java, так что разработчику №3 потребуется меньше знать, чтобы работать)

Я бы сосредоточился на автоматизации всего, что требует ручной работы, поэтому может быть испорчен неопытным человеком . Который, основываясь на вашем кратком комментарии выше, включает в себя следующее:

• установить контроль версий и заменить ручные резервные копии на автоматические,
• настройте автоматическое развертывание в максимально возможной степени (как минимум, напишите сценарий для развертывания через FTP, а не делайте это вручную.

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

Другая важная задача, как отметил @dimitris, документация. @S. Лотт добавил гораздо больше подробностей об этом, поэтому просто +1 к нему, а не повторять :-)

Вот некоторые мысли, частично основанные на личном опыте:

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

• Сначала сконцентрируйтесь на коде уровня API / ядра, предоставляя новому сотруднику некоторую работу «прикладного уровня» или исправляя ошибки, чтобы постепенно познакомить их с кодом. Как правило, начните с более простых , но значимых и, таким образом, полезных задач .

• Общение важно. Быть отзывчивым на вопросы, комментарии и идеи нового сотрудника. Объясните, почему, по вашему мнению, идея не очень хорошая. Свежая пара глаз может найти место для улучшения на удивление хорошо. Если ваш новый сотрудник достойный, он может просмотреть ваш код и в конечном итоге принять участие в архитектурных решениях. Обсудите, отразите идеи друг от друга. Это одно из величайших преимуществ наличия сотрудника в вашем проекте.

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

• Используйте систему контроля версий . Поддерживать логическое расположение исходного файла и дисциплину сборки .

Что касается собеседования - я не большой поклонник искусственных тестов кодирования или хитрых вопросов, если только вы не хотите попробовать стрессоустойчивую способность кандидата. Даже самые умные из решателей проблем могут запереться в такой ситуации. Среди прочих качеств, которые вы будете искать: честность , профессиональные возможности , технологические знания / понимание , энтузиазм и взаимная совместимость . Рабочая атмосфера может много значить; нежелательно выбирать партнера по команде, который вам не нравится. Разместите ваши вопросы правильно и проведите неформальную дискуссию, чтобы получить хорошее представление о вашем кандидате. Удачи!

Технологии

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

1. Управления источником
2. Отслеживание проблем
3. Непрерывная интеграция

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

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

У Pragmatic Programmer есть несколько довольно хороших книг по этому вопросу. Вот несколько, которые я бы порекомендовал. Они имеют другие похожие названия в зависимости от того, какой язык программирования вы используете или какой контроль версий вы хотите использовать:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. ком / название / авто / прагматичная-проект-автоматизация

личный

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

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

Эти пункты являются наиболее важными на мой взгляд:

1. Прочитайте важные части вашего кода и убедитесь, что их легко понять. Используйте комментарии или интуитивно понятные имена функций и переменных.
2. Сделайте так, чтобы новый человек легко отправлял код.
3. Если это не тривиально, создайте файл README, который объясняет все необходимые шаги для нового разработчика по настройке среды разработки. В качестве альтернативы тесно помогите в настройке этой среды.
4. Дайте новому разработчику очень четко определенные задачи при работе над этим новым проектом. На мой взгляд, эти задачи должны включать новую, но простую функциональность. На мой взгляд, задачи по очистке не имеют особого смысла, так как новый разработчик должен сначала привыкнуть к вашему стилю кодирования и тем его привычкам, даже если они плохие. Очистка или даже рефакторинг - это работы, которые должны выполнять люди, знающие код.
5. Уточните, каков процесс отправки кода. (Например, отправляйте только то, что компилируется.) Но не будьте слишком строги, это может быть неприятно в начале.
6. Подготовьте документ с правилами кодирования. Может быть очень сложно догадаться, каковы другие соглашения о кодировании.
7. Если приложение сложное, подготовьте документацию, объясняющую архитектуру. Или объясните архитектуру новому человеку, используя блок-схемы или что-то подобное. Вы не хотите, чтобы новый разработчик тратил слишком много времени на реинжиниринг вашего проекта.
8. Если новый разработчик должен сам выполнять развертывание, подготовьте упорядоченный контрольный список, объясняющий все необходимые шаги для развертывания.

И последнее, но не менее важное: получить систему контроля версий. Subversion просто отлично. Но не добавляйте те файлы Eclipse (или что-то еще), которые являются специфическими для пользователя и поэтому постоянно изменяются. Они заставляют вас тратить часы. Не стесняйтесь спрашивать о Stackoverflow, если у вас есть проблемы с ним.