Командная разработка

Зачем нужна командная разработка

Командная разработка — это организованная совместная работа нескольких специалистов над программным продуктом. В ней важны общие правила, прозрачные процессы и единые инструменты. Без этого возникает хаос: задачи теряются, релизы срываются, качество падает. В этом топике мы разберём, как применять Agile-подходы, чем отличаются Scrum и Kanban, как называть ветки в Git и привязывать их к задачам, как пользоваться Git-Flow, а также как настроить релизный цикл с release candidate (RC).

Agile: принципы и ценности

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

Фокус на ценности для пользователя: каждый спринт должен приносить ощутимый результат.
Инкрементальность: продукт развивается маленькими шагами, а не «одним большим релизом».
Прозрачность: статус задач и метрики доступны всей команде.
Адаптивность: планы меняются по мере появления новой информации.

Scrum: роли, события, артефакты

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

Роли: Product Owner (приоритизирует backlog), Scrum Master (помогает процессу), Команда разработки (делает инкремент).
События: планирование спринта, ежедневные стендапы, ревью спринта, ретроспектива.
Артефакты: Product Backlog, Sprint Backlog, Инкремент.

Спринт обычно длится 1–2 недели. На планировании команда выбирает задачи из backlog по приоритету и оценивает их сложность. По итогам спринта проводится демонстрация результата и ретроспектива для улучшения процесса.

Kanban: визуализация потока и ограничение WIP

Kanban — фреймворк непрерывного потока. Вместо спринтов — постоянная доставка. Основные практики: визуализация колонками (Backlog → In Progress → Review → Testing → Done), ограничение WIP (Work In Progress) и управление потоком по метрикам (cycle time, throughput).

Визуализация: каждая задача видна на доске, легко понять узкие места.
Ограничение WIP: нельзя начинать новую работу, пока не завершена текущая — это снижает переключение контекста.
Сервисные уровни: SLA для классов работ (например, баги — быстрее, чем фичи).

Правила наименования веток и привязки к задачам

Единый шаблон имён веток делает историю репозитория предсказуемой и упрощает автоматизацию. Ветка должна однозначно указывать тип работы и ссылаться на идентификатор задачи в трекере (например, Jira , YouTrack, GitHub Issues).

Типы веток: feature/, bugfix/, hotfix/, chore/, refactor/, docs/.
Шаблон: type/TICKET-123/korotkoe-opisanie.
Только латиница, цифры и дефисы; все слова в kebab-case.
Связь с задачей: ссылка на задачу в описании pull request и в первом коммите.

            git checkout -b feature/APP-742/user-profile-avatar-upload
            git push -u origin feature/APP-742/user-profile-avatar-upload
        

Формат коммитов удобно стандартизировать по Conventional Commits. Это помогает автоматически генерировать релиз-ноты и семантические версии.

            git commit -m "APP-742: allow avatar upload via drag-and-drop"
            git commit -m "APP-801: handle refresh token rotation on 401"
        

Git-Flow: типы веток и правила слияния

Git-Flow — модель ветвления, в которой выделены постоянные ветки main и develop, а также короткоживущие ветки feature, release и hotfix. Она обеспечивает предсказуемость релизов и безопасные исправления в продакшене.

main — всегда готовая к релизу стабильная ветка.
develop — интеграционная ветка для завершённых фич до формирования релиза.
feature/* — ведётся от develop, по завершении вливается обратно в develop через Pull Request.
release/* — создаётся от develop, сюда входят только фиксы и полировка; после релиза вливается в main и в develop.
hotfix/* — создаётся от main для срочных исправлений продакшена; после фикса вливается в main и в develop.

            # начало фичи
            git checkout develop
            git checkout -b feature/APP-900/export-to-csv

            #завершение фичи

            git push -u origin feature/APP-900/export-to-csv

            #подготовка релиза

            git checkout develop
            git checkout -b release/1.8.0
            git push -u origin release/1.8.0

            #хотфикс продакшена

            git checkout main
            git checkout -b hotfix/1.7.1/null-pointer-on-login
            git push -u origin hotfix/1.7.1/null-pointer-on-login

            git checkout develop
            git merge --no-ff feature/APP-900/export-to-csv
            git tag -a v1.8.0-rc.1 -m "RC1 for 1.8.0"
            git push origin v1.8.0-rc.1
        

Релизный цикл и работа с Release Candidate (RC)

Release Candidate (RC) — это кандидат на релиз, который проходит финальные проверки. Если дефектов блокирующего уровня не найдено, RC становится официальным релизом. Такой процесс снижает риски и делает выпуск предсказуемым.

Заморозка фич: в ветку release/* попадают только исправления багов и тексты.
Версионирование: используйте SemVer (MAJOR.MINOR.PATCH).
Теги: v1.8.0-rc.1, v1.8.0-rc.2 до готовности; затем v1.8.0.
Артефакты: для каждого тега собираются образы контейнеров и пакеты.
Среды: RC деплоится на staging, релиз — на production.

            # создание RC-тэга
            git checkout release/1.8.0
            git tag -a v1.8.0-rc.1 -m "Release candidate 1 for 1.8.0"
            git push origin v1.8.0-rc.1
        

После прохождения регресса и приёмки RC переводится в релиз: создаётся тег v1.8.0 на том же коммите и выполняется продакшен-деплой. Баги, найденные в RC, фиксируются коммитами в release/* с инкрементом rc-номера.

            # перевод RC в релиз
            git tag -a v1.8.0 -m "Release 1.8.0"
            git push origin v1.8.0
        

Связка с трекером задач и релиз-ноты

Каждая задача должна иметь ссылку на коммит, ветку и Pull Request, а каждый релиз — список задач и изменений. Это достигается единым форматом сообщений коммитов и шаблонами PR.

Коммиты: type(scope): message (TICKET-ID).
PR: шаблон с «Описание», «Как тестировать», «Ссылки на задачи», «Скриншоты».
Changelog: генерируется из Conventional Commits, сгруппирован по feature/fix/chore.

Минимальные политики для начинающей команды

Имена веток: type/TICKET-ID/short-desc.
Conventional Commits и обязательный PR-review.
Доска Kanban с ограничением WIP или Scrum-спринты на 1–2 недели.
Еженедельные релизы с RC на staging.
Автоматическая сборка по тегу и генерация релиз-нот.