Цикл Деминга, Scrum и Toyota Production System

Нередко про цикл Деминга, Scrum и Toyota Production System рассказывают дискретно, будто несколько историй в одном фильме под эгидой одной идеи. И как они между собой связаны — не всем и не всегда очевидно.

Выгдядит это примерно так. Долгий рассказ о PDCA. Затем долгий рассказ о Тойоте и MURI, MURA, MUDA. После чего долгий рассказ про скрам: плаирование, спринты, ретро и т.д.

Попробуем разобраться, как эти три модели между собой соотносятся.

Scrum
Plan    —>  Release/Sprint Planning
Do       —>  Sprint, Daily Scrum
Check —>  Sprint Review
Act      —>  Retrospective

Toyota Production System
Plan    —>  Убрать Muri (перегрузка людей или оборудования)
Do       —>  Убрать Mura (неравномерность выполнения работы)
Check —>  Убрать Muda (потери)
Act      —>  Стандартизация, устранение root cause.

Чтобы приземлить и сделать заметку полезной в практическом смысле, свяжем через PDCA описанные в Toyota Production System виды потерь с практиками Scrum.

 

 

Mura — это «неравномерность» и «неконсистентность». В Scrum мы движемся равными по времени итерации, что задает ритм, стараемся делить задачи на примерно равные по сложности. Если над одним продуктом работает несколько команд — синхронизируем их по времени, выставляем единые требования по качеству (через DoD) и т.д.

В Muda еще больше пунктов. Если пропустить семь агрегирующих категорий и сразу перейти к конкретным проблемам, то это могут быть:

  • Частично реализованые истории
  • Дефекты
  • Создание низкоприоритетных фич вместо высокоприоритетных
  • Перетестирование
  • Изучение чужого кода (не путать с Code Review)
  • Исправление проблем с зависимостями
  • Передача информации (документ против живого общения)
  • Настройка окружений
  • Ручной регресс
  • Блокирующие баги
  • Не готовые к интеграции внешние системы
  • Ревокри всех мастей
  • Ожидания (принятия решений, одобрения, пока босс со встречи вернется и т.д.)
  • Накладные расходы на работу с инструментами (excel, например)

С Muri «проще». Это абсурдно большой, невыполнимый скоуп, постоянное ожидание героических действий от команды и перегрузка участников. Перегрузка не только из-за скоупа конкретного проекта. Если сотрудник работает параллельно на трех проектах, то каждому из проектов он может уделить только 20% своего времени, а потери на переключение контекста составят 40%, но многие привыкли делить человека поровну, что приводит к перегрузке. В приведенном примере — в два раза.

 

 


Leave a Reply