Коллективная разработка: принципы эффективности

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

Сервисы Git, SVN, Mercurial упрощают коллективную разработку, но не заменяют основных правил эффективного взаимодействия. Именно о них и пойдет речь.

Принцип 1. Разделение по интересам

Главный вопрос — как делить области ответственности так, чтобы коллективная разработка давала результат? Личный интерес каждого из членов группы здесь имеет первостепенное значение. Без желания каждого члена коллектива выложиться на максимум невозможно получить на финише успешный проект. Поэтому в основе разделения должен быть не опыт и не слепой жребий, а инициатива участников, которые хотят отвечать за конкретный участок работы.

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

Принцип 2. Разделение по опыту

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

А вот личностные характеристики должны отойти на второй план. Если человек с резюме «халтурщика» горит идеей реализовать модуль, худшее, что можно сделать — пойти на поводу у сомнений. В первые же рабочие дни вы узнаете, кто подтверждает опасения, а кто решил их опровергнуть. Так к чему портить отношения на этапе планирования?

Принцип 3. Общие правила оформления

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

Сразу договоритесь об основных моментах:

  1. Комментарии. Должны быть короткими и понятными, дополнять код, а не расшифровывать его.
  2. Стиль. В каждом языке есть свод правил по оформлению кода, но команда может очертить собственные основные принципы — относительно пространства имен, табуляций, формирования модулей.
  3. Настройки. Организационные моменты, касающиеся выбора общей среды разработки, настроек доступа, подключаемых библиотек и прочего.

Принцип 4. Карта вопросов

Когда новички вступают в командную разработку продукта, требующего более высокого уровня подготовки, у них возникает множество вопросов. Выход первый — задавать их напрямую более опытным коллегам. Способ почти идеальный, но далеко не всегда разъяснение бывает оперативным. Второй — искать решение самостоятельно, но помнить, что это может стать «бутылочным горлышком» проекта ина этом коллективная разработка может застопориться. И в этом случае надо позаботиться о «карте вопросов»: комментариях в коде или отдельном текстовом файле, адресованных проверяющему. Так все причастные смогут понять, где в проекте потенциальные проблемы.

Принцип 5. Визуализация

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

Визуализировать можно не только алгоритм, но и схему кода. Это поможет не только окружающим, но и вам — задачи не будут скакать от строки к строке, а соберутся в блоки.

Принцип 6. Перекрестный опрос

Когда код написан, надо его проверить. Заниматься этим самому необходимо, но 100% качества это не дает. Поэтому хорошо бы изначально понимать, кто за проверку чьего кода будет отвечать.

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

Выгоды здесь две:

  1. Меньше времени на адаптацию. Когда взаимодействие ограничено двумя людьми, вы не тратите часы на привыкание к чужому стилю, выяснение задач и способов решения. Изложенные выше принципы командной разработки минимизируют сложности индивидуального подхода, но не устраняют их совсем. Перекрестная проверка — еще один помощник.
  2. Больше времени для коммуникации. Когда два человека проверяют друг друга, они «на связи» и могут чаще задавать мелкие вопросы, которые в ином случае забылись бы. А успех от провала часто отделяет мелочь.

Принцип 7. Время на проверку

Хоть проверять код и необходимо, но нельзя затягивать эту работу. Следуйте правилу: проверка чужого кода не должна занимать более 10% от вашей деятельности.  Это статистический барьер, который позволяет определить шаг проверок, контролировать выполнение правил и не отставать от общего графика из-за халтуры отдельных коллег.

Собрать команду разработчиков, которые хотят поучаствовать в создании большого проекта, несложно. Куда тяжелее заставить всех двигаться в одном направлении, идти на взаимные уступки. Но имея под рукой этот свод принципов, вы точно найдете ответы на два вечных вопроса: «кто виноват?» и «что делать?».

Коллективная разработка: итоги

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

 

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

Комментарии

mood_bad
  • Пока нет коментариев.
  • chat
    Добавить комментарий