Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Практика показывает, что на длинных дистанциях он наоборот повышает производительность. Потому что улучшает понимание проекта в целом и снижает риск выгорания.

Он не только на длинных дистанциях повышает производительность, но и на коротких. Потому что производительность важна не сама по себе, а только тогда, когда она прикладывается к наиболее высокоприоритетной задачи. Банальная теория ограничений — имеет значение только производительность бутылочного горлышка. Производительность остальных частей, которые не являются бутылочным горлышком никакой роли не играет. При этом если у тебя более-менее сбалансированная по компетенциям команда, то бутылочное горлышко каждый раз будет в новом месте, в зависимости от задачи. То есть, например, одна задача требует больше UI кода, другая больше backend кода и т.д. При этом если у теюя узкая специализация команды, то остается только два варианта: либо загружать бутылочное горлышко на 100%, а остальные в это время будут "плевать в потолок", либо брать в параллель дополнительные более низкоприоритетные задачи, чтобы недозагруженные разработчики не маялись от безделия. Оба варианта по своему плохи и оба увеличивают TTM и Lead Time. Если же нет узкой специализации, то появляется возможность всей командой сфокусированно разрабатывать одну самую высокоприоритетную фичу и быстро отправить её в продакшен.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Практика показывает, что на длинных дистанциях он наоборот повышает производительность. Потому что улучшает понимание проекта в целом и снижает риск выгорания.

Он не только на длинных дистанциях повышает производительность, но и на коротких. Потому что производительность важна не сама по себе, а только тогда, когда она прикладывается к наиболее высокоприоритетной задаче. Банальная теория ограничений — имеет значение только производительность бутылочного горлышка. Производительность остальных частей, которые не являются бутылочным горлышком никакой роли не играет. При этом если у тебя более-менее сбалансированная по компетенциям команда, то бутылочное горлышко каждый раз будет в новом месте, в зависимости от задачи. То есть, например, одна задача требует больше UI кода, другая больше backend кода и т.д. При этом если у теюя узкая специализация команды, то остается только два варианта: либо загружать бутылочное горлышко на 100%, а остальные в это время будут "плевать в потолок", либо брать в параллель дополнительные более низкоприоритетные задачи, чтобы недозагруженные разработчики не маялись от безделия. Оба варианта по своему плохи и оба увеличивают TTM и Lead Time. Если же нет узкой специализации, то появляется возможность всей командой сфокусированно разрабатывать одну самую высокоприоритетную фичу и быстро отправить её в продакшен.