Twelve Mistakes in Agile Manifesto

В настоящее время Agile Manifesto - это библия из 12 принципов, изобретенных в 2001 году, которые показывают нам, как должна быть организована разработка программного обеспечения. Вообще, я люблю их соглашаюсь со всеми из них. Однако на практике большинство команд на самом деле не понимают их. Вот краткое изложение того, что происходит, и моя интерпретация каждого принципа.

Принцип №1: «Высший приоритет - удовлетворить клиента за счет скорейшей и непрерывной доставки (continuous delivery) ценного программного обеспечения». 

 

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

 

Однако а самом деле все совершенно противоположно этому - клиент будет удовлетворен только когда... и если программное обеспечение будет отлично сделано и доставлено. 

 

Успешная команда будет фокусироваться чтобы сделать процесс разработки «быстрым и непрерывным», и именно это приведет к удовлетворенности клиентов. Будет фокусироваться на улучшении процесса, а не на удовлетворении клиента. Удовлетворение - следствие, а не главная цель.

Принцип № 2: «Добро пожаловать в постоянно меняющиеся требования. Гибкие процессы меняют конкурентные преимущества».

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

 

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

Принцип № 3: «Поставлять рабочее ПО часто, от пары недель до нескольких месяцев, с предпочтением более короткой временной шкалы».

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

 

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

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

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

 

Манифест не о том! «Совместная работа» означает больше коммуникации и более быстрое реагирование на нее. Это определенно совсем не означает отсутствие ролей и обязанностей.

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

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

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

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

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

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

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

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

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

Это идеальный принцип, который говорит так много и ничего не говорит в то же время. Что такое «внимание»? Я могу объяснить. Это означает правила и политики. Прежде всего, любая политика означает наказание тем, кто нарушает правила. 

 

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

Принцип № 10: «Простота - искусство максимизировать объем ненужной к выполнению работы».

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

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

Это правило часто переводится как легализация анархии. Мы не нуждаемся ни в каких менеджерах проектов, процессах, дисциплине, правилах или политиках - вместо этого у нас есть хоракция! Нам также не нужен архитектор программного обеспечения - наши программисты могут принимать все технические решения на регулярных собраниях! Более того, мы не хотим, чтобы наши программисты несли индивидуальную ответственность за что угодно - они всегда вместе во всех рисках и проблемах. 

 

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

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

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

 

Хорошо известно, что лучшая команда - это та, которая способна быстро и неизбежно отвергать плохие элементы. Эффективно ли ваша команда? Помогают ли в этом ретроспективные встречи? Я сомневаюсь в этом. Поэтому я считаю, что манифест означает здесь не собрания. Это означает, что команда должна иметь эффективный механизм саморегуляции и самосовершенствования. Кроме того, ретроспективные встречи просто не могут быть таким механизмом, потому что они не позволяют команде принимать сложные дисциплинарные решения.