К чему это приводит на практике? В компании внедряется фреймворк Scrum, и оказывается, что ряд команд отлично работает по Scrum'у, а другие — плюются и открещиваются от него. Казалось бы — вот одни молодцы, а вторые — ретрограды. Ведь компания одна, люди вроде одинаковые, но одним командам Scrum помогает, а другим - мешает. Детальное рассмотрение позволило увидеть, что ряд команд создают продукты, а другие команды реализуют проекты. Последние команды страдают от того, что их заставляют делать то, в чём они не находят ни малейшей пользы. Ужасные ощущения. А учитывая, что внешний стресс и выполнение работы без осознания результата приводит к вьетнамскому синдрому, когда выбирается не лучшее, а похожее на лучшее, решение, соответственно, качество продукта данных команд ухудшается, что приводит к ложному выводу - они не работают по Scrum'у, поэтому у них ничего не получается!
Фраза "ДНК всех модных методологий и фреймворков" статью не красит.
Тезисы типа "Если команда работает над продуктом, то Scrum" не являются очевидными и требуют детального обоснования.
> Например, мой бывший коллега Алексей снизил очередь задач в бэклоге с 40 недель до 20 за счёт применения идей Канбан-подхода
Вот это поворот.
Если перспективы развития вашего проекта-продукта-ватэвер насколько ясны, что вы можете запилить бэклог на 40 недель, то в общем-то причем тут скрам?
Отличное summary методологий управления! Спасибо!
Читал ряд других статей на тему "выбора методологии управления" и всё время задавался вопросом: а вообще менеджеры, которые "выбирают инструмент под задачу" (скрам, канбан, вотерфол /PMI) в природе существуют? И в каких компаниях водятся?
Практически всегда приходишь в средУ компании, где на вопрос об организации раб. процесса обозначают "у нас Скрам" или "У нас Канбан" или "У нас смесь Скрам\ Канбан" или "у нас все по PMBoK". А вот такого, чтоб "давайте оценим задачу и выберем методологию" - не припомню такого. :)
Думаю, все дело в том, что многие не отдают себе отчет, что для решения разных задач могут использоваться разные методологии, даже если работают в режиме многозадачности. Например, зачем использовать Scrum, если можно работать по инструкции, верно? Но если команда сталкивается с новой задачей, то тогда этот метод применить было бы вполне логично. Вот тут, кстати, хорошо описано, для каких целей лучше использовать Scrum https://leadstartup.ru/db/scrum
Постановка вопроса "Scrum vs Kanban" некорректна.
Картинка "При этом со Scrum'ом дело усложняется следующим образом:" еще менее корректна.
Kanban-метод не противоречит Scrum фреймворку и не конкурирует с ним в чистом виде.
Результат применения Канбан-метода как измененный процесс работы может конкурировать. Но не Канбан-метод.
Scrum может быть одним из этапов развития процессов по Канбан-методу. А может быть преобразован в что-то иное, если это "иное" лучше подходит для конкретного сервиса.
Для полного следования канону "Scrum vs Kanban" нужно добавить в статью "Waterfall" (тм).
Комментарий недоступен
А если проект - это проект о проекте по созданию проекта?!