Сбор требований end-to-end по Аджайл

Небольшое введение.

Требования в Аджайл документируются в виде Юзер Стори (коротко Стори).
Стори — это описание функциональности, которая приносит пользу либо конечному пользователю, либо заказчику продукта.

Функции Стори:
— Письменное описание деталей Стори для целей планирования и как напоминание.
— Обсуждение Стори как способ выявить все детали Стори
— Тесты призванные задокументировать детали и определить готовность Стори

Стори должна соответствовать характеристикам INVEST:
— Independent. Не должна зависеть от других Стори.
— Negotiable. Стори не должна включать полностью детализированные требования. Стори должна служить напоминанием той части функционала, которую нужно обсудить.
— Valuable. Стори должна приносить пользу либо пользователю, либо тому, кто заказал продукт, но никак не разработчику, архитектору, тестеру и т.д. Стори не должна быть технической.
— Estimable. Стори должна быть понятна девелоперам чтобы они могли ее оценить. Стори может быть не понятна если:
— Девелоперы на обладают доменными знаниями
— Девелоперы не обладают техническими знаниями
— Стори очень большая
— Small. Стори не должна быть очень большой как Эпик и маленькой как Стори сложностью в 1 час разработки. Проблема маленьких Стори в том, что времени на их документирование уходит больше, чем на разработку — в таком случае Стори мержат. Большие Стори или Эпики могут быть 2х видов:
— Композитная. Разбивается на мелкие Стори.
— Сложная. Разбивается на 2 части — часть, которая понятна и ее можно оценить и часть, которая требует исследования — Спайк.
— Testable. Стори должны быть функциональными требованиями. Стори не должна быть нефункциональным требованием, потому как ее невозможно будет протестировать.

ШАГ 1. Моделируем роли или типы пользователей.

Большинство команд, как и наша, предполагают все лишь один тип пользователя. Это приводит к тому, что продукт игнорирует потребности других типов пользователей и мы теряем важные Стори. На ряду с написанием Стори необходимо также определять типы пользователей. Каждый тип пользователя должен иметь описание, примерный список пользователей:
— Соискатель работы. Очень хочет найти работу.
— Менеджер по персоналу. Хочет найти сотрудника.
— Директор. Хочет видеть, как работает его менеджер по персоналу.

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

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

Шаг 2. Сбор требований.

В отличие от вотерфола, где под СБОРОМ требований подразумевается, что все требования можно собрать предварительно, аджайл использует термин TRAWL (ловить рыбу неводом), намекая на то, что все требования собрать сразу не реально, а нужно охотится на них в течении разработки продукта.

Сбор требований в аджайле намного проще чем в вотерфоле. Всего 4 основных техники:
1. Интервью с пользователями
2. Опросники
3. Воркшопы
4. Изучение поведения пользователей — то, как работают юзеры

В идеале, Стори должны собираться напрямую у пользователей всех типов. Но часто заказчик выдвигает своего Прокси пользователя. Прокси — это всегда плохо.
Чтобы обойти прокси есть несколько методов:
1. Начать User Task Force. Эта техника подразумевает организацию как можно большего количества реальных пользователей и проведение серии митингов по сбору требований. Последнее слово остается за Прокси (поэтому обычно он не против)
2 Если первый пункт не реализуем, второй способ — работать с несколькими прокси разных типов, например один из маркетинга, второй из саппорта.

По ходу сбора Стори, нужно не забывать писать к ним Аксептанс Критерии — здесь мы раскрываем детали Стори. В идеале, Аксептанс Критерии стоит сразу же записывать в виде тестов в тулзу написания тестов — FitNesse, Cucumber, и др.

Шаг 3. Написание Стори.

12 заповедей написания хороших Стори.

Заповедь 1. Начать со Стори, описывающих ключевой необходимый функционал. Например, для сайта по поиску работы, ключевая Стори — поиск работы

Заповедь 2. При декомпозиции сложных Стори следовать правилу Slice the Cake. Например, плохой вариант разбития Стори на одну техническую и одну UI. Стори 1 — Создать базу и структуру таблиц для записи данных анкеты пользователя. Стори 2 — Кандидат должен иметь возможность ввести все необходимые анкетные данные на веб форме. Хороший вариант — это когда каждая Стори включает небольшую часть бекенд и UI разработки, и ее можно протестировать енд ту енд. Стори 1. Кандидат должен иметь возможность ввести только ФИО на веб форме и иметь возможность сохранить ее. Стори 2. Кандидат должен иметь возможность ввести все остальные необходимые поля на форме и сохранить ее.

Заповедь 3. Стори должна быть закрытой или другими словами — приносить удовлетворение пользователю. Например, Стори вида «Менеджер по персоналу должен иметь возможность управлять рекламными баннерами» не является закрытой, потому как не понятно, что значит управлять и нет конечного ожидаемого результата. Вместо этой Стори можно написать несколько закрытых. Стори 1. Менеджер может добавлять и удалять резюме в рекламные баннеры. Стори 2. Менеджер может смотреть количество просмотров баннера.

Заповедь 4. Не функциональные требования. В аджайле с ними все иначе. В аджайле их принято называть ограничениями (constrains). Ограничения записываются на Стори карточках и для них пишутся автоматизированные тесты. Если при билде все тесты прошли — код соответствует всем ограничениям. Кроме того, ограничения должны быть всегда на виду и напоминать о себе девелоперам.

Заповедь 5. Детализация Стори должна соответствовать времени ее имплементации. Нет смысла детально описывать Стори, которая запланирована на несколько спринтов вперед.

Заповедь 6. Начинать описывать Стори по юзер интерфейсу как можно позже. Болячка всех требований что они содержат детали имплементации. Чтобы избежать попадания деталей имплементации в требования на ранних этапах, мы придерживаем описание UI как можно дольше. В идеале описание UI должно начинаться естественно, как улучшение существующего работающего функционала.

Заповедь 7. Не Всё есть Стори. Некоторые вещи, как например описание работы интерфейсов, юзер гайды, документация сторонних вендоров, лучше описывать наиболее для этого подходящими средствами. Это нормально, когда в Беклоге содержатся не только Стори.

Заповедь 8. Стори лучше писать используя роли пользователей. О ролях я писал выше.

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

Заповедь 10. Плохая привычка нумеровать Стори. Часто нумерация мешает при декомпозиции большой Стори на более мелкие и создает ненужный оверхед к управлению Беклогом.

Заповедь 11. Стори пишет заказчик — звучит как-то чересчур идеализированно, но заставляйте его как минимум читать их.

Заповедь 12. Не забывайте основную цель Стори — служить напоминанием о функционале, который нужно обсудить в деталях непосредственно перед имплементацией.

И в результате мы получаем готовую Стори.

Готовая Стори соответствует критерию Definition of Ready:

— Стори понятна девелоперам, нужны минимальные дискуссии для написания Тасок
— Содержит четкое ожидание заказчика — Аксептанс Критерии
— Содержит все необходимые спеки, диаграммы, мокапы и т.д.
— Соответствует критерию INVEST
— Не имеет внешних зависимостей, т.е. у команды есть все необходимое для завершения Стори

Стори, которые плохо пахнут или симптомы плохих Стори и как их лечить.

1. Стори очень маленькие.
Симптомы: часто приходится пересматривать оценки.
Таблетка: маленькие Стори вызывают проблемы с оценкой и частым перепланированием. Это случается потому, что оценка Стори существенно меняется в зависимости от последовательности, в которой Стори имплементируется. Например, Стори 1 — менеджер может сохранить результат поиска в формате XML. Стори 2 — менеджер может сохранить результат поиска в формате HTML. Очевидно, что имеется существенная зависимость количества требуемой работы. Такие Стори лучше объединять для простоты планирования и управления. Конечно, ее можно разбить на 2, но уже в самом Спринт Беклоге.

2. Зависимые Стори.
Симптомы: сложность в планировании итераций.
Таблетка: команда находится в ситуации, когда для того, чтобы добавить Стори в Спринт, необходимо добавить еще одну Стори, с которой она связана. Это случается при не правильной декомпозиции Стори либо когда Стори очень маленькие.

3. Goldplating.
Симптомы: девелоперы добавляют фичи, без которых функционал отлично работает. Либо Стори трактуется таким образом, что время на ее имплементацию занимает в разы больше запланированного.
Таблетка: девелоперы часто любят добавлять фичи по ряду причин:
— Произвести вау эффект на кастомера
— Отодвинуть завершение Стори как можно дальше, тем самым дать себе время отдохнуть и ничего не делать
— Добавить свою «фичу», которая будет напоминать следующим поколениям о гениальном девелопере

4. Очень много деталей в Стори.
Симптомы: очень много времени потрачено на описание деталей Стори, которые будут имплементироваться еще не скоро. На описание Стори затрачено в разы больше времени чем на ее устное обсуждение.
Таблетка: писать Стори на бумажных карточках, это физически ограничивает большее количество деталей. «Если вам не хватает места — возьмите карточку меньше размером» — Tom Poppendieck.

5. Добавление деталей UI чересчур рано.
Симптомы: Стори, написанные на ранних стадиях продукта содержать детали пользовательского интерфейса.
Таблетка: на ранних стадиях еще нет ясности какие элементы будут использоватся на UI, поэтому с большой вероятностью работа, проделанная над этой Стори окажется бесполезной. Лечение простое — просто так не делать.

6. Очень частое дробление Стори.
Симптомы: В процессе Спринт планинга приходится сплитить очень много Стори.
Таблетка: обычно разбивка большой Стори на более мелкие необходимо при:
— Стори большая и не помещается в Спринт
— Стори содержит функционал с различным приоритетом
— Стори сложная и только одна ее часть понятна разработчикам

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

7. Заказчику тяжело приоритезировать Стори.
Симптомы: заказчику тяжело выставить приоритеты Стори и спланировать Спринт.
Таблетка: Стори настолько большие что заказчик не может правильно расставить приоритеты. Стори не содержит бизнес ценности для заказчика.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю! Мені дуже допомогли приклади в INVEST, оскільки намагаюся зробити веб-сервіс для автоматичної перевірки якості юзер сторі — userstory.top

Стори не должна быть нефункциональным требованием, потому как ее невозможно будет протестировать.

Ага, а наприклад стрес-тестування придумали рептилоїди.
Нефункціональні вимоги тестуються і для цього є купа методів.

ага, как автору такая анти-стори
Пользователь подходит к банкомату, вставляет карточку вводит пинкод, ждет 30 минут (на экране написано — ожидание ответа сервера), разбивает банкомат что бы забрать карточку и уходит =D
Вот такая неважная и совершенно нереальначя задача по тестированию НЕФУНКЦИОНАЛЬНЫХ перформанса и ограничения таймаута респонса с сервера

Что-то шановне паньство явно путает. Я не говорил что НЕ нужно тестировать нефункциональные требования — см. Заповедь 4.
Я о том, что Стори — это всегда функциональное требование. А кроме Стори в беклоге может быть куча всякого... добра :)

INVEST — дерьмовая методология потому что в половину случае не будет твоя стори Independent. Вот в упор не понимаю какой умник придумал что в сложных системах стори обязательно не должна зависеть от других стори (а точнее — их имплементации). не в этом мире

Заповедь 10. Плохая привычка нумеровать Стори. Часто нумерация мешает при декомпозиции большой Стори на более мелкие и создает ненужный оверхед к управлению Беклогом.

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

Я добавил абзац

Стори, которые плохо пахнут или симптомы плохих Стори и как их лечить.

Там написано, что зависимые Стори мешают правильно планировать итерации. А ИНВЕСТ техника — это идеальный мир (не наш)

ну теперь уже точно на О-1!

Подписаться на комментарии