Agile Requirements Management

Подходы гибкого управлениятребованиями в бизнес-

ориентированных проектах

www.scrumguides.com

© Alexey Krivitsky

Доклад для UA-Web , 27-28 марта 2008

2

Немного о себе

Java, .NET разработчик с 1999Team lead с 2002ScrumMaster с 2005

Украинское сообщество Agilewww.agileukraine.org

Методологический сайт о SCRUMwww.scrum.com.ua

Мы помогаем внедрить SCRUMwww.scrumguides.com

3

Контекст и терминология доклада

Подходы гибкого управления требованиями в бизнес-ориентированных проектах.

Под бизнес-ориентированными проектами мы понимаем такиепроекты, в которых требования с большой вероятностью будутизменяться в ходе проекта по причинам, не зависящих откачества планирования или проработки требований на раннихэтапах проекта.

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

4

О чём мы будем говорить

1. Традиционные подходы управления требованиями.

2. Сложность управления требованиями.

3. Истории (user stories) как механизм гибкого управлениятребованиями.

4. Применение историй в SCRUM проектах.

5. Приоритезация требований.

6. Визуализация управления требованиями.

5

Управление требованиями. Что это?

«The purpose of Requirements management is to manage the requirements of a project and to identify inconsistencies between those requirements and the project's plans and work products.»

www.wikipedia.org

6

Как мы говорим об управлениитребованиями...

«Когда все требования будут специфированы иоценены, мы сможем подписать контракт иприступить к годичному планированию».

«Так как ни вы ни мы точно не знаем, как должнавыглядеть система, то мы предлагаемразрабатывать продукт короткими фазами – отпрототипа к реальному продукту».

7

Взаимосвязи

Когда мы говорим об управлении требованиями, мытакже подразумеваем определённый процесспланирования и разработки проекта.

То есть эти тесно взаимосвязанные вещи.

9

Традиционные подходыуправления требованиями

Предписывают составлениемногостраничных многоуровневыхспецификаций на ранних этапах проектов:

– Детализированные ТЗ;– Product Requirement Documents (PRD);– Software Requirement Specifications (SRS);– Use-case модели.

10

Особенности таких подходов

Требования «готовятся» специально обученнымиспециалистами.На сбор и документацию требований отводитсяотносительно много времени.Документы с требованиями имеют высокую степеньпроработки.

Плюсы:Отсекаются «сырые» проекты.Заказчики и исполнители прорабатывают и продумываюттребования.Происходит первичная сработка заказчика и исполнителя.Прорабатываются концептуальные моменты (риски).

11

Неопределенность является неотъемлемой и неизбежной вобласти разработки продуктов ПО (Ziv’s Uncertainty Principle)

Питер Вагнер продемонстрировал, что невозможнополностью определить интерактивную систему, котораяпризвана реагировать на внешние воздействия (Wegner's lemma)

Для новой системы ПО требования не будут полностьюизвестны до того как пользователи смогут опробовать этусистему (Humphrey’s Requirements Uncertainty Principle)

Но есть «но»...

12

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

Как следствие...

13

Основные причины

Заказчика принуждают «заказать» больше, чем ему нужно.Зачастую отсутствует понимание приоритетов требований.Реальные нужды пользователей перемешаны спредлагаемыми решениями.Создаётся ощущение полноты требований.Команды разработчиков оторваны от контекста продукта, что мешает им принимать адекватные решения.Из-за изменчивости нужд заказчика детальнопроработанные требования возможно не войдут в конечныйпродукт.

Как же решить эти проблемы?

15

Требования к требованиям

Для того, чтобы решить описанные проблемы, требования должны быть:

1. Должны описывать нужду конечногопользователя.

2. Не должны быть перегружены деталями.

3. Описаны в виде приоритезированного списка.

4. Их не должно быть слишком много (!)

16

“User stories”Пользовательские истории.

Это набор высказываний о системе в виде:

As a <user>, I can <do> so that <value>.

17

Примеры историй для сайта UA-Web

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

Как посетитель, я могу зарегистрироваться, чтобы оплатить участие в конференции.

Как гость, я могу посмотреть прямуютрансляцию докладов.

18

Переделайте истории

Сайт должен предоставлять пользователямрасписание докладов.

Все данные, вычитываемые из бекенда, должныбыть закешированы.

Реализовать подсистему отображениярекламных баннеров для реализации программыприбыльности сайта.

19

INVESTируем в хорошие истории

Independent – быть независимыми одна от одной.

Negotiable – оставлять место для дискуссий.

Valuable – нести ценность.

Estimatable – быть оцениваемыми.

Sized properly – быть адекватного размера.

Testable – быть тестируемыми.

20

Детали нужны. Как же мы без них?Нужны также и критерии приёма истории (тесты). Иначе как мы знаем, что история готова?

«Как посетитель, я могу зарегистрироваться, чтобыоплатить участие в конференции»

Детали:– Оплата может быть произведена от физ. или юр. лица.– Оплатить можно только за одного участника.Тесты:

– После регистрации посетитель получает сгенерированный счет.– Статус посетителя меняется на «счёт выставлен».

Детали и границы историй

21

Детализация требований «на лету»

Из презентации Майка Кона (Mike Cohn) “Prioritizing your backlog”

22

Что более оптимально?

V VV

2009

Q3/4 2008

Q2 2008

Q1 2008

Dec 2007

Nov 2007

V

2008

2009

2010

2011

23

Применение историй в SCRUM проектах

24

Пример беклога с историями

Sprint User Story Tests Details

sprint NAs a normal user I can securely enter the site

1. Extended menu is active2. Imported users can log in3. Expired users can't log in

Use https for login page User enters email and password

sprint NAs a normal user I can enter new meetings

1. New meetings appear in the list with all typed fields2. After re-login the meetings are preserved

Meeting data is: summary, details, datetime, place

sprint N+1

As a normal user I can browse through my meetings

1. The list contains all meetings sorted by datetime2. Meetings in the past are not showed.

Sort by datetimeEnable paging, 10 p.p

25

Приоритезация историй

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

26

Один из подходов приоритезации

Группы историйОтносит.выгода

Относит.штраф Ценность Ценность %

Относит.стоимость Стоимость % Приоритет

управление аккаунтами 8 6 14 40% 64 44% 0,9

обработка изображений 9 2 11 31% 40 27% 1,1

нотификации 1 9 10 29% 42 29% 1,0

Ценность = (Относит. выгода) + (Относит. штраф)

Приоритет = (Ценность%) / (Стоимость %)

27

Визуализация управления требованиями

Release Burndown

17851620

713512

324155 228 175

0200400600800

100012001400160018002000

1 2 3 4 5 6 7 8

Итерации

Оценки

29

Спасибо! Вопросы?

Alexey Krivitskyalexeykrivitsky@gmail.comwww.agileukraine.orgwww.scrumguides.com