Site icon AppTractor

Agile-проекты превратились в Водопады со спринтами

Делать Agile — это не то же самое, что быть Agile.

Agile-проекты превратились в раздутые, ленивые Waterfall проекты с двухнедельными спринтами. Подход с каскадной производственной линией подходит для проектов с известными требованиями или создания виджетов.

Сейчас Agile-проекты — это какашка, обваленная в изюме и названная розой. Любой разработчик даже с половиной носа может учуять, что это не розы, а запоздалый или провальный проект, который только и ждет, чтобы случится.

Agile-манифест полон энтузиазма, энергии и позитивного настроя. Он позволяет небольшим командам создавать программное обеспечение с минимальным руководством и предлагает им просто пойти и сделать его.

Agile не устанавливает точных правил, которым нужно следовать, потому что вы должны учиться и совершенствоваться по мере продвижения и вырабатывать наиболее эффективный способ работы на основе обратной связи. Он признает, что не существует лучших способов, потому что каждый проект уникален.

Agile обещал быстрее поставлять программное обеспечение, а клиентам быстрее окупать вложения. Но когда вы хайпуете на любой проектной мифологии больше, чем на концерте Леди Гаги, разочарование, скорее всего, будет ждать вас в 99% Agile-проектов.

Agile превратился в чопорного старика

Agile завоевал мир и стал настолько популярным, что клиенты требовали Agile-проектов независимо от того, был ли это хороший выбор и были ли для него нужные люди.

В книге «Раньше, безопаснее, счастливее: антишаблоны и шаблоны для гибкости бизнеса» авторы жалуются, что проекты просто делают Agile вместо того, чтобы быть Agile (гибкими). Agile стал продуктом, а не образом мышления.

Это змеиное масло Agile, формочка для печенья Agile, Agile из коробке. Установите его, и вы будете Agile. Это Agile ради Agile — Раньше, Безопаснее, Счастливее.

Я бы сказал, что все еще хуже. Компаниям и командам разработчиков нужна гибкая поставка, которая включает в себя продуктовые беклоги, спринты и фиксированные сроки/стоимость. Гибкая часть гибких проектов полностью удалена.

Это больше похоже на Waterfall проекты с предварительными требованиями, фиксированными сроками, спринтами и двумя демо в неделю.

Слово Agile ничего не значит, и Agile-проекты выжали из себя всю гибкость.

Худший из всех миров

Есть много проектов, которые Agile по названию, но хаос на самом деле.

Нет желания расширять права и возможности небольших команд. Менеджмент не доверяет командам и хочет контролировать все решения, и это приводит к взрывному росту числа совещаний.

Нет фокуса на улучшении способов работы для оптимизации проекта.

Этот дополнительный уровень менеджмента и совещаний замедляет разработку, давая командам разработчиков все меньше и меньше времени на разработку. Любое время, выигранное от удаленной работы, тратится на митинги.

Разработчики более заняты и одиноки, чем когда-либо прежде. Выгорание в больших количествах и продолжение смены работ в надежде, что следующая компания будет лучше.

Надувной дартс

Разработка программного обеспечения Wagile — это группа методологий разработки программного обеспечения, которые являются результатом попытки реализовать Agile в средах, которые не идеально подходят или плохо подготовлены для этой методологии, где в результате подход представляет собой комбинацию методологий Agile и Waterfall — Wiki.

Wagile не подходит для создания уникального программного обеспечения. Это надувная доска для дартса или шоколадный чайник.

Он создает невыполнимые планы для доставки проектов с опозданием и с более высокими затратами. Никто не знает, как программа должна работать на старте. Это внезапный процесс, когда вы обнаруживаете требования по мере того, как требования высокого уровня превращаются в подробные.

Вы не можете установить фиксированные сроки, если не знаете все требований и не гарантируете, что они не изменятся.

Как мы сюда попали?

Водопадные проекты плохо подходили для программных проектов до появления Agile и до сих пор не подходят для них.

Agile предложил волшебный способ быстрой и своевременной реализации проектов небольшими командами. Agile не был волшебной формулой, которая превращала плохих разработчиков в супергероев и выполняла все проекты вовремя (спойлер, волшебной формулы не существует).

Теперь у нас есть «более зеленая» трава в новом сценарии.

Слишком заняты, чтобы думать

Мне нравилось работать над Agile-проектами, потому что они могли начинаться плохо, но была надежда, что они улучшатся. Было приятно, что команду разработчиков просили выявлять проблемы и выдвигать предложения (которые в основном игнорировались как слишком сложные).

Команда разработчиков чувствовала (слегка) возможность принимать решения и действовать быстро. Наличие владельца продукта, который может принимать решения, позволило разработчикам иметь прямой доступ к бизнес-экспертизе.

В наши дни Agile — это медленная, разочаровывающая борьба, подпитываемая встречами. Как плавание в арахисовом масле: много усилий и небольшое продвижение.

Методология Agile-проектов не исчезнет, ​​но она уже вошла в стадию дойной коровы с проектами, использующих Agile, но не являющихся Agile. Впрочем, слухи о смерти Agile сильно преувеличены.

Когда наступит конец света, останутся Agile-проекты, опаздывающие и доставляемые тараканами :-)

Вывод

Люди являются причиной успеха или неудачи. Методология проекта, технологии и языки программирования — это инструменты, используемые для создания программного обеспечения.

Нет и никогда не будет волшебной формулы для реализации проектов.

Вскоре появится новая проектная методология, которая пообещает выполнять проекты программного обеспечения вовремя и в рамках бюджета. Это не сработает, но мы все получим удовольствие, изучая новые термины и присоединяясь к культу новой методологии.

Сейчас же мы застряли в подходе к проектам наполовину водопад/наполовину Agile, который берет понемногу от каждого подхода и все равно делает опаздывающие проекты.

Источник

Exit mobile version