Привет Хабр! Меня зовут Татьяна Ошуркова, я разработчик, аналитик и автор телеграм-канала IT Talks. В продолжение к одной из моих предыдущих статье по user stories, где я подробно рассказала про различные техники работы с пользовательскими историями, в этой статье я разберу семь разных методик к проработке и уточнению пользовательских историй: INVEST, MoSCoW, DEEP, 3Cs, SMART, Kano Model и RICE.

Возьмем краткую, непроработанную пользовательскую историю: «Как пользователь мобильного приложения банка, я хочу иметь возможность изменить PIN-код карты».

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

INVEST

Методика INVEST помогает создавать качественные и легко оцениваемые пользовательские истории. Эта техника была предложена в 2003 году и состоит из шести принципов. Пользовательская история должна быть: Independent (Независимая), Negotiable (Обсуждаемая), Valuable (Ценная), Estimable (Оцениваемая), Small (Компактная) и Testable (Тестируемая).

Independent (Независимая). Уточним, что эта история независима от других функций и действий, например, от блокировки карты.

Negotiable (Обсуждаемая). Оставим место для обсуждения требований безопасности и возможных подтверждений личности.

Valuable (Ценная). Добавим ценность, объяснив, зачем пользователю нужна смена PIN-кода – например, для повышения безопасности.

Estimable (Оцениваемая). Упростим историю для оценки, уточнив шаги для изменения PIN-кода.

Small (Компактная). Сократим задачу до одного изменения PIN-кода, избежав дополнительных функций.

Testable (Тестируемая). Установим критерии тестирования – например, успешное изменение PIN-кода при корректном подтверждении действия при помощи смс.

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

Преимущества:

• Подходит для формирования небольших, независимых пользовательских историй, которые легко реализовать в одном спринте.

• Помогает оценить задачи, проверить их ценность и формализовать критерии приемки.

Недостатки:

• Не подходит для сложных и взаимосвязанных требований, где зависимости между задачами невозможно устранить.

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

MoSCoW

MoSCoW — это методика приоритизации, которая помогает команде понять, какие требования должны быть реализованы в первую очередь. Методика была предложена в 1980-х годах в рамках DSDM (Dynamic Systems Development Method), широко используемого подхода в Agile-разработке. Название «MoSCoW» происходит от первых букв слов: Must have (Обязательно), Should have (Желательно), Could have (Может быть), Won't have (Не будет).

Must have (Обязательно). Возможность смены PIN-кода с подтверждением по смс.

Should have (Желательно). Уведомление об успешной смене PIN-кода.

Could have (Может быть). Временная блокировка функции смены PIN-кода при множественных ошибках.

Won't have (Не будет). Восстановление старого PIN-кода после изменения.

В результате мы также уточним формулировку пользовательской истории: «Как пользователь мобильного приложения банка, я хочу изменить PIN-код своей карты с подтверждением по смс». Также данная методика помогла выявить, какой функционал должен быть реализован и приоритизировать его. Кроме этого, мы уточнили возможные перспективы и ограничения реализации.

Преимущества:

• Удобна для приоритизации функций на этапе разработки MVP (Minimum Viable Product).

• Проста в использовании для коммуникации с заказчиком.

Недостатки:

• Трудно применять для долгосрочного планирования, так как приоритеты могут меняться.

• Неэффективен в условиях, где все функции оцениваются как «Must».

DEEP

DEEP – это методика, используемая для оценки качества бэклога в Agile. Эта техника позволяет проверить, что история достаточно детализирована и при этом может развиваться по мере изменений в проекте. Методика позволяет создать истории, которые можно легко оценить и доработать.

Detailed appropriately (Детализирована). Добавим шаги и требования к подтверждению смены PIN.

Estimated (Оценена). Задача оценивается командой в два спринта общей длительностью в 4 недели.

Emergent (Гибкая). Оставим возможность добавить улучшенную верификацию.

Prioritized (Приоритетная). Высокий приоритет из-за влияния на безопасность.

В результате мы проработаем требования к этапу подтверждения, выполнили оценку задачи, определились с приоритетом и наметили возможность необходимых доработка на будущее.

Преимущества:

• Позволяет сохранять гибкость и актуальность требований на разных этапах проекта.

• Подходит для проектов с динамично меняющимися требованиями.

Недостатки:

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

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

3Cs

3Cs – это методика, которая помогает проработать пользовательскую историю, разделяя ее на три составляющие: Card (Карточка), Conversation (Обсуждение) и Confirmation (Подтверждение). Она была предложена в рамках подхода Scrum и предназначена для того, чтобы сделать пользовательские истории более понятными и обоснованными.

Card (Карточка). Краткое описание – «Изменение PIN-кода карты с подтверждением по смс».

Conversation (Обсуждение). Подтвердим, что смена требует дополнительного подтверждения.

Confirmation (Подтверждение). Критерии приемки включают успешное изменение PIN-кода после ввода корректного кода из смс.

В результате мы проработаем с командой необходимые аспекты пользовательской истории и финализируем критерии приемки.

Преимущества:

• Хорошо подходит для выяснения требований на ранних стадиях проекта.

• Сохраняет баланс между формализацией и гибкостью.

Недостатки:

• Не подходит для процессов с минимальным взаимодействием между участниками.

SMART

SMART — это методика постановки целей, впервые была представлена в 1981 году. Раньше я знала данную методику только для её первоначальных целей и была удивлена, что её можно применить в работе с требованиями. Каждый элемент аббревиатуры обозначает критерии, которым должна соответствовать цель, в нашем случае пользовательская история: Specific (Конкретная), Measurable (Измеримая), Achievable (Достижимая), Relevant (Актуальная) и Time-bound (С ограничением по времени).

Specific (Конкретная). Убедимся, что наша пользовательская история касается определенного функционала и четко описывает только его.

Measurable (Измеримая). Опишем используемую метрику для оценки качества функционала пользователями, например CSI.

Achievable (Достижимая). Убедимся, что функция может быть реализована, сформулировав критерии приемки.

Relevant (Актуальная). Подтверждаем значимость для безопасности.

Time-bound (С ограничением по времени). Планируем выполнение в текущем релизе.

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

Преимущества:

• Отлично работает для формулирования целей на уровне проекта или задачи.

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

Недостатки:

• Может усложнить процесс формулирования мелких или интуитивно понятных задач.

• Сложно применять для абстрактных концепций или исследований.

Kano Model

Модель Кано была разработана в 1980-х годах для анализа удовлетворенности пользователей. Модель делит требования на пять категорий, которые помогают понять, какие аспекты продукта наиболее значимы для пользователей и каким образом они влияют на их удовлетворенность.

Must-Be Quality (Базовые потребности). Это обязательные характеристики продукта или функции, которые пользователи считают само собой разумеющимися. Их наличие не вызывает восторга, но отсутствие вызывает значительное неудовлетворение.

Для нашей пользовательской истории это возможность сменить PIN-код с подтверждением по смс.

One-Dimensional Quality (Ожидаемые потребности). Это характеристики, которые линейно влияют на удовлетворенность пользователя. Чем лучше они реализованы, тем выше удовлетворенность.

В нашем случае это будет уведомление об успешной смене PIN-кода.

Attractive Quality (Привлекательные потребности). Это функции, которые пользователи не ожидают, но которые вызывают положительные эмоции при их наличии. Отсутствие таких характеристик не вызывает неудовлетворенности.

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

Indifferent Quality (Безразличные потребности). Это характеристики, которые не оказывают влияния на удовлетворенность пользователя, независимо от того, реализованы они или нет.

Это может цвет кнопки «Подтвердить» на экране смены PIN-кода, что не окажется влияния на удовлетворённость пользователя от самого функционала.

Reverse Quality (Обратные потребности). Это характеристики, которые могут вызвать удовлетворенность у одной группы пользователей, но неудовлетворенность у другой.

Временная блокировка функции смены PIN-кода после нескольких неверных попыток ввода текущего пароля может восприниматься одними как дополнительная защита, а другими — как неудобство.

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

Преимущества:

• Полезна при разработке новых продуктов, где важно понять, что удовлетворит пользователей.

• Помогает выявить зоны для инноваций.

Недостатки:

• Не подходит для проектов с ограниченными ресурсами, так как требует значительных усилий для исследования.

• Трудно применить для технических задач, где пользовательские эмоции не имеют значения.

RICE

Метод RICE (Reach, Impact, Confidence, Effort) был разработан как инструмент приоритизации, который помогает командам принять решения о том, какие задачи стоит реализовать в первую очередь, особенно когда ресурсы ограничены. RICE оценивает задачи по четырем численным критериям.

Reach (Охват). Сколько пользователей или сценариев затрагивает данная функция в заданный период. Чем выше охват, тем более значимой считается функция.

Функцию смены PIN-кода может использовать около 40 процентов пользователей приложения в течение года.

Impact (Влияние). Как сильно данная функция повлияет на каждого отдельного пользователя или на достижение целей компании (3 = массивное воздействие, 2 = сильное воздействие, 1 = среднее воздействие, 0,5 = слабое воздействие, 0,25 = минимальное воздействие).

Влияние функции на пользователей оценивается как «высокое», что принимаем за коэффициент 3.

Confidence (Уверенность). Степень уверенности в точности оценок Reach и Impact. Этот показатель помогает снизить риск недооценки или переоценки эффекта функции (100% = высокая достоверность, 80% = средняя достоверность, 50% = низкая достоверность).

В нашем случае уверенность высокая, так как есть подтвержденные данные и составляет 100 процентов.

Effort (Трудозатраты). Затраты на реализацию функции, измеряемые обычно в человеко-часах или story points. Чем ниже трудозатраты при высоких значениях Reach и Impact, тем приоритетнее задача.

Можно сказать, что в нашем случае реализация потребует примерно 40 человеко-часов на разработку и тестирование.

Далее по формуле вычисляем RICE Score:

Чтобы приоритизировать пользовательскую историю для нашей задачи в проекте необходимо для остальных задач также вычислить RICE Score. Исходя из имеющихся значений мы сможем понять, реализация какого функционала сейчас в приоритете.

Преимущества:

• Удобна для приоритизации задач в больших проектах с ограниченными ресурсами.

• Помогает сбалансировать охват, влияние и трудозатраты.

Недостатки:

• Неэффективен для мелких задач, где точная оценка может занять больше времени, чем сама реализация.

• Субъективность оценок (особенно Reach и Impact) может снизить точность приоритизации.

• Не подходит для сложных системных изменений, которые сложно измерить.

Подведем итоги

Мы рассмотрели различные методики работы с пользовательскими историями. Некоторые из них были созданы для других целей, но их также можно удачно применять в контексте user stories. Сложно сразу точно сказать, какая из методик подойдет к определенной задачи. Кроме особенностей требований, нужно также учитывать детали проекта, потребности проработки и цели детализации. Но в любом случае каждая из методик сможет помочь вам с определённой стороны и решить ряд возникающих вопросов.

Удачи в работе!