Сейчас у меня идет что-то типа вводной лекции в этот Agile и прочий Kanban. Испытываю непреодолимое отвращение.
Если честно, я в ужасе от того, насколько это чудовищная трата времени и ресурсов (есть несколько коучей на это дело, не говоря уж о затратах времени на эти вот словесные мастурбации). Я пробовал рассматривать это и в вариантах, когда я подчиненный, и в вариантах, когда я сам в топе принимающих решения по проектам.
Вот основные ценности выше. Вопросы есть просто гигантские и практически к каждому пункту. Причем, при обучении даются "удобные" варианты трактовки пунктов. Несмотря на то, что одной из идей поборников Agile - это избавление от бюрократии, на самом деле бюрократия никуда не пропадает, но зато возникает куча встреч с обсуждением, как хорошо без нее жить. Сами принципы сформулированы именно так, что если их рассматривать как-то абстрактно, то вроде и возразить нечего, но если перейти к частностям, то получается абсолютнейший бред с натягиванием совы на глобус.
Беру последовательно по пунктам...
"Люди важнее процессов и инструментов" - типа главное, чтобы люди между собой трепались в достаточной мере, а существование отлаженного годами процесса - фигня. Здоровые люди вообще? Вот существует поставка продукта, детские болезни все выявлены и исправлены. Приходит Вася с новой идеей тестировать еще до вывода в альфу. И все поехало боком? Заново переделывать процесс с каждым новым Васей, его разрушающим и собирать детские болезни?
"Работающий продукт важнее исчерпывающей документации" - страшный сон саппорта, я там был, я знаю, о чем говорю. Родили продукт, документации нет. Нет, он работает. Но как понять, что ему надо, и что должно получаться? В итоге у клиентов тонна вопросов, у саппорта какой-то объем неотвеченного, двусмысленного и с разными трактовками (они бегают, отвлекают программистов), на фоне этого клиенты делают гору основополагающих ошибок, весь учет едет по бороде, бизнес тонет или начинает жизнь с нуля с осознанием бессмысленной потери года или нескольких лет, в том числе в росте.
"Сотрудничество с заказчиком важнее согласования условий контракта" - да-да, если у вас оплата за проект, то разоритесь вы, а если почасовая - заказчик :) На фоне миллиона историй о том, как бы переделать все по другому при подходе к финишу проекта, этот пункт выглядит очень весело. Может, это у нас не будет работать, а работает где-то с другими сферическими конями в вакууме, но у нас если не обозначить четко условия и поэтапные сроки, а потом не вздрючивать команду за соблюдение графика, то работать ни хрена не будет.
"Готовность к изменениям важнее следования первоначальному плану" - аналогично предыдущему пункту нюанс по разорению. Компетентность заказчика, как правило, такова, что он не хочет возиться и изначально сформулировать все, что он хочет. Он хочет поговорить и чтобы наступило счастье. Так не бывает. Изначально необходимо понять, к чему мы идем. Зафиксировать это и дать понять заказчику, какую цель мы хотим достичь. Согласовать и уточнить, что заказчик вкладывается именно в эту цель, путь к которой оплачивается поэтапно с ценностью и оплатой каждого этапа, возможно, в разных размерах. Заказчик может забыть итоговую цель, может отменить ее, может метаться, как в проруби, команда исполнителя не дожна поддаваться такому разрушающему фактору и идти в своем графике, а не бегать по потолку, потому, что цель кардинально меняет локацию. Любые стрессы и внеплановые изменения влияют на качество результата и перегорание людей. Дробить можно на какой-то разумной длины этапы, по прошествии которых общаться с заказчиком, убедиться, что цель актуальна и идти дальше, либо переназначать цели, если выясняется, что что-то изменилось.
Среди прочего от этого всего - ежедневные "дейли", чтобы "каждый из команды понимал, что в ней происходит и кто чем занят". Ну я понимаю еще еженедельные планерки, чтобы действительно как-то поделиться новостями... Но, &^$#, полуторачасовые голосовые марафоны каждый день с одним и тем же перемыванием одного и того же! Да нахрен мне вообще, расскажите, что там делает вебер в заголовке сайта, если у меня в этот момент DoS на базу идет?
Еще убило, что в соответствии с этой хренью начальника-то и нет. Есть лидер. А команда должна самоорганизовываться. Ну надо же было изобрести что-то, чтобы совсем дерьмом не казаться :) То есть вот команда с лидером, на нее накидывают задачки, а ее лидер "смотрит в будущее" и "собирает и анализирует метрики успешности выполнения". Какой-то самообман вообще. Вот именно подчеркивается, что лидер задачи людям не раздает. "Уот так уот" (с). Вся теория управления в виде, что руководитель должен понять задачу, найти исполнителя и проконтролировать выполнение идет лесом. Теперь у нас лидер команды, который для команды ничего не значит. Дескать лидер "может быть не в курсе каких-то деталей, чтобы оценить задачу". Эти изобретатели аджайлов вообще думали чем-то? А нахрена тогда задача в команду прилетает, если лидер не в курсе?
Еще веселые утверждения с этими шариками. Выстраивают несколько потерпевших в ряд, дают им один шарик, чтобы передали из руки в руку, потом несколько конвеером, дескать, смотрите, насколько вы стали продуктивнее... Сразу вспомнился шедевр от Чаплина. Даже и объяснять много не надо.
Глубокое мое убеждение, что это все - бредовая мода, которая дает рабочие места ее внедренцам за счет умения вливать в уши руководителям. Любое управление должно быть прежде всего разумным, предсказуемым и контролируемым. А вот эта малоэффективная и тем раздражающая болтовня с рисунками и перекладыванием шариков не нужна.