Бизнес-процесс управления разработкой
Эта статья поможет организовать процесс разработки сайтов, приложений и других цифровых продуктов для команд на аутсорсе и инхаус. Здесь описан жизненный цикл задачи от постановки в таск-трекер до релиза в продакшн и дана схема бизнес-процесса.
Текущие описание — результат эволюции подхода к управлению разработкой в моей аутсорс-компании panfilov.digital с 2013 года. Я также помогаю внедрять эту систему в рамках консалтинга. Процесс отлажен на производственных командах до 20 человек, в которых задействованы менеджеры, тимлиды, разработчики, тестировщики, дизайнеры. Скорее всего, он без проблем масштабируется и на большее количество участников.
Я буду рассказывать о процессе разработки, но подход может быть применён на любом «цифровом производстве», где есть менеджеры, исполнители и руководители групп: например, в дизайне, маркетинге, создании контента.
Подход описан на базовом уровне без учёта возможной автоматизации многих процессов, таких как автотесты и DevOps. Статья адресована не только профессионалам в разработке, поэтому для специальных технических терминов будут даны пояснения.
Задачи и роли в команде
Производственный процесс разработки должен решать следующие задачи:
- укладываться в сроки;
- создавать качественный продукт;
- обеспечивать преемственность кода, чтобы было легко масштабироваться;
- приносить больше денег, чем тратить.
Обязательны три роли: менеджер, тимлид и разработчик. Если у вас есть отдельная роль тестировщика, он тоже участвует в процессе.
Менеджер отвечает за сроки и себестоимость проекта. Он собирает материал для работы, формулирует требования, руководит проектом и ставит задачи.
Тимлид отвечает за техническую архитектуру, качество кода и соблюдение сроков разработки. Тимлид контролирует загрузку исполнителей и организует релиз на продакшн.
Разработчик пишет код. Мы считаем, что разработчик выполняет задачу, когда он делает свою работу качественно и в срок, не превышая оценку.
Тестировщик тестирует задачи на предмет функциональных ошибок и составляет баглисты.
— продакшн площадка («прод», «продуктив», «бой», production) — сервер, хостинг, на котором расположена версия сайта или приложения, доступная пользователям;
— релиз (stable release», «деплой», «вылить на прод», deployment) — загрузка кода на продакшн, когда новая версия продукта становится доступна пользователям.
Настройка таск-трекера
Чтобы реализовать предложенную схему управления разработкой, подойдёт любой таск-менеджер, в котором можно устанавливать статусы для задач. Если нужен трекинг времени, то выбирайте сервис с учётом этого, либо попросите исполнителей вносить затраты вручную.
Популярные сервисы для управления задачами: Asana, Trello, Notion, Wrike, Clickup. Сервисы специально под задачи разработки: Jira, Pivotal. В panfilov.digital мы используем YouTrack.
У задачи должна быть следующая структура полей:
- Assignee — исполнитель задачи;
- Due Date — дедлайн;
- Estimation — оценка времени на выполнение задачи;
- Priority — приоритет. Три основных значения: Normal (обычная задача), Major (важно, но не критично), Critical (важно). Есть ещё Show-stopper — когда что-то сломалось настолько, что напрямую вредит бизнесу;
- Spent time — потраченное время, в идеале автоматически заполняется таймером;
- State — статус задачи.
👉 Три правила работы с таск-трекером:
— если задачи нет в трекере, её не существует;
Жизненный цикл задачи по разработке
Жизненный цикл задачи от постановки до релиза состоит из четырёх этапов:
В этом процессе исполнители передают задачу друг другу через смену Assignee и меняют её статус (поле State).
Проектирование и оценка
Роль менеджера. Менеджер ставит задачу: готовит описание и собирает все необходимые данные для начала работы. Затем передаёт задачу тимлиду.
Роль тимлида. Тимлид проверяет задачу на полноту, чтобы менеджер не упустил важных деталей. Если чего-то не хватает, возвращает задачу менеджеру. Когда проверка тимлидом пройдена, задача переходит к разработчику.
Если задача крупная, тимлид декомпозирует её и также может отдать разным исполнителям.
Для каждой задачи нужна предварительная оценка (поле Estimate). Не буду углубляться в методы оценки творческих задач (а программирование — это творческая деятельность), уточню, что оценка нужна для планирования проекта, хотя бы приблизительного.
Есть два подхода к формированию оценки задачи:
- Исполнитель оценивает задачу сам, а тимлид согласовывает. Если тимлид не согласен с оценкой, это сигнал, что требования сформулированы неправильно или у разработчика недостаточно информации.
- Задачу оценивает тимлид, а разработчик принимает или не принимает его оценку.
Общее правило — одна задача не должна быть с оценкой больше 8 часов. Если оценка получается больше, то задачу декомпозируют.
Когда оценка согласована, тимлид устанавливает дедлайн в поле Due date в зависимости от загрузки исполнителя.
Роль разработчика. В процессе анализа задачи исполнитель готовит план реализации — это набросок схемы будущего решения, понимание задачи исполнителем. Часто в процессе подготовки плана исполнитель настолько глубоко погружается в задачу, что на само написание кода уходит меньше времени, чем на проектирование — это нормально, посколько время на подготовку плана тоже учитывается в задаче.
Когда согласована оценка и готов план реализации, исполнитель берёт задачу в работу.
Выполнение задачи
Роль разработчика. Когда начинается работа над задачей, исполнитель меняет статус на In progress — в этот момент включается таймер. Если задача ещё не выполнена, но таймер нужно остановить, устанавливается статус Paused.
Время в задачу могут по очереди списывать несколько исполнителей, для этого необязательно создавать отдельные задачи:
Таким образом видно, сколько всего у команды ушло времени на задачу.
В процессе выполнения могут возникать вопросы, которые препятствуют дальнейшей работе — абсолютно всё невозможно предвидеть на этапе проектирования. Если так случается, задачу переводят в статус To be discussed и переназначают тому, кто может дать ответы.
Ещё бывает, что разработчик в какой-то момент понимает, что не укладывается в первоначальную оценку или дедлайн. В этом случае он сразу же в комментариях просит тимлида согласовать новую оценку и сообщает причину.
👉 Система контроля версий (version control) — система для хранения исходного кода; самая распространённая — git;
репозиторий (repository, «репа») — виртуальный контейнер с кодом: обычно под каждый проект — свой репозиторий, или два: для бекенда и для фронтенда;
ветка (branch) — ответвление от основной версии кода, с копией которого разработчик работает до релиза в продакшн
Когда разработчик заканчивает работу над задачей:
- выливает весь код в репозиторий,
- пишет в комментарии номер ветки,
- устанавливает у задачи статус Fixed,
- переводит её на тимлида.
Приёмка
Перед тем, как подготовить релиз, задача проходит несколько уровней проверки.
Роль тимлида. У тимлида есть список задач в статусе Fixed, которые перевели ему разработчики. На проверку отводятся сутки. Тимлид берёт их в порядке очереди, проводит code review и поверхностно проверяет на соответствие изначальным требованиям.
👉 Code review — процесс проверки кода на предмет ошибок: обычно поводит тимлид, но возможен перекрёстный код ревью, когда разработчики проверяют друг друга.
Тестовый сервер («dev-площадка», «дев») — серверная площадка, на которой развёрнута копия production-сервера. Используется для тестирования перед релизом. Чаще всего закрыта паролем (для веб-проектов — http-авторизация).
Роль менеджера. Если с кодом всё ок, то задача поступает менеджеру в статусе Ready to Check. Здесь менеджер вправе подключить QA (тестировщика), если задача комплексная и её нужно протестировать на разных браузерах и платформах.
Чтобы протестировать задачу, на тестовом сервере включают ветку git с версией кода, в которой она реализована, и проходят по тест-плану. Если всё круто, ставят статус Verified — задача готова к релизу. Если есть ошибки — возвращают исполнителю вместе с баг-листом.
Деплой на боевом сервере
Роль тимлида. Тимлид готовит релиз из задач в статусе Verified и заливает результат на боевой сервер по одной из трёх схем:
- непрерывный деплой — задачи выливаются в ближайший деплой;
- деплой по требованию — задачи выливаются только по указанию менеджера;
- система релизов — несколько задач сливаются в одну ветку, и происходит дополнительный этап тестирования всего релиза.
После деплоя тимлид присваивает задаче статус Deployed.
Роль менеджера. Менеджер проверяет проект на боевом сервере. Если всё хорошо — задача получает заветный статус Completed. Ура, мы справились!
Если на продакшене оказывается неработающий код, то релиз откатывается обратно, но такое случается редко. Задача специально проходит несколько уровней контроля, что практически исключает наличие критических ошибок на проде.
Что нужно для управления разработкой
- Выделить роли менеджера, тимлида и разработчика, определить их зоны ответственности и обязанности.
- Выбрать сервис для управления задачами, настроить поля у сущности задачи и трекинг времени.
- Построить серверную инфраструктуру с площадками для теста и продакшном.
- Контролировать дисциплину выполнения бизнес-процесса.
- Улучшать процесс, если выясняется, что какие-то шаги неэффективны.
Подписаться на телеграм → @panfilovonline
Заказать разработку → panfilov.digital
Получить консультацию по управлению и запуску digital-проектов → consulting@panfilov.group
Если вы оставите донат, то я пойму, что статья принесла вам ощутимую пользу и продолжу делиться такими материалами.