SCRUM:open - Управление требованями в Agile проектах

Тимофей Евграшин
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

О докладчике
Тимофей Евграшин
 Опыт разработки ПО 12+ лет
 Лидер команд и менеджер
проектов 8+ лет
 Certified ScrumMaster
 «Евангелист» и тренер по
внедрению гибких методологий
управления проектами
(Agile/Scrum)

email: tim@tim.com.ua
http://www.tim.com.ua

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

Давайте сделаем «проЭкт»
 Заказчик хочет нанять
исполнителя, который даст
меньшую оценку времени на
сортировку стопки монет

 Каждая команда может
сделать ставку (в секундах)

 И попробовать!


«Дерево ожиданий»

http://www.jacobsen.no/anders/blog/archives/images/project-thumb.jpg


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


Ужасающая статистика


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

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

О жизненном цикле проекта
 Последовательный
Feasibility

Definition

Design

Construction Release

 Итеративный
Release 1 Release 2

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration…

Жизненный цикл требований

Новые истории создаются и
Утверждается
добавляются в Product Backlog
бюджет
проекта/
релиза

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


Чтобы быть Agile...
 Мы принимаем решения ... и мы делаем это часто
на основе той
информации, которая
есть сейчас

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

При таком подходе, нам необходим простой инструмент
работы с требованиями
Истории Пользователя (User Stories) помогут нам

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


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


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

Что такое Истории Пользователей
 User Story (Истории Пользователя) - это нужды
конкретного пользователя выраженные в
простой форме

 Как <тип пользователя> я хочу <сделать> и тем
самым получить <выгоды>.

 Примеры:
 Как гость, я хочу зарезервировать номер, тем самым
иметь гарантии размещения во время приезда
 Как работник гостиницы, я хочу просматривать
отчеты, тем самым получать информацию о работе
гостиницы


3 «C» от Рона Джеффриса
Source: XP Magazine 8/30/01, Ron Jeffries.

 Истории пишутся на карточке
 Вся служебная информация и
Card комментарии должны вместиться на
маленьком куске бумаги

 Детали опущены до тех пор, когда
Conversation они понадобятся
 Когда понадобится, Product Owner
расскажет их

 Acceptance tests подтверждают, что
Confirmation история сделана


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

 Следует ли слать подтверждение
пользователю?


Детали как более мелкие Истории
 Как Премиум
пользователь я могу
отменить резервацию
вплоть до последней
 Как пользователь, я хочу минуты
 Как Не Премиум
Пользователь я могу
минимум за 24 часа

 Как посетитель сайта я
хочу получить по e-mail
уведомление об
отмененной резервации


Детали как критерии приемки
 Критерии приемки, которые подразумевает
Владелец Продукта, могут быть добавлены для
уточнения деталей.

 Как пользователь, я хочу отменить резервацию
● Проверить, что Премиум пользователи отменяют резервацию
без штрафов
● Проверить, что все Не Премиум пользователи платят 10%,
если отменяют резервацию меньше чем за 24 часа
● Проверить, что все пользователи получают уведомления по
e-mail
● Проверить, что Отели уведомляются об отмене резервации


Айсберг требований


Истории, Темы и Эпосы


Хорошие Истории – это INVEST
 Independent - Независимые
должна быть возможность приоритизировать истории независимо одну от
другой

 Negotiable - Обсуждаемые
Истории – лишь напоминание - обсудить детали, когда придет время. Не
думайте о них, как о спецификации или контракте

 Valuable - Ценные
Каждая история должна иметь ценность для пользователя

 Estimatable - Оцениваемые
должно быть достаточно информации, чтобы оценить каждую историю

 Sized appropriately - Соразмерные
Комплексные истории тяжело оценить, а связанные тяжело
приоритезировать
Спасибо William Wake за
 Testable - Тестируемые акроним
Нужно четко знать, когда история закончена www.xp123.com

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

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


Неудачная спецификация
 Спецификация по стандарту IEEE 830:
1. Продукт должен иметь бензиновый
двигатель
2. Продукт должен иметь четыре колеса
 Продукт должен иметь резиновые покрышки на
каждом колесе
3. Продукт должен иметь рулевое колесо
4. Продукт должен иметь металлический корпус

 И что мы строим?
Источник: The Inmates are Running the
Asylum by Alan Cooper (1999).

Об источниках информации...

 Майк Кон
 Agile Estimating and Planning
User Stories Applied

 http://www.mountaingoatsoftware.com/articles-
user-stories


Вопросы? 

Если у нас осталось время, мы можем
обсудить интересующие вас вопросы


SCRUM:open - Управление требованями в Agile проектах

More Related Content

Similar to SCRUM:open - Управление требованями в Agile проектах

More from Timofey (Tim) Yevgrashyn

SCRUM:open - Управление требованями в Agile проектах