Мы продолжаем разговор об особенностях применения Scrum в заказной разработке и в этой статье я расскажу, как скрестить управление рисками и Agile.
В заказной разработке появляются дополнительные потенциальные проблемы, связанные с заказчиком и его бизнесом, поэтому управление рисками становится критически важным. Традиционный Scrum не содержит такой дисциплины, поэтому необходимо адаптировать классические подходы по управлению рисками, не забывая про принципы Agile.
Хотя выделенных практик по управлению в Scrum’е нет, надо отметить, что как любая итеративная и инкрементальная методология, Scrum значительно снижает риски за счет получения раннего фидбека от заказчика. Еще в Scrum'е есть очень хорошая практика проведения ретроспектив в конце спринта, она поможет выработать реакцию на риски, но к сожалению реактивную, после того, как риски реализовались.
Работа с рисками ведется в несколько этапов, которые изображены на этой схеме:
Первый мозговой штурм по рискам можно включить в нулевой спринт (кстати, его можно провести в виде инновационной игры Speed Boat), и затем каждый спринт проводить дополнительный анализ и вырабатывать контрмеры. Отмечу, что контрмеры должны быть именно превентивными, так получается дешевле :) Но ни в коем случае не делайте больше, чем надо, свято соблюдая принципы KISS и YAGNI. В мозговом штурме могут участвовать и представители заказчика, озвучивая своё видение возможных проблем.
Для стимуляция мозгового штурма крайне рекомендую использовать один из следующих риск-воркшопов:
- SEI Taxonomy-Based Risk Identification – таксономия рисков и опросник от Software Engineering Institute
- Дисциплина Управления Рисками MSF вер 1.1 – более легковесная версия категоризации софтверных рисков от Microsoft
Риски надо визуализировать, чтобы их знала вся команда (и заказчик) и полноценно участвовала в управлении ими. Самый плохой вариант сделать Excel-файл с рисками (в самом укромном уголке) и при факапе сказать: «Этот риск у меня есть в реестре под номером 37». Самый «аджайльный» вариант – сделать доску с рисками и отслеживать их жизненный цикл.
Но рисками важно не переборщить, особенно привлекая к этой работе заказчика, ведь ему и команде может показаться, что проект состоит из одних потенциальных проблем. Очень ярко эта ситуация проявляется в командах, которые до этого не проводили подробный анализ рисков, а просто с завязанными глазами наступали на грабли.
Давайте чуть подробней остановимся на этапе анализа и приоритезации рисков. Мы договорились делать процесс максимально простым, поэтому предлагаю найти золотую середину между качественной и количественной оценкой рисков. Количественные оценки и математическое моделирование – вещь достаточно условная и необходимо хорошо понимать свойства построенной модели.
Возьмем только три градации для оценки вероятности и угроз (сколько ущерба он принесет) риска, при этом не будем использовать денежные оценки:
Безусловно, максимум внимания необходимо уделить «красным» рискам, мало того, что они наиболее вероятны, но и ущерб от них обещает быть максимальным.
Активности, связанные с оперативным мониторингом рисков и коррекцией последствий очень удобно проводить на ежедневных стендапах: теперь команда будет оперировать не виртуальными проблемами, а конкретными рисками.
Что касается Lessons Learned, то для этого просто идеально подходит ретроспектива. Только замечу, что эти уроки и лучшие практики также необходимо распространять между командами, например, на Scrum of Scrum.
Автор: Борис Вольфсон — Руководитель департамента разработки Softline
