Манифест жёсткого программиста

Прошу прощения, а чем Agile провоцирует «назвал сроки, завысил ожидания и возбудил аппетит.»? Если мне не изменяет память оценки complexity, ретроспективы, планирование спринтов, как раз и призваны сказать, какой будет срок от фичи до релиза с учетом capacity команды. Возможно я не так понимаю agile разработку?

Манифест жёсткого программиста

Вообще Agile неплохо так защищает кодеров от произвола менеджмента — так как он призван быть гибким — и гибкость эта раскрывается в умении адаптации процесса разработки под требования бизнеса И команды. Если вам не повезло работать в командах, которые просто бездумно выполняют ритуалы и не вовлечены в улучшение процесса разработки — это не проблема Agile =)) Во всех гибких командах, где бы мне не довелось работать в РФ и в Европе мы всегда выстраивали свой процесс и оптимизировали его. И так же радели за качество продукта и архитектурные изыскания и процесс ввода фич из беклога в спринты/канбан доску. Да! Agile работает не для всех продуктов, есть продукты где лучше работает водопад, но такова жизнь. Agile — не волшебная палочка для решения проблем — единственную проблему, которую вижу я сейчас с этим вопросом — это то, что его как и любой «модный инструмент» подают под соусом «мазь для решения всех ваших проблем с разработкой ПО». Да и всегда следует помнить, что рабочие места организует бизнес, не будет бизнеса не будет и программистов =) А последнее время и вы и другие коллеги все чаще подают такую мысль: «Я — программист, я — основа этого бизнеса, без меня его не будет — следовательно, я хочу диктовать свою волю бизнесу», но это не так работает =)) Обучить кодера — это полгода — еще за год сверху он станет крепким мидлом, поверьте заменить человека сложно, но на рынке уже есть подготовленные кадры, поэтому свою волю бизнесу навязывать ультиматумами — глупо. Что сделать спросите Вы? Я отвечу — все очень просто — меняйте бизнес-процессы изнутри, если в ваших предложениях есть измеримая, хотя бы косвенно прибыль — то сознательный бизнес мало того, что пойдет на встречу, но и выделит вас, может сделает техническим управленцем даже =)) А если бизнес не хочет вести диалог на своем языке — то и нафиг там работать(мы же программисты-здвёздочки — найти новую работу ведь легко =)))

Менеджерам пора проснуться

Это ж как у вас построен процесс, что программист не отвечает за свои предложения и реализации? Ок я согласен, если было принято стратегическое решение всей командой, то ответственность распределяется на команду, то бишь на ПМ, Тим Лидов и линейный состав, да при таком распределении больше спроса будет с ПМ и Тим Лидов, но опять же неудачные решения должны быть отсечены опытными участника ми команды. Плюс ведущие разработчики должны понимать нужды бизнеса и обкатывать новые идеи только в рамках новых микросервисов, если есть такая возможность. А то уж очень однобокая у вас позиция получается. Мол программист за свои идеи не отвечает, следовательно право голоса у него урезано, да и в общем то вся власть у меня, как у ПМа, так что забудьте друзья про инновации =) Я согласен с вами, что внедрение технологий должно иметь бизнес мотивацию — например сокращение накладных расходов, ускорение критичных мест, улучшение масштабируемости, сокращение технического долга. Опять же крайне печально, если ваши разработчики такого не понимают, а хотят лепить технологии ради технологий — тут кстати может быть и проблема обучения разработчиков. Во всяком случае ни когда я работал ПМом, ни когда перешел в ряды разработчиков не было даже идеи о том, чтобы влепить новую технологию без бизнес-обоснования. Да и за коллегами такого не замечал.

Можно ли использовать Laravel для больших Enterprise-решений?

У меня для вас плохие новости, но то что вы описали как раз и является примером фрактала плохого кода. А именно ТТУК и прочие фишечки. Примеры кода в документации Laravel приведены as is с использованием Facades, которые в большинстве случаев не используются напрямую в правильном коде, для введения дополнительных объектов существует крайне умный DI, что так же повышает тестируемость кода. Структурированием кода так же занимается программный архитектор/ведущий разработчик/тимлид. Да Laravel дает довольно много свободы в плане написания кода и очень редко заставляет вас писать код по шаблону. Поэтому написание крупных, да и вообще нормальных проектов на Laravel требует серьезной дисциплины и понимания. Если вам требуется погонщик с хлыстом, чтобы не сходить с right way, то тогда Laravel не для вас. А вообще холиварить на эту тему можно долго, но статистика говорит об обратных цифрах. с 2015 года Laravel бьет все рекорды по популярности в мире PHP, как для пет-проектов, так и для рабочих, просто в Западном мире. И даже не стоит отрицать того факта, что платная подписка на Laracast дает кучу видеоуроков крайне полезных с best-practice разработки, где люди на пальцах рассказывают про TDD, BDD и грамотное проектирование и работу с проектом, которые кстати вы можете спокойно перенести в работу с другими фреймворками.