Как организовать совместную разработку на проекте при работе нескольких команд

Перед началом работ

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

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

Основные рекомендации при использовании Slack:

1. По возможности вести всё общение в одном канале, чтобы все участники видели, что происходит.
2. Каждое сообщение в канале должно быть обдуманным и необходимым, каждое сообщение – это отдельная тема, которая раскрывается в треде (чате по сообщению) данного сообщения. В треде сообщения указываются ссылки на участников, которые необходимы для ведения общения.
3. В отдельные каналы можно выводить темы, не связанные напрямую с ходом работ по проекту. Отдельно можно вынести канал по митингам и принятым решениям, чтобы они не потерялись в потоке сообщений.
4. Также полезно сделать специальный канал сообщений для реализации «эффекта кулера». Под «эффектом кулера» понимается ситуация, когда коллеги в одной компании собираются около всеми любимого устройства с горячей и холодной питьевой водой и обсуждают рабочие и около рабочие темы. Другие коллеги, услышав важную информацию, могут оперативно помочь в решении возникшего вопроса либо найти решение для какой-то из своих задач.

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

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

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

Единое хранилище разработки

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

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

Зачем нужна СКВ:

1. Хранение всех изменений проекта.
2. Возможность переключений на любую стадию развития проекта.
3. Возможность вести одновременную командную разработку.
4. Возможность решать проблемы, связанные с некорректностью или пересечением требований, которые пропустили на этапе проектирования.

На проектах в основном используется централизованное хранилище на базе технологии GIT.

Основной инструментарий:

1. MS Team Foundation Server (TFS) – это сервис, который позволяет организовать работу команды разработчиков с использованием технологии GIT, позволяет реализовать защищенный доступ к репозиторию в соответствии с ролевой моделью прав.
2. Git Extension – официальный инструмент от разработчика GIT для более удобной работы с ветками через UI.

На проектах выделяется три типа веток разработки:

MASTER - Мы считаем ветку origin/master главной. Т.е. исходный код в ней должен находиться в состоянии production-ready в любой произвольный момент времени.

DEVELOP - Ветвь origin/develop мы считаем главной ветвью для разработки. Хранящийся в ней код в любой момент времени должен содержать самые последние изменения, необходимые для следующего релиза.

FEATURE/HOTFIX - Вспомогательные ветви, в рамках которых выполняется разработка новой функциональности или исправление дефектов.

Рекомендуемый порядок работы с ветками:

1. Из ветки master создается ветка develop.
2. Из ветки develop создаются ветки feature.
3. Когда работа над веткой feature завершена, она сливается с веткой develop.
4. Когда работа по основным фичам в ветке develop завершена, она сливается в ветку master.
5. Если в master обнаружена проблема, из master создается ветка hotfix.
6. Когда работа над веткой исправления hotfix завершена, она сливается в ветки develop и master.

Работа нескольких команд в одном репозитории

Вариант 1. Для каждой группы разработчиков создается отдельная ветка для разработки develop.

Положительные моменты:

• У всех команд есть своя ветка develop.
• Рецензирование и сливание разработки выполняется независимо от других команд.
• Публикация разработки от одной команды не зависит от публикации разработки другой команды.

Отрицательные моменты:

• Требуется много времени на разрешение конфликтов при сливании в develop и получении из develop доработок в ветку команд.
• Возможна потеря наработок при некорректном разрешении конфликтов.

Вариант 2. Группы разработки работают с одной веткой develop, но работа по каждой «фиче» выполняется в отдельной ветке.

Положительные моменты:

• Отсутствует необходимость синхронизации веток команд.
• Независимость публикации веток «фич» друг от друга.
• Значительно меньше времени на разрешение конфликтов.
• Низкая вероятность потери наработок.

Отрицательные моменты:

• Необходимость взаимодействия между командами при публикации из ветки «фичи» в develop и master, требуется ожидание подтверждения слияния всех ответственных от команд – зависимость от доступности и готовности всех ответственных от групп.

Вариант 1 подходит для команд с полностью отделяемой разработкой. Вариант 2 – для команд, где разработка часто пересекается.

Принципы формирования наименования ветки

Для решения этой задачи ветка в наименовании должна содержать следующую информацию:

• Тип ветки (feature или hotfix).
• Кто вносит изменения.
• Команда.
• Разрабатываемая функциональность.

Пример:
feature-aav-directum-CreateNewDatabookConfigurations
hotfix-aav-directum-FixErrorContractList_NullException

Разрешения конфликтов

По наиболее частым кейсам по разрешению конфликтов прошу подробнее ознакомиться со статьей: Эффективный GitFlow на проектах

Организация процесса работ

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

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

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

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

Пример: реализовать новый процесс для работы со служебными записками при работе с несколькими адресатами.

Реализация данного процесса будет затрагивать как минимум две сущности:

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

Для декомпозиции удобно использовать любой инструмент для работы с майнд картами (ассоциативными картами):

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

Опять же при делегировании задач разработчику не следует их «схлапывать» в одну задачу, лучше сделать несколько отдельных задач и реализовать по приоритету. Это поможет ускорить процесс тестирования. Пока разработчик будет реализовывать второе требование, первое будет тестироваться.

Контроль выполнения задач

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

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

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

Для работы с kanban-досками преимущественно используем сервис Trello, поскольку: 

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

Рекомендуемый набор колонок:

Для определения критичности задачи, группы разработки, группировки по модифицируемым сущностям удобно использовать метки.

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

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

Объединение и управление

Как видим, можно выделить 3 блока механизмов взаимодействия, которыми требуется управлять:

1. Среда оперативного общения и взаимодействия.
2. Система управления версионностью.
3. Среда управления процессом выполнения задач.

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

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

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