29 марта 2023

⚙️ Эпоха Agile должна закончиться

iOS-developer, ИТ-переводчица, пишу статьи и гайды.
Возможно, вначале у создателей Agile были благие намерения — относиться к разработчикам как к людям, а не как к винтикам в машине, но со временем оказалось, что эти принципы превратились в нечто едкое для организаций: грязная смесь выгорания, технического долга, долга за проектирование, раздувающийся бэклог и постоянная угроза полного рефакторинга. Что же пошло не так?
5
⚙️ Эпоха Agile должна закончиться
Данная статья является переводом. Автор: Michael Burnett. Ссылка на оригинал.

30 лет назад технологическая индустрия попыталась внедрить бережливые практики, но потерпела неудачу. Вместо «постоянного улучшения» прогресс остановился. Agile несовместим с исследованиями UX, проектированием и масштабируемой разработкой. Так будет всегда. Пришло время создать новые стандарты.

Поскольку стартапы переключаются на «операционную эффективность», давайте подчеркнем, что эффективность — это про способ работы, а не про численность персонала.

Agile-разработка уже более 20 лет является принципом работы № 1 в технологиях, не проверяемым и не подвергаемым сомнению. Тем не менее у него есть фундаментальные недостатки, которые бросались в глаза нам все это время.

Недостаток № 1: Люди — это не машины.

Недостаток № 2: Проектирование — это не переучет.

Недостаток № 3. Продукт не может быть определен тем, что может быть сделано произвольным количеством людей с произвольными навыками и опытом за двухнедельный спринт.

Давайте взглянем назад на то, как мы ограничивали себя во времени:

  • 2001 — Agile
  • 1995 — Scrum
  • 1988 — Lean
  • 1960’s — Toyota Production System (TPS)

Начнем с начала

⚙️ Эпоха Agile должна закончиться

Система TPS развивалась десятилетиями, с 40-х по 70-е годы, что позволило Toyota достичь и сохранить свое доминирующее положение среди мировых автопроизводителей. Эти блестящие начинания были сосредоточены на устранении муда (напрасных трат), мура (непоследовательности) и мури (перегруженности).

Наиболее тщательно документировали устранение отходов. Среди восьми видов отходов наиболее вредными оказались излишки товарных запасов — как готовой продукции, так и сырья, а также простаивающее оборудование. Другими словами, вещи, на которые вы потратили деньги, не приносящие вам денег. Решения Toyota были связаны с материально-техническим снабжением и стали известны как «производство точно в срок».

«Получите материалы вовремя, чтобы сборочная линия обработала их вовремя, чтобы готовый продукт соответствовал требованиям клиентов».

Партнером в совершенствовании TPS был «Путь Тойоты». Эта философия призывала к постоянному совершенствованию, включая преодоление трудностей на пути к долгосрочному виденью, кайдзен (инновациям в операциях) и моему личному фавориту – генти генбуцу. Дословно означая «реальное место, реальную вещь», этот принцип гласил: «пойди и посмотри сам», т. е. принимай соответствующие решения. Он также поощрял подход к улучшению «снизу вверх», сбор информации от каждого сотрудника, независимо от его уровня.

Америка сотворила свое волшебство и превратила «Путь Тойоты» в аналог быстрорастворимой лапши. Ладно, может быть, я несправедлив. Производство «точно в срок» хорошо применялось в США для… производства. Он был переименован в Lean в статье 1988 года «Триумф системы бережливого производства (Lean)» — однако было понятно его происхождение.

Бережливое производство и его предшественники идеально подходят для производства физических товаров, особенно при наличии устоявшегося рынка и зрелого продукта. В основе лежит предсказуемость как спроса, так и цепочки поставок. Когда дело доходит до создания нового продукта, производители полагаются на разные процессы в своих отделах исследований и разработок. Будь то Genentech, разрабатывающая синтетический инсулин, или Proctor & Gamble, разрабатывающая Swiffer, процесс был долгим и довольно линейным. Он включал в себя глубокие исследования и анализ рынка перед разработкой продукта.

Как Waterfall сделали козлом отпущения

⚙️ Эпоха Agile должна закончиться

Развивающаяся индустрия программного обеспечения в значительной степени следовала этим процессам; применительно к цифровым продуктам они стали известны как методология Waterfall. Термин Waterfall стал универсальным для описания линейного процесса разработки, кульминацией которого являлся полностью реализованный выпуск продукта. Справедливая критика заключается в том, что выпуск большого дорогого продукта все еще может быть неудачным. Таким образом, Waterfall используется для того, чтобы доказать, что итерация, тестирование и реакция на рынок необходимы в более короткие сроки.

В 1990-х специалисты-практики в технологической отрасли изучали способы применения бережливого производства к цифровым продуктам. К сожалению, с самого начала они неправильно диагностировали проблему. Время выхода на рынок важно, но я считаю, что только с точки зрения денежного потока, особенно для стартапов. Сторонники бережливого производства отказались от ненужного, лишившись также полезного. Обратите внимание, что в литературе по Scrum и Agile практически не упоминаются исследования или стратегия. Проектирование получило плохую репутацию из-за того, что в Waterfall тратится много времени. Основы бережливого производства — это сборка и выпуск.

Примерно в это же время произошла битва в стиле Kaiju vs. Mecha (прим.пер. файтинг между монстрами и роботами) между сторонниками бережливого производства и теми, кто практиковал разработку Waterfall. И монстр, и робот не смогли учесть потребности пользователей, а вместо этого растоптали их и уничтожили мир.

В чем разница? Если представить как диаграмму — Agile представляет часть, Waterfall — целое.

Agile ошибочно предполагает, что функция будет пересмотрена. Waterfall ошибочно предполагает, что продукт не будет пересматриваться. Изображение адаптировано из <a href="https://asana.com/resources/agile-methodology" target="_blank" rel="noopener noreferrer nofollow">Asana</a>.
Agile ошибочно предполагает, что функция будет пересмотрена. Waterfall ошибочно предполагает, что продукт не будет пересматриваться. Изображение адаптировано из Asana.

Практика повторения существующего продукта на рынке — это роскошь для программного обеспечения — обновления могут быть запущены в любое время; сборочные линии и инструменты не нуждаются в реконструкции. Каждый технологический продукт должен создаваться поэтапно, но он также должен быть создан для достижения конечной цели и полностью реализованного продукта. Успех требует стратегии, исследований, проектирования и генти генбуцу, как и предполагалось в «Пути Тойоты». Аргумент Agile против Waterfall — это ложная дихотомия: компания может иметь долгосрочную стратегию и реализовывать ее, продолжая выпускать продукт постепенно, итеративно.

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»

Ошибка 30-летней давности

Когда владельцы продуктов и инженеры пытались применить принципы бережливого производства к разработке программного обеспечения, они нашли способы имитировать сборочную линию. Требования будут определены как раз вовремя, а затем кросс-функциональная команда будет спешить, чтобы выпустить работающее программное обеспечение. Термин «Scrum» был удачным — он пришел из регби, когда ряд парней мчатся по полю, перебрасывая мяч туда-сюда. Подход к разработке программного обеспечения имеет тот же уровень изящества и стратегии.

Вам всем приходилось иметь дело со Scrum, вот причины, почему он такой, какой он есть:

  • Должно быть ограничение по времени спринтом (Sprint), чтобы убедиться, что программное обеспечение может быть выпущено на рынок в «итеративном» цикле.
  • Планирование спринта (Sprint Planning) происходит прямо перед спринтом, потому что именно тогда у вас будет понимание того, на чем нужно сосредоточиться.
  • Проведение ежедневных заседаний (Daily Standup) для того, чтобы на лету проводить «оперативные улучшения». (Выступать разрешено только разработчикам, дискуссии не допускаются, так как в этом случае техника простаивает.)
  • В конце спринта проводить ревью (Review) для просмотра работающего программного обеспечения и определения того, что не было завершено или что нуждается в улучшении.
  • Также предполагается проведение ретроспективы (Retrospective) для обсуждения того, что получилось хорошо, а что не очень, в интересах увеличения количества выпускаемой продукции.
  • Незавершенные задания (Backlog) не являются основой практики Scrum, это артефакт побочного ущерба и обломков всего, что было выброшено за борт во время спринта.

Вы можете заметить, что Scrum уже довольно нелогичен, но дальше все становится намного хуже.

Несколько создателей Scrum объединились с другими парнями, которые разработали другие методы бережливого производства. Объединив свои усилия, они создали Манифест гибкой разработки программного обеспечения. Марксистский подтекст, вероятно, преднамеренный: они заявляли, что рабочие будут владеть средствами производства.

Манифест хрупкого Agile

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

Основные моменты (с моими переводами):

  • Люди и взаимодействия важнее процессов и инструментов. (Да, мы будем делать все, что захотим).
  • Приветствуется изменение требований, даже на поздних стадиях разработки. (Мы также можем передумать в любое время).
  • Проекты строятся вокруг целеустремленных людей, которым стоит доверять. (Оставь нас в покое, бери что есть).
  • Работающее программное обеспечение является основным мерилом прогресса. (Тот факт, что мы что-то произвели, имеет значение).
  • Простота — искусство минимизации лишней работы — крайне необходима. (Мы собираемся сделать как можно меньше).
  • Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. (Не говорите нам, что делать).

Это не нападение на наших друзей-инженеров. Большинство разработчиков, с которыми я работаю, заботятся о том, чтобы делать работу хорошо, и чувствуют себя обязанными производить качественную работу, основываясь на сроках спринта и обещанных результатах. Тем не менее некоторые техлиды, приобщившиеся к культу Agile, чувствуют себя вполне свободно, следуя вышеуказанным принципам. Требования — это больше предложение, чем правило, проектирование требует интерпретации, все можно вырезать, если конечный результат все еще «работает».

Сочетание принципов Agile и практики Scrum губительно для стартапов. Это оперативные указания руководства; дизайнеры, продакт-менеджеры и инженеры не самоорганизуются и не выбирают такой способ работы. Это все во имя MVP и времени выхода на рынок. Вот что происходит. Каждый. Раз.

Исследования и проектирования создают решения для решения проблем клиентов, но то, что создается, всегда меркнет по сравнению с ними.

Менеджеры по продукту торопятся создать следующий блестящий объект в дорожной карте… только как можно меньше.

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

Руководству остается только ломать голову, почему продукт такой шаткий и неэффективный.

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

Как мы можем выйти из этого цикла?

Просто остановитесь.

Вы не можете впихнуть ориентированное на клиента решение в спринт.

  • Определите, что нужно создать.
  • Определите лучший способ создания, который позволит в будущем совершать масштабирование и проверки.
  • Затем создайте его, сколько бы времени это ни заняло. (Это не займет два года, но и не займет две недели. Релизы можно нарезать на кусочки, пока продукт создается в соответствии со спецификацией.)
  • Поощряйте создание продукта превосходного качества, а не «срезание углов».
  • Инвестируйте в фундаментальную работу, такую, как системы проектирования и стек чистых технологий, чтобы будущие усилия могли быть более эффективными.
  • Инвестируйте в UX и глубину, а не в широту набора функций.
  • Правильно инвестируйте в операционную эффективность, а не сокращайте численность персонала и ожидайте того же количества продукции.
***

Материалы по теме

МЕРОПРИЯТИЯ

Agile можно любить и ненавидеть, но она живет и будет жить. Как вы к ней относитесь?

 
 

ВАКАНСИИ

Добавить вакансию
Go-разработчик
по итогам собеседования

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

Подпишись

на push-уведомления