Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt 1. Что такое пользовательские истории (User Stories) 2. Зачем они нужны в ваших проектах? 3. Как пользовательские истории помогают повысить удовлетворённость заказчика? 4. Как применяются пользовательские истории в Scrum? Для кого: Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах

1. Пользовательские истории в
Agile-проектах
Школа управления продуктами

2. О себе
В прошлом
• С 2004 коммерческая разработка ПО
• С 2011 Руководство проектами разработки ПО
• С 2011 Scrum Mastering
• 2014–2016 Agile Coach в ScrumTrek
Сейчас
• Руководство проектами (Artezio)
• Трансформация проектов и команд и
внедрение Agile
• Процессный аудит
• Тренинги (Agile, Scrum, Kanban, XP)

3. Агенда

4. Тайминг
• Презентация – 30-40 минут
• Вопросы – 15-20 минут

5. Agile манифест
http://agilemanifesto.org/iso/ru/
Работающий
продукт
важнее
исчерпывающей
документации
Сотрудничество с
заказчиком
важнее
согласования
условий
контракта
Готовность к
изменениям
важнее
следования
первоначальному
плану

6. Проблемы при работе
с требованиями

7. Проблемы при работе
с требованиями
• Требования меняются и добавляются
• Заказчик не знает, что хочет пока не
увидит
• Заказчик «не это имел в виду»
• Меняются приоритеты
• При изменении требований тяжело
работать с большими
спецификациями

9. Определение
Пользовательские истории (User Story) —
способ описания требований к
разрабатываемой системе,
сформулированных как одно или более
предложений на повседневном или
деловом языке пользователя.

10. Feature vs User Story
• 1. Как менеджер, я могу использовать
отчет «утилизация персонала»
• 2. Как менеджер, я могу видеть загрузку
своих подчиненных
В чём разница?

11. F-16

12. Истребитель F-16
• Первоначальные требования к разработке
– скорость 2-2.5 M
• В комплексе с другими требованиями
разработка и производство самолета
очень дорогие

13. Истребитель F-16
• Harry Hillaker:
– Почему так важно это
требование скорости?
– Истребитель должен смотаться, если
станет действительно жарко
• Hillaker предложил и создал истребитель,
превосходящий другие по маневренности
• Прошло более 30 лет, а эти истребители
все еще производят.
4400 самолетов продано в 25 стран мира

14. Feature vs User Story
• Как менеджер , я могу использовать отчет
«утилизация персонала»
– Feature.
Предлагается готовое решение задачи пользователя
– Описывает реализацию
• Как менеджер, я могу видеть загрузку своих
подчиненных, чтобы грамотно распределять задачи.
– User Story.
Не предписывает конкретных вариантов достижения цели.
– Описывает кейс пользователя

15. Шаблон пользовательских
историй
A team at Connextra developed the traditional user-story template in 2001:
"As a <role>, I want <goal/desire> so that <benefit>"
Mike Cohn, a well-known author on user stories, regards the "so that" clause as optional:
"As a <role>, I want <goal/desire>"
Chris Matts suggested that "hunting the value" was the first step in successfully delivering software,
and proposed this alternative as part of Feature Injection:
"In order to <receive benefit> as a <role>, I want <goal/desire>"
Another template based on the Five Ws specifies:
"As <who> <when> <where>, I <what> because <why>."
A template developed at Capital One in 2004 during their initial adoption of Agile methods focuses on
the functionality and specifies:
"As a <role>, I can <action with system> so that <external benefit>"

16. Шаблон пользовательских
историй
• Я, как <роль>, могу <цель> для того,
чтобы <Причина/результат>
• As a <role>, I want <goal/desire> so
that <benefit>

17. Преимущества User story

18. Преимущества User story
1. Быстрый способ писать требования клиента, без
необходимости разрабатывать большие
формализованные документы
2. Выше вероятность разработать то, что нужно
пользователю (заказчику)
3. Возможность предложить заказчику более простой и
дешёвый вариант реализации, что повышает доверие
4. Возможность выбрать вариант реализации
требующий минимальных изменений архитектуры

19. User story
Приёмка
• Приёмка осуществляется не по User
Story, а согласно приёмочной
процедуре:
– Критерии приёмки (Acceptance Criterias)
– Приёмочные тесты (Acceptance Tests)

20. Критерии приёмки
• Считывать показатели счетчика
Декаватт каждые 10 сек. и
показывать на портале в виде 15-
минутных инкрементов
• Считывать показатели в
Киловаттах, как только появляются
новые данные и показывать на
портале каждый час
• Пока никакого многодневного
трендинга (попадет в другую стори)

21. Приёмочные тесты
1. Инкремент декаватта,
произошедший ранее, чем 15
минут, назад и позднее, чем 30
минут назад, будет отображён в
последней записи на портале
2. Новые записи на портале не
должны появляться чаще, чем 1
раз в 15 минут
3. …

22. Приёмочные тесты в виде
спецификации на примерах
(Spec By Example)

23. Приёмочные тесты в виде
спецификации на примерах
(Spec By Example)
Тип аккаунта В корзине Доставка
VIP 1 книга Бесплатно
VIP 10 книг Бесплатно
VIP 11 книг Стандартная
Обычный 10 книг Стандартная
VIP
5 стиральных
машин
Стандартная
VIP
1 стиральная
машина и 5 книг
Стандартная

24. Критерий готовности к
разработке (Definition of Ready)
Пример:
• Имеет приоритет
• Имеются приемочные тесты
• Есть предварительная оценка командой
разработки и она не больше 13 очков историй
(Story Points)

25. Критерий готовности к
поставке (Definition of Done)

26. Критерий готовности к
поставке (Definition of Done)
Пример:
• Пройдены приемочные тесты
• Проходят интеграционные тесты всего
проекта
• Проходят модульные тесты всего проекта
• Все задачи сделаны
• Имеется запись ChangeLog

27. Scrum
Беклог продукта Беклог спринта
Скрам-митинг
15 минут
Готовый продукт с
новой
функциональностью
Владелец
продукта
Владелец
продукта
8 часов
Спринт
1-4 недели
Ретроспектива
Демонстрация
Планирование
спринта
Скрам-мастер
Команда
разработки
7±2 человек

28. Беклог (Backlog)
Spike 1

29. INVEST
I Independent Независимая
N Negotiable Обсуждаемая и изменяемая
V Valuable Ценная конечному пользователю
E Estimable Пригодная для оценки
S Small Достаточно маленькая
T Testable С критериями приёмки

30. Преимущества User story в
Методе Канбан (Kanban Method)
1. Быстрый способ писать требования клиента, без
необходимости разрабатывать большие
формализованные документы
2. Выше вероятность разработать то, что нужно
пользователю (заказчику)
3. Возможность предложить заказчику более простой и
дешёвый вариант реализации, что повышает доверие
4. Возможность выбрать вариант реализации
требующий минимальных изменений архитектуры
5. Возможность снизить неравномерность за счёт
декомпозиции (в т.ч. использования INVEST)

31. Что почитать?
Майк Кон «Пользовательские истории. Гибкая
разработка программного обеспечения
Бестселлер»
(Mike Cohn “User Stories Applied: For Agile Software
Development”)
Кен Швабер и Джефф Сазерленд
Скрам Гайд

32. Что почитать?
Specification By Example:
• Specification By Example – BDD для прагматиков
• Spec By Example на примере одного требования
• Gojko Adzic “Specification by Example”

33. Денис Тучин
• Внедрение Agile
• Процессный аудит
• Тренинги (Agile, Scrum, Kanban, XP)
denistuchin@gmail.com
facebook.com/denis.tuchin
linkedin.com/in/denistuchin
Вопросы