Причина этого подхода в том, что действительно важные идеи обязательно всплывут, и рано или поздно на них будет выделен отдельный цикл. Таким образом, подход гарантирует, что вы сосредоточитесь на том, что является важным сейчас, вместо того, чтобы тупо брать следующую задачу в списке.
Если вам интересен практический опыт по Shape Up, то вот: https://ain.ua/ru/2021/09/20/zachem-my-pereveli-razrabotku-work-ua-na-shape-up-i-kak-eto-sdelali/
Спасибо! Ознакомлюсь.
Вопрос вот какой: почему мы не можем пользоваться уже имеющимися методологиями, а вместо этого должны бежать учить и внедрять шейп ап? Что мы не можем уже сейчас без шейп апа делать?
Вообще, в мире существует пока всего 4 подхода к управлению большими проектами, это TTTF:
T1) Task-oriented - это основанный на задачах, например знаменитый водопад, когда неизбежны временные лаги и др. проблемы, но гарантируется целостность общего результата.
T2) Time-oriented - это подходы, основанные на "нарезании" всех работ по времени на "спринты" с последующей сборкой и склейками результатов из получившихся кусков, а также попытками перенести ответственность за результат с менеджмента (кто режет таски) на разработчиков, кто вынужден плясать не как нужно проекту, а как удобно менеджерам. Это Аджайлы со спринтами и многими "корректирующими" фреймворками (Канбан) в целях формирования из получившейся фигни норм. рабочего процесса.
T3) Team-oriented - тоже в каком то смысле Аджайл, но тут небольшие группы разработчиков сами в начале берут себе в работу отдельные части большого проекта (Микросервисы например) из которых потом архитекторы и ведущие разработчики собирают финальное решение.
T4) Forced - если ничего не помогает, приходит товарищь-Майор (самый крутой перец, который сам всё знает и всё умеет) и "вручную" все сам разруливает или делегирует на уровень ниже проблематику, которой Царю заниматься не положено.
TG: @andytimo