Как стать автором
Обновить

Комментарии 9

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

Странно ожидать от мух ничего кроме как фокусировании на сортах. Если есть болезнь, значит есть необходимость в лечении. Если бы разрабы идеально делали всё правильно и вовремя, то и необходимости в этих подходах не было бы.

Огромная проблема всех подобных "решений" - это шатание по крайностям. Либо всё, либо ничего, посередине не существует. Двоичное мышление, чтоб его.

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

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

Единственное справедливое утверждение:

Анти‑Agile акцентирует внимание на том, чтобы в начале проекта были зафиксированы четкие требования, что минимизирует вероятность изменений в будущем.

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

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

По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.

Остальные утверждения - очень спорные.

Agile поощряет изменения и адаптацию, тогда как анти‑Agile требует строгого следования заранее установленным процессам и графикам.

Нет.

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

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

Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.

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

Свод подходов во второй половине статьи для неруководителя полезный: чаще всего — с учётом того, что не занимаюсь исследованием такой информации профессионально, а просто хватаю, что само слышится — звучат сам эджайл, вотерфол и лин, остальные, можно сказать, здесь для себя только открываю; а вот анти-эджайл сам по себе звучит почти как фордовский конвейер (безоценочно, просто высказываю наблюдение)... Но можно ли говорить о настолько строгом регламентировании процессов там, где нет речи о "вырезать деталь — сформовать — окрасить — передать на соединение с другими"? Всё-таки, наряду с шаблонными подходами к шаблонным элементам задач, где доступно, в разработке очень даже приходится и поизобретать — а это как будто заключить в расписание сложнее.

Уважаемая редакция. Если вы приводите в качестве альтернативы SAFe, то следует понимать, что А в этой аббревиатуре — это Agile, натянутый на глобус корпорацию. Почему я зацепился за SAFe? Потому что именно из тех же мотивов про сложные проекты и разрозненные команды выросла эта методология. О том, почему Agile не масштабируется в своей исходной концепции, также рекомендую разобраться. В ином случае список альтернатив не будет иметь ценности больше, чем поиск в Google.

Но давайте честно: Agile не идеален

Или всё же его применение? Я ничего не хочу сказать в пользу Agile здесь, но этот серьёзный тезис требует серьёзных аргументов в качестве подкрепления. Иначе, "а вы, друзья, как ни садитесь...."

И всегда-всегда триггерит вот это "но давайте честно". Ломовой способ манипуляции наряду со "всем давно известно" и "никто не будет спорить".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий