Исправление abcq, (текущая версия) :
Из такого примера создается впечатление что люди не общаются друг с другом и каждый день требования к проекту меняются настолько, что это может ломать согласованность на уровне интерфейсов, хотя стоп… это же и есть базарная разработка по аджайлу, «архитектор системы» - гибкий табунщик готовый расставлять «ворота» (читай цели которых нужно достичь от спринта к спринту) по указке краснобая-бизнеса, и команда баранов которых нужно вести к этим воротам (читай каждый день по несколько раз согласовывать проделанную работу, ставить новые цели в спринтах и т.д.) и смотреть чтобы они сами себе ворот не наделали (читай не реализовали то, что уже реализовано перекрывая друг друга или другой аналогичный пример или как вы сказали «хьюстон-бэк, у нас проблемы»).
Таким образом у меня все тот же вопрос, можно ли оправдать нужность этого подхода, если разработка превращается в цирк, хоть и реактивный по отклику на «хотелки» бизнеса? Можно ли с таким подходом вообще написать что-то нормальное? Не кажется ли вам, что при данном подходе все те плюсы гибкости для бизнеса в плане внесения очередной «хотелки» перечеркиваются потерей времени и контекста на нескончаемых совещаниях и попытках увязать новую «хотелку» в систему на ходу, искусственно затягивая цикл разработки за счет этого постоянного реинита задачи с «немного» изменившимися условиями, которые надо бы обсудить и довести до каждого в стаде? Можно ли получить что-то стройное, элегантное и эффективное, если весь проект это череда быстрых решений-заплат чтобы подстроиться под новые условия, которые некогда обдумать, потому что надо хотя бы успеть обсудить с баранами-работягами что им нужно теперь делать и не ломает ли эта новая калитка старый загон.
Резюмируя, можно сказать, что все эти новомодные подходы, это мыльная пена как некоторая конструкция из мыльных пузырей, скрывающая (под новым названием aka мыльным пузырем) очевидные вещи типа того, что коллеги должны общаться, под слоем этой самой пены (читай терминологии) + удобный реактивный подход для бизнеса, но совершенно пагубный для тех, кто это будет пытаться реализовать и для конечного продукта в целом.
Исходная версия abcq, :
Из такого примера создается впечатление что люди не общаются друг с другом и каждый день требования к проекту меняются на столько, что это может ломать согласованность на уровне интерфейсов, хотя стоп… это же и есть базарная разработка по аджайлу, «архитектор системы» - гибкий табунщик готовый расставлять «ворота» (читай цели которых нужно достичь от спринта к спринту) по указке краснобая-бизнеса, и команда баранов которых нужно вести к этим воротам (читай каждый день по несколько раз согласовывать проделанную работу, ставить новые цели в спринтах и т.д.) и смотреть чтобы они сами себе ворот не наделали (читай не реализовали то, что уже реализовано перекрывая друг друга или другой аналогичный пример или как вы сказали «хьюстон-бэк, у нас проблемы»).
Таким образом у меня все тот же вопрос, можно ли оправдать нужность этого подхода, если разработка превращается в цирк, хоть и реактивный по отклику на «хотелки» бизнеса? Можно ли с таким подходом вообще написать что-то нормальное? Не кажется ли вам, что при данном подходе все те плюсы гибкости для бизнеса в плане внесения очередной «хотелки» перечеркиваются потерей времени и контекста на нескончаемых совещаниях и попытках увязать новую «хотелку» в систему на ходу, искусственно затягивая цикл разработки за счет этого постоянного реинита задачи с «немного» изменившимися условиями, которые надо бы обсудить и довести до каждого в стаде? Можно ли получить что-то стройное, элегантное и эффективное, если весь проект это череда быстрых решений-заплат чтобы подстроиться под новые условия, которые некогда обдумать, потому что надо хотя бы успеть обсудить с баранами-работягами что им нужно теперь делать и не ломает ли эта новая калитка старый загон.
Резюмируя, можно сказать, что все эти новомодные подходы, это мыльная пена как некоторая конструкция из мыльных пузырей, скрывающая (под новым названием aka мыльным пузырем) очевидные вещи типа того, что коллеги должны общаться, под слоем этой самой пены (читай терминологии) + удобный реактивный подход для бизнеса, но совершенно пагубный для тех, кто это будет пытаться реализовать и для конечного продукта в целом.