Comments 7
почему Agile — это секта
Лет 10 уже читаю различные анафемы аджайлу. И всё время тезисы болтаются на уровне "мне знакомые пацаны рассказали, что у них в проекте бардак - значит аджайл фигня в принципе". Рабинович напел. Далее, как правило, следует явление миру новой уникальной методологии разработки. Которая, конечно же, ни разу не аджайл, и железобетонно защищена от любых злоупотреблений. Верим.
Потому что именно так оно полезнее: специфицированная методология «для всех» неизбежно превращается в бюрократию, а вот гибкий класс - в реальный инструмент.
Интересно почему же у аджайла не получилось, это же тоже методология направленная на результат и кажется даже более гибкая? Да и скрам тоже нацелен на результат и одна из основ это то самое доверие к исполнителю.
Приёмщик формулирует задачу с измеримыми критериями.
Вот на этом пункте погорели гибкие методологии. Источник бабла по умолчанию предпочитает считать, что он платит за решение проблемы. А формулирование проблемы - задача исполнителя. А исполнитель - ждет вменяемого описания требований приемки до выполнения задач. В результате, все погрязли в бесконечных согласованиях еще на этапе начала работ.
Вся проблема в том, что в российских корпорациях процветает карго культ. А именно, бездумное внедрение методологии без понимания, в каком контексте она создавалась и работает, и что надо поменять в процессах команды, чтобы метода стала рабочей.
Это как внедрение ИИ. Все ждут быстрых результатов не подозревая, а то чтобы ИИ заработал, нужно провести работу по приведению в порядок процессов и артефактов команды
Kanban честно визуализирует поток задач, но при малейшем отсутствии дисциплины превращается в кладбище бесконечно висящих стикеров в колонке «в процессе» и легитимизирует многозадачность на грани нервного срыва.
При отсутствии дисциплины и не следовании правилам любая методология начинает хромать на обе ноги.
Kanban как раз-таки наоборот прямо запрещает более одной задачи в статусе а-ля in progress у исполнителя.
Автор смешал всё в кучу, ему ещё и плюсов поставили
По сути, он просто описал «как правильно ставить задачи». Внезапно, хорошая задача должна иметь definition of ready, definition of done, и оценку трудоёмкости
Что мешает получить это всё при agile автор не рассказывает. Например, у нас классический scrum на 2 недели. В тасках есть dor, dod. Раз в спринт есть refinement, где как раз и обсуждаются детали имплементации. Затем идёт planning, где задачам дают оценку и приоритет. Ровно то, что автор описал в неком магическом подходе, который «лучше этого вашего agile», хотя, по факту, всё это в agile есть с самого начала :)
То, что какие-то команды выхолащивают процесс до «отчитался на дейли и дальше пью кофе», не проблема методологии, а проблема менеджмента
Как человек, который успел поработать и в маленькой команде, и в крупной компании, могу сказать, что крайности одинаково плохо работают. Когда контролируют каждый шаг, чувствуешь себя школьницей под присмотром. Когда контроля нет совсем, очень быстро находится пара человек, которые умеют красиво рассказывать о результатах, но не очень любят их показывать. Мне кажется, главный талант хорошего руководителя как раз в том, чтобы найти баланс между доверием и прозрачностью.
Как эффективно работать и почему Agile — это секта