Итак, первый пост в цикле про релизные процессы будет посвящён начальному этапу. Задача в бэклоге команды — что дальше? Я рассмотрю два диаметрально противоположных варианта обработки задач для их последующего движения и выскажу своё субъективное мнение, какой вариант лучше.

Первый вариант: оценка задачи архитектором или архитекторами и дальнейшее выделение ресурсов команды лидерами направлений. Этот процесс иногда называют дискавери. В небольших командах архитектор может быть один, в крупных — несколько. Это, как правило, enterprise-архитектор, отвечающий за архитектуру в компании, и solution-архитектор, отвечающий за конкретный продукт или платформу. Архитекторы рассматривают задачу со всех сторон: подходит ли целевое решение, попадает ли задача под импортозамещение, как она вписывается в действующую архитектуру. Как итог, задача может быть отклонена, передана другой команде или продвинута далее с предварительной архитектурой. Далее руководители направлений проводят оценку (эстимацию), выделяя (предварительно) исполнителей и необходимое количество ресурсов. Это может быть в дальнейшем скорректировано.

Второй вариант — это командный разбор и оценка задач, или PBR (Product Backlog Refinement). Команда совместно оценивает задачу и выносит решение по ней, в том числе определяет необходимые для её реализации ресурсы. Зачастую этот процесс несколько корректируется, и задачи проходят предварительную аналитику, чтобы команды не рассматривали откровенно сырые идеи, далёкие от жизни. Задача, прошедшая PBR, считается провалидированной и может быть взята в работу.

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

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

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

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