Comments 36
Почему Agile больше не спасает проекты в России?
Ушёл Agile - завяли помидоры.
А оно разве, что-то спасало? :) проекты спасали конкретные исполнители, а уж какими способами, вопрос "десятый" :)
Воистину так. Можно сколько угодно планировать, расписывать, нарезать, но если условный Вася Пупкин не напишет код, то все это ерунда. А код он может написать и без этих шаманских плясок и заклинаний. Вася без методологов и адептов всякой хрени прекрасно обойдется; они без Васи - никак. Весь смысл их существоаания заключается в наличии этого самого Васи
Потому в нашем ойти любят KPI, ттм и другие модные абревиатуры. А про нормальные бизнес процессы я промолчу. Не доросли... Простите.
Да, "новомодный" KPI отлично "подстегивает" в развитии компании))
А ещё новомодные ОКРы приходят)
все новое - это хорошо забытое старое. Раньше это было: Опытно Конструкторская Работа.
Не. Это другое. Objective Key Results. Типа каждый период человек ставит себе таких несколько штук, которых он должен достигнуть... Или отдел должен достигнуть... Ну и т.п.
Это сверх всяких KPI, Agile, waterfall и прочего
ипа каждый период человек ставит себе таких несколько штук, которых он должен достигнуть...
самое интересное что человек может себе поставить Objective Key Result в виде: перейти на работу в другую компанию и на в два раза большую зарплату, а в бумажку (Джиру-какую-то) написать совсем другое. Я прям про такой случай слышал из первых рук - когда начальство долбило разработчиков-проектировщиков, что они должны искать себе работу сами, только начальство, видимо, не очень понимало что работа для разработчиков-проектировщиков существует не только под его началом.
Но это другое, точно! Это я всегда согласен :) !
Нет же, это обсессивно-компульсивное расстройство.
Agile-методологии, основанные на манифесте 2001 года, стали краеугольным камнем современной разработки программного обеспечения (ПО) благодаря своей гибкости, ориентации на клиента и способности адаптироваться к изменениям.
В этой фразе все прекрасно, прекрасно даже то чего в ней нет.
Но ни одна методология не заменит инженерно-технической экспертизы-компетенции! И если этой базы нет, то никакие методологии не помогут и даже наоборот они отвлекают внимание руководства в сторону от формирования именно инженерно-технической экспертизы-компетенции на организационные вопросы. Действительно, как стратегия отвлечения внимания эти методологии какое-то время работают - у всех создается ощущение что процессы становятся лучше, ведь все только этим и занимаются! Но со временем через лоск красивых отчетов и высокоумных процессов неизменно проступает бедность, а иногда и убогость инженерно-технической экспертизы-компетенции, которыми просто некому было заниматься, отсутствие профессионализма на инженерно-техническом уровне, который просто никому не интересен потому что главное - это красивые отчеты по гибкой организации работы.
Да он никогда и не спасал.
Потому что вместо Agile в 90% корпораций карго культы со своими племенными вождями и шаманами. На Хабре в корпоративных блогах зачастую радостно евангелизируют свой корпоративный Agile, который не соответствует Agile-ценностям ни разу.
"Гибридные подходы (Agile + Waterfall) доминируют, так как "чистый" Agile не подходит для долгосрочных проектов в условиях нестабильности." - а waterfall же как раз известен оптимальностью его применения для долгосрочных проектов в условиях нестабильности?
Секрет же прост и банален, в "крупных компаниях" чаще всего в роли представителя Заказчика выступают сотрудники, которые тратят не свои деньги, это раз, нежелающие увеличения своей работы, которая бы требовала от них реальных усилий, это два, и действительно, зачастую, ответственность за проект к ним прилетает строго дополнительно к имеющимся текущим обязанностям, это три.
В итоге, чтобы делать честный аджайл, нужно сначала заказать в ИТ то, что действительно окажет эффект, потому что уже через месяц, нужно будет этот эффект подтвердить (или ответить за неподтверждение), плюс требуемая скорость подразумевает существенное количество единоличных и реальных решений ряда должностных лиц, которые они должны принимать со всеми их последствиями, если на каждый "чих" устраивать традиционную "собачью свадьбу" на ...дцать персон, половина из которых ещё вопрос "распишет" на своих замов, то время, потраченное на всякую бюрократию, будет кратно больше времени полезной работы и это будет прямо бросаться в глаза.
То ли дело, святой waterfall, когда можно назаказывать кучу всего по принципу "мне вот так хочется", причем без особой даже проработки того, а что хочется, мы же только в самом начале большого пути, так что на этом этапе допускаем, что закидаем просто в общих чертах потребности свои, потом насчитать всякой ерунды в эффектах, согласовать это за несколько месяцев с целым сарафаном всяких участников для размытой коллективной ответственности за результат, уйти "в проект" на три года, после которых эффекты не сыграют, но это ничего страшного, мы же вон когда считали, за три года все поменялось.
Удобно. Но, топы-то (или даже мажоритарии) требуют аджайл, хотят быть на острие моды, хотят бесплатно поднять эффективность и выглядеть современными, прогрессивными и конкурентоспособными. Тогда звено ниже придумывает "гибрид", чтобы от вотерфолл взять самое, для них, нужное, общие сроки и безответственность, ну и чтобы "с высоты птичьего полета" это было похоже на аджайл - всякие еженедельные, ежедневные, бумажки, встречи, протоколы, графики и планы - это знакомо и нравится, к тому же, тратит рабочее время, которое можно провести без усилий. И потом статью на хабре написать, почему аджайл плохой выбор в условиях нестабильности. ;-)
Представьте что аджайл, это правила дорожного движения. А теперь попробуйте порассуждать работают они или нет ))) Спасают они жизни или нет... А если не спасают.. то может быть они не работают... и их надо отменить...
Аджайл это не ПДД, не юридический и не физический закон. Это свод рекомендаций.
И? ))) Если их не соблюдать? Что происходит? ))
Да ничего фатального особо не происходит. Проекты пилятся, ну пусть в обычных условиях менее эффективно, чем при хорошем agile. Некоторые проекты проваливаются, ну так они и при agile, бывает, проваливаются.
То ли дело ПДД - если выехать на красный, сразу хороший шанс повредить имущество, убиться, убить кого-нибудь.
Правильно, Ну также и ппд, и без пдд можно ездить, просто движение будет менее эффективно и больше людей будет погибать.
На красный, можно много раз проезжать и ничего не случится)) а можно никогда на красный не проезжать и попасть в аварию с зеленым))) так в чем же дело?)
Ну так люди и с пдд калечатся и без пдд.. Верно? Вот так и с аджайлом)) и ним делают/валят проекты, - и без него.
Значит ли это, что аджайл плохой? Значит ли что ПДД плохие?
рекомендация становится законом когда ее записали в какой-нибудь кодекс и назначили наказание за не выполнение. Но от этого рекомендация не перестала быть рекомендацией.
Кстати поставить в определенном месте при определенных условиях светофор - это тоже изначально просто рекомендация, а потом это стандарт организации дорожного движения, а потом эта рекомендация может быть оформлена как закон с определенной ответственностью для кого-то.
рекомендация становится законом когда ее записали в какой-нибудь кодекс и назначили наказание за не выполнение. Но от этого рекомендация не перестала быть рекомендацией.
Спасибо за пояснение. Получается, разница в наказании. Где наказывают за отклонение от agile - там это закон :)
Ну бывает по разному, просто отклонение от аджайл, это как правило, бардак, хаос, несогласованость целей, неслаженность команды, с такими меньше сотрудничают... Вот как Вы можете наказать человека, который меняет цели каждый день или не желает с вами согласовывать общие цели? Или у которого другие правила/рекомендации, по которым он работает, или он выборочно правила трактует как ему удобно... Ну.. скорее всего сведете по минимуму с ним взаимодействие... С Вашей стороны это и будет наказание..
Статья избыточна в числах, много слов, а смысл в одном предложении: "Наконец наступило понимание что выкинуть толстую книгу PM BoK и заменить на листик Аджайла не решит проблему управления".
Далее как обычно у пользователей Аджайла. Методология то, сё. Автор, Аджайл это не Методология, это Метод.
"Если забить на документы, чаще общаться с Заказчиком и собираться каждое утро для пения хором Мы-команда, то проект будет успешным".
Это работает. Правда. Но где всё остальное? План, бюджет, риски... От того, что это постарались забыть, оно никуда не исчезло. И именно поэтому:
- весь этот "чистый Аджайл" работает только на проектах уровня пионерлагеря. Потому что дальше приходит неизбежный водопад.
- ещё в 2020 году все радостные внедренцы Аджайла" вне ИТ" резко к нему охладели.
Автор, спасибо, статья большая конечно и аргументов много. Но сама тема слабая и 100 раз обсуждённая.
Agile бывает неуспешен из-за кривого его внедрения, иногда внедряют так, что получается более негибко, чем в любых других подходах. "Заставь дурака Богу молиться - он лоб расшибёт". По сравнению с таким agile даже отсутствие методологии приносит больше результатов.
Вместе с тем даже весьма вольное и частичное следование принципам agile может приносить хорошие результаты. Успешность проекта больше зависит от управленческой компетентности менеджера, а не от декларируемого названия методологии.
Имхо, любой фреймворк типа SAFe, если он при внедрении не превратился в кастомный через какое-то время — маразм. Сами принципы Agile не предполагают жёсткости. Но нет, мы получили весь этот идиотизм сертификациями, "без бумажки ты букашка" и прочий формализованный идиотизм под видом Agile.
Имхо: в статье много фактов и цифр, но нет ни одной ссылки на источники. Есть ощущение, что статья AI-generated. Тем не менее, интересный повод для дискуссий (спасибо автору). Ко всему вышеизложенному добавлю только афоризм (не помню где услышал): "Наш проект управляется по Agile, поэтому закончится тогда, когда закончатся деньги" :)
Почему Agile больше не спасает проекты в России?