Декомпозиция и оценка задач

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

Кейс: «личный кабинет» одной строкой

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

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

Что такое декомпозиция

Декомпозиция - это разбиение крупной задачи на более мелкие части. Её описывают как разбиение крупного элемента бэклога на небольшие части, которые можно выполнить за один спринт. Цели такие: ясность, более удачное планирование, быстрая обратная связь и предсказуемость.

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

Три способа резать задачу

Различают два приёма. Разделение (splitting) делит крупный элемент на части, каждая из которых осмысленна сама по себе. Срез (slicing) даёт тонкий кусок ценности от начала до конца, пусть и не полную функцию. Хороший срез можно использовать и проверить, и он приносит пользу, даже если это не вся функция.

На практике задачу режут тремя способами.

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

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

Как разрезали личный кабинет

В нашем кейсе кабинет делится на четыре сценарных среза: вход и список заказов, карточка заказа, отмена заказа и адреса доставки. Каждый срез отвечает на вопрос «что покупатель сможет сделать». Для каждого уже можно написать требования и тест (связь между ними описана в статье 02-22).

Срез «Отмена заказа» опирается на правило отмены до передачи курьеру, которое мы разбирали в предыдущих статьях раздела. Остальные срезы от него не зависят, и их можно выпускать в любом порядке. Так видно, где есть зависимости: их записывают рядом с задачей, чтобы порядок работ не оказался сюрпризом.

Какой размер подходит

Подходящая задача проходит три проверки.

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

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

Из чего складывается оценка

Оценка работы включает не только время на код. В неё входят несколько частей:

• объём самой работы: экраны, правила, интеграции;
• неопределённость: сколько вопросов ещё без ответа;
• зависимости: от других задач, команд и внешних систем;
• проверка и согласование: тесты, показ владельцу, правки.

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

Вилка оценки - это диапазон, в котором мы ожидаем результат: от минимума до максимума. Если задача только на стадии идеи, вилка широкая. Когда требования описаны, она уже. Когда задача готова к работе, вилка узкая, но не нулевая. Но и узкая вилка остаётся оценкой: точнее по ней предсказать нельзя, можно только оказаться удачливее.

Наш вклад в оценку

Оценивают те, кто будет делать работу. Мы участвуем иначе: приносим срез с понятным результатом, перечисляем допущения и открытые вопросы и записываем их рядом с вилкой. Допущение звучит так: «считаем, что список заказов уже есть в API». Если допущение не подтвердится, вилка сдвигается, и это видно заранее, а не в конце итерации.

Если требования меняются, оценку пересматривают. Это нормально: вилка поменялась потому, что изменилась задача (процесс описан в статье 02-20).

Где это встречается в работе

• Планирование итерации: из бэклога берут срезы, которые помещаются в срок.
• Оценка на встрече с командой: вилка и список допущений.
• Подготовка задачи к передаче в разработку (статья 02-26).
• Разговор с владельцем продукта о том, что войдёт в релиз (статья 02-21).
• Разбор задержки: видно, какое допущение не оправдалось.

Итог

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

Что дальше

Дальше разберём виды тестирования и то, кто их проводит (статья 02-24), а затем соберём всё в чек-лист постановки задачи разработке (статья 02-26).