От идеи до релиза: жизненный цикл разработки и путь задачи

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

Кейс: «Где мой заказ?»

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

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

Что происходит на каждом этапе

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

Этап	Что происходит	Результат (артефакт)	Какие вопросы закрывают
Идея	Кто-то замечает проблему или возможность	Короткая формулировка: «покупатель видит статус заказа»	Зачем это нужно и стоит ли заниматься этим сейчас
Уточнение	Детали разбирают вместе с владельцем, поддержкой и разработчиками	Список ответов и открытых вопросов	Какие статусы бывают, кто их меняет, что делать, если SMS не доставлено
Постановка (запись требований: что именно должна делать система)	Ответы превращаются в текст	Требование с правилами проверки	Что система делает в обычном и необычном случае и как проверить, что готово
Разработка	Программисты пишут код	Работающая функция на тестовой копии сайта	Хватает ли данных для решения, что в требовании неоднозначно
Тестирование	Результат сравнивают с требованием и ищут отличия	Список найденных ошибок или подтверждение, что всё совпадает	Совпадает ли результат с записью и что в записи не предусмотрено
Приёмка (проверка работы владельцем продукта)	Владелец смотрит результат и решает, принимать ли	Решение: принято или нет	Это ли то, что просили
Релиз (выпуск изменений покупателям)	Готовая функция попадает на рабочий сайт	Обновлённый рабочий сайт	Когда выпускать и как вернуть прежнее, если что-то пойдёт не так
Поддержка	Покупатели пользуются функцией и пишут о проблемах	Обращения и исправления	Что нового выяснилось в работе и не пора ли новая идея

Как подготовить постановку, чтобы её можно было взять в работу, разбирает статья 02-26, а как проводится приёмка, статья 02-25. Здесь важно другое: у каждого этапа есть вход (что ему передали) и выход (что он передаёт дальше), и по ним видно, где в цепочке пробел.

Что происходит, когда вопрос остался без ответа

Предположим, на этапе уточнения никто не спросил: «что делать, если SMS не доставлено?». Вопрос не исчезает: он ждёт своего часа и всё равно возникнет, просто в более позднем месте. Чем позже обнаружен пробел, тем больше людей и готовой работы он затрагивает: на уточнении вопрос задаётся разговором, на тестировании возвращается в постановку и в код, в поддержке исправляется отдельным релизом.

Ошибка здесь не в разработчике и не в тестировщике: вопрос не был задан на входе. Поэтому в таблице выше вопросы уточнения и постановки стоят раньше разработки.

Как этапы повторяются и где задачи ждут очереди

В таблице этапы идут по порядку, но на практике так бывает не всегда. В подходах, где работают короткими циклами, этапы повторяются: задачу делят на небольшие части, и каждая проходит путь от уточнения до проверки отдельно. Статус заказа «Узелок» может выпустить в два захода: сначала статус в личном кабинете, потом SMS. Подходы к организации работы разбирает статья 01-07.

Задачи ждут своей очереди в бэклоге: списке работ, упорядоченном по важности. Задачу про статус заказа владелец ставит выше, если поддержка тонет в звонках, и ниже, если горит оплата. Готовые изменения выпускают релизом, а каждый релиз фиксирует версию: состояние продукта с номером и списком изменений, например «Узелок 1.4». Статус в кабинете попадёт в одну версию, SMS в следующую.

Кто участвует на каждом этапе

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

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

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

Итог

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

Что дальше

• 01-07. Методологии разработки: обзор
• 01-09. Окружения, стенды и доставка кода
• 02-26. Постановка задачи разработке: Definition of Ready
• 02-25. От требований к тестированию: тест-кейсы и приёмка
• 02-24. Виды тестирования: что проверяют и кто

Источники

• Product Backlog, Atlassian. Определение бэклога как упорядоченного списка работ.
• The Scrum Guide. Циклы работы короткими частями и приоритет задач в бэклоге.