Хорошие новости … для сторонников классического подхода к управлению проектами. Если вам не понятны Ценность, Прозрачность, WIP, то для вас в Agile легко найти все этапы процесса – которыми так сильны традиционные методы!
Итак начнем с шага – Идентификации рисков. На этом этапе нам важны две составляющие:
Максимально вовлечь команду (да,да – команду!) в процесс идентификации
Сделать этот процесс нескучным но эффективным
В своей практике мы начали использовать – игровые практики, такие как «Doomsday clock». Более того, помимо рисков подобная игра полезна для генерации возможностей – положительных рисков, которые надо развивать в проекте («Karmas day»).
Суть игры простая – Используя нарисованный циферблат (на доске или флипчарте), мы просим, чтобы члены команды генерировали риски, связанных с каждой из тем, представленных линией часа на часах. Далее члены команды размещали полученные риски стикерами на циферблате. Результат – первичная картина рисков в проекте. Важно – то что генерирует их команда, а значит нам удалось частично передать ей ответственность за риски.
Знаю, что многие команды использую оценки вероятности для рисков. Но как сложно проводить оценку в абсолютных единицах. Как сложно определить вероятность, что произойдет тот или иной риск? Лучше использовать практику использования относительных оценок (аналогичную оценке user story в бэклоге). На мой взгляд такой относительный способ более простой и интуитивным. Нас не интересует числовой параметр (значение) риска.
Вместо этого мы измеряем риски (возможности) относительно друг друга и располагаем по осям. Здесь важно – не количественная составляющая – а то что все члены команды в течении всего процесса проводят анализ вместе. И вместе располагают риски относительно друг друга – теперь еще одну цель достигли – все члены команды одинаково понимают риски в проекте.
После проведения качественного анализа рисков мы проводим количественный анализ. Мы используем оценку ожидаемой стоимости Рисков. Это работа позволяет нам перевести Риски в денежный эквивалент, а значит появляется возможность приоретезировать наравне с user story в бэклоге. И определять затраты на минимизацию и/или реакцию на риски.
Как только команда определила действие на минимизацию и/или реакцию на риск – мы можем помещать это действие в бэклог и приоритезировать наравне с пользовательскими историями. И теперь Product owner и команда будут договариваться: “Что мы будем делать в следующей итерации: реализуем требование или снижаем проектный риск? ” .
Возьмите за правило работать с рисками в каждой итерации. Помещая риски (вернее реакцию или действия по снижению риска) вы получаете неоценимые преимущества по сравнению с классическим подходом:
Вы всегда проактивны по отношению к рискам
Регулярно пересматриваете/приоритезируете риски относительно пользовательских историй
Не делаете лишнюю работу по управлению “ненужными” рисками – помним про Lean-подход
Вся команда владеет списком рисков на текущую итерацию
Используйте Risk burn-down диаграммы для оперативного мониторинга
А где обсуждать риски? Где найти место работы с рисками? Что вы слышали о проведении Ретроспективы для рисков? Как показала практика, сложно выделить отдельное мероприятие для рисков. И обсуждать риски на отдельной ретроспективе очень сложно. Наше предложение – найдите время для работы с рисками на грумминге (Product Backlog Refinement)! Выделяйте 15 минут работы с рисками на грумминге , делайте обзор и сразу планируйте анализ (spike) в итерацию.
Итак, мы разобрались. Риски есть в ЛЮБЫХ, в том числе в ИТ проектах. Так почему же мы считаем, что в Agile рисков “нет”?
Конечно, не потому, что Аджайл очень крут, работает на небольших проектах и некому брать ответственность за риски. Просто Управление рисками уже “зашито” в Agile: инкрементально-итеративный подход, быстрые циклы обратной связи – все то, что есть в Манифесте.