2. Немного о себе
• С 2004 разработка коммерческого ПО
• С 2009 применение инженерных практик Agile
• С 2011 руководитель
• С 2011 Scrum-Мастер
• С 2014 Agile Coach
• Обучил на тренингах более 400 человек
• Запустил более 30 Agile-команд
• Scrum, Kanban, Scrumban, DevOps
• Ака хобби: мотивация взрослых и детей
3. План
1. Коротко про пользовательские истории
2. Практика: пишем User Story в группах
3. Что такое критерии приёмки и с чем их едят?
4. Практика: пишем критерии приёмки
6. Преимущества User story
1. Быстрый способ писать требования клиента, без
необходимости разрабатывать большие
формализованные документы
2. Выше вероятность разработать то, что нужно
пользователю (заказчику)
3. Возможность предложить заказчику более простой и
дешёвый вариант реализации, что повышает доверие
4. Возможность выбрать вариант реализации требующий
минимальных изменений архитектуры
9. F-16: Разговор
«Истребитель должен развивать
2-2,5 скорости звука»
Почему это важно?
Истребитель должен смотаться, если станет
действительно жарко
10. F-16: реализация
• Конструкторы создали истребитель,
превосходящий другие по маневренности
• Прошло более 30 лет, а эти истребители все еще
производят.
• 4400 самолетов продано в 25 стран мира
11. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
12. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
13. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
• Как менеджер, я хочу видеть загрузку своих подчиненных,
чтобы грамотно распределять задачи.
14. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
• Как менеджер, я хочу видеть загрузку своих подчиненных,
чтобы грамотно распределять задачи.
15. Шаблон пользовательских историй
• Я, как <роль>, хочу <цель/желание> для того,
чтобы <выгода>
• As a <role>, I want <goal/desire> so
that <benefit>
16. Шаблоны пользовательских историй
Наиболее распространённый шаблон (Connextra, 2001):
"As a <role>, I want <goal/desire> so that <benefit>"
Mike Cohn, автор концепции User Stories, иногда опускает
последнюю часть:
"As a <role>, I want <goal/desire>"
Chris Matts предложил больше фокусироваться на ценности для
пользователя:
"In order to <receive benefit> as a <role>, I want <goal/desire>"
Изящный формат основанный на пяти W:
"As <who> <when> <where>, I <what> because <why>."
17. User Story: практика
В группах по 4 человека
Переформулировать требования в формат
пользовательских историй
1. Реализовать вход по логину и паролю на сайт Почты
России
2. Мне как покупателю нужна корзина в онлайн магазине,
чтобы проще сделать заказ
3. Получение баланса по кредитному остатку через
телефонное меню банка
9 минут
19. Приёмочные критерии
Я, как получатель посылки,
хочу видеть статусы всех моих посылки вместе
для того, чтобы сэкономить время на запрос трекинга
каждой
• На одном экране помещается не меньше чем 10 посылок
• В списке посылок видно короткое название посылок,
текущий статус и дату обновления статуса
• Если пользователь просматривает посылки со своего
устройства, то он не должен аутентифицироваться
каждый раз.
20. Приёмочные критерии: практика
В группах по 4 человека
Написать приёмочные критерии для историй
1. Я как клиент интернет-магазина, хочу иметь возможность
формировать заказ из нескольких товаров, чтобы
однократно вводить детали доставки и оплачивать
2. Я, как пользователь кредитной карты, хочу узнавать
остаток по карте, чтобы понимать сколько ещё могу
потратить
5 минут
21. Приёмочные критерии: пример
Я, как пользователь кредитной карты, хочу узнавать
остаток по карте, чтобы понимать сколько ещё могу
потратить
• Остаток должен сообщаться с точностью до копеек
• Чтобы услышать свой остаток клиент не должен
нажимать больше чем 3 раза кнопки в тональном режиме
• Если у пользователя более одной кредитной карты, то
предложить ему выбор с помощью тонального набора
• Если у пользователя более одной кредитной карты,
всегда сохранять порядок кредитных карт, если их состав
не изменился
22. Приёмочные критерии
• Приёмочные критерии (Acceptance Crithirea)
описываются во время реализации или
непосредственно перед самым её началом,
когда уже ясен способ реализации
• Описываются, как правило, не пользователем, но
на основе его пожеланий