РискивAgile-проектах.Часть2.RiskDrivenDevelopment

Хорошие новости …  для сторонников классического подхода к управлению проектами. Если вам не понятны Ценность, Прозрачность, WIP, то для вас в Agile легко найти все этапы процесса –  которыми так сильны традиционные методы!

Идентификации рисков. «Doomsday clock» vs. «Karmas day»

Итак начнем с шага – Идентификации рисков. На этом этапе нам важны две составляющие:

• Максимально вовлечь команду (да,да – команду!) в процесс идентификации

• Сделать этот процесс нескучным но эффективным

В своей практике мы начали использовать – игровые практики, такие как «Doomsday clock». Более того, помимо рисков подобная игра полезна для генерации возможностей – положительных рисков, которые надо развивать в проекте («Karmas day»).

Суть игры простая – Используя нарисованный циферблат (на доске или флипчарте), мы просим, чтобы члены команды генерировали  риски, связанных с каждой из тем, представленных линией часа на часах. Далее члены команды размещали полученные риски стикерами на циферблате. Результат – первичная картина рисков в проекте. Важно – то что генерирует их команда, а значит нам удалось частично передать ей ответственность за риски.

Следующий шаг – оценка

Знаю, что многие команды использую оценки вероятности для рисков. Но как сложно проводить оценку в абсолютных единицах. Как сложно определить вероятность, что произойдет тот или иной риск? Лучше использовать практику использования относительных оценок (аналогичную оценке user story в бэклоге). На мой взгляд такой относительный способ более простой и интуитивным. Нас не интересует числовой параметр (значение) риска.

Вместо этого мы измеряем риски (возможности) относительно друг друга и располагаем по осям. Здесь важно – не количественная составляющая – а то что все члены команды в течении всего процесса проводят анализ вместе. И вместе располагают риски относительно друг друга – теперь еще одну цель достигли – все члены команды одинаково понимают риски в проекте.

Количественный анализ

После проведения качественного анализа рисков мы проводим количественный анализ. Мы используем оценку ожидаемой стоимости Рисков. Это работа позволяет нам перевести Риски в денежный эквивалент, а значит появляется возможность приоретезировать наравне с user story  в бэклоге. И определять затраты на минимизацию и/или реакцию на риски.

Реакция. Помещение в бэклог и работа в каждой интеграции

Как только команда определила действие на минимизацию и/или реакцию на риск – мы можем помещать это действие в бэклог и приоритезировать наравне с пользовательскими историями. И теперь Product owner и команда будут договариваться: “Что мы будем делать в следующей итерации: реализуем требование или снижаем проектный риск? ” .

Возьмите за правило работать с рисками в каждой итерации. Помещая риски (вернее реакцию или действия по снижению риска) вы получаете неоценимые преимущества по сравнению с классическим подходом:

• Вы всегда проактивны по отношению к рискам

• Регулярно пересматриваете/приоритезируете риски относительно пользовательских историй

• Не делаете лишнюю работу по управлению “ненужными” рисками – помним про Lean-подход

• Вся команда владеет списком рисков на текущую итерацию

• Используйте Risk burn-down диаграммы для оперативного мониторинга

Мониторинг и контроль. Product Backlog Refinement

А где обсуждать риски? Где найти место работы с рисками? Что вы слышали о проведении Ретроспективы для рисков? Как показала практика, сложно выделить отдельное мероприятие для рисков. И обсуждать риски на отдельной ретроспективе очень сложно. Наше предложение – найдите время для работы с рисками на грумминге (Product Backlog Refinement)! Выделяйте 15 минут работы с рисками на грумминге , делайте обзор и сразу планируйте анализ (spike) в итерацию.

Заключение

Итак,  мы разобрались. Риски есть в ЛЮБЫХ, в том числе в ИТ проектах. Так почему же мы считаем, что в Agile рисков “нет”?

Конечно, не потому, что Аджайл очень крут, работает на небольших проектах и некому брать ответственность за риски. Просто Управление рисками уже “зашито” в Agile:  инкрементально-итеративный подход, быстрые циклы обратной связи – все то, что есть в Манифесте.

Что почитать

1. Managing Risk on Agile Projects with the Risk Burndown Chart
2. New Approaches to Risk Management
3. Five Simple Steps to Agile Risk Management
4. Risk Driven Development
5. Agile: pragmatic tools for managing risk in projects