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