В наши дни Agile-манифест разработки программного обеспечения — Библия для многих команд разработчиков. Он содержит 12 принципов, которые показывают нам, как должна быть организована разработка ПО. Эти принципы были придуманы в 2001 году. В целом мне они нравятся и я со всеми ими согласен. Однако на деле большинство команд понимает их неправильно. Следовательно, далее резюмирую, что происходит, и свою интерпретацию каждого принципа.

Принцип № 1: «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения».


Сосредоточивая внимание на «удовлетворении потребностей заказчика», адепты Agile совершенно забывают о части «благодаря». Они считают, что их истинная цель — счастливый заказчик, а «continuous delivery» — это что-то, очевидно, полезное, но не принципиальное. Однако всё совсем наоборот: заказчик будет удовлетворен, если ПО идеально создается и доставляется. Если заказчик не удовлетворен, мы ищем другого — вот истинный дух, которого должна придерживаться команда разработки ПО. Я полагаю, что Манифест имеет в виду именно это. Мы гарантируем, что наш процесс «ранний и непрерывный», и это приведет к удовлетворенности заказчика. Мы сосредоточиваемся на улучшении своего процесса, а не на удовлетворении заказчика. Удовлетворение — это последствие, а не основная цель.

Принцип № 2: «Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества».


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

Принцип № 3: «Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев».


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

Принцип № 4: «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе».


«Работать вместе» не означает «работать без четко определенных правил и процессов». Однако большинство команд понимает этот принцип как легализацию хаоса. Они считают, что, раз мы работаем вместе, нам больше не нужно определять роли, мы не должны документировать требования, нам не нужно заботиться об обязанностях. В конце концов, мы не знаем ни кто чем занимается, ни структуру команды. Это не то, о чем говорит Манифест! «Работать вместе» означает более «поворотливые» коммуникации и более короткие циклы реагирования. Это определенно не означает отсутствие ролей и обязанностей.

Принцип № 5: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им».


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

Принцип № 6: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды».


«Непосредственное общение» не значит «сидеть в одном офисе». Манифест ничего не говорит о совместно размещенных или распределенных командах. Очевидно, что в современных программных проектах виртуальные коммуникации (c помощью видеозвонков) гораздо эффективнее, чем совместная работа в одной стране, одном городе, одном офисе и одной комнате. Поэтому большинство адептов Agile всё ещё продвигает такой стиль разработки, когда все находятся в одном месте, в качестве доказательства используя Манифест. Это ошибка; «непосредственное общение» означает нечто совершенно иное, чем 15 лет назад, когда был написан Манифест.

Принцип № 7: «Работающий продукт — основной показатель прогресса».


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

Принцип № 8: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки».


Это не значит, что мы должны бесконечно прожигать деньги заказчика. Да, мы должны вести разработку с определенной скоростью, но всегда должны помнить, чьи деньги тратим: деньги заказчика. Манифест ничего не говорит о стоимости разработки, и это, видимо, из-за того, что его писали те, кто делает деньги (программисты), а не те, кто тратих их (заказчики). Поэтому мы должны помнить, что любой проект — это прежде всего машина для сжигания денег. Вот почему команда всегда должна измерять свою "скорость прожигания" и следить за тем, чтобы она соответствовала количеству business value, которое команда поставляет. Просто быть счастливой командой — это не то, что предлагает Манифест, но именно так многие понимают этот принцип.

Принцип № 9: «Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта».


Это идеальный принцип, который одновременно говорит так много и не говорит ничего. Что именно значит «внимание»? Я могу объяснить. Оно означает правила и политики. Любая политика прежде всего означает наказание тех, кто нарушает правила. Таким образом, если Agile-команда действительно имеет в виду постоянное внимание к техническому совершенству, у нее должна быть политика качества. Эта политика должна четко определять, какой дизайн хороший, а какой — плохой, какой кусок Java-кода отличный, какой — уродливый и т.д. Кроме того, политика должна указывать, что происходит с теми, кто нарушает принципы совершенства. Тем не менее, большинство Agile-команд понимает «качество» как отличный флаг, который можно повесить на стену, но пугается, когда я спрашиваю: «Что произойдет, если кто-то поставляет низкое качество?»

Принцип № 10: «Простота — искусство минимизации лишней работы — крайне необходима».


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

Принцип № 11: «Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд».


«Самоорганизующиеся» не значит «неорганизованные». Это правило часто толкуют как легализацию анархии. Нам не нужны никакие менеджеры проектов, процессы, дисциплина, правила или политики — вместо этого у нас есть холакратия! Архитектор нам тоже не нужен — наши программисты могут принимать все технические решения на регулярных встречах! Кроме того, мы не хотим, чтобы наши программисты были ответственны за что-либо персонально, — они всегда вместе при любых рисках и проблемах. Прекратите это безумие! Это не то, что имеет в виду Манифест. Самоорганизующаяся команда — это команда, которой не нужен внешний надзор; команда с четко определенными ролями внутри; команда с идеальной внутренней дисциплиной; команда с профессиональным менеджментом. Не с отсутствием всего этого.

Принцип № 12: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».


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

Комментарии (14)


  1. staticlab
    18.01.2019 09:59
    +1

    Статья называется "Двенадцать ошибок в Agile Manifesto", а фактически должна называться "Двенадцать ошибок трактовки Agile Manifesto".


    1. s-kozlov Автор
      18.01.2019 10:50

      Есть такое. Но я решил, что так поменять заголовок — это уже не перевод, а отсебятина.
      Можно, кстати, интерпретировать это так, что в каждом принципе Манифеста одна и та же ошибка — слишком расплывчатая формулировка.


      1. John_Minority
        18.01.2019 18:04
        +1

        Вообще намек на то, что автор поста не совсем правильно понимает манифест и то, как его трактуют другие.


  1. John_Minority
    18.01.2019 11:16

    > Мы сосредоточиваемся на улучшении своего процесса, а не на удовлетворении заказчика. Удовлетворение — это последствие, а не основная цель.

    Это стеб или серьезно?


    1. s-kozlov Автор
      18.01.2019 11:33

      А что, разумно перестраивать наработанные процессы под каждого заказчика?


      1. kagarich
        18.01.2019 11:53

        Как по мне, так если с заказчиком не заключен контракт по 44ФЗ, или иной с драконовскими штрафами за просрочку, то удовлетворенность заказчика — главное. И если для максимальной удовлетворенности заказчика дешевле вместо свежего релиза сводить его в кабак, то так тому и быть — идём в кабак. Удовлетворенность заказчика на периоде — главная цель, а не следствие и что-то там еще; и найти правильные методы поддержания удовлетворенности в тонусе — главная задача того, кто общается с заказчиком.


        1. s-kozlov Автор
          18.01.2019 11:55

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


        1. s-kozlov Автор
          18.01.2019 11:56

          И да, мало какой бизнес создается для удовлетворения какого-то там заказчика.


          1. kagarich
            18.01.2019 12:56

            И здесь, и в предыдущем комментарии вы пишите про маржу? Т.е. прямую экономическую выгоду от того или иного проекта?

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

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


            1. s-kozlov Автор
              18.01.2019 13:44

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


      1. John_Minority
        18.01.2019 18:03
        +1

        > А что, разумно перестраивать наработанные процессы под каждого заказчика?

        1. Не разумно вообще обсуждать сферических коней в вакууме.
        2. Не разумно работать с каждым заказчиком — если заказчик дебил, то зачем с ним работать?
        3. Не разумно смешивать внутреннюю кухню с потребностью заказчика — потребности заказчика в редких случаях коррелируют с внутренними процессами разработки, а если для работы с заказчиком необходимо менять процессы, можно с этим заказчиком не работать.

        Тупняк какой-то очередной начался.


        1. s-kozlov Автор
          18.01.2019 18:55
          +1

          Не разумно смешивать внутреннюю кухню с потребностью заказчика

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


  1. viknt
    19.01.2019 11:12

    вы забыли о тринадцатой ошибке


    1. s-kozlov Автор
      19.01.2019 11:14

      И какая же тринадцатая?
      P.S. Если что, это перевод. Можете написать автору, он даже отвечает на комменты на русском.