Доклад на конференции SCRUM:open в Харькове 25 июня 2009. Краткий обзор о том, как гибко управлять требованиями с использованиями Историй Пользователя как наиболее удобного инструмента. Иллюстрация теоретических и практических аспектов. Основано на работах Майка Кона с его разрешения.

1. Тимофей Евграшин
SCRUM-тренер
Тел.: +38 067 408 53 30
e-mail: tim@tim.com.ua
www.tim.com.ua
Управление требованиями в
Agile проектах
SCRUM:open
2009-06-25
© The Improved Methods

2. О докладчике
Тимофей Евграшин
 Опыт разработки ПО 12+ лет
 Лидер команд и менеджер
проектов 8+ лет
 Certified ScrumMaster
 «Евангелист» и тренер по
внедрению гибких методологий
управления проектами
(Agile/Scrum)
email: tim@tim.com.ua
http://www.tim.com.ua
© The Improved Methods

3. О вас
 Разбейтесь на пары
 За 3 минуты выясните друг у друга:
 Имя
 Роль в проекте
 Роль в управлении требованиями
 Опыт в работе с требованиями
 Два слова о подходах, применяемых в проекте
для работы с требованиями
 По истечении времени, представьте
своего собеседника остальным
© The Improved Methods

4. Давайте сделаем «проЭкт»
 Заказчик хочет нанять
исполнителя, который даст
меньшую оценку времени на
сортировку стопки монет
 Каждая команда может
сделать ставку (в секундах)
 И попробовать!
© The Improved Methods

5. «Дерево ожиданий»
http://www.jacobsen.no/anders/blog/archives/images/project-thumb.jpg
© The Improved Methods

6. Проблемы коммуникации
 Требования и особенно процесс «Управление
требованиями» – это общая проблема
 Те, кто «хотят» (заказчики), должны общаться с теми
кто «может» (разработчики), чтобы достигнуть
максимального результата
 Часто говорят во всем виноват плохой процесс
«Управления требованиями»
 Что по вашему значит плохой процесс управления
требованиями?
 Какие проблемы появляются в результате плохого
управления требованиями?
© The Improved Methods

7. Ужасающая статистика
© The Improved Methods

8. Если разработчикам дать волю...
 ... они перестанут слушать и учиться
понимать нужды заказчика
 «технический жаргон» заглушит «голос
бизнеса»
 Качество будет пожертвовано в пользу
дополнительных «прибамбасов»
 «Фичи» могут быть реализованы частично
 Будут приниматься решения о
функциональности без привлечения
заказчиков
© The Improved Methods

9. Если заказчикам дать волю...
 Функциональность и даты будут
обещаться без всякого учета реалий
 Будут затяжные сессии предварительного
сбора требований и их согласования
 По мере наступления «дня Д» будут
выкидываться первые попавшие под руку
«фичи».
 Мало кто будет интересоваться тем, как
хорошо разработчики понимают нужды
заказчика
© The Improved Methods

10. О жизненном цикле проекта
 Последовательный
Feasibility
Definition
Design
Construction Release
 Итеративный
Release 1 Release 2
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration…
© The Improved Methods

11. Жизненный цикл требований
Новые истории создаются и
Утверждается
добавляются в Product Backlog
бюджет
проекта/
релиза
Спринт 1 Спринт ... Спринт N Релиз
Создается Сессия Сессия
концепция написания написания
продукта/ основных основных
релиза, историй историй
чтобы для Релиза для Релиза
получить
бюджет
© The Improved Methods

12. Чтобы быть Agile...
 Мы принимаем решения ... и мы делаем это часто
на основе той
информации, которая
есть сейчас
... мы принимаем решения в
 Вместо того, чтобы течении жизни всего
делать один раунд проекта
принятия всех решений
При таком подходе, нам необходим простой инструмент
работы с требованиями
Истории Пользователя (User Stories) помогут нам
© The Improved Methods

13. Еще планы на сегодня
 Концепция – хорошая отправная точка
 Роли
 Что такое Истории Пользователей
 Признаки хороших историй
 Чем Истории Пользователей не являются
© The Improved Methods

14. Концепция продукта / релиза
 Концепция - несколько предложений,
описывающих идею, цели, ожидания
 Основа для понимания кто и как будет
использовать продукт
 Основа для расстановки приоритетов и
планирования релизов
 Постоянное напоминание о целях и
инструмент поддержания фокуса команды и
всех заинтересованных лиц
© The Improved Methods

15. Роли
 Не думайте, что пользователь только один –
расширьте кругозор
 Попробуйте различать пользователей по:
 Целям использования приложения
 Стилю использования приложения
 Знаниям предметной области
 Знаниям компьютеров, других приложений и т.п.
 Общим атрибутам и т.п.
 Все это может помочь при создании дизайна
интерфейсов и архитектуры приложения,
ориентированных, в первую очередь,
НА ПОЛЬЗОВАТЕЛЕЙ
© The Improved Methods

16. Что такое Истории Пользователей
 User Story (Истории Пользователя) - это нужды
конкретного пользователя выраженные в
простой форме
 Как <тип пользователя> я хочу <сделать> и тем
самым получить <выгоды>.
 Примеры:
 Как гость, я хочу зарезервировать номер, тем самым
иметь гарантии размещения во время приезда
 Как работник гостиницы, я хочу просматривать
отчеты, тем самым получать информацию о работе
гостиницы
© The Improved Methods

17. 3 «C» от Рона Джеффриса
Source: XP Magazine 8/30/01, Ron Jeffries.
 Истории пишутся на карточке
 Вся служебная информация и
Card комментарии должны вместиться на
маленьком куске бумаги
 Детали опущены до тех пор, когда
Conversation они понадобятся
 Когда понадобится, Product Owner
расскажет их
 Acceptance tests подтверждают, что
Confirmation история сделана
© The Improved Methods

18. А где детали?
 Как пользователь, я хочу отменить
резервацию
 Полный или частичный возврат денег?
 Какой лимит во времени?
 Единый для всех пользователей?
 Единый для всех отелей?
 Следует ли слать подтверждение
пользователю?
© The Improved Methods

19. Детали как более мелкие Истории
 Как Премиум
пользователь я могу
отменить резервацию
вплоть до последней
 Как пользователь, я хочу минуты
отменить резервацию
 Как Не Премиум
Пользователь я могу
отменить резервацию
минимум за 24 часа
 Как посетитель сайта я
хочу получить по e-mail
уведомление об
отмененной резервации
© The Improved Methods

20. Детали как критерии приемки
 Критерии приемки, которые подразумевает
Владелец Продукта, могут быть добавлены для
уточнения деталей.
 Как пользователь, я хочу отменить резервацию
● Проверить, что Премиум пользователи отменяют резервацию
без штрафов
● Проверить, что все Не Премиум пользователи платят 10%,
если отменяют резервацию меньше чем за 24 часа
● Проверить, что все пользователи получают уведомления по
e-mail
● Проверить, что Отели уведомляются об отмене резервации
© The Improved Methods

21. Айсберг требований
© The Improved Methods

22. Истории, Темы и Эпосы
© The Improved Methods

23. Хорошие Истории – это INVEST
 Independent - Независимые
должна быть возможность приоритизировать истории независимо одну от
другой
 Negotiable - Обсуждаемые
Истории – лишь напоминание - обсудить детали, когда придет время. Не
думайте о них, как о спецификации или контракте
 Valuable - Ценные
Каждая история должна иметь ценность для пользователя
 Estimatable - Оцениваемые
должно быть достаточно информации, чтобы оценить каждую историю
 Sized appropriately - Соразмерные
Комплексные истории тяжело оценить, а связанные тяжело
приоритезировать
Спасибо William Wake за
 Testable - Тестируемые акроним
Нужно четко знать, когда история закончена www.xp123.com
© The Improved Methods

24. Чем Истории не являются
 Истории Пользователя – это не Use Cases
 Отличие в масштабах
 Отличие в целях:
 Use Case – обычно воспринимается как
документальное соглашение между заказчиком и
разработчиками
 User Stories – лишь напоминание о необходимости
поговорить. Служат подспорьем для планирования
релизов и итераций
 Отличие в сроке жизни
 Отличие в детализации
© The Improved Methods

25. Чем Истории не являются
 Истории Пользователя – это не спецификации
 Например, по стандарту IEEE 830:
 «Система должна ...», «Система имеет ...»
 Большие спецификации тяжело писать и читать
(поэтому люди пропускают целые страницы )
 Зачастую, спецификация подразумевает, что все
известно заранее
 Требования не описываются на одинаковом
уровне, поэтому возникают разные толкования
© The Improved Methods

26. Неудачная спецификация
 Спецификация по стандарту IEEE 830:
1. Продукт должен иметь бензиновый
двигатель
2. Продукт должен иметь четыре колеса
 Продукт должен иметь резиновые покрышки на
каждом колесе
3. Продукт должен иметь рулевое колесо
4. Продукт должен иметь металлический корпус
 И что мы строим?
Источник: The Inmates are Running the
Asylum by Alan Cooper (1999).
© The Improved Methods

27. Об источниках информации...
 Майк Кон
 Agile Estimating and Planning
User Stories Applied
 http://www.mountaingoatsoftware.com/articles-
user-stories
© The Improved Methods

28. Вопросы? 
Если у нас осталось время, мы можем
обсудить интересующие вас вопросы
© The Improved Methods