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

1. Timofey Yevgrashyn
tim@tim.com.ua
http://tim.com.ua
Гибкое управление Вебинар
требованиями 24.02.2010
©

2. О себе
 Тимофей Евграшин
 Менеджер проектов с Agile
уклоном
 Certified ScrumMaster
 Scrum практик
 Тренер по внедрению гибких
методологий управления
проектами (Agile/Scrum)
 Автор блога «The Improved
Methods»
 email: tim@tim.com.ua
 skype: spidertim
 http://tim.com.ua
©

3. О вас
 Кто из вас работает с требованиями как
член команды разработчиков?
 Кто из вас работает с требованиями как
посредник (бизнес-аналитик, менеджер
проекта)?
 Кто из вас работает с требованиями как
представитель бизнеса?
 Не относится на прямую к работе с
требованиями
©

4. Как работает команда разработки
© http://www.jacobsen.no/anders/blog/archives/images/project.html

5. Проблемы коммуникации
Требования и особенно
процесс «Управление
требованиями» –
это общая проблема
Те, кто «хотят» (заказчики), должны общаться с теми,
кто «может» (разработчики), чтобы достигнуть
максимального результата
©

6. Вопрос к участникам
 Часто говорят во всем виноват плохой
процесс «Управления требованиями»
 Что по вашему значит плохой процесс
управления требованиями?
 Какие проблемы появляются в результате
плохого управления требованиями?
©

7. Важен баланс
Если разработчикам Если заказчикам
дать волю… дать волю...
•Качество пожертвовано •Обещания без всякого
в пользу «прибамбасов» учета реалий
•Функциональность •Затяжные сессии
реализуется частично сбора требований
•Принимаются решения •Выкидывается первое
без привлечения заказчиков попавшееся под руку
©

8. Проблема оценок
Размер спецификации
Спецификация Похожая спецификация –
больше страниц
117 ч. 173 ч.
SM
SM
Источник: How to avoid impact from irrelevant and misleading information on your cost
estimates. Simula Research Labs Estimation Seminar, Oslo, Norway 2006.
©

9. Проблема оценок
Несущественные детали
Похожая спецификация +
Спецификация
несущественные детали
A A
B B
C C
20 ч. 39 ч.
SM
SM
Источник: How to avoid impact from irrelevant and misleading information on your cost
estimates. Simula Research Labs Estimation Seminar, Oslo, Norway 2006.
©

10. Если собирать все требования сначала…
©

11. Выравнивание работы
©

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

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

14. Истории Пользователей
Структура
Как <КТО> я хочу <ЧТО> и <ПОЧЕМУ>
(As a <role> I want to <what> so that <why>)
 Фокус на реальных пользователях
 Фокус на результате
©

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

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

17. «Виденье продукта»
 Для (целевой
заказчик/аудитория)
 Которому нужно
(описание нужд или
возможностей)
 Имя (продукта) в
(категория продуктов)
 Который (ключевые
выгоды, повод купить)
 В отличие (главное
отличие от конкурентов)
 Наш продукт (главное
преимущество)
©

18. Роли
©

19. Подходы: «Копать»
 Начните с Эпоса для
одной или нескольких
ролей
 Разбивайте его на
отдельные Темы
 Темы разбивайте на
отдельные Истории
©

20. Подходы: «Генерировать»
 Выберите роль
 Подумайте, что бы
этот пользователь
хотел бы сделать?
 Как ему может
помочь ваша
система?
©

21. Подходы: «Прототип»
 Возьмите черновой
(бумажный) прототип
 Задавайте вопросы
 Что пользователь будет
делать дальше?
 Какие ошибки он может
допустить?
 Что может запутать
пользователя?
 Какую информацию ему
нужно видеть?
 Задайте эти вопросы для
каждой роли
©

22. Что может пойти не так
Неправильные вопросы
Закрытый вопрос:
- Вы хотите чтобы все
работало в браузере?
- О да, конечно, раз вы
так предлагаете!
Открытый вопрос:
- Чем вы готовы пожертвовать,
чтобы все работало в браузере?
©

23. Что может пойти не так
Знать проблему, не означает знать решение
 Можно услышать:
«Я знаю, чего я хочу, и вы должны сделать
так…»
 Иногда лучше прекратить спрашивать и начать
придумывать систему совместно
 Наблюдения за реальными пользователями
 Прототипирование
 Совместное придумывание требований
(брейншторм)
©

24. Что может пойти не так
Неточности
Слова могут быть
истолкованы неоднозначно…
Например:
 Основное блюдо идет с
супом или салатом и хлебом
 (Супом или Салатом) и
Хлебом?
 (Супом) или (Салатом и
Хлебом)?
©

25. Что может пойти не так
Неточности
 Пользователь может ввести имя. Оно может
быть 127 символов
 Имя обязательно?
 Обязательно все 127 или любой длины?
 Система должна немедленно показать
сообщение об ошибке, если пользователь
ввел неправильные данные
 Что значит немедленно?
 Когда осуществляется проверка?
©

26. Чем Истории не являются
Истории Пользователя – это не Use Cases
 Отличие в масштабах
 Отличие в целях
 Отличие в сроке жизни
 Отличие в детализации
©

27. Чем Истории не являются
Истории Пользователя – это не
спецификация
 Большие спецификации тяжело писать и
читать (поэтому люди пропускают целые
страницы )
 Зачастую, спецификация подразумевает,
что все известно заранее
 Требования не описываются на
одинаковом уровне, поэтому возникают
разные толкования
©

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

29. Возможные истории
 Как садовод я хочу подстричь траву, и
моя лужайка будет красивой
 Как садовод я хочу, чтобы мне было
удобно, когда я подстригаю траву, и
таким образом я не уставал бы
 Как неопытный водитель я могу
цеплять деревья и кусты, таким
образом косилка должна быть надежной
©

30. Результат
©

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

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