Введение
Управление рисками является неотъемлемой частью как классического, так и гибкого управления проектами. Управление рисками позволяет своевременно увидеть отклонения в реализации проекта и избежать нежелательных событий. Руководство по Scrum содержит лишь общее заявление о рисках в таких областях, как продолжительность спринтов и прозрачность артефактов (отдельных результатов работы). Как это часто бывает в управлении проектами, процедуры, используемые на практике, обсуждаются в Scrum-сообществе, обобщаются и только после этого включаются в Руководство по Scrum.
Цель исследования – проанализировать особенности управления рисками Scrum-проектов.
Материалы и методы исследования
Управление рисками включает процессы идентификации, анализа, обработки, мониторинга и контроля рисков.
Риски представляют собой события, вызванные случайными причинами и приводящие к отклонениям от ожидаемых целевых значений проекта. Отклонения могут быть как отрицательными («опасности/риски»), так и положительными («возможности») [1].
Рис. 1. Процедуры управления рисками
Рис. 2. Пример реестра рисков
В отличие от рисков, которые могут реализоваться (или не реализоваться) в будущем, проблемы и нарушения всех видов, мешающие отдельным членам команды (или даже всей команде) эффективно выполнять свои задачи, уже произошли и должны быть устранены. Методология Scrum неявно предполагает определенные механизмы, позволяющие снизить риски при разработке продуктов, услуг и процессов. Например, после каждого спринта делается его обзор и проверяется развитие продукта. Риск ограничивается длиной одного спринта [2].
Стратегия «быстрого провала» (fail fast) – это целенаправленный подход, при котором в ходе работы над задачей или продуктом, быстро осуществляется обратная связь и принимается решение о продолжении работы или использовании другого подхода (Inspect&adapt). Если проект идет не лучшим образом, то это следует понять как можно раньше, чтобы не тратить на провальный проект драгоценного времени и денежных ресурсов. Информация о невыполненной работе по продукту должна приоритизироваться в соответствии с уровнем риска, чтобы важную информацию можно было обрабатывать быстрее и тем самым снижать риск.
Значимым аспектом контроля рисков в Scrum является прозрачность. Scrum основан на всесторонней прозрачности артефактов (результатов работы, включая развитие продукта). «... Решения по оптимизации стоимости и управлению рисками принимаются на основе установленного состояния артефактов...» [2]. Достигается ли действительно всеобъемлющая прозрачность, можно определить, анализируя закономерности и обнаруживая расхождения между ожидаемыми и фактическими результатами.
Задачи, роли, обязанности в управлении рисками проектов в рамках Scrum
Управление рисками осуществляется всей командой Scrum, состоящей из владельца продукта, Scrum-мастера и разработчиков. Однако описание ролей и соответствующего круга задач приводят к появлению различных центров управления рисками.
Владелец продукта несет ответственность за его экономический успех и должен максимизировать ценность продукта, полученного в результате работы команды проекта. Владелец организует, управляет и расставляет приоритеты невыполненных работ, таким образом, оказывает большое влияние на управление рисками. Он находится в постоянном контакте со многими заинтересованными сторонами и обладает множеством источников идентификации рисков.
Scrum-мастер обеспечивает соблюдение правил Scrum, помогает понять и запустить методологию Scrum, выбирает подходы к созданию максимальной прозрачности артефактов, т.е. помогает снизить риски. Причины должны быть устранены до того, как они приведут к рисковому событию.
Команда разработчиков как самоуправляемая, самоорганизующаяся команда отвечает за выполнение требований к продукту. Все возникающие риски должны быть идентифицированы командой.
Основные процедуры управления рисками
Систематическое управление рисками включает в себя следующие процедуры (рис. 1) [3].
Необходимо создать реестр рисков и регулярно вести его, как на начальных этапах существования проекта, так и на протяжении всего жизненного цикла (рис. 2).
Стратегии реагирования на риски
Существуют следующие основные стратегии реагирования на риски:
• избежание риска (исключение вероятности возникновения риска);
• уменьшение риска (уменьшение вероятности возникновения и/или последствий возникновения рисковой ситуации);
• передача риска третьим лицам (например, субподрядчикам);
• страхование риска;
• принятие риска [4].
Результаты исследования и их обсуждение
Управление рисками в методологии Scrum начинается одновременно с инициацией проекта.
Управление рисками можно разделить на первичное управление рисками и текущее управление рисками (рис. 3).
Первичное управление рисками
Каждый проект/разработка продукта по методологии Scrum начинается с идеи, признанной или предполагаемой потребности частного клиента или юридического лица. Уже на этапе инициации проекта следует провести первоначальную оценку риска.
Это может быть осуществлено, например, на рабочем совещании по анализу рисков с соответствующими заинтересованными сторонами.
Среди прочего необходимо учитывать следующие источники риска.
Рис. 3. Жизненный цикл Scrum-продукта
Рис. 4. Возможные категории рисков Scrum-проектов
Слишком глубокий маркетинговый анализ может привести к позднему выходу на рынок. Маркетинговые исследования, изучение долей рынка, показателей продаж, прогнозы прибыли и т. д. не заменят разработки минимально жизнеспособного продукта и получения быстрой обратной связи с клиентами/ пользователями. Риски и неопределенность останутся неотъемлемой частью каждого инновационного продукта.
Нельзя с полной уверенностью утверждать, что потребности клиента точно известны. Очень часто время и деньги вкладываются в продукты, которые никому не нужны.
При проектировании желательно предусмотреть развитие минимально жизнеспособного продукта (прототипа), увеличение его функциональности.
Рассмотрим возможные категории рисков Scrum-проектов (рис. 4).
В рамках инициации Scrum-проекта и первичного управления рисками создается бэклог (портфель) работ по продукту. Он представляет собой постоянно корректируемый, упорядоченный перечень всех предстоящих работ и служит единственным источником требований по изменениям в продукте.
Атрибутами невыполненной работы являются, в том числе, приоритет и оценка стоимости (бизнес-стоимости). Атрибутом может быть также идентифицированный риск. В первую очередь, разрабатываются наиболее ценные и рискованные функции продукта. При этом часто используется стратегия «быстрого провала».
В Scrum-проектах существует дополнительный источник риска, а именно кросс-функциональная и самоорганизующаяся команда разработчиков, обладающая необходимыми навыками и доступностью на время решения задач проекта.
Текущее управление рисками
Текущее управление рисками: отправные точки (рис. 5)
Обычно в спринте команда основное внимание уделяет продукту, а систематическое управление рисками часто не осуществляется вообще или осуществляется недостаточно эффективно.
Отправная точка 1 – Планирование спринта
Scrum-команда определяет продолжительность спринта индивидуально, в зависимости от продукта. Продолжительность может составлять от 2 до 4 недель, она не может меняться по ходу выполнения проекта.
Рис. 5. Отправные точки управления рисками в Scrum-проектах
Если спринт очень продолжительный, то он может оказаться весьма сложным и, соответственно, рискованным. Цель спринта, согласованная Scrum-командой в соответствии с принципами SMART (конкретная, измеримая, достижимая, разумная, ограниченная по времени), дает четкое представление о том, как должно выглядеть приращение продукта [4]. В бэклог спринта могут входить только требования из бэклога продукта, которые соответствуют статусу «готовые к разработке» (Definition of Ready – DoR). Разбивка требований на отдельные задачи также дает возможность идентификации рисков. План реализации спринта определяет способ создания приращения продукта в спринте. Обеспечение высокого уровня прозрачности снижает потенциал риска для разработки продукта.
Отправная точка 2 – Спринт
В спринте могут возникнуть социальные риски, которые являются результатом самоорганизации, а также межличностного сотрудничества, присущего каждой команде.
Во время спринта часто появляются препятствия (барьеры), мешающие достижению цели. Здесь важно быстрое вмешательство Scrum-мастера, чтобы препятствия не становились источником риска. Ежедневное ведение доски задач обеспечивает максимальную прозрачность текущего процесса и позволяет относительно быстро выявлять нежелательные события.
Определение DoR отчасти ограничивает риски потенциальной потери качества.
Отправная точка 3 – Обзор спринта
При обзоре спринта проверяется приращение продукта. Заинтересованные стороны (заказчик пользователь, Scrum-команда, маркетологи, продавцы и т. д.) проверяют технические/функциональные возможности, а также оценивают экономические и экологические свойства продукта. Подход Scrum «Проверка и адаптация» позволяет быстро корректировать качество продукта, что снижает соответствующие риски его успеха. Например, экономический риск ограничивается продолжительностью спринта, если заинтересованные стороны считают, что разработка продукта не должна быть продолжена, например, из-за изменившихся условий окружающей среды.
Отправная точка 4 – Ретроспективный анализ спринта
При ретроспективном анализе спринта процессы, инструменты, сотрудничество в команде и т. д. критически оцениваются и ищутся пути оптимизации, которые могут быть реализованы в следующем спринте. Этот шаг также помогает постоянно снижать возможные риски, так как ретроспективный анализ проводится после каждого спринта.
Выводы
Гибкая методология управления проектами Scrum неявно предполагает механизмы снижения риска, однако мы настоятельно рекомендуем проведение систематического управления рисками. Особенно на этапе инициации проекта первичное управление рисками может помочь принимать правильные решения и выявить наиболее подходящий путь достижения целей.