Оценка разработки. Декомпозиция

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

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

Инкрементальный подход
Я убежден, что декомпозиция должна строиться вокруг функциональных и бизнесовых инкрементов и подразумевать, что для реализации каждого пункта будет задействована комплексная экспертиза (аналитики, frontend-разработчики, backend-разработчики, DevOps и др.). Такой подход делает разбиение полезным, понятным и обсуждаемым для широкого состава участников: и для представителей бизнеса (которые могут не понимать, что такое «фронтенд», «бэкенд» и прочие технические термины), и для технарей (которым важно понимать контекст задач и их бизнесовый смысл).

Критерии хорошей декомпозиции
В мире продуктовой разработки есть замечательная аббревиатура INVEST, — это набор критериев, которым должна соответствовать «хорошая» UserStory. Этим же критериям (с небольшими оговорками) должны соответствовать и задачи в нашей декомпозиции.

Адаптированная под оценку трактовка INVEST:
• Independent — независимость. Возможность реализовать функционал в отрыве от других фичей. На этапе активной разработки это выполнить сложно, практически невозможно, но надо стараться, и в одном из следующих постов поговорим подробнее о работе с пунктами, для которых этот критерий НЕ выполняется.
• Negotiable — обсуждаемость. Формулировка должна отражать суть, а не детали и оставлять возможность для дальнейшего обсуждения.
• Valuable — ценность для клиентов/бизнеса/стейкхолдеров.
• Estimable — оцениваемость. Понимание требований и уровень неопределенности должны позволять оценить данный функционал, и оценка должна удовлетворять критерию Small. Если критерий Estimable не выполняется, следует выходить на дополнительные обсуждения и уточнения по функционалу.
• Small — компактность. Мы для себя этот критерий уточняем следующим образом: оценка трудоемкости ни по одной из компетенций (front, back, QA…) данной фичи не должна превышать Х часов.
• Testable — проверяемость. Возможность сформулировать «критерии приемки» (Acceptance Criteria) для данного функционала через призму ценности для бизнеса и продукта, а не для команды разработки («реализована API-точка для хххх» — плохо, «пользователь системы имеет возможность скачать расходную накладную в формате PDF» — хорошо)

100%-е отражение требований
Критически важно на самых первых этапах отражать в декомпозиции 100% входящих требований. Ошибки типа «не учли это требование в оценке» — традиционно самые дорогие.
Есть очень-очень размытое и непонятное требование, с которым совсем непонятно что делать? Вынесите его в декомпозицию, пометьте как пункт на обсуждение — и работайте дальше.

Немного практики
Небольшая заметка о процессе в Spectr.
Изучать требования и делать декомпозицию — очень трудоемкий и скрупулезный процесс. Занимается этим, как правило, аналитик или даже архитектор. При наличии возможности это делает человек с опытом разработки похожих продуктов (он должен хорошо ориентироваться в предметной области или очень глубоко понимать нюансы технической реализации подобных продуктов).
В процессе первичной декомпозиции детально анализируются все требования и выделяются так называемые проблемные, из которых в том числе формируется повестка на дальнейшее обсуждение с заказчиком и с технической командой.