Risk Stories Seminar. XP Injection. Kiev. Ukraine

Записки о Рисках
www.xpinjection.com
Сергей Поволяшко
27/11/2010

15 лет стажа в IT. Работал по нескольким IT
специальностям (разработчик, системный
администратор, тестировщик). С 2001 года
управляю IT подразделениями и проектами.
Место работы – Team ODC (TODC), LLC. www.
teaminternational.com.
 Менеджер отдела разработки, менеджер
проектов, менеджер IT инфраструктуры
 Принимал лидирующее участие во внедрении
CMMI Level 3
Тренер XP Injection - www.xpinjection.com
Образование, сертификации:
 ХГТУРЭ, 1996.
 Project Management
Professional (PMP), PMI. 2007
 ITIL Foundation V3. 2009
Давайте познакомимся
Сергей Поволяшко

Тезисы
С одной стороны область знаний по управлению рисками
хорошо описана и понятна. Но давайте посмотрим шире, и,
немного со стороны, на разнообразие практик, наблюдений,
связанных с рисками. В общем, записки о Рисках:
 Записка 1. Поразмышляем что же такое риск. И риск ли это
вообще? И какие около рисковые (смежные) области
задействованы? Сравним риск и факт. Поговорим о
шаблонах поведения. Рассмотрим пользу исторических
данных.
 Записка 2. Методологический экскурс. Рассмотрим какие
подходы рекомендуют разные методологии. И поштурмуем
вопрос о том, почему в Agile/SCRUM ничего не говорится об
управлении рисками.
 Записка 3. Визуальное управление рисками. Рассмотрим
простой и понятный инструментарий представления
информации о рисках, ясность ситуации за секунды. 100%-
ная понятность информации.
 Важное дополнение – призы!

Содержание
 Правила игры
 Ваши ожидания
 Напоминание об управлении рисками
 Записка 1. Поразмышляем что же такое риск
 Записка 2. Методологический экскурс
 Записка 3. Визуальное управление рисками

Правила игры
 Активное участие
 Телефоны в беззвучный режим
 Слышим и уважаем другие мнения
 Нет нигилизму
 Нет фанатизму
 Непонятно – спрашивайте
 Призы:
 За лучшую теоретическую подготовку
 За неординарный ответ
 За активное участие

Ваши ожидания
 От семинара ожидаю того, что он будет проведен с упором на практику, обсуждение позитивных и
негативных примеров (принятие решений и ожидаемый результат).
 "Хочу все же, после нескольких вебинаров и семинаров, таки понять зачем нужно _управление_ рисками
НА ПРАКТИКЕ. И как это управление, помогает снизить их вероятность - ведь для ее снижения нужно не
управление, а ресурсы :)"
 Хотелось бы услышать примеры работы с рисками из опыта
 демонстрация практических примеров с рельного применения
 "Ожидаю услышать небольшой теоретический экскурс с проекцией на жизнь, реальные кейсы.
 В описании мероприятия затронута тема рисков и гибких методологий - интересно послушать, актуальная
тема."
 Познакомится с рисками и управлением ими
 Освежить в памяти тему; интересно что еще можно сказать после Де-Марко и Листера
 Получить новый опыт, услышать интересную информацию.
 Понять насколько правильнонеправильно мы управляем рисками у нас
 Услышать реальные подходы к планированию, которые на практике приносили позитивные результаты.
 Управление рисками важная часть процесса разработки ПО. Будет интересно узнать как можно его
интегрировать в Agile/Scrum.
 Улучшить понимание и работу с рисками.
 "Хотелось бы услышать реальные истории.
 Хотелось бы услышать про влияние человеского фактора на оценку рисков, и как с этим бороться."
 Управление рисками в SCRUM - интересная тема для моей практики в роли SM.
 Услышать о лучших практиках риск-менеджента на примере реальных проектов.

Ваши ожидания
Если коротко, то:
 Практическое применение, кейсы
 Познакомиться с управлением рисками или
освежить знания, теоретический экскурс
 Управление рисками и SCRUM
 Зачем это вообще надо

Напоминание
Риск и его характеристики:
 Некоторое событие в будущем
 Оказывает негативное или
позитивное воздействие
 Вероятность
 Последствия
 Причина

Подпроцессы управления рисками:
 Risk Management Approach/Plan
 Risks Identification
 Risk Analysis
 Risk Responses Planning
 Monitor and Control Risks

Артефакты в управлении рисками:
 План управления рисками
 Реестр рисков
 Планы реагирования на риски
 Изменения проектных,
контрактных условий

Участники управления рисками:
Эксперт
Проектная
командаМенеджмент
Заказчик

Группы стратегий по реагированию:
До:
 Avoid
 Mitigate
 Transfer
После:
 Contingent
plans
 Active
acceptance
 Passive
acceptance

Записка 1
Поразмышляем что же такое риск. И риск ли
это вообще? И какие около рисковые
(смежные) области задействованы?
Сравним риск и факт. Поговорим о
шаблонах поведения. Рассмотрим пользу
исторических данных.

Записка 1.
Риск? – > Факт – > План
Анти примеры:
 Интеграция произошла …
 без проблем и …
 вовремя
 При приемке продукта заказчик ...
 согласился-таки с функционалом
 Все вовлеченные в проект + заказчик отвечают на вопросы …
 быстро

Записка 1.
Анти примеры:
 Интеграция произошла …
 без проблем и …
 вовремя
 При приемке продукта заказчик ...
 согласился-таки с функционалом
 Все вовлеченные в проект + заказчик отвечают на вопросы …
 быстро
Такого не бывает! И правда, давайте признаемся, это НЕ
Риски – это ФАКТЫ. Они ДОЛЖНЫ быть в Плане Проекта, в
Product Backlog и т.п.

Записка 1.
Некоторые вещи воспринимаются нами как риски, отсюда:
 Применение практик управления рисками
 Или же, как часто происходит, игнорирование , авось
пронесет
Но, это факты!

Записка 1.
Некоторые вещи воспринимаются нами как риски, отсюда:
 Применение практик управления рисками
 Или же, как часто происходит, игнорирование , авось
пронесет
Но, это факты!
IF Вероятность > 90% THEN
{
Риск = Факт
Create План (работы, ресурсы, время)
Include План в План Проекта
}

Записка 1.
Каков же План:
Интеграция – включаем изначально больше времени; разрабатываем
план интеграции; привлекаем высококвалифицированого специалиста;
собираем среду, близкую к целевой
Приемка продукта – четко определяем критерии приемки; вводим
формальное утверждение требований; используем итерации, прототипы;
вводим поэтапную приемку и оплату; четко обрабатываем запросы на
изменения
Скорость ответа – договариваемся о правилах коммуникации;
документируем факты задержек; эскалируем; формализуем
коммуникации; используем эффективные способы коммуникации

Записка 1.
Риск? – > Шаблон поведения – > Факт – > План
1 2 3 4 5 6 7 8 9 10 11 12
Месяцы
Текучка кадров
Отсутствие по болезни
1 2 3 4 5 6 7 8 9 10 11 12
Месяцы
Нагрузка канала связи
0 3 6 9 12 15 18 21
Часы

Записка 1.
Некоторые вещи воспринимаются нами как неожиданности,
ассоциируемые с рисками:
Вдруг выпал снег, снегоуборочная техника не готова
Ну вот опять все кинулись в отпуск в августе
Верьте или нет, но эти вещи случаются с завидной
регулярностью!

Записка 1.
Некоторые вещи воспринимаются нами как неожиданности,
ассоциируемые с рисками:
Вдруг выпал снег, снегоуборочная техника не готова
Ну вот опять все кинулись в отпуск в августе
Верьте или нет, но эти вещи случаются с завидной
регулярностью!
IF Вероятность_Регулярности > 60-70% THEN
{
Риск = Шаблон поведения
Шаблон поведения = Факт
Create План (работы, ресурсы, время)
Include План в План Проекта
}

Записка 1.
Шаблон «Текучка кадров» - держим руку на пульсе, общаемся;
держим скамейку запасных; вводим человеко-независимость;
критичные люди готовят себе замену
Шаблон «Отсутствие по болезни» - оздоровительные меры
(проветривание, витамины, заболел – сиди дома, и т.д.);
планируем пониженную отдачу; вводим человеко-независимость
Шаблон «Нагрузка канала связи» - все что можно, включая
личные закачки переносим на нерабочее время; наиболее
критичным сервисам – гарантированную полосу пропускания или
отдельный канал; расширяем канал; вводим политики
пользования

Записка 1.
Риск? – > История – > Прогноз – > Контроль
Некоторые неприятности, ОЙ, опять случаются, опять Риски:
В очередной итерации мы скорее всего отстанем от графика, на сколько?
Опять скорее всего будут проблемы с качеством, какие?
А ведь можно проанализировать причины, принять меры,
спрогнозировать!

Записка 1.
Некоторые неприятности, ОЙ, опять случаются, опять Риски:
В очередной итерации мы скорее всего отстанем от графика, на сколько?
Опять скорее всего будут проблемы с качеством, какие?
А ведь можно проанализировать причины, принять меры,
спрогнозировать!
IF Типичные:_Проекты_Итерации_Проблемы = TRUE THEN
{
Collect Исторические данные
Analyze Исторические данные
[Create План корректирующих воздействий]
Forecast Нужные показатели
Monitor Нужные показатели
}

Записка 1.
Примеры:
Итеративная разработка продукта – можно относительно
несложно собирать данные о: разнице запланированных и
реальных усилий, денег, времени. Цель – тренды по итерациям.
Пользуемся баг трекерами – можно настроить отчетность: кто
сколько дефектов произвел; происхождение дефектов; сколько
дефектов обнаружил заказчик во время и/или после приемки.
Цель – понять, спрогнозировать, улучшить процессы на проекте.

Записка 1.
Рекомендации по сбору данных/метрик:
 Обеспечиваем базовые условия
полезности сбора и дальнейшего
использования данных/метрик
Люди
Процессы Инструментари
й

Записка 1.
 Собираем только те
данные/метрики, которые
отражают проблемы/риски,
которые вас действительно
беспокоят
Люди
й

Записка 1.
 Собираем только те
данные/метрики, которые
отражают проблемы/риски,
которые вас действительно
беспокоят
 Настраиваем эффективные
процедуры сбора и анализа
данных/метрик: автоматизация,
человеконезависимость
Люди
й

Записка 1.
Рекомендации по анализу данных/метрик:
 Анализируем не людей, а проблемы, процессы

Записка 1.
 Выявляем причины

Записка 1.
• Важно! Внедряем корректирующие воздействия/улучшения
 Выявляем причины
 Анализируем с конкретными целями (то, что действительно
беспокоит)
Требования Тестирование Сдача
Инспекция спецификации
показывает большое
количество дефектов
.......

Записка 1.
Рекомендации по прогнозированию:
 Основываем прогноз на нескольких типичных итерациях,
проектах, проблемах
Проект А
Проект B
Проект C
База знаний Проект F

Записка 1.
 Прогнозируем те нужные показатели, которые отражают
проблемы/риски, которые вас действительно беспокоят
Проект А
Проект B
Проект C

Записка 1.
 Прогнозируем те нужные показатели, которые отражают
проблемы/риски, которые вас действительно беспокоят
 Важно! Устанавливаем ОЖИДАНИЯ – свои, менеджмента,
заказчика на основании прогноза, таким образом снижая
неопределенность или же превращая риск в факт
Проект А
Проект B
Проект C

Записка 2
Методологический экскурс. Рассмотрим какие
подходы рекомендуют разные методологии.
И поштурмуем вопрос о том, почему в
Agile/SCRUM ничего не говорится об
управлении рисками.

Записка 2
Что говорится об управлении рисками в других
методологиях
 PMBOK
 PRINCE2
 CMMI
 ISO 31000

Записка 2
PRINCE2 создан и поддерживается UK Office of Government
Commerce, www.ogc.gov.uk.
PRINCE2 (PRojects IN Controlled Environments) – широко
используемый стандарт, в правительственных организациях
Великобритании, а также в коммерческих структурах, в
основном Великобритании и западной Европы
PRINCE2 является предписывающим стандартом – как и что
делать

Записка 2
CMMI создан и поддерживается Software Engineering Institute at
Carnegie Mellon University, www.sei.cmu.edu/cmmi. Всемирно
признаваемая модель.
CMMI (Capability Maturity Model Integration) - модель оценки
зрелости компаний, постановки и улучшения процессов.
CMMI включает 5 уровней зрелости (Maturity Levels) - (2 –
Managed; 3 – Defined; 4 - Quantitatively Managed; 5 - Optimizing).
Может быть использована для областей: разработка продуктов и
сервисов; проектирование, внедрение, управление и поставка
сервисов; приобретение продуктов и сервисов.
Важно! Внедряет и стимулирует применение инженерных и
управленческих практик. Но не диктует как именно это
делать

Записка 2
Почему в Agile/SCRUM ничего не говорится
об управлении рисками?
Приз за неординарный ответ!
А если серьезно?

Записка 2
Гуру говорят об управлении рисками в Agile/SCRUM (www.infoq.com)
Jurgen Appelo
“Risk Management is part of Prince2, part of PMBOK, and part of the CMMI, but you don't
often see it addressed explicitly in books on agile methods. I think that's strange.”
Michele Sliger
“In Agile software development risk gets addressed all the time as a part of daily stand-
ups, iteration planning meetings, release planning meetings, retrospective and review
meetings. However, a structured approach is suggested for managing risk. The steps
included: Risk Identification; Risk Analysis; Risk Response Planning; Risk Monitoring
and Controlling.”
Mike Cottmeyer
“Agile is so effective at managing risk because risk management processes are built into
the very fabric of how we run the project.
There is an implicit understanding that risk is EVERYWHERE on a project. Risk
cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a
periodic risk review session. Dealing with risk has to be an obsession. Our mitigation
strategies don’t live outside the project, but influence the very nature of how we
structure and plan our work.”

Записка 2
Ареал обитания Agile/SCRUM
Качество
архитектуры
Компания
Сроки
Внешние риски,
процесс
Закупки
Рекрутинг
Коммуникации
Качество
продукта
Требования
Бизнес
приоритеты
Проект

Записка 2
Ареал обитания Agile/SCRUM
Качество
архитектуры
Компания
Сроки
Внешние риски,
процесс
Закупки
Рекрутинг
Коммуникации
Качество
продукта
Требования
Бизнес
приоритеты
Проект
Эффективно,
но замкнуто
внутри

Записка 2
Каким образом и какие именно риски погашаются в
Agile/SCRUM?
 Каким образом:
 Коммуникации
 Достаточно профессиональная, сработавшаяся команда
 Приоритезация
 Короткие итерации
 Доступный заказчик
 Какие риски:
 Нужды бизнеса, требования
 Технические
 Качество
 Коммуникационные

Записка 2
Выводы:
 Применение областей знаний управления проектами
гармонично дополняет Agile/SCRUM, и никоим
образом не противоречит
 Учет возможностей, политик, требований компании
привносит реалистичность в проект и увеличивает
ценность компании
 Роль Проектного Менеджера (настоящего –
обученного, опытного) в качестве координатора
дополняет сильные стороны Agile/SCRUM и
размыкает замкнутость
 Говоря о рисках – применение процедур
управления рисками повышает успех Agile/SCRUM
проекта, как и любого другого
 Говоря о рисках – в команде должна быть роль
ОБУЧЕННОГО Менеджера по Рискам

Записка 3
Визуальное управление рисками. Рассмотрим
простой и понятный инструментарий
представления информации о рисках,
ясность ситуации за секунды. 100%-ная
понятность информации.

Записка 3
Рисковая Доска
Probability
Risk Board
5 5 10 15 25
3 3 6 9 15
2 2 4 6 10
1 1 2 3 5
Impact 1 2 3 5
Risk Risk
Risk
Risk
Risk
Risk
Risk
RiskRisk

Записка 3
Рисковый Профиль

Итог. Зачем это нужно
 Увеличивает вероятность успеха
 Реалистичность сроков, затрат и т.п.
 Решает проблемы на ранних стадиях
 Повышает прибыльность
 Снижает стресс
 Повышает профессионализм и репутацию
 Добавляет гибкости за счет альтернатив
 Открывает новые возможности
 Определение ответственности

Спасибо за внимание!
Вопросы
Полезные ссылки:
 http://www.infoq.com/news/2009/01/agile-risk-management
 http://www.slideshare.net/RHDrown/agile-or-pmbok-11-jun09
 www.ogc.gov.uk
 www.sei.cmu.edu/cmmi

Тренинг “Управление рисками в IT проектах ”:
http://xpinjection.com/trainings/risk-management/
Тренер XP Injection: http://xpinjection.com/coaches/
Контакт: promengine@yahoo.com
Другие тренинги:
 Scheduling (Планирование, Разработка расписания работ). Не
так просто как кажется, структурируем очевидные вещи.
 Software Measurements (Измерения в разработке ПО). Как, что и
зачем измерять.
 Полет по приборам: метрики проектных команд – управляемое
движение.
Подробнее:
 О себе http://www.linkedin.com/in/sergiypovolyashko
 О тренингах http://trn.work.ua/companies/1437
 Презентации http://www.slideshare.net/sergiyp1974

Risk Stories Seminar. XP Injection. Kiev. Ukraine

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Risk Stories Seminar. XP Injection. Kiev. Ukraine

Similar to Risk Stories Seminar. XP Injection. Kiev. Ukraine (20)

Risk Stories Seminar. XP Injection. Kiev. Ukraine

Editor's Notes