3. Пользовательские истории
• Заменяют формальные тяжеловесные «бюрократические»
требования
• Подробности формулируются и обсуждаются устно
• Кратко записываются в виде отдельных карточек
• Просто описывают функциональные возможности с точки зрения
клиента
• «Клиентом» может быть не только конкретный конечный
пользователь, но и некоторая система
• Составляют product backlog
3
4. Неколько «не» про User Story
• Не соответствуют стандартам на написание
требований
• Не являются сценариями использования (use
case)
• Не занимают много места
• Не детализированы в самом начале
4
12. «User Story» и «задача»
12
USER STORY ЗАДАЧА
Представляет ценность для
Product Owner’а (бизнеса)
Сама по себе может не нести
никакой ценности
Можно продемонстрировать
Демонстрация бывает
затруднительна
17. Уточнение требований
• Разбить эпические истории
• Несколько коротких историй лучше, чем одна,
в которой куча деталей
• Выяснить и записать «условия
удовлетворенности»
17
19. Разбиение эпиков на истории
Эпик:
«Будучи пользователем, я должен
войти в систему таким образом, чтобы
только я имел доступ к своей
информации.»
19
20. Разбиение эпиков на истории
«Будучи зарегистрированным
пользователем, я могу войти в систему,
задав свои имя пользователя и
пароль.»
20
21. Разбиение эпиков на истории
«Будучи новым пользователем, я хочу
зарегистрироваться, создав имя
пользователя и пароль, чтобы система
могла запомнить мою персональную
информацию.»
21
22. Разбиение эпиков на истории
«Будучи зарегистрированным
пользователем, я могу изменить свой
пароль, чтобы быть уверенным в его
надежности или чтобы мне было легче
его запомнить.»
22
25. Что еще?
• Оценка в story points и planing
poker
• Зависимость и независимость
одних историй от других
• Ценность истории для бизнеса
• «Технические истории»
25
26. Что читать?
Scrum и XP: заметки
с передовой
http://agilerussia.ru/
books/scrum_xp-
from-the-trenches/
26
27. Что читать?
База знаний от
Mountain Goat
http://
www.mountaingoatsoftware.com
/agile/user-stories
27