Надеюсь, я не раскрою каких-то секретов.

В рамках конференции CEE-SECR 2009 я и мои коллеги по работе участвовали в игре-симуляции "Управление требованиями по Agile", проводимой Асхатом Уразбаевым и Никитой Филипповым.

Игра проходила так.

Было несколько столов по 6 человек. Каждой команде были выданы:
1. видение в некоторой формальной форме
2. шаблоны для описания персонифицированных ролей
3. стикеры
4. карточки с обязательными работами
5. кубик (кости)

Асхат или Никита делали некоторое объяснение по каждому этапу. Затем включался счетчик и команда должна за короткий период выполнить некоторую задачу.

1 этап заключался в выделении бизнес-драйверов. Так я узнал совершенно новый термин. Оказывается всякие бизнес-цйели, требования или потребности принято называть емким словом бизнес-драйвер. Итак наша задача заключалась в поисках 3 таких бизнес-драйверов.

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

Как потом оказалось наш бизнес-драйвер оказался ошибочным. Мы определили его так Сделать решение, чтобы получить полный бюджет. Можете ли вы сказать, а что должно было послужить определяющим бизнес-драйвером в этом случае?

2 этап заключался в выдлении о описании персонифицированных ролей. Нужно было выделить 4 роли и дать им описание:
Имя, описание роли, ценности роли. Т.е. нужно было представить определенного человека и дать его описание. Например:
Верующий Сергей. 30 лет, работник завода химических удобрений, женат, имеет двоих детей, не курит, не пьет. Православен. Ценности: Семья, Признание, Общение с единомышленниками ...

3 этап заключался в описании пользовательских историй в формате: Как <пользователь>, я могу <действие>, для того, чтобы <цель>. (Подробнее смотри статью User Stories, часть 1) Нужно было написать не меньше 4 историй.

4 этап заключался в приоритезации и оценке трудоемкости реализации каждой истории. В настоящей практики трудоемкость оценивалась в 10 балльной шкале. А приоритезация относилась к тому, как история помогает достигнуть поставленную цель - бизнес-драйвер. В игре мы заменили это бросанием костяшки. Сколько очков выпадало - столько и записывали

5 этап - планирование релиза и итераций. Каждая итерация равнялась 18 поинтов и должна была занимать 3 недели.  Общее количество требований и расставленных баллов + 4 работы, связанных с развертыванием сервера БД и хоста для проекта и для тестирования давало, что наш релиз мог появится не раньше 4 месяцев.

Итак мы составили первую итерацию, как поступила вводная, что первую итерацию вследствие разных причин урезаетсядо 9 поинтов. Потребовалось перепланировать итерации. Посколько срок релиза жестко лимитрован, то нужно было принять решение - какую функциональность можно временно убрать из первого релиза.

Agile методика по словам Асхата в этом случае предполагает возможность пересмотра всего пула историй и даже видения, если обнаружены неточности, несоотвествия, или доверие к информации, изложенной в видении, сильно подорвано

На этом игра закончилась, так формат времени не позволял ее продолжать. К сожалению разбора полетов практически не было. Но нас пригласили принять участие в тренинге с 20% скидкой

1 этап заключался в выделении бизнес-драйверов. Так я узнал совершенно новый термин. Оказывается всякие бизнес-цйели, требования или потребности принято называть емким словом бизнес-драйвер. Итак наша задача заключалась в поисках 3 таких бизнес-драйверов.

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

Как потом оказалось наш бизнес-драйвер оказался ошибочным. Мы определили его так Сделать решение, чтобы получить полный бюджет. Можете ли вы сказать, а что должно было послужить определяющим бизнес-драйвером в этом случае?

IMHO "бизнес-драйвер" определяет некий базовый интерес заинтересованных лиц (заказчика). Грубо говоря, отвечает на вопрос "Зачем вся эта хрень нужна?". Ответ типа "сделать решение" больше характерен для исполнителей и по большому счету соответствует сентенции "чтобы было" (... а там что хотите с этим, то и делайте, главное заплатите за него...)

От обсуждавшейся тематики я довольно далек, но в наше время всеобщей клерикализации предположу (как говорится "чую, но обосновать не могу"), что интересами подобного рода могли бы быть:
 - общей прирост "клиентской базы" или какой-нибудь удельный ее прирост за период
 - увеличение среднего времени взаимодействия (или количества обращений) "клиента" с "церковью"
 - рост числа совершенных обрядов, сделок по атрибутике, литературе (возможно объема полученных средств)
 - увеличение количества упоминаний, ссылок и т.п. на создаваемый ресурс (или просто количества "выложенных публикаций", количества уникальных хостов и т.п.)

- популяризации церкви среди интернет пользователей...

Вот, что сказал Асхат. А сказал он примерно следующее:
- Представьте, что это ваши деньги. Вы хотите понять стоит ли их вкладывать в этот проект. Вы тратите определенную сумму (в нашем случае что-то типа 300000). И если к концу отведенного вам периода вы понимаете, что это плохо, то вы сэкономите в 8 раз больше.

Типа это и может быть бизнес-драйвером в данном ситуации (если я, конечно, правильно понял критику)

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

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

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

---

"Было выделено определенное количество денег и 3 месяца для того, чтобы понять эффективность таких мер."
Т.е. не систему надо было создавать, а "рынок" человеческих душ исследовать.

Да, один из методов - создать прототип "сайта" для единомышленников.

Но IMHO - это изобретение велосипеда. Между тем, "велосипед" уже есть, нужно просто понять, сколько человек готовы на нём "кататься". Я бы взял какой-нибудь существующий церковный сайт, и в течение 2,5 мес. активно его "раскручивал" - баннеры на улицах и на сайтах, социальная реклама на ТВ, плакаты, брошюры. А затем, в течение оставшихся 0,5 мес. исследовал бы, как это отразилось на посещаемости сайта, а также изменение посещаемости церквей и общей соц. обстановки в районе рекламной компании среди её целевой аудитории и семей представителей этой целевой аудитории. Да и то, срок, конечно, маловат.

---

"Было сказано также, что над подобной проблемой работают конкуренты."
Обратите внимание, проект - некоммерческий, не для денег, а для того, чтобы принести людям пользу. Сродни FOSS, но сильнее ориентирован на пользу людям.  Люди в рамках такого проекта - "вольноопределяющиеся". Если докажете, что ваша идея лучше - "конкуренты" к вам примкнут.

---

Вообще, я бы посоветовал Асхату и Никите не приводить примеров работы на некоммерческой основе. Особенно связанных с верой и церковью. Уж лучше web-магазин или АСУ склада. Работа на благо людям как цель не укладывается в достижение американской мечты.

---

То, что было - судя по описанию, про управление проектом, а не про управление требованиями, и в сильно упрощённом виде. Оценка - не методикой (COCOMO II или IFPUG FPA, например), а киданием "костей". Ресурсов - предостаточно (4*10<3*18), ничего не резали. US между собой не связаны. Риски не прорабатывались. SCRUM-команда - одна. Работа - чистой воды каскад (каламбур?), спланировали и поехали. А где же обязательный в этом случае для agile батюшка on-site?

Самое интересное же с управлением требованиями IMHO происходит не при инициации и планировании, которые были разобраны, а при выполнении, контроле и закрытии, про которые здесь - ни слова. А как полетят к вам запросы, распоряжения, отвлечения людей на другие проекты, "напихивания" в текущую итерацию дополнительной функциональности против всех правил SCRUM, как выяснится, что 1-ю US нельзя реализовать раньше последней, как взыграют людские амбиции (каждый захочет показать богатство своего внутреннего мира) и встанет человеческий фактор в полный рост - всё с требованиями станет куда интереснее.

Небольшой оффтоп:
Прочитал тут биографию Исаака Зингера. Так вот, он (его корпорация) был в своем роде первоначальником многих приемов рекламы, в том числе он понял, что рекламировать швейные машинки в газетах не дает нужного результата, т.к. их домохозяйки не читают, и начал рекламировать свой товар в публичных местах и на листовках, которые раздались в церкви

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

Алекс, я не специалист в Agile, возможно я не специалист в понимание управления требованиями. Я в данном случае рассказал, то что нам рассказывали, то как я это понял. Я мог и не понять. В чем тут конкретно Agile? Вопрос к Асхату

Но, управление или все-таки лучше говорить об цикле управления, предполагает следующие функции управления (по Файолю или любые другие концепции):
Сбор, учет, контроль, анализ, прогнозирование и планирование, оперативное управление, доведение решения.

Между учетом и ОУ возникает цикл через обратную связь.

На мой взгляд вопросы управления требований тут затрагиваются.

Ну и естественно за 1.5 часа сделать многое не так просто, тем более учитывая, что люди, сидящие за столом были до этого мало или вообще не знакомы друг с другом