kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 9/18: Agile-практики → Тема 2/7: Истории → Урок 2/6
INVEST-критерии
В прошлом уроке вы узнали о том, что такое пользовательская история (User Story) и из чего она состоит. В этом уроке вы познакомитесь с критериями качества (INVEST-критерии), которым должны соответствовать пользовательские истории.
Критерии пользовательской истории
Пользовательская история должна быть:
- Независимой (Independent).
- Обсуждаемой (Negotiable).
- Ценной (Valuable).
- Оцениваемой (Estimable).
- Масштабируемой (Sized Appropriately).
- Тестируемой (Testable).
Названия этих критериев складываются в акроним INVEST, поэтому их и называют INVEST-критериями.
Шаблон и INVEST-критерии помогают команде разработки достичь единого понимания пользовательской истории и реализовывать её более эффективно.
Независимая
В бэклоге одна история должна не зависеть от других. Это значит, что её реализация не затронет реализацию других историй.
Есть три вида зависимости историй:
- Пересечение (Overlap Dependency) — негативный вид зависимости, при котором разные истории включают в себя одни и те же пользовательские требования.
- Порядок (Order Dependency) — допустимый вид зависимости, при котором истории должны реализоваться в определённом порядке. То есть нельзя, например, приступить к реализации истории «Оплатить счёт» до тех пор, пока не реализована история «Получить счёт».
- Включение (Containment Dependency) — может быть полезным видом зависимости, при котором одна история включает в себя несколько других.
Например, история «Как пользователь, я хочу редактировать свои данные в личном кабинете, чтобы иметь возможность их исправить» может состоять из более мелких историй: «Как пользователь, я хочу редактировать номер телефона в личном кабинете, чтобы изменить его в случае смены номера», «Как пользователь, я хочу редактировать адрес электронной почты, чтобы изменить его в случае смены почтового сервиса» и так далее.
Когда системный аналитик пишет карточку истории (да, мы говорим именно так), в первую очередь нужно следить за тем, чтобы у неё не было пересечений с другими историями. Представьте, что занимаетесь разработкой приложения для обмена файлами. Есть две пользовательские истории:
- Как пользователь, я хочу сохранять файлы на Google Диск, чтобы они были доступны с любого устройства.
- Как пользователь, я хочу сохранять файлы на Яндекс Диск, чтобы они были доступны с любого устройства.
Команда разработки пришла к выводу, что для создания функции сохранения файла на диск, который выберут первым, потребуется пять дней, а для добавления поддержки второго типа хранилища потребуется ещё два дня. В описанных историях сложно определить, с какой истории начать и разработку какой именно нужно оценить в пять дней, какой — в два.
Таким образом, эти истории зависят друг от друга, так как пересекается их функциональность (сохранение файла в облачное хранилище).
Чтобы убрать пересечения, можно объединить две истории в одну: «Как пользователь, я хочу сохранять файлы в облачном хранилище, чтобы они были доступны с любого устройства».
Если при объединении история включает в себя слишком много функций, команда не успеет реализовать её в течение одного спринта. Тогда историю можно декомпозировать, то есть разбить на меньшие истории.
Обсуждаемая
Основное преимущество истории в том, что СА обсуждает её с пользователями и командой разработки. Поэтому историю нужно записывать так, чтобы команде было что обсуждать.
- История не должна содержать точные указания на то, как её нужно реализовывать.
- История должна включать только информацию о том, что должно получиться в итоге и с какой целью реализуется история.
В процессе обсуждения истории команда принимает решение о способе её реализации.
Если какие-то важные детали реализации хочется сохранить, в истории их можно описать в графе «Примечания». Примечания должны быть краткими и не содержать перечень условий. Их задача — помогать команде в дальнейшем обсуждении истории.
Примечания в карточке первой истории не дают забыть о том, что нужно обсудить детали и выяснить, какую информацию необходимо отображать в справке. Примечания ко второй истории содержат так много деталей, что кажется, будто обсуждать тут нечего и можно сразу приступить к реализации истории. В таком случае команда разработки реализует историю только с тем набором данных, который был описан в примечании (Ф. И. О., баланс в рублях, текущая дата). Но, возможно, пользователю важно, чтобы в справке ещё отражался адрес или была возможность выбирать валюту.
Ценная
Карточку истории можно назвать ценной, если она приносит пользу заинтересованным лицам. Поэтому, создавая историю, нужно думать о её ценности для пользователей и заказчиков.
Обычно ценность может заключаться в уменьшении затрат бизнеса, увеличении его доходов или улучшении сервиса для пользователя. Но даже если реализация истории приводит только к тому, что команда приобретает новые знания, это тоже ценные изменения, которые в итоге приведут к улучшениям в бизнесе. Определить ценность истории поможет вопрос: «Можно ли вообще не реализовывать эту историю?»
Рассмотрим историю: «Как пользователь, я хочу получить справку о балансе счёта, чтобы отнести её в посольство». Предположим, что в справке должны отображаться такие поля:
- Ф. И. О. клиента.
- Баланс.
- Дата формирования справки.
Справка также должна содержать логотип банка и информацию о том, кто её выдал, а её оформление должно соответствовать фирменным цветам.
В ходе обсуждения команда разработки выяснила: для того чтобы добавить каждое поле, потребуется отдельная интеграция с внешними системами, в которых хранятся данные. Поэтому выполнить всю историю за один спринт не получится. Тогда в бэклог добавляют более мелкие истории:
- «Как пользователь, я хочу видеть в справке свои Ф. И. О., чтобы подтвердить, что этот документ принадлежит мне».
- «Как пользователь, я хочу видеть в справке баланс счёта, чтобы подтвердить, что я платёжеспособен».
- «Как пользователь, я хочу видеть в справке дату её создания, чтобы подтвердить, что информация актуальна».
Каждая из этих историй не приведёт команду к реализации всей справки, поэтому кажется, что в них нет ценности. Но если постепенно реализовать эти истории, в справке будет появляться необходимая информация, что приблизит команду к финальной цели. Создавать такую функциональность маленькими шагами может быть даже более ценно, так как после выполнения каждой истории можно получить обратную связь от заказчика или пользователей и оперативно внести изменения. Плюс ко всему команда будет приобретать новые знания об интеграциях с системами, которые помогут в дальнейшем выполнять такие задачи быстрее.
Оцениваемая
История должна быть достаточно понятной, чтобы команда разработки оценила, сколько усилий потребуется для её реализации.
Команде будет сложно оценить размер истории, если:
- Недостаточно знаний о предметной области.
В этом случае историю нужно подробнее обсудить с пользователями или другими заинтересованными лицами, которые обладают знаниями о предметной области. Это позволит получить больше информации о предметной области и иметь представление о том, что требуется разработать и для чего.
- Недостаточно знаний о технологии или мало опыта работы с ней.
Историю сложно оценить, если у команды разработки нет знаний о технологии, которая нужна для реализации истории, или нет опыта работы с ней.
- История слишком большая.
Если история слишком большая и неопределённая, команда может использовать технику декомпозиции и оценить отдельно каждую новую историю.
Команда разработки может приобрести необходимые знания и опыт, исследовав технологию для реализации истории в спайке. В результате исследования команда получит знания, которые помогут ей оценить первоначальную историю.
Масштабируемая
Истории должны иметь масштаб (или размер), подходящий для использования на разных этапах разработки и для разных целей. Истории бывают высокого, среднего и низкого уровня.
Высокий уровень
Истории высокого уровня реализуются для достижения бизнес-целей. Такие истории формулируются обобщённо, без углубления в детали, а их реализация может длиться годами. Истории высокого уровня могут формулироваться так:
- Как директор по развитию, я хочу увеличивать вовлечённость пользователей социальной сети, чтобы они проводили в ней больше времени.
- Как директор по развитию, я хочу улучшать пользовательский опыт, чтобы увеличить количество пользователей социальной сети.
Средний уровень
Истории высокого уровня делятся на истории среднего уровня. Они направлены на достижение целей заинтересованных лиц. Реализация таких историй занимает несколько месяцев или год. Истории среднего уровня могут формулироваться так:
- Как пользователь, я хочу делиться новостями с друзьями, чтобы они были в курсе произошедших в моей жизни событий.
- Как пользователь, я хочу общаться с друзьями через социальную сеть, чтобы поддерживать с ними контакт.
Низкий уровень
Истории низкого уровня максимально детализированы. Они подходят для реализации командой разработки в рамках одной или нескольких итераций. Истории низкого уровня могут формулироваться так:
- Как пользователь, я хочу указать свои имя и фамилию, чтобы другие пользователи могли меня узнать.
- Как пользователь, я хочу писать в приватный чат, чтобы поговорить с другом тет-а-тет.
- Как пользователь, я хочу редактировать информацию о себе, чтобы иметь возможность менять актуальный номер телефона.
На каждом уровне истории должны быть примерно одинакового размера. При написании истории системный аналитик должен подбирать масштаб исходя из целей истории (понимания, для чего она создаётся).
Тестируемая
Команда должна хорошо представлять, каковы критерии приёмки результата истории. Это позволит ей точно понимать, что реализация одной истории завершена и можно переходить к следующей по приоритету истории. Нетестируемые истории (те, что нельзя проверить) обычно появляются тогда, когда составляются для нефункциональных требований. Например, одно из требований — быстрая реакция системы в ответ на действие пользователя, чтобы ему было удобно работать с системой. В этом случае историю можно записать так:
- Как пользователь, я не хочу долго ждать появления страницы оплаты, чтобы быстро оплачивать покупки.
Эта история будет нетестируемой, ведь «долго» — понятие относительное. В этом случае при реализации истории можно стремиться к тому, чтобы ожидание появления страницы происходило очень редко, тогда история будет звучать так: «Как пользователь, я хочу, чтобы страница оплаты открывалась не дольше двух секунд». Такую историю мы сможем протестировать, а значит, она будет соответствовать последнему INVEST-критерию.
Подведём итоги
Чтобы владелец продукта мог легко управлять бэклогом, а команда разработки эффективно справляться с поставленными задачами, истории должны соответствовать INVEST-критериям, то есть быть:
- Независимыми. Это значит, что реализовать истории можно в любой очерёдности, независимо друг от друга.
- Обсуждаемыми. Истории должны говорить команде разработки о том, что надо разработать, а не как.
- Ценными. Истории должны приносить выгоду бизнесу и пользователям.
- Оцениваемыми. Команда должна ясно представлять себе, как оценивать сроки реализации историй.
- Масштабируемыми. Истории должны иметь подходящий размер для реализации в разное время для разных целей.
- Тестируемыми. Команда должна иметь возможность удостовериться в том, что разработка истории завершена.
Запомнить INVEST-критерии и их назначение вам поможет памятка. Используйте её, чтобы проверить свои истории на соответствие критериям.
Чат поддержки