Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

CodeFest
April 09, 2018

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

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

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

CodeFest

April 09, 2018
Tweet

More Decks by CodeFest

Other Decks in Technology

Transcript

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

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

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

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

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

  6. 14

  7. 16

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

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

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

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

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

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

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

    по выполнению работы в проекте? 39 Вряд ли Да Возможно 10 1 5
  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 41 10 1 5
  16. Опыт: Рассмотрите опыт и навыки ключевых ролей в команде. Есть

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

    одному представителю заказчика/бизнеса для получения обратной связи и ответов на вопросы? 43 Нет Да Частично 10 1 5
  18. Критичность: Чтобы определить уровни дополнительной верификации и строгости документации, которая

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

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