Пользовательские истории и уточнение Бэклога Продукта
Узнайте, почему пользовательские истории представляют собой диалог, а не контракт, и как эффективное уточнение Бэклога помогает Scrum-командам поставлять ценный Инкремент каждый Спринт.
Многие команды воспринимают пользовательские истории как облегченные документы с требованиями. Они заносят их в трекер задач, прикрепляют списки пунктов и считают дело сделанным. Но пользовательская история никогда не задумывалась как спецификация. Она должна была стать приглашением к диалогу. Именно на уточнении Бэклога Продукта этот диалог и происходит. Когда команды осознают эту разницу, их встречи становятся короче, код проще, а работа движется гораздо быстрее.
Scrum Guide не требует историй
Сам по себе Scrum не навязывает пользовательские истории. Scrum Guide говорит только об элементах Бэклога Продукта. Элемент Бэклога, это просто единица работы, способная принести ценность. Это может быть исправление бага, архитектурный эксперимент, техническая задача или описание функции простым текстом. Команды приняли формат пользовательских историй, потому что он заставлял указывать конкретного пользователя и желаемый результат.
Со временем во многих организациях этот шаблон превратился в догму. Формулировка «Как пользователь, я хочу X, чтобы Y» стала бюрократической формальностью. Если составление этой фразы не помогает понять, кому именно полезна доработка, перестаньте ее писать. Ценность заключается не в синтаксисе. Ценность в том, чтобы каждый участник разработки функции понимал, ради чего она создается.
Уточнение Бэклога, это деятельность, а не встреча
Scrum Guide 2020 года описывает уточнение Бэклога Продукта как непрерывный процесс детализации, оценки и упорядочивания элементов. Это не событие со строгими временными рамками. Вам не обязательно проводить одну двухчасовую встречу каждый второй четверг, чтобы разбирать тикеты. Сильные команды занимаются уточнением постоянно.
Product Owner может позвать двух разработчиков на пятнадцать минут во вторник утром, чтобы набросать схему процесса на доске. Разработчик может обсудить план миграции базы данных с Product Owner после обеда. Когда уточнение идет непрерывно, Бэклог остается актуальным без изнуряющих многочасовых сессий.
Три составляющие каждой истории
Десятилетия назад Рон Джеффрис описал пользовательские истории тремя простыми словами: карточка, разговор и подтверждение (Card, Conversation, Confirmation). Эта концепция остается лучшим ориентиром для уточнения Бэклога:
- Карточка (Card): короткое напоминание о том, что нужно обсудить, записанное на карточке или в системе трекинга.
- Разговор (Conversation): диалог между разработчиками и продуктовой стороной для изучения проблемы, компромиссов и крайних технических случаев.
- Подтверждение (Confirmation): конкретные примеры и критерии приемки, позволяющие понять, когда работа действительно выполнена и готова к релизу.
Большинство неудачных сессий уточнения страдают от пропуска диалога. Product Owner в одиночку пишет карточку и критерии подтверждения, а затем передает их разработчикам на Планировании Спринта. Это не гибкая разработка. Это миниатюрный waterfall, замаскированный под тикеты.
Дробление элементов под размер Спринта
Главная цель уточнения заключается в том, чтобы сделать элементы достаточно компактными для выполнения за один Спринт. Scrum Guide указывает, что за оценку размера отвечают Разработчики, которые будут выполнять работу. Если элемент кажется слишком крупным, рискованным или неоднозначным, не стоит просто давать ему больше баллов. Его нужно разбить.
Самый чистый способ разбить историю, сделать это по поведению пользователя или пути движения данных, а не по архитектурным слоям. Не разделяйте историю на задачи для фронтенда и бэкенда в разных Спринтах. Это оставляет вас с незавершенным, непроверенным программным обеспечением в конце Спринта. Вместо этого создайте тонкий вертикальный срез, реализующий один простой позитивный сценарий от базы данных до пользовательского интерфейса. Когда этот тонкий срез заработает в продакшене, уточните детали и добавьте следующий вариант.
Как понять, что элемент готов
Элемент Бэклога готов к Планированию Спринта, когда Разработчики понимают, какую проблему они решают, почему это важно и как проверить решение. Нет необходимости выяснять все детали заранее. Достаточно той ясности, которая позволит начать работу и не застрять на второй день.
Если команда требует полной архитектурной определенности перед тем, как взять элемент в Спринт, она избегает эмпирического подхода. Неопределенность нормальна для разработки программного обеспечения. Уточнение не уничтожает неопределенность, оно лишь уменьшает ее ровно настолько, чтобы команда могла узнать остальное в процессе создания.