CodeFest 2018. Дмитрий Ильенков (Московское отделение PMI) — Agile и Waterfall - нужны мосты, а не стены

16b6c87229eaf58768d25ed7b2bbbf52?s=47 CodeFest
April 09, 2018

CodeFest 2018. Дмитрий Ильенков (Московское отделение PMI) — Agile и Waterfall - нужны мосты, а не стены

Посмотрите выступление Дмитрия: https://2018.codefest.ru/lecture/1269/

— Противоречия между Agile и Waterfall не существует.
— Компании нужны результаты, а не инструменты.
— Осознанный выбор подхода: Stacey Complexity model.
— Жизненный цикл проекта. Вам точно нужен один?
— Нужен ли вам Agile? Готовы ли вы к нему?

16b6c87229eaf58768d25ed7b2bbbf52?s=128

CodeFest

April 09, 2018
Tweet

Transcript

  1. Agile и Waterfall: нужны мосты, а не стены Дмитрий Ильенков

    Член Правления Московское отделение PMI «Противоречий не существует… Проверь исходные положения.» (Айн Рэнд)
  2. 2 ▪ к.э.н, сертифицированный руководитель проектов (PMP, PRINCE2, ПМ СТАНДАРТ)

    ▪ член Правления Московского отделения Института управления проектами (PMI) ▪ асессор конкурса «Проектный Олимп» ▪ Более 10 лет опыта управления проектами в электроэнергетике, e-commerce, консалтинге и образовании https://t.me/pmclub Дмитрий Ильенков
  3. 3 Институт управления проектами (PMI) 851 570+ сертифицированных специалистов 287+

    открытых отделений 500 000+ действующих членов
  4. 4 Часть 1: Мифы

  5. PMI – это не только PMBOK. 5

  6. 6 Базовые стандарты Практические стандарты и фреймворки Практические руководства

  7. PMBOK – это не методология. 7

  8. Методология – система практик, методов, процедур и правил, используемых в

    определённой сфере деятельности.* 8 *Руководство PMBOK 6-е издание
  9. PMBOK – основа, на которой организации могут разработать свои политики,

    методологии, правила и методы.* 9 *Руководство PMBOK 6-е издание
  10. PMBOK – это не Waterfall. 10

  11. 11

  12. Что такое Agile? 12

  13. 13 12 Принципов Agile Мышление 4 Ценности Практики *Ahmed Sidky

    Agile – это система мышления
  14. 14

  15. А что гласит Waterfall Manifesto? 15

  16. 16

  17. Его нет. 17

  18. 18 Анализ Проектирование Разработка Тестирование Поставка Мифический Waterfall

  19. 19 Анализ Проектирование Разработка Тестирование Поставка Вариант 2…

  20. 20 *Winston W. Royce, Managing the development of large software

    systems
  21. 21 Часть 2: Реальность

  22. Waterfall (предиктивный ЖЦ)– форма жизненного цикла проекта, при которой содержание,

    сроки и стоимость проекта определяются на ранних фазах жизненного цикла. 22 ***
  23. 23 Анализ Проектирование Разработка Тестирование Поставка Модель предиктивного жизненного цикла

  24. 24 Итеративная модель Анализ Проектирование Разработка Поставка Анализ Тестирование Прототип

    Совершенствование
  25. 25 Инкрементальная модель Проектирование Анализ Разработка Тестирование Поставка Проектирование Анализ

    Разработка Тестирование Поставка Проектирование Анализ Разработка Тестирование Поставка
  26. 26 Гибкая модель Повторяется столько, сколько необходимо Проектирование Анализ Разработка

    Тестирование Поставка Требования Проектирование Анализ Разработка Тестирование Поставка Требования Проектирование Анализ Разработка Тестирование Поставка Требования
  27. 27 Гибкая разработка с последующим предиктивным выведением на рынок Предиктивный

    Гибкий Гибкий Гибкий Предиктивный Гибридные модели
  28. 28 Гибридные модели Гибкий Гибкий Гибкий Предиктивный Предиктивный Предиктивный Два

    подхода применяются одновременно
  29. 29 Характеристика жизненных циклов ПОДХОД ТРЕБОВАНИЯ ДЕЙСТВИЯ ПОСТАВКА ЦЕЛЬ Предиктивный

    Фиксированные Выполняются один раз за весь проект Одна Управление стоимостью Итеративный Динамические Повторяются, пока не будет правильно Одна Правильность решения Инкрементальный Динамические Выполняются один раз для конкретного инкремента Частые более мелкие поставки Скорость Гибкий Динамические Повторяются, пока не будет правильно Частые небольшие поставки Ценность для клиента через частые поставки и обратную связь
  30. 30 Проблема не в том, какой подход. Проблема в его

    отсутствии.
  31. Организаций используют стандартизированные практики управления проектами 93% 70% Ограничивают их

    использование
  32. 32 *PMI Пульс Профессии 2018 Применение формального проектного подхода повышает

    успешность проектов* Проектов достигли целей Проектов выполнены в рамках бюджета Проектов закончены в срок Используют предиктивный, гибкий и гибридные подходы ▪ Всегда/часто ▪ Редко/никогда 73% 63% 59%
  33. Предиктивные подходы Гибкие подходы Гибридные подходы Другие подходы 44% 30%

    23% 4% *PMI Пульс Профессии 2018
  34. 34 Stacey Complexity Model

  35. Agile Suitability Model опрос 35

  36. Культура Категория 1 36

  37. Поддержка: Поддерживает ли спонсор проекта (куратор) применение гибких методов на

    данном проекте? 37 Нет Да Частично 10 1 5
  38. Доверие: Рассмотрите спонсора проекта и представителей заказчика, работающих с командой.

    Считают ли данные стейкхолдеры, что команда сможет трансформировать их видение и потребности в продукт или услугу - при их поддержке и постоянной обратной связи? 38 Вряд ли Да Возможно 10 1 5
  39. Решения: Будет ли у команды автономия в принятии локальных решений

    по выполнению работы в проекте? 39 Вряд ли Да Возможно 10 1 5
  40. Команда Категория 2 40

  41. Команда: Оцените размер основной команды проекта по следующей шкале: •

    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 41 10 1 5
  42. Опыт: Рассмотрите опыт и навыки ключевых ролей в команде. Есть

    ли в команде по одному опытному члену команды на каждую роль? 42 Нет Да Частично 10 1 5
  43. Доступ: Будет ли у команды ежедневный доступ хотя бы к

    одному представителю заказчика/бизнеса для получения обратной связи и ответов на вопросы? 43 Нет Да Частично 10 1 5
  44. Проект Категория 3 44

  45. Изменения: Какой процент требований возможно будет меняться или обнаруживаться каждый

    месяц? 45 5% 50% 25% 10 1 5
  46. Критичность: Чтобы определить уровни дополнительной верификации и строгости документации, которая

    может потребоваться, оцените значение продукта или услуги. Рассмотрите потери, которые могут возникнуть из-за дефектов, определите, чем может закончиться провал. 46 Много жизней Время 10 1 5 Критичные ресурсы Одна жизнь Свободные ресурсы
  47. Поставка: Может ли продукт разрабатываться и оцениваться по частям? Смогут

    ли представители заказчика/бизнеса своевременно давать обратную связь по инкрементам? 47 Вряд ли Да Возможно/иногда 10 1 5
  48. 48 Agile Гибрид Предиктивный

  49. ВОПРОСЫ? https://www.facebook.com/dmitry.ilienkov dailenkov@pmi.ru https://t.me/pmclub Дмитрий Ильенков Член Правления Московское отделение

    PMI