Стори:
- не являются детальным описанием требований, а представляют собой намерения (нужно сделать что-то вроде этого)
- не содержат деталей поведения системы (критерии приемки).
Они прорабатываются позже, посредством диалога между командой разработки и владельцем продукта - должны быть короткими и понятными разработчикам и заказчику
- представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках одного, двух спринтов, а значит поддаются оценке трудозатрат
У декомпозиции много преимуществ, начиная с более точных оценок трудозатрат и заканчивая эффективностью реализации.
Под эффективностью понимается полное соответствие реализованной стори критериям приемки и критериям готовности. То есть, сделано качественно (у каждой команды/заказчика, конечно же, свои маркеры) и работает так, что продукт получил к своей карме +ценность.
А значит качество декомпозиции напрямую влияет на качество продукта и приближает нас к тому, что нужно заказчикам
и пользователям.
Часто в процессе декомпозиции получаются стори больше похожие
на технические задачи или архитектурные компоненты. Бывает, что требуется дополнительная декомпозиция. А иногда, с декомпозицией совсем беда и просто непонятно с чего начать.
Билл Вейк (один из авторов XP), ввел в работу аббревиатуру INVEST, чтобы описать атрибуты хорошо декомпозированной пользовательской истории.
Содержание статьи
Независимость
В идеале, каждая стори может быть реализована, оттестирована
и задеплоена, а значит может существовать без зависимостей
с другими стори.
Пример:
Как администратор, я могу управлять правилами безопасности вывода средств из системы пользователями.
Как пользователь, я не могу создать заявку на вывод средств
из системы, если она нарушает правила безопасности вывода средств из системы.
Обе стори связаны. Не очень понятно, как их тестировать и поставлять в продукт по отдельности.
Как администратор, я могу установить максимальную сумму вывода средств из системы пользователями.
Как администратор, я могу включить обязательную двухфакторную авторизацию при выводе средств из системы пользователями.
Убрали зависимость и переформировали стори иначе.
Обсуждаемость
Этот атрибут добавляет гибкости команде разработки. Мы принимаем, что у нас нет четко зафиксированных требований, так как допускается возможность непредвиденных изменений. Мы верим в способность команды и бизнеса найти компромисс между функциональностью
и датой релиза. Это увеличивает надежность продукта и усиливает доверие между сторонами.
Ценность
Думаю, это самый важный атрибут. Отвечает за наличие в стори любого объема ценности за отведенное нам на работу время. Именно на основе этого атрибута приоритизируются все доступные пользовательские истории. Чем ценность для бизнеса выше, тем раньше стори уйдет в разработку.
Оценка трудозатрат
От этого атрибута зависит предсказуемость команды разработки. Если мы не можем приблизительно оценить стори, значит она недостаточно декомпозирована. Часто, в процессе обсуждения трудозатрат удается найти какие-то скрытые в стори моменты, что еще раз подтверждает важность этого атрибута и самого процесса предварительной оценки.
Компактность
Один из ключевых принципов бережливого производства — чтобы увеличить пропускную способность и поставлять больше ценности, требуется разделить объем задач на продолжительность. Чем меньше объем каждой пользовательской истории, тем выше будет пропускная способность и скорость поставки ценности.
Априори, значительно легче маневрировать компактными объектами при движении в нагруженной системе, а команда разработки обычно похожа на нагруженную систему 🙂 Поэтому компактность стори влияет на предсказуемость команды разработки, а значит и на доверие к команде.
Тестируемость
Если команда знает как оттестировать стори, значит понимает, как
ее реализовать. Используйте согласованные с заказчиком критерия приемки и пишите тесты.
Чтобы команде и заказчику было проще синхронизировать ожидания по результатам избегайте размытых формулировок “быстро, красиво, удобно, интуитивно понятно и т. д.” Подобные вещи не поддаются тестированию, поскольку являются субъективными.
Представьте, вы готовите блюдо, которое не сможете попробовать прежде, чем все ингредиенты дойдут до нужной кондиции и вы
приготовите их в правильной последовательности.
А теперь, что готовите пиццу. Нарезали ингредиенты, пока доходило тесто, добавили соусы и отправили все вместе выпекаться. Спустя некоторое время вы уже пробуете, что у вас получилось.
Если по истечению 5 спринтов работы, мы поставим пользователям только слой с тестом, он не доставит им почти никакой ценности, просто по причине отсутствия возможности использовать его (без UI).
При создании бэклога мысленно «разрезайте» пользовательские истории насквозь (вертикальные слои), так чтобы предоставить ценность пользователю и получить его фидбэк настолько рано, насколько это возможно.
Использование горизонтальных слоев замедляет поставку ценности
до тех пор, пока все слои не будут соединены воедино в результате серии итераций: UX слой, UI слой, backend с архитектурой БД и т.д. Такой подход не проходит проверку атрибутами на независимость
и ценность.
Мы уже знаем, что работа над формированием пользовательских историй — командная, а сами стори исходят из целей и задач бизнеса.
Уметь переваривать потенциальные бизнес-цели, требования заказчика и правильно трассировать их в пользовательские истории — одна из ключевых задач команды разработки.
Так выглядит трассировка у нас в студии:
Цели → Эпики → Пользовательские истории → Задачи на разработку → Подзадачи
Сама формулировка:
Как <действующее лицо>, в случае <ситуация/обстоятельство>, я хочу <действие>, чтобы <ожидаемый результат>
- <действующее лицо> — роль пользователя в системе или его статус
- <ситуация/обстоятельство> — например, оплата заказа или регистрация нового пользователя
- <действие> — например, принять заказ. Тут скрывается коварнейшая ошибка. Важно записывать не конкретное действие в системе («Нажать кнопку принять»), а запрос на удовлетворение потребности (“Подтвердить оплаченный заказ”). Не загоняйте сами себя в рамки готового решения, вместо поиска наилучшего варианта под существующие требования.
- <ожидаемый результат> — например, отправить заказ на комплектацию. Не пропускайте эту часть, она поддерживает объективность мнений среди всех участников и здорово отсеивает pet features.
В завершении указываем:
- критерии приемки. Не путайте их с критериями работы. Первые формируют ожидания заказчика от деталей процесса работы и отвечают на вопрос “как”, тогда как вторые отвечают на “что”.
- возможные сценарии. Флоу работы пользовательской истории, когда у истории несколько сценариев. И все должны удовлетворять критериям приемки. Благодаря сценариям проще писать автотесты по пользовательским историям и демонстрировать результат заказчику.
- список всех задач, которые составляют реализацию указанной стори. У нас декомпозицию на задачи производит каждый разработчик самостоятельно, согласуя результат с лидом направления.
- Формулируя стори, описывайте намерения, что система должна делать для пользователя.
- Концентрируйтесь на ценности для пользователей от вашей стори, нежели на структурном или функциональном разбиении на задачи и технические компоненты.
- Проверяйте получившиеся стори на соответствие INVEST.
- Отдельно прорабатывайте с владельцем продукта критерии приемки каждой стори.
- Продумывая реализацию и создавая задачи, мысленно «разрезайте» пользовательские истории насквозь, чтобы пользователи почувствовали ценность ваших результатов настолько рано, насколько это возможно.
- Проверяйте формулировки стори, особое внимание <действию>
и наличию потребности.
Загрузка...
