Мифы об Agile. Миф №4: Agile мертв

Мифы об Agile. Миф №4: Agile мертв

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

Виктор Вальчук
Критическая цепь. Управление проектами по ТОС

Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.

Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 3 июня 2024.

ПОДРОБНЕЕ

«Никто больше не работает по Agile, все перешли на что-то другое»

«Что-то другое» в этом контексте – это обычно DevOps. Сейчас я не эксперт с черным поясом по DevOps, но из того, что я знаю о нем, он великолепен и отлично подходит для Agile-разработки. Но это не замена Agile, это дополнение.

Agile рассказывает, как воспринимать идеи и превращать их в программное обеспечение в среде разработки или тестирования. То есть подготовить его для выпуска.

Помните определение непрерывной поставки (или доставки, кому как нравится)? Это когда программное обеспечение находится в таком состоянии, что может быть выпущено в использование в любое время. DevOps – это несколько компонентов, но в основном они оптимизируют сам процесс выпуска ПО в использование.

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

Другим «чем-то другим» может быть CMMI (интеграция моделей зрелости), снова Waterfall (правда?) или Lean Startup. Не поймите меня неправильно, у Lean Startup есть несколько действительно хороших идей, но опять-таки, это не методология разработки программного обеспечения, а методология управления продуктом. Управление продуктом заключается в том, чтобы найти продукт, подходящий для рынка, то есть выбрать, что создать. Agile – это поиск наилучшего способа создания продукта, который вы выбрали с помощью своей методологии управления продуктами. Видите разницу?

Управление продуктом: создать правильный продукт.

Разработка программного обеспечения: создать продукт правильно.

Как и в случае с DevOps, Lean Startup и Agile хорошо работают вместе, а не заменяют друг друга. Найдите свой продукт с помощью Lean Startup, создайте его с помощью Agile, а затем разверните его с помощью DevOps. Так и делают успешные стартапы сегодня.

«Люди начали работать по Agile, но оказалось, что он просто не работает. Поэтому они отказались от Agile, и теперь он мертв»

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

Конечно, определенно были истории провалов с Agile. Но это не должно быть сюрпризом. Agile – это не панацея, и никто этого не обещал. Agile не гарантирует успеха. Проекты Agile проваливаются быстро и заметно. Проекты Waterfall умирают медленной, мучительной смертью.

Критики любят ссылаться на истории о больших ужасных провалах Agile, но есть множество (столько же, если не больше) историй о больших провалах Waterfall. Означает ли это, что Waterfall мусор? Конечно, нет. Я действительно считаю, что Waterfall может быть хорошим способом работы для определенных проектов в определенных контекстах. Поэтому все эти примеры бесполезны и обычно являются признаком глубоко укоренившейся предвзятости подтверждения.

«На самом деле никто не занимается Agile-разработкой, все только говорят, что занимаются»

Вероятно, большинство людей имеют в виду именно это, когда говорят, что Agile мертв, и в этом есть большая доля правды. Логическая цепочка примерна такая:

  1. Agile был классной идеей.
  2. Затем возможности Agile быстро раздули и разбавили нечистые на руку консультанты и продавцы чудодейственных снадобий.
  3. После этого Agile достиг пика в цикле зрелости технологии Gartner. Все вскочили на подножку уходящего поезда и начали говорить, что они используют Agile, точно так же, как консультанты на втором этапе.
  4. И вот Agile достиг дна в цикле зрелости (слишком раздутые ожидания и в итоге разочарование) и теперь мертв.

На самом деле в приведенных выше утверждениях есть доля правды. Agile действительно стал одной из «крутых умных технологий», которые внезапно захотели использовать организации по всему миру.

Есть много организаций, занимающихся странной псевдо-Agile ерундой. И самое главное, многие организации плохо или неправильно работают с Agile. Но вы знаете, что? Есть много организаций, которые так же плохо справляются с Waterfall, но почему-то никто не бегает и не кричит: «Waterfall мертв!».

Agile ни жив, ни мертв

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

Люди внезапно не перестали заниматься Agile. Они пытаются его использовать. Некоторые делают это лучше и целесообразнее, чем другие. И они достигают больше успеха, чем другие. Мы все пытаемся, и мы все учимся.

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

Разве SAFe (Scaled Agile Framework) признак того, что Agile изжил себя?

SAFe – это фактически скрам для крупных организаций. Скрам предназначался для работы в небольших группах (до 9-11 человек), работающих в небольших компаниях. Есть трудности и вопросы без ответа о том, как заставить его работать в крупных организациях в больших командах. Тогда люди придумали систему SAFe, которая должна была решить эту проблему. SAFe – это сомнительный ящик Пандоры, который я пока не хочу открывать. Но достаточно сказать, что какими бы ни были проблемы с SAFe, они специфичны для SAFe и не влияют на Agile-разработку программного обеспечения.

Автор: Leon Tranter
Источник
Business photo created by freepik — www.freepik.com

Прорыв

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!


Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.

Давайте обсудим...