Как скрестить управление рисками и Agile?


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

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

    Хотя выделенных практик по управлению в Scrum’е нет, надо отметить, что как любая итеративная и инкрементальная методология, Scrum значительно снижает риски за счет получения раннего фидбека от заказчика. Еще в Scrum'е есть очень хорошая практика проведения ретроспектив в конце спринта, она поможет выработать реакцию на риски, но к сожалению реактивную, после того, как риски реализовались.

    Работа с рисками ведется в несколько этапов, которые изображены на этой схеме:


    Первый мозговой штурм по рискам можно включить в нулевой спринт (кстати, его можно провести в виде инновационной игры Speed Boat), и затем каждый спринт проводить дополнительный анализ и вырабатывать контрмеры. Отмечу, что контрмеры должны быть именно превентивными, так получается дешевле :) Но ни в коем случае не делайте больше, чем надо, свято соблюдая принципы KISS и YAGNI. В мозговом штурме могут участвовать и представители заказчика, озвучивая своё видение возможных проблем.
    Для стимуляция мозгового штурма крайне рекомендую использовать один из следующих риск-воркшопов:



    Риски надо визуализировать, чтобы их знала вся команда (и заказчик) и полноценно участвовала в управлении ими. Самый плохой вариант сделать Excel-файл с рисками (в самом укромном уголке) и при факапе сказать: «Этот риск у меня есть в реестре под номером 37». Самый «аджайльный» вариант – сделать доску с рисками и отслеживать их жизненный цикл.

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

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

    Возьмем только три градации для оценки вероятности и угроз (сколько ущерба он принесет) риска, при этом не будем использовать денежные оценки:



    Безусловно, максимум внимания необходимо уделить «красным» рискам, мало того, что они наиболее вероятны, но и ущерб от них обещает быть максимальным.

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

    Что касается Lessons Learned, то для этого просто идеально подходит ретроспектива. Только замечу, что эти уроки и лучшие практики также необходимо распространять между командами, например, на Scrum of Scrum.

    Автор: Борис Вольфсон — Руководитель департамента разработки Softline
    • +16
    • 12.5k
    • 4
    Softline
    73.68
    Company
    Share post

    Comments 4

      +1
      Это хорошая статья. Интересно только было бы поподробнее почитать о самом определении рисков, хотя это и не относится к аджайлу, но тем не менее вопрос больной. На хабре как раз давно статей таких не было :(
        +1
        Проще извлечь все риски из опыта и приложить к новому проекту:

        Выбор неверной архитектуры
        Устаревание технологических решений
        Потеря ключевых разработчиков (других ролей в коллективе)
        Некомпетентность сотрудников подрядчика
        Сбой аппаратного обеспечения подрядчика
        Нехватка трудовых ресурсов подрядчика
        Неверная оценка сложности проекта
        Слабый менеджмент проекта

        Несоответствие продукта ожиданиям заказчика
        Изменение масштата проекта

        Устаревание аппаратного обеспечения к моменту старта эксплуатации проекта
        Отказ от поддержки технологий вендорами
        Срыв сроков поставки вендором
        Сбой аппаратного обеспечения вендора

        Некомпетентность заказчика
        Нежелание среднего и младшего звеньев заказчика сотрудничать
        Неверный выбор фич заказчиком, неверная их приоретизация
        Запоздалые пожелания заказчика
        Недостаточность технической базы заказчика для эксплуатации проекта
        Превышение заказчиком договоренного объёма работ
        Консервативность любых звеньев заказчика при формулировании требований
        Консервативность среднего и младшего звеньев заказчика при тестировании и внедрении
        Гиперактивность заказчика при тестировании (обычно после пассивности во время ТЗ включается «а прикрыть задницу?»)
        Вымогательство среднего и младшего звеньев заказчика
        Неготовность заказчика к принятию продукта
        Переезд заказчика
        Изменение бизнес процессов или структуры заказчика после утверждения объёмов работ
        Сложности коммуникации со смежными к заказчику контрагентами
        Срыв сроков оплаты заказчиком
        Приостановка финансирования проекта
        Смена руководства заказчика

        и так далее и тому подобное.
        во второй и третьей колонке припишите последствия выстрела рисков, стоимость выстрела рисков.
        в четвёртой вы уж как-то постарайтесь понять к каким рискам склонен текущий заказчик и проект.
        в пятой пишите контр-меры и стоимость конртмер.
          +1
          А потом перепишите табличку в более примитивный формат как указано в статье, если это действительно требуется.
          0
          А всей матрицы рисков (если смотреть сильно издалека, они стандартны для всех проектов) нет?

          Only users with full accounts can post comments. Log in, please.