Как работает IT-команда: путь задачи от бэклога до релиза

С чего начинается рабочий день

Рабочий день разработчика в команде обычно начинается с проверки текущего состояния проекта. В трекере могли появиться комментарии к задаче, в pull request замечания от ревьюеров, а в CI могла упасть сборка. Иногда приоритет меняется из-за стоппера в соседней команде или ошибки, найденной во время тестирования.

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

После синка разработчик обновляет карточку задачи: меняет статус, добавляет ссылки на pull request или сборку, фиксирует блокеры и договорённости. По хорошему описанию коллега должен понять текущее состояние работы без дополнительного созвона.

Если задачу можно брать в разработку, перед первым коммитом стоит ещё раз проверить её содержание. В карточке должны быть указаны:

• цель изменения,
• ожидаемое поведение системы,
• пользовательские сценарии,
• ограничения, 
• условия приёмки. 

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

Как задача попадает в работу

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

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

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

Готовая к разработке карточка обычно содержит:

• цель изменения и ожидаемый результат;
• пользовательские сценарии;
• дизайн, спецификацию или контракт API;
• условия приёмки и способ тестирования;
• ограничения и зависимости от других компонентов;
• оценку объёма работы.

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

При работе спринтами готовые карточки обсуждают на планировании. Команда определяет цель спринта, оценивает доступные ресурсы и выбирает объём работы. После планирования карточка переходит в статус To Do. Теперь у разработчика есть понятная цель, согласованный объём и условия приёмки.

С этого момента начинается техническая работа: исследование проекта, выбор решения и декомпозиция реализации.

Что проверяет разработчик перед кодом

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

• где находится код, связанный с задачей;
• какие модули, интерфейсы и пользовательские сценарии изменятся;
• какие готовые компоненты можно использовать;
• зависит ли реализация от другой задачи или сервиса;
• потребуется ли feature toggle или A/B-тест;
• какие проверки нужно добавить или обновить.

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

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

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

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

Как проходит код-ревью

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

Перед ручным ревью запускается CI. Пайплайн собирает проект, проверяет код линтером и прогоняет юнит-тесты. Результаты видны прямо в pull request, поэтому ошибки сборки и упавшие тесты можно исправить до мержа.

Ревьюеры проверяют:

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

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

Замечания оставляют в комментариях к конкретным строкам или участкам решения. Автор исправляет код, обновляет pull request и повторно запускает проверки. Если комментариев недостаточно для обсуждения сложной реализации, участники созваниваются и разбирают решение вместе.

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

Как задачу тестируют

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

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

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

Найденная ошибка возвращает карточку в статус Reopen. Разработчик исправляет код, CI выпускает новую сборку, и проверка запускается повторно. После успешного тестирования задача получает статус готовности к релизу и связывается с нужной версией продукта.

Как команда готовит релиз

Когда задачи прошли тестирование, команда фиксирует состав релиза. Карточки связывают с конкретной версией продукта, а изменения, которые не успели пройти все проверки, переносят в следующую.

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

Перед выпуском срабатывают quality gates:

• проект успешно собирается;
• юнит-тесты проходят;
• статический анализ не находит критических проблем;
• регрессионные и UI-тесты завершаются успешно.

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

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

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

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

Что происходит после выхода в прод

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

Команда отслеживает:

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

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

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

Для срочного исправления создают hotfix. Он проходит сокращённый по времени цикл, сохраняя обязательные проверки: код-ревью, сборку и тестирование затронутого сценария. После выпуска исправление добавляют в основную ветку разработки, чтобы ошибка не вернулась в следующем релизе.

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

Как рабочие встречи связаны с задачей

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

Основные встречи связаны с процессом так:

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

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

Итого

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

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