То, что шустрые ребята собрали в кучу ряд стандартных подпроцессов и дали им красивые имена не делает эту методу стандартом. Более того в ряде реальных бизнесов и продуктов, Agile не работает в принципе.
Нужно, наверное, немного внести ясность, что такое Agile и как он возник. Agile — это исторический момент перехода количественных изменений методик разработки в качественные. Примерно как вода, при при накоплении энергии до температуры 100°C, переходит в новое качественное состояние.
Изначально все работали по BDUF, поскольку изменение реализованных проектных решений стоило очень дорого (стоимость росла экспоненциально). BDUF тоже стоит недешево, поскольку он создается в условиях недостаточной информированности (и обработка этой недостаточности требует работы высококвалифицированных архитекторов), а вероятность ошибки в этих условиях слишком высока. Но тем не менее, он стоил дешевле изменения реализованных решений.
В определенный исторический момент уровень зрелости методик разработки (OOP, TDD, Refactoring, Design Patterns, PoEAA и т.п.) достиг такого уровня, при котором изменение уже реализованных проектных решений стало стоить дешевле создания BDUF. График роста стоимости изменения кода изменился с экспоненциального на асимптотический.
Наука, отвечающая за линейный рост стоимости изменения кода, как я уже, говорил, называется архитектура. А поэтому, на собрании, которое организовал всем известный Robert C. Martin (автор Clean Code) для подписания Agile Manifesto в 2001 году, присутствовал ряд ведущих архитекторов того времени: Ward Cunningham, Kent Beck, Martin Fowler и др.
Иными словами, достижение низкой стоимости изменения кода открыло бизнес-возможность вести разработку итеративно, таким образом, чтобы проектные решения будущих итераций опирались на обратную связь (feedback) от практической эксплуатации реализации проектных решений предыдущих итераций.
Отсюда становится понятно, почему бывает что «Agile не работает в принципе», если правильно понимать его принцип (разумеется, кроме принципиальной причины, существует еще и ряд других причин — организационные, финансовые и пр.). Принципиальная же причина заключается в том, что многим проектам не удается удержать стоимость изменения кода низкой (обычно — в силу невысокого внутреннего качества программы), в итоге, исправление реализованных проектных решений стоит настолько дорого, что дешевле спроектировать все заблаговременно.
На самом деле, единственная цель внутреннего качества программы — это разрабатывать быстрее. Это из моей личной практики. В среднем, когда я берусь за legacy проект, то уже через год экономические показатели разработки всей команды улучшаются более чем в 5 раз. А вот это — немного из теории, если интересно.
в 95% случаев побеждают реальные пацаны.
Только недавно я сталкивался с подобным legacy-проектом, в котором, несмотря на возраст всего в один(!!!) год, более 80% бюджета разработки тратилось на багфикс. Осуществить новую разработку ключевых компонентов с нуля стоило в разы дешевле, чем чинить их. При этом, заказчик не жадничал — проект имел хорошее финансирование, а разработчики, доведшие его до такого состояния, получали зарплаты существенно выше рыночных. Вообще, должен сказать, что я часто наблюдаю на рынке труда предложения «спасти» проект от финансового краха, и возраст таких проектов редко превышает 3 года. Т.е. в среднем, уже через 3 года дальнейшая разработка таких проектов становится нерентабельной, и инвесторы прибегают к радикальным решениям.
P.S.: rudnevr, статья, конечно, имеет несколько броскую стилистику изложения, но в целом, по моему мнению, вам удалось ухватить проблему за хвост. Мне кажется, что статья заслуживает больше, чем ее оценили, и соответствует своему саркастическому стилю. Продолжайте писать.
С каких пор Agile стал стандартом процесса разработки ПО и может ли он стандартизировать процесс
Ну, мы обсуждаем не стандарты, а проблему, озвученную как «Никакие «хорошие» практики не сделают из олимпиадника хорошего разработчика.» Для решения этой проблемы и существуют практики Collaborative Development. И они работают, если, конечно, уметь их «готовить» («Extreme Programming Explained» 1st edition раскрывает эту тему).
Кстати, Agile можно встретить в ряде стандартов, например, в ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes, или в ГОСТ Р 56920-2016.
Что касается корректности перевода термина «практики», то п. 3.3.8 действующего ГОСТ Р ИСО/МЭК 33001-2017 определяет ее как «практика (practice): Определенный тип активности в рамках выполнения процесса.»
шустрые ребята
Искренне надеюсь, что вы ознакомились с фамилиями 17-ти этих «шустрых ребят», и осознаете их вклад в развитие ИТ-индустрии (помимо Agile), прежде чем это написать.
Каждый реальный бизнес и продукт требует построения своего процесса разработки, основанного на базовых принципах разработки ПО.
Возможно, но это уже выходит за рамки обсуждаемой проблемы о практиках, которые могли бы сделать из олимпиадника хорошего разработчика.
Был даже один с ученой степенью, эта ученая степень защищала его от необходимости дальнейшего обучения. Разгребая за ним его творчество мы потеряли кучу здоровья и денег.
Есть такое явление в контексте гибкой разработки, здесь вы зря минусуете. Это известная проблема. Еще в конце 90-х Кент Бек говорил, что труднее всего работать по гибким методологиям докторам наук. Во первых, они склонны к заблаговременному поиску решения реализации, что негативно отражается на темпы разработки и чревато ошибкой в условиях недостаточной информированности (т.н. проблема умных людей). А во вторых, «Хороший код выразителен, а не впечатляющ». Этой теме посвящен первый шаг принципов KISS: «Be Humble, don't think of yourself as a super genius, this is your first mistake. By being humble, you will eventually achieve super genius status =), and even if you don't, who cares! your code is stupid simple, so you don't have to be a genius to work with it.»
Но проблема, на самом деле, не в самом уме как таковом, а в их привычке обращаться со своим умом. Для решения этой проблему и существуют «практики», и когда такие ребята осваивают базовые принципы гибкой разработки, — они становится очень успешными (я знаю целый ряд таких примеров, когда умственные способности из тормоза общего процесса превращались в мощнейший его катализатор).
Ну, это официальный термин, используемый организацией Agile Alliance, которая берет свое начало с подписания Agile Manifesto. Этот же термин используется в официальном Scrum Guide и Extreme Programming. Как бы мы к нему не относились.
автомеханика, у которого хорошая практика затягивать гайки.
Задача практик заключается в том, чтобы все гайки затягивались в нужный момент времени, в нужной последовательности, с нужным усилием (моментом) затяжки, в отведенный интервал времени, выполняли свое назначение и чтобы качество результата не зависело от уровня квалификации конкретного участника команды.
Покер плэннинг длится до тех пор пока каждый участник не будет хорошо понимать обсуждаемый функционал.
Planning poker — это форма коллективной оценки, которая используется для оценки Story (поскольку Story выполняется коллективно). Коллективная оценка тоже имеет свою стоимость, и, поэтому, затраты на нее должны находиться в балансе с бизнес-выгодой от этой оценки (обычно это не более 5% от релиза/итерации/спринта в зависимости от конкретной методологии). Высокая точность оценки и понимание всех деталей реализации на этом этапе не требуется (поскольку затраты на точность оценки растут экспоненциально, а бизнес-выгоды от этой точности — линейно). В некоторых методиках (обычно в двух-итеративных или с Continuous Release), для раннего обнаружения отклонений от плана, кроме коллективной оценки, используется еще и индивидуальная оценка, но уже на уровне конкретных задач (которые выполняются индивидуально), на которые декомпозируется Story.
Объектом тестирования выступает поведение, а не юнит. Поведение однго юнита. И для проверки работоспособности лампочки совершенно неважно, ввернута она в торшер или в стенд.
P.S.: Пример с лампочкой был очень удачным, спасибо.
Я надеюсь, что вы, все-таки, прошли по ссылке, и ознакомились, как минимум, с названием статьи. То, что тестируемый вами юнит взаимодействует с другими, вовсе не означает то, что вы тестируете другие юниты:
«But not all unit testers use solitary unit tests.»
«Indeed using sociable unit tests was one of the reasons we were criticized for our use of the term „unit testing“. I think that the term „unit testing“ is appropriate because these tests are tests of the behavior of a single unit. We write the tests assuming everything other than that unit is working correctly.»
Я имел ввиду книгу Вернона, она сегодня, пожалуй, вторая, если даже не первая, по значимости в сообществе DDD. А в статью цитату Вернона вставил уже я. Но, рад, если понравилось.
Автору спасибо за статью, — интересная точка зрения.
то данный метод стоит объявить в отдельном классе. И эти классы называют сервисами.
Стоит добавить, что Сервисы бывают трех уровней: Application, Domain и Infrastructure. В данном примере Вы говорите именно о Доменном Сервисе. Ограниченный список оснований для создания Доменных Сервисов хорошо выразил Vaughn Vernon в «Implementing Domain-Driven Design».
Из текста статьи (и из ряда комментариев), создается впечатление, что, для многих, интеграционные тесты приравниваются к Sociable Unit Tests, а юнит-тестами считаются исключительно полностью изолированные Solitary Unit Tests. Я, конечно, могу в этом ошибаться, но мне так показалось. В таком случае, хотелось бы привести слова основателя TDD Кент Бека: "My personal practice — I mock almost nothing.". Интеграционные и юнит-тесты имеют немного разные цели.
можно менять интерфейс взаимодействия внутренних компонентов
Самотестируемость кода является первостепенным условием для осуществления его рефакторинга. А поэтому, действительно, тесты должны облегчать рефакторинг, а не накладывать на код оковы. Тестировать нужно поведение, а не реализацию, и спускаться в глубь реализации следует тогда, когда это необходимо для сокращения количества комбинаций тестовых условий. Наглядный пример: «Many people make bad trade-offs, especially with heavy mocking. Kent thinks it’s about trade-offs: is it worth making intermediate results testable? He used the example of a compiler where an intermediate parse-tree makes a good test point, and is also a better design.» — "Is TDD Dead?"
P.S.: Раз уж статья была помечена тэгом ТДД, то хотелось бы обратить внимание, что ТДД — это не методика тестирования, а методика проектирования и разработки.
я больше всего страдал от наличия «опытного архитектора»
Не знаю что сказать… Хороший архитектор должен привносить, как раз, облегчение, а не страдание. Разумеется, в балансе долгосрочных и краткосрочных интересов.
Зато другая половина — из противоположных идей
Если мне что-то в коде непонятно
Именно этим архитектор и должен заниматься — формированием коллективного понимания того, как устроена система (об этом еще Рольф Джонсон говорил). Если в первом, описанном Вами, случае проблема решалась через глобальный божественный объект, а во втором случае — в 10 раз больше кода, и никто (я полагаю, что не Вы один) не понимает зачем, то, мне трудно судить насколько опытным был ваш архитектор.
Но я хотел бы обратить Ваше внимание на другой момент. Из Ваших слов следует, что вы позиционируете свой уровень знаний выше уровня вашего архитектора (раз уж возмущаетесь его решениями). Но загвоздка в том, что если бы это было действительно так, то Вы бы легко и аргументированно, с отсылкой к первоисточникам, доказали бы ему свою правоту в прямом диалоге, а не выражали бы здесь сейчас свое субъективное отношение к нему. В профессиональном поведении принято разбирать проблемы предметно и по сути, а не выражать свое субъективное отношение к личности, тем более, за спиной этой личности (пусть даже и анонимизируя ее). С ваших слов, ситуация похожа просто на широко известный в ИТ-индустрии эффект Даннинга-Крюгера, ибо единственное, что объективно известно с Ваших слов, так это то, Вы имеете более высокое мнение о собственных способностях, чем это свойственно людям, должность которых подразумевает быть более компетентными.
связи между ними, согласно фен-шую — никакой, но работать как-то надо… а потому давайте-ка заведём тут, посреди этого всего, глобал и будем общаться через него».
В этом случае нужно просто правильно организовать внедрение зависимостей и соблюдать Low Copling and High Cohesion principle.
Наука, отвечающая за линейный рост стоимости изменения кода, в зависимости от увеличения его объема, называется архитектура. Конечно, если в команде нет опытного архитектора, то никакой CR не поможет.
Если вы работаете в условиях полной информированности — то нет проблем. Но гораздо чаще приходится работать в условиях недостаточной информированности. Если бы это было не так, то все до сих пор писали бы по BDUF, а не по Agile. И здесь, как раз, чаще случается обратное явление — предполагаемая потребность была реализована, потребляла ресурсы на сопровождение, но так и осталась невостребованной. Или же она оказалась востребованной, но через значительное время, т.е. потраченные ресурсы все это время были «заморожены» и не приносили выгоды.
Именно эту проблему и решают YAGNI и Evolutionary Design — достижение наилучшей экономики разработки в условиях недостаточной информированности.
Половина костылей и легаси рождаются именно под девизом
А поэтому, если решение ухудшает экономику разработки, то это не YAGNI, так как оно противоречит его назначению. Например, нарушение Open–closed principle не есть YAGNI. Хороший архитектор, наоборот, максимизирует количество неприятных решений.
Только не очень просто оценить
Воздержусь от обсуждений, выходящих за пределы темы статьи. Оценивание — это тема, действительно, не простая, особенно для новичков, но не такая уж и неразрешимая.
Разумеется делать так, чтобы в новом кода, который вы обсуждаете, можно было что-то улучшить
Тут, правда, следует отличать термины «улучшить» от «эволюционировать». Рефакторится не только плохой код, но и хороший код, который практикует принципы YAGNI и Evolutionary Design — необычайно мощные методики, дающие колоссальный прирост в темпах разработки.
Но нужно отличать рефакторинг с целью развития программы (т.е. эволюция решений, принятых ранее в условиях недостаточной информированности) от рефакторинга с целью повышения внутреннего качества и экономики разработки. Код должен поставляться всегда качественным, в то же время, с точки зрения YAGNI и Evolutionary Design, он не обязательно должен быть завершенным.
Существует простая лакмусовая бумажка принципа YAGNI: «выделение лишних абстракций (и любое другое усложнение) оправдано лишь в том случае, если стоимость их выделения в будущем будет существенно дороже, чем сейчас».
Никакие «хорошие» практики не сделают из олимпиадника хорошего разработчика.
Один из известнейших программистов истории говорил: «I'm not a great programmer; I'm just a good programmer with great habits.». Так что «правильные практики» могут сделать многое. Вопрос в самих практиках.
Если у вас нет времени сделать это правильно, то сделать это дважды — времени точно не будет. Потому что с точки зрения накопления техдолга, самая выгодная позиция у вас — именно сегодня, пока долг наименьший.
Нахождение баланса между бизнес-интересами и техническими интересами — очень непростая задача, которая трудно достижима на практике даже для опытных ребят (в силу эффектов Даннинга — Крюгера, Confirmation bias и т.п.). Именно для решения этой задачи и служат 4 переменные (Cost, Time, Quality, Scope), над которыми должен быть организован правильный контроль с соблюдением баланса сторон. Подробности, если интересно, можно найти в «Extreme Programming Explained» 1st edition by Kent Beck.
Описанная вами проблема всегда возникает при использовании «Collective Ownership» в отрыве от «Collaborative Development». Просто начните использовать практики «Collaborative Development».
Изначально все работали по BDUF, поскольку изменение реализованных проектных решений стоило очень дорого (стоимость росла экспоненциально). BDUF тоже стоит недешево, поскольку он создается в условиях недостаточной информированности (и обработка этой недостаточности требует работы высококвалифицированных архитекторов), а вероятность ошибки в этих условиях слишком высока. Но тем не менее, он стоил дешевле изменения реализованных решений.
В определенный исторический момент уровень зрелости методик разработки (OOP, TDD, Refactoring, Design Patterns, PoEAA и т.п.) достиг такого уровня, при котором изменение уже реализованных проектных решений стало стоить дешевле создания BDUF. График роста стоимости изменения кода изменился с экспоненциального на асимптотический.
Наука, отвечающая за линейный рост стоимости изменения кода, как я уже, говорил, называется архитектура. А поэтому, на собрании, которое организовал всем известный Robert C. Martin (автор Clean Code) для подписания Agile Manifesto в 2001 году, присутствовал ряд ведущих архитекторов того времени: Ward Cunningham, Kent Beck, Martin Fowler и др.
Иными словами, достижение низкой стоимости изменения кода открыло бизнес-возможность вести разработку итеративно, таким образом, чтобы проектные решения будущих итераций опирались на обратную связь (feedback) от практической эксплуатации реализации проектных решений предыдущих итераций.
Отсюда становится понятно, почему бывает что «Agile не работает в принципе», если правильно понимать его принцип (разумеется, кроме принципиальной причины, существует еще и ряд других причин — организационные, финансовые и пр.). Принципиальная же причина заключается в том, что многим проектам не удается удержать стоимость изменения кода низкой (обычно — в силу невысокого внутреннего качества программы), в итоге, исправление реализованных проектных решений стоит настолько дорого, что дешевле спроектировать все заблаговременно.
Только недавно я сталкивался с подобным legacy-проектом, в котором, несмотря на возраст всего в один(!!!) год, более 80% бюджета разработки тратилось на багфикс. Осуществить новую разработку ключевых компонентов с нуля стоило в разы дешевле, чем чинить их. При этом, заказчик не жадничал — проект имел хорошее финансирование, а разработчики, доведшие его до такого состояния, получали зарплаты существенно выше рыночных. Вообще, должен сказать, что я часто наблюдаю на рынке труда предложения «спасти» проект от финансового краха, и возраст таких проектов редко превышает 3 года. Т.е. в среднем, уже через 3 года дальнейшая разработка таких проектов становится нерентабельной, и инвесторы прибегают к радикальным решениям.
P.S.: rudnevr, статья, конечно, имеет несколько броскую стилистику изложения, но в целом, по моему мнению, вам удалось ухватить проблему за хвост. Мне кажется, что статья заслуживает больше, чем ее оценили, и соответствует своему саркастическому стилю. Продолжайте писать.
Ну, мы обсуждаем не стандарты, а проблему, озвученную как «Никакие «хорошие» практики не сделают из олимпиадника хорошего разработчика.» Для решения этой проблемы и существуют практики Collaborative Development. И они работают, если, конечно, уметь их «готовить» («Extreme Programming Explained» 1st edition раскрывает эту тему).
Кстати, Agile можно встретить в ряде стандартов, например, в ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes, или в ГОСТ Р 56920-2016.
Что касается корректности перевода термина «практики», то п. 3.3.8 действующего ГОСТ Р ИСО/МЭК 33001-2017 определяет ее как «практика (practice): Определенный тип активности в рамках выполнения процесса.»
Искренне надеюсь, что вы ознакомились с фамилиями 17-ти этих «шустрых ребят», и осознаете их вклад в развитие ИТ-индустрии (помимо Agile), прежде чем это написать.
Возможно, но это уже выходит за рамки обсуждаемой проблемы о практиках, которые могли бы сделать из олимпиадника хорошего разработчика.
Но проблема, на самом деле, не в самом уме как таковом, а в их привычке обращаться со своим умом. Для решения этой проблему и существуют «практики», и когда такие ребята осваивают базовые принципы гибкой разработки, — они становится очень успешными (я знаю целый ряд таких примеров, когда умственные способности из тормоза общего процесса превращались в мощнейший его катализатор).
Задача практик заключается в том, чтобы все гайки затягивались в нужный момент времени, в нужной последовательности, с нужным усилием (моментом) затяжки, в отведенный интервал времени, выполняли свое назначение и чтобы качество результата не зависело от уровня квалификации конкретного участника команды.
Planning poker — это форма коллективной оценки, которая используется для оценки Story (поскольку Story выполняется коллективно). Коллективная оценка тоже имеет свою стоимость, и, поэтому, затраты на нее должны находиться в балансе с бизнес-выгодой от этой оценки (обычно это не более 5% от релиза/итерации/спринта в зависимости от конкретной методологии). Высокая точность оценки и понимание всех деталей реализации на этом этапе не требуется (поскольку затраты на точность оценки растут экспоненциально, а бизнес-выгоды от этой точности — линейно). В некоторых методиках (обычно в двух-итеративных или с Continuous Release), для раннего обнаружения отклонений от плана, кроме коллективной оценки, используется еще и индивидуальная оценка, но уже на уровне конкретных задач (которые выполняются индивидуально), на которые декомпозируется Story.
Объектом тестирования выступает поведение, а не юнит. Поведение однго юнита. И для проверки работоспособности лампочки совершенно неважно, ввернута она в торшер или в стенд.
P.S.: Пример с лампочкой был очень удачным, спасибо.
«But not all unit testers use solitary unit tests.»
«Indeed using sociable unit tests was one of the reasons we were criticized for our use of the term „unit testing“. I think that the term „unit testing“ is appropriate because these tests are tests of the behavior of a single unit. We write the tests assuming everything other than that unit is working correctly.»
Стоит добавить, что Сервисы бывают трех уровней: Application, Domain и Infrastructure. В данном примере Вы говорите именно о Доменном Сервисе. Ограниченный список оснований для создания Доменных Сервисов хорошо выразил Vaughn Vernon в «Implementing Domain-Driven Design».
Самотестируемость кода является первостепенным условием для осуществления его рефакторинга. А поэтому, действительно, тесты должны облегчать рефакторинг, а не накладывать на код оковы. Тестировать нужно поведение, а не реализацию, и спускаться в глубь реализации следует тогда, когда это необходимо для сокращения количества комбинаций тестовых условий. Наглядный пример: «Many people make bad trade-offs, especially with heavy mocking. Kent thinks it’s about trade-offs: is it worth making intermediate results testable? He used the example of a compiler where an intermediate parse-tree makes a good test point, and is also a better design.» — "Is TDD Dead?"
P.S.: Раз уж статья была помечена тэгом ТДД, то хотелось бы обратить внимание, что ТДД — это не методика тестирования, а методика проектирования и разработки.
Именно этим архитектор и должен заниматься — формированием коллективного понимания того, как устроена система (об этом еще Рольф Джонсон говорил). Если в первом, описанном Вами, случае проблема решалась через глобальный божественный объект, а во втором случае — в 10 раз больше кода, и никто (я полагаю, что не Вы один) не понимает зачем, то, мне трудно судить насколько опытным был ваш архитектор.
Но я хотел бы обратить Ваше внимание на другой момент. Из Ваших слов следует, что вы позиционируете свой уровень знаний выше уровня вашего архитектора (раз уж возмущаетесь его решениями). Но загвоздка в том, что если бы это было действительно так, то Вы бы легко и аргументированно, с отсылкой к первоисточникам, доказали бы ему свою правоту в прямом диалоге, а не выражали бы здесь сейчас свое субъективное отношение к нему. В профессиональном поведении принято разбирать проблемы предметно и по сути, а не выражать свое субъективное отношение к личности, тем более, за спиной этой личности (пусть даже и анонимизируя ее). С ваших слов, ситуация похожа просто на широко известный в ИТ-индустрии эффект Даннинга-Крюгера, ибо единственное, что объективно известно с Ваших слов, так это то, Вы имеете более высокое мнение о собственных способностях, чем это свойственно людям, должность которых подразумевает быть более компетентными.
В этом случае нужно просто правильно организовать внедрение зависимостей и соблюдать Low Copling and High Cohesion principle.
Наука, отвечающая за линейный рост стоимости изменения кода, в зависимости от увеличения его объема, называется архитектура. Конечно, если в команде нет опытного архитектора, то никакой CR не поможет.
Именно эту проблему и решают YAGNI и Evolutionary Design — достижение наилучшей экономики разработки в условиях недостаточной информированности.
А поэтому, если решение ухудшает экономику разработки, то это не YAGNI, так как оно противоречит его назначению. Например, нарушение Open–closed principle не есть YAGNI. Хороший архитектор, наоборот, максимизирует количество неприятных решений.
Воздержусь от обсуждений, выходящих за пределы темы статьи. Оценивание — это тема, действительно, не простая, особенно для новичков, но не такая уж и неразрешимая.
Тут, правда, следует отличать термины «улучшить» от «эволюционировать». Рефакторится не только плохой код, но и хороший код, который практикует принципы YAGNI и Evolutionary Design — необычайно мощные методики, дающие колоссальный прирост в темпах разработки.
Но нужно отличать рефакторинг с целью развития программы (т.е. эволюция решений, принятых ранее в условиях недостаточной информированности) от рефакторинга с целью повышения внутреннего качества и экономики разработки. Код должен поставляться всегда качественным, в то же время, с точки зрения YAGNI и Evolutionary Design, он не обязательно должен быть завершенным.
Существует простая лакмусовая бумажка принципа YAGNI: «выделение лишних абстракций (и любое другое усложнение) оправдано лишь в том случае, если стоимость их выделения в будущем будет существенно дороже, чем сейчас».
Один из известнейших программистов истории говорил: «I'm not a great programmer; I'm just a good programmer with great habits.». Так что «правильные практики» могут сделать многое. Вопрос в самих практиках.
Нахождение баланса между бизнес-интересами и техническими интересами — очень непростая задача, которая трудно достижима на практике даже для опытных ребят (в силу эффектов Даннинга — Крюгера, Confirmation bias и т.п.). Именно для решения этой задачи и служат 4 переменные (Cost, Time, Quality, Scope), над которыми должен быть организован правильный контроль с соблюдением баланса сторон. Подробности, если интересно, можно найти в «Extreme Programming Explained» 1st edition by Kent Beck.
Описанная вами проблема всегда возникает при использовании «Collective Ownership» в отрыве от «Collaborative Development». Просто начните использовать практики «Collaborative Development».