Выбор подхода к управлению проектом

1. Выбор подхода к управлению проектом

2. Stacey Complexity Model

Модель применяется для
оценки проекта с точки
зрения неопределённости.
Вертикальная ось
показывает, понятно ли, что
мы хотим сделать.
Горизонтальная ось
показывает, понимаем ли
мы, как этого достичь.
Оси образуют четыре
домена, в которые может
попасть проект: простые,
сложные, комплексные и
хаос. После определения
домена можно подбирать
подход.

3. Частые поставки – как инструмент борьбы с неопределённостью

Многие команды обнаружили, что когда они изучают требования
итеративно и осуществляют поставки чаще и по частям
(инкрементно), им становится легче адаптироваться к изменениям.
Такие итеративные и инкрементные подходы позволяют сократить
объемы потерь и доработок, поскольку команда получает
обратную связь. В этих подходах используются: » очень короткие
циклы обратной связи » частая адаптация процесса » пересмотр
приоритетов » регулярное обновление планов » частые поставки

4.

• Итеративные, инкрементные аgile-подходы хорошо работают в
проектах, которые связаны с использованием новых или
инновационных инструментов, методов, материалов или
областей применения. Хорошо работают в проектах, которые:
• требуют проведения НИОКР
• имеют высокие темпы изменений
• имеют неясные или неизвестные требования
• неопределенность или риск
• имеют конечную цель, которую сложно описать

5. 4 категории жизненного цикла

6. Континуум жизненных циклов проекта

7. Итеративный жизненный цикл

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

8. Инкрементный жизненный цикл

• Процесс разработки разбивается частую поставку частей
продукта.
• Акцент на возможность поставки результат по частям и
возможность заказчика в процессе создания продукта
использовать в своей работе уже поставленные части.

9. Жизненные циклы Agile

Итерационный подход:
Постоянные временные рамки
Результат – проверка заявленных свойств

10. Жизненные циклы Agile

Потоковый подход:
• Части определяются заявленными возможностями продукта
• Результат – проверка 1 возможности (функции) продукта
• Временные рамки могут варьироваться в зависимости от
представляемой возможности.

11. Agile Suitability Model

Несколько человек, в идеале включая
спонсора, представителей команды и
заказчика, отвечают на вопросы,
сгруппированные в 3 домена:
Культура – насколько окружение
способствует подходу?
Команда – сможет ли сама команда
воспользоваться преимуществами
подхода?
Проект – а что с самим проектом?
насколько нужно и можно быть
гибкими?
Группа должна обсудить вопрос,
прийти к общей оценке и занести её
на лепестковую (радарную) диаграмму

12. Домен “Культура”

Поддержка: Поддерживает ли спонсор проекта (куратор) применение гибких методов на данном проекте?
N.B. Если спонсор говорит “делайте, что хотите” – это ещё не поддержка.

13. Домен “Культура”

Решения: Будет ли у команды автономия в принятии локальных
решений по выполнению работы в проекте?
Если на входе вас встречает ТЗ толщиной с войну и мир, а на выходе ожидает комиссия с
хмурыми лицами и защитой отчета – это очень плохой знак. Задумайтесь.

14. Домен “Культура”

Решения: Будет ли у команды автономия в принятии локальных решений
по выполнению работы в проекте?

15. Домен “Команда”

Размер команды: Оцените
размер основной команды
проекта по следующей
шкале:
1-9 = 1;
10-20 = 2;
21-30 = 3;
31-45 = 4;
46-60 = 5;
61-80 = 6;
81-110 = 7;
111-150 = 8;
151 – 200 = 9;
201+ = 10.

16. Домен “Команда”

Опыт: Рассмотрите опыт и навыки ключевых ролей в команде.
Есть ли в команде по одному опытному члену команды на
каждую роль?

17. Домен “Команда”

Доступ: Будет ли у команды ежедневный доступ хотя бы к одному
представителю заказчика/бизнеса для получения обратной связи
и ответов на вопросы?

18. Домен “Проект”

Изменения: Какой процент требований возможно будет меняться
каждый месяц?
Здесь полезно вспомнить Stacey Complexity Model.
Если у вас ничего не меняется, то к чему вам гибкость?

19. Домен “Проект”

Критичность: Рассмотрите потери, которые могут
возникнуть из-за дефектов, определите, чем может
закончиться провал.

20. Домен “Проект”

Поставка: Может ли продукт разрабатываться и оцениваться
по частям? Смогут ли представители заказчика/бизнеса
своевременно давать обратную связь по инкрементам?

21.

Результаты, сосредоточенные в
центре показывают готовность к
гибким подходам. Результаты в
гибридной зоне показывают
возможность сочетания гибкого
и предиктивного подхода. Чем
дальше от центра расположены
результаты, тем выше
вероятность, что оптимальный
подход – предиктивный. Вполне
вероятно, что на вашей
диаграмме будут крайности в
обе стороны.

22. КАДЕНЦИЯ ПОСТАВОК

Каденция поставок означает сроки и частоту применительно к поставляемым результатам проекта. У
проектов может быть разовая поставка, неоднократные или периодические поставки.
▶ Разовая поставка. Разовая поставка осуществляется в конце проекта. Например, в проекте по
реинжинирингу процесса может не быть поставок до конца проекта, когда происходит выпуск нового
процесса.
▶ Неоднократные поставки. В некоторых проектах поставок несколько. Проект может иметь несколько
компонентов, которые поставляются в разное время на протяжении всего проекта Проект по разработке
нового лекарственного средства может иметь несколько поставок, например доклинические материалы,
результаты исследования 1-й фазы, результаты исследования 2-й фазы, результаты исследования 3й фазы, регистрация и затем выпуск. В данном примере поставки происходят последовательно. В
некоторых проектах, например по модернизации системы безопасности здания, поставки
разрабатываются раздельно, а не последовательно. Поставки могут включать в себя физические
барьеры на входе, новые идентификационные карточки, новые панели набора кода и так далее. Каждый
из этих элементов является отдельной поставкой, но они не обязательно осуществляются в
определенном порядке. Все поставки завершаются до момента, когда проект считается завершенным.
▶ Периодические поставки. Периодические поставки схожи с неоднократными поставками, но они
осуществляются по фиксированному расписанию поставок, например ежемесячно или один раз в два
месяца. В случае с новым программным приложением внутренние поставки могут осуществляться
каждые две недели с последующим периодическим релизом поставок на рынке.

23.

24. Предиктивный подход.

Предиктивный подход полезен, когда требования к проекту и продукту
поддаются определению, сбору и анализу в начале проекта. Данный подход
также может называться водопадным. Его также можно использовать, когда
привлечен значительный объем инвестиций и существует высокий уровень
риска, что может потребовать частых проверок, механизмов контроля
изменений и перепланирования между фазами разработки. Содержание,
расписание, стоимость, потребности в ресурсах и риски можно в достаточной
степени определить на ранних фазах жизненного цикла проекта, и они
относительно стабильны. Данный подход к разработке позволяет команде
проекта снизить уровень неопределенности на раннем этапе проекта и
осуществить значительный объем планирования заранее. В предиктивных
подходах может использоваться разработка проверок концепции для поиска
вариантов, однако значительная часть работы проекта следует планам,
разработанным вскоре после начала проекта. Часто проекты,
придерживающиеся данного подхода, используют шаблоны от предыдущих
похожих проектов.

25. Гибридный подход.

Гибридный подход к разработке представляет собой сочетание адаптивного и предиктивного
подходов. Это значит, что в нем используются элементы как предиктивного, так и адаптивного
подходов. Данный подход к разработке полезен, когда существует неопределенность или риск в
связи с требованиями. Он также полезен, когда поставляемые результаты можно разбить на
модули или когда поставляемые результаты могут разрабатывать различные команды проекта.
Гибридный подход более адаптивен, чем предиктивный, но менее адаптивен, чем чисто
адаптивный подход.
В гибридных подходах часто используется итеративный или инкрементный подход к разработке.
Итеративный подход полезен для уточнения требований и поиска разнообразных вариантов. При
итеративном подходе могут быть получены достаточные характеристики, которые считаются
приемлемыми до заключительной итерации. Инкрементный подход используется для создания
поставляемого результата посредством серии итераций. Каждая итерация добавляет функционал в
пределах заранее определенного срока (временных рамок). Поставляемый результат содержит
характеристики, которые считаются завершенными только после заключительной итерации.
Примером гибридного подхода может служить применение адаптивного подхода для разработки
продукта, с требованиями к которому связана значительная неопределенность. Однако
развертывание продукта можно осуществить с помощью предиктивного подхода. Другим
примером может служить проект с двумя основными поставляемыми результатами, один из
которых разрабатывается с помощью адаптивного, а другой — с применением предиктивного
подхода.

26. Адаптивный подход.

Адаптивные подходы полезны, когда с требованиями связан высокий уровень
неопределенности и изменчивости, и они с высокой вероятностью будут меняться на
протяжении проекта. В начале проекта формируется четкое видение, а известные
изначально требования проходят уточнение, детализацию, изменение или замену в
ответ на обратную связь от пользователей, среду или непредвиденные события.
В адаптивных подходах используются итеративный и инкрементный подходы. Тем не
менее чем более адаптивен метод, тем короче итерации и тем вероятнее, что
продукт будет развиваться на основе обратной связи от заинтересованных сторон.
Хотя гибкость — это широкое мышление, которое шире фреймворка разработки,
agile-подходы можно считать адаптивными. Некоторые agile-подходы подразумевают
итерации длительностью 1–2 недели с демонстрацией достижений в конце каждой.
Команда проекта в значительной степени вовлечена в планирование каждой
итерации. Команда проекта определяет содержание, которого они могут достигнуть,
на основе приоритизированного бэклога, оценивает требуемый объем работы и
сотрудничает на протяжении итерации над разработкой содержания.

27. Boehm and Turner – Radar Chart

• В данной модели для оценки
используется 5 критериев, а результаты
наносятся на лепестковую диаграмму.
Авторы предлагают оценивать:
• Уровень подготовки персонала
• Долю требований, которые
ежемесячно меняются
• Культуру
• Численность команды
• Критичность

28. DSDM Suitability Filter

• В 1994 году DSDM консорциум разработал
опросники Project Suitability Filter (PSF) и
Organization Suitability Filter (OSF), которые
позволяли оценить, насколько проект и
организация подходят для применения
гибкого подхода и зафиксировать
потенциальные источники проблем.
Сейчас на сайте Agile Business Consortium
доступен DSDM Project Approach
Questionnaire (PAQ). Это список из 17
утверждений, которые позволяют выявить
риски применения DSDM. Утверждения
касаются понимания философии и практик
DSDM, соблюдения ролей в команде. Имеет
смысл ознакомиться, если уже разбираетесь
в подходе.

29. Объединяющие понятия для многих методов

30. Подходы аgile, представленные по ширине охвата и детализации

31. Alistair Cockburn’s Criticality and Team Size Factors

Алистар Кокберн использовал
показатели “критичность
системы” и “размер команды”,
чтобы показать, какой из
методов семейства Сrystal
следует применять в
зависимости от сочетания
факторов. Под критичностью
понимается уровень ущерба,
который может быть нанесён,
если что-то пойдёт не так