Хабрахабр

[Перевод] Дорогой Agile, мне надоело притворяться

Люди всё время так говорят. «Agile мёртв». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но обязательно добавляют: «Мы просто шутим». Просто все его делают неправильно. Но «настоящий» Agile не мёртв. Даже я его внедрял. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Мне надоело. И знаете что?

Тогда Боб Маршалл сказал мне правду. Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Манифест Agile — это кувшин, который мы наполняем». Он сказал: «Заткнись, Чарльз. Я задумался. Он сделал несколько замечаний, с которыми мне пришлось согласиться. Как начинается первая строка манифеста Agile? Результатом стала эта статья.
Вот вам тест. Не знаете? Не подглядывать. Это не имеет значения. Всё в порядке. Заметьте, написано: «разработка программного обеспечения». Там говорится: «Мы открываем более совершенные методы разработки программного обеспечения...» Стоп. Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это альтернативная история. Там не говорится: «вытягивание вашей организации», «погашение долга за трансформацию», «выкраивание его с помощью этого командно-контрольного дерьма», «сосредоточение на результатах и улучшение работы по открытию», «исправление вашей средневековой системы бюджетирования» или любой ещё более продвинутой добавленной ценности, которую люди пытались в него вложить. Это нечестно.

Я имею в виду, да, большинство крупных организаций всё ещё застряли в 1987 году, но ладно вам. Заметьте также, что он начинается «Мы открываем...» Он не говорит: «Мы получили свыше...» Вам не кажется, что с 2001 года мы кое-чему научились? Можем мы наконец перестать притворяться? Вопреки распространённому мнению, фотография ниже на самом деле не из акта подписания Манифеста.

Так что приступайте к учёбе. Манифест служил определённой цели, но он не приведёт вас туда, куда вам нужно. У всех есть коллеги (обычно начальники), которые утверждают, что у них «нет времени учиться». У наших знаний есть срок годности, и не такой большой, как мы думаем. Так что найдите хороший список книг. Вы сами знаете, что они слишком самоуверенны в своих знаниях. Вот для начала: если вы не читали Sense & Respond, Lean Enterprise, A Seat at the Table и Everyone Is a Change Agent, предлагаю сделать это немедленно. Следите за хорошими блогами. И вашим начальникам.

Они все согласны друг с другом (или со мной)? Начните читать посты Джона Катлера, Мелиссы Перри, Боба Маршалла, Аллена Холуба, Лоры Кляйн, Эрики Холл, Нила Киллика и тех, на кого они ссылаются. Приступайте к чтению и поощряйте других. Нет, но они умны и вас тоже сделают умнее. Сколько книг читают ваши руководители? Fast Company говорит, что средний генеральный директор читает 60 книг в год. (Статьи HBR, репортажи Gartner и романы Мейв Бинчи не в счёт). И что они читают? Потому что давайте посмотрим правде в глаза: если ваши руководители мастера Scrum, то вы прочно застряли в 80-х и 90-х годах.

Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы. Давайте перейдём к непрерывному обучению и перестанем притворяться, что Agile — какое-то лекарство. Это никак не повышает организационную гибкость. Только Agile несправедливо вынес под микроскоп команды разработчиков программного обеспечения. Интересно, что, по словам Кена Швабера (см. НИКАК. Потому что есть разница между теорией и практикой. его «Небезопасно на любой скорости»), Agile был попыткой «компенсировать ущерб, нанесённый водопадом», и всё же никогда не давал организациям целостную, жизнеспособную альтернативу водопаду. Когда мы жалуемся на AINO (Agile In Name Only), мы не честны с самими собой. Работа над продуктом — это скорее практика.

Мы должны быть прагматичными. Теория против практики, помните? Похоже, проблема с самим движением, не так ли? Agile на практике почти всегда AINO. В любом случае, есть более важные вещи, о которых нужно узнать, включая (но не ограничиваясь) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, организационная терапия Маршалла и т. д.

Из-за того, что по своей сути Lean UX популяризует концепцию ориентированности на результат. Вы спросите, почему Lean UX возглавляет список? Если у вас нет однозначной сигнализации «поворота» (pivoting), то вы уже не можете быть гибким. Подумайте: если вы не знаете, какое изменение поведения пытаетесь создать, то не будете понимать свои действия. Некоторые могут возразить: «Но-но-но, проверять и адаптироваться!» Конечно. Вот что такое Agile, в конце концов, это pivoting. Я не вижу гибких команд, которые проверяют и адаптируются. Теория против практики, помните? Я вижу, как команды Agile пытаются наверстать отставание, возятся с Jira и Rally и работают так, будто строят кирпичную стену по приказу.

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

Два лагеря с двумя радикально разными перспективами, где один лагерь получает оценки от другого? Угадайте, кто победит? Выход в том, чтобы признать, что система — это команда. Если команды похожи на слепых, которые чувствуют слона и не согласны с тем, что это такое, то руководство похоже на слепых слонов, наступающих на людей и соглашающихся, что они все плоские. Перестаньте несправедливо помещать разработчиков под микроскоп, позволяя остальным прятаться в чёрном ящике. Кончайте уже с локальными оптимизациями и осознайте, что доверие — это проблема №1. Или как архитекторы легаси являются ограничениями в системе?) (Почему нас не интересует, как работают команды стратегического развития?

Мы не штампуем пластиковую посуду. И пока мы этим занимаемся, следует перестать относиться к командам разработчиков так, будто они работают на заводе. Нужно перестать вести себя так, будто мы заправляем пиццерией. Мы создаём программное обеспечение. Мы не используем один и тот же проверенный рецепт. Здесь другие правила. Если вы ещё не поняли, это работа по открытию, а не просто доставка. Мы разрабатываем рецепты. Это обнажает ещё один глубокий недостаток Agile. Пренебрежение открытием приводит к массовым потерям: неиспользуемые функции и другая работа, которая не достигает результатов. За исключением того, что дерьмовый продукт обычно таким и остаётся, не так ли? Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его». Будущие улучшения становятся ненужными «затратами».

Правда? Но-но-но, Agile действительно нацелен на исследования! Теория против практики, помните? Будем честными. Как вы обычно относитесь к работе с гибкими командами? Если вы зарабатываете на жизнь проектированием или исследованиями, то ответьте на этот вопрос. Или вас просят «доказать свою ценность»? Вас изначально рассматривают как ценность и просят помочь «проверить и адаптировать»? Обратите внимание, что они просят отдельного участника доказать свою ценность — они не спрашивают, какая часть их кода на самом деле смещает показатели в правильном направлении. Как сказал Алан Купер, когда вас просят «доказать свою ценность», вам ясно дают понять, что вы находитесь в системе, которая вас не ценит. Вероятно, они всё ещё сосредоточены на костах, а не на ценности, игнорируя те области, где значительная часть ценности фактически утекает. Другими словами, они по-прежнему фокусируются на людях, а не на самой работе.

Начните задавать им вопросы. Если вы работаете с гибкими командами, в следующий раз, когда вас попросят «показать свою ценность», попробуйте это. Какие упражнения они используют для оценки этого параметра? Знают ли они, какова цена задержки? Какая доля их продукта фактически достигает своих показателей? Каких конкретных результатов они пытаются достичь? Если есть более быстрые и дешёвые способы узнать, что разрабатывать, кроме как просто выпускать код, заинтересованы ли они в обучении? Они не знают? Насколько всё плохо? Какова их эффективность потока? Если есть дизайнерские игры и упрощённые действия, которые приведут к лучшим решениям за гораздо меньшее время, они заинтересованы в обучении? Сколько времени они проводят на собраниях? Потому что я не просто покажу вам свою ценность — я научу вас создавать больше ценности во всём, что вы делаете.

Это мета. Это другой способ мышления. Как отмечает Остин Говелла, и Agile, и водопад сосредоточены на разработке. Это стратегически. Если они не заинтересованы, можно уходить. Дизайн — это проверка. Это фабрика по производству функций. Если они просто опустив головы выпускают продукт, фокусируясь на издержках, то никогда даже не узнают достаточно, чтобы понять, что вы, как правило, получаете больше того, на чём фокусируетесь (гм, косты). Они притворяются, что создают пластиковую посуду. Круговая порука. Потому что реальная ценность обеспечивается опциями, которые генерируются путём исследования. У вас есть дела поважнее. Чего они пытаются достичь? Чем больше опций вы создаёте и чем более гибок ваш подход, тем больше возможных путей к лучше результат. Это приведёт к лучшему принятию решений на перспективу. Исследовали ли они три-пять способов достижения этой цели? Два — это дилемма. Одна опция — это не выбор. Три — теперь вы кое-чего добились.

Компонент с наибольшим количеством опций управляет системой. Когда-нибудь слышали о Законе необходимого разнообразия? У вас были руководители, которые пытались сохранить контроль над системой сверху, и гибкие команды, которые пытаются приблизить ценность к источнику (реальные пользователи и клиенты). Примените это к тупой борьбе за власть «Agile против водопада». Путь вперёд — не «Agile против водопада». Выход из бессмысленной гражданской войны — научить людей генерировать варианты на всех уровнях. Дизайн и открытие помогают в обоих случаях. Это умная стратегическая работа сверху вниз (водопад) с эмпирически-ориентированными тактиками снизу вверх.

Это разумный фокус на чётких результатах, а не на выдаче, с запланированными результатами вместо запланированных отметок, не с проектными, а с надёжными продуктовыми командами, уполномоченными проверять предположения и находить кратчайший путь к ценности. Так… каков выход?

Теперь к обучению (адаптировано на базе диаграммы Джона Катлера).

Конечно, нет. Так… значит, Agile уходит? У меня нет никакой власти. Это просто глупое сообщение в блоге. Движение Agile сделало возможным появление многих из упомянутых концепций. И если бы даже была, Agile всё равно не исчез бы. Они появились на десятилетия раньше. Кроме того, вопреки распространённому мнению, гибкие практики не были изобретены движением Agile.

Так что нет, я не хочу, чтобы Agile уходил.

Я просто хочу, чтобы мы стали честнее.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть