Три проблемы agile — краткий перевод выступления Мартина Фаулера на конференции Agile Australia 2018 в Мельбурне
Гибкая разработка в 2018-м
Сибирикс
Гибкая разработка
в 2018-м
Три проблемы agile — краткий перевод выступления Мартина Фаулера на конференции Agile Australia 2018 в Мельбурне
Мартин Фаулер — автор ряда книг и статей по архитектуре ПО, объектно-ориентированному анализу и разработке, рефакторингу и нюансам программирования. В своём выступлении на Agile Australia он задался вопросом: почему, если индустрия agile постоянно развивается, agile внутри компаний часто теряет свой первоначальный облик? В этой статье он говорит о текущем состоянии гибких методологий и о трёх проблемах, которые, по его мнению, имеют значение при превращении agile в псевдо-agile.
Кажется, что мир гибкой разработки ПО яркий, ведь он является мейнстримом. Но в реальности всё не так радужно, ведь большая часть того, что создаётся, имеет мало общего с agile и игнорирует базовые ценности и принципы гибкой разработки. И в связи с этой проблемой стоит сосредоточиться на трёх задачах:

  1. бороться с agile-«сектой» и её привычкой навязывать процесс командам,
  2. повышать важность технического совершенства,
  3. организовывать наши команды вокруг продуктов (а не проектов).

То, как мы смотрим на agile сегодня — с разных сторон и точек зрения — выглядит неплохо. На какую бы конференцию вы ни пошли, есть большой шанс услышать что-то о гибких методологиях. Об этом говорят повсюду — не то, что лет 10 назад, когда это было в новинку. А если побеседовать об этом с людьми, которые практикуют agile долгое время, ещё до того как сам термин появился в поздние 90-е, — гибкие методологии больше вызывают беспокойство, разочарование и несчастье, которые витают в воздухе.

И в этом нет ничего удивительного, потому что эта неудовлетворенность — признак стремления к улучшению. Но при этом приходится задаваться вопросом «А за что мы боремся?».

Еще 10 лет назад проблема была в том, что некоторые всерьез практиковали agile. Я помню, как один из моих крупных клиентов попросил меня прийти и выступить с каким-то очередным рутинным докладом: «мы хотим, чтобы вы говорили о том, что вам нравится, но пожалуйста, давайте ни слова об agile». Тогда это воспринималось довольно тревожно — в середине 2000-х годов, когда я много рассказывал о гибких методологиях, у многих возникало чувство, будто это что-то плохое.

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

Сейчас наша задача не в том, чтобы сделать agile тем, что всем хотелось бы практиковать. Мы имеем дело с псевдо-agile, когда про гибкие методологии вроде бы говорят, но на деле это не соответствует ни одной из практик или ценностей. Это ещё иногда называют «Dark Agile» (тёмный agile) или «Dark Scrum». Это даже хуже, чем просто притворяться гибким — здесь «гибкость» идёт вразрез с основными принципами, которые формировались в 90-е. Многие люди практикуют и называют agile нечто, что на самом деле этим не является, или пытаются придумывать какие-то свои методологии (вроде post-agile), чтобы хоть как-то назвать то, чем они занимаются. Это своего рода вызов, и нам стоит отстаивать ценности и принципы истинного agile и объяснять людям, что это действительно означает.

Это глобальная проблема, но у неё есть несколько проблемных областей — сосредоточимся на трёх из них, которые особенно достойны внимания.
Проблема 1: Agile-«секта» (Agile Industrial Complex)
Казалось бы, чего это я? Я сам рассказываю сейчас об этом, стоя на сцене, и многие из нас сейчас работают на консалтинговые фирмы, в названии которых, вероятно, есть слово agile. Но многое из того, что подаётся под этим соусом, идёт вразрез со всеми принципами agile.

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

В Agile Manifesto есть четыре заявления (при создании мы не очень заботились о порядке их перечисления), но первым всё-таки идёт принцип «Физические лица и взаимодействия над процессами и инструментами».
Agile Manifesto (скрин отсюда)
То есть, если вы хотите добиться успеха в разработке программного обеспечения, вам нужно найти хороших людей. Хороших людей, которые работают вместе на человеческом уровне, чтобы они могли эффективно сотрудничать. Выбор того, какие инструменты они используют или какой процесс они должны соблюдать, — это уже их задача. Важно то, что команда выбирает свой собственный путь.

Команда не должна просто выбирать процесс — ей следует активно продолжать развивать и менять его по мере продвижения к цели. Один из признаков agile-методологии — она по своей сути очень скользкая: меняется от недели к неделе, от месяца к месяцу. Потому что, если вы не берете на себя ответственность и не изменяете вещи в соответствии с вашими обстоятельствами, то вы теряете суть.

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

Вам известно имя Фредерика Тейлора? Вероятно, он является одной из самых важных фигур в истории 20-го века с точки зрения влияния на повседневную жизнь людей. Он жил в конце 19-го века в Америке и он был очень заинтересован повышением эффективности рабочих мест в промышленности. Он считал, что рабочие по природе ленивы, продажны и глупы. Поэтому никто не хотел, чтобы те решали, как именно создавать определенную машину. Вместо них кто-то другой, кто-то более умный и образованный, должен был выяснить, как это сделать наилучшим образом. Даже банальные вещи: сначала то, а затем это — или наоборот. Четкая последовательность действий, из которой выросла целая сфера нормирования труда. В её основе лежало то, что люди, которые делают работу, не должны решать, как её делать.

Это сильно повлияло на производственную и заводскую работу в начале 20-го века. Позже это повлияло и на индустрию программного обеспечения — люди сказали: «Нам нужны специалисты по процессам разработки ПО, которые определят, как это сделать, а затем программисты, которые просто подберут нужные теги». Ещё интереснее, что пока разработчики убеждали всех в том, что нужно следовать этому плану, и в этом кроется будущее развития программного обеспечения (я слышал, как люди говорили это еще в 80-х и 90-х годах), мир производства отходил от него. На производстве приходили к тому, что работники должны иметь гораздо больше прав, поскольку они действительно видят, что происходит.

Движение agile попыталось подтолкнуть к этому: команды разработки должны сами решить, как сделать работу. Это ведь люди, которым хорошо платят, которые хорошо образованы и хорошо замотивированы — поэтому именно они должны выяснить, что в их конкретном случае необходимо.

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

Даже адепты agile не сказали бы, что гибкость — это всегда лучшее, что стоит использовать. Если команда не хочет работать в рамках гибкой методологии, вероятно, этот подход не подходит в этом контексте, и не использовать agile — это наилучший способ сделать эту работу.
Проблема 2: техническое совершенствование в стороне
Вторая проблема в том, что техническое совершенствование уже созданных продуктов не признаётся важным. На большинстве конференций по agile очень мало говорится о реальных методах написания программного обеспечения — гораздо чаще речь идёт об управлении проектами, например. Хотя технари — это люди, которые действительно выполняют эту работу. И это довольно трагично.

Последние пару лет я провёл за написанием книги о рефакторинге. Это очень важный метод для гибкого мышления, поскольку он даёт ответ, как мы можем создавать программное обеспечение таким образом, чтобы оно легко менялось.

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

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

Но без хорошего рефакторинга всё равно ничего не получится. А он, в свою очередь, зависит от тестирования и непрерывной интеграции, и вместе с непрерывной интеграцией у вас есть практика непрерывных улучшений и представление о том, что мы можем выпускать ПО очень-очень часто. И в некоторых организациях это действительно так.

Сейчас есть мнение, будто быстрое создание ПО возможно только тогда, когда вы готовы мириться с множеством ошибок. И если вы хотите, чтобы программное обеспечение было надежным, вы делаете это гораздо медленнее — преднамеренно. Чушь. В книге «Ускорь» Николь Форсгрен, Джез Хамбл и Джин Ким показывают, как разные практики влияют на вещи. Одна из них — снизить уровень ошибок, прежде чем ускорять процессы обновлений. Для этого требуется автоматическое тестирование, рефакторинг, yagni — причём, все вместе.
Проблема 3: программные проекты
Важно избавиться от программных проектов как от понятия. Вместо этого мы хотим перейти к ориентированному на продукт взгляду на мир, где вместо проектов (которые сначала запускаются, а потом приостанавливаются) вы скажете: «Давайте сосредоточимся на вещах, которые намного более долговечны, и организуем продуктовую команду вокруг этого». Как вариант — выяснить бизнес-возможности вашей организации и организовать команды вокруг них. Эти бизнес-возможности будут долговечными и обязательно будут означать объединение программистов и людей из бизнеса в одной команде.

Пример — команда Amazon Two-Pizza. Возможно здесь есть доля шутки, поскольку американские пиццы действительно довольно большие, а значит, и команды могут быть больше, чем вы думаете. Но при этом они должны быть связаны между собой на пути к конечному клиенту. Каждая команда сосредоточена на каком-то аспекте опыта клиента, и их развитие в этом аспекте даёт понимание, как наилучшим образом связать между собой маленькие команды.

Но это постоянно нарушается. В одной из предположительно гибких компаний я общался с командой разработчиков. Около полдюжины программистов. Четыре пользователя ПО, которое они пишут, и главные специалисты по планированию в розничной торговле. Шесть разработчиков, четыре пользователя. Они никогда не разговаривали друг с другом — им было запрещено. Вместо этого существовал владелец скрам-продукта, который вёл коммуникацию между ними. Ах да, в течение года было аж четыре владельца продукта.

Если бы я был в этой команде в качестве разработчика, я бы хотел знать каждого участника команды поимённо. Я бы хотел поговорить. Я хотел бы посмотреть, что они делают, я хотел бы понять, как они думают о том, чтобы сделать своих клиентов счастливее и увидеть весь поток. Не забывайте про это, если практикуете agile.
Вместо вывода
  • Избавьтесь от Agile Industrial Complex и идеи влияния кого-то извне на команду. Пусть команды работают так, как они сами решат.

  • Повышайте важность технического совершенства и никогда не забывайте, что при написании программного обеспечения технологическая сторона тоже имеет значение.

  • Организовывайте команды вокруг продуктов.