Манифест гибкой разработки программного обеспечения (Agile Manifesto) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования, именующих себя «Agile Alliance».

Текст манифеста доступен на более чем 50 языках (и на русском), и включает в себя 4 ценности, 12 принципов.

Ценности Agile Manifesto

1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

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

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам:

1. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

А теперь давайте пройдемся по заблуждениям относительно Agile Manifesto

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

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

Вячеслав Цырульник писал в своём блоге на Medium колонку о том, что такое манифест Agile, зачем он нужен компаниям и как лучше трансформировать бизнес. Очень правильные замечания по теме.

Agile — прилагательное

В переводе с английского языка, Agile («эджайл») — гибкий. Поэтому все эти фразы, которые я встречал за последнее время в интернете:

• управление проектами в стиле Agile;
• Agile-манифест;
• Agile у нас не заработал;
• стань первым Agile-маркетологом в России;

можно перевести, как:

• управление проектами в стиле гибкий»;
• «гибкий-манифест»;
• «гибкий у нас не заработал».

Ну и очевидно, что йоги-маркетологи — новый тренд, который только-только идет в Россию. А гибкий-манифест, — вы можете себе такое представить? Наверное, это кусочек пергамента, который умеет танцевать на столе. Понимаете к чему я? Люди вокруг говорят странные фразы, при этом у них горят глаза и они спешат внедрить Scrum. Страшно!

Так, а что же там за манифест

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

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

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

Простой пример: «Agile-манифест разработки программного обеспечения». Что вы запомните из этой фразы? Наверное, «Agile-манифест», а вспомните ли вы, что это про разработку программных продуктов? Надеюсь. А вот призёр — первое место, золотая медаль на конкурсе по потере контекста в процессе перевода.

В оригинале книга называется «Scrum — the art of doing twice the work in half the time», что практический любой бесплатный электронный переводчик переведёт как «Scrum — искусство делать вдвое больше работы в два раза быстрее». Ни слова о проекте. Scrum вообще не про проекты. Увы и ах.

Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану. То есть, не отрицая того, что справа, мы всё-таки ценим то, что слева.

— из Agile-манифеста

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

Кстати, позвольте придерусь к первой ценности в русскоязычном манифесте. В оригинале на месте слова «важнее» стоит слово “over», которое дословно переводится как «над». То есть дословный перевод — «Люди и взаимодействие над процессами и инструментами».

Да, на русском языке фраза достаточно странная, но в данном случае перевод мог бы быть: «Люди и характер их взаимодействия определяют необходимые процессы и инструменты».

Agile — про создание программных продуктов?!

Не просто про создание программных продуктов, а про создание продуктов, для которых не существует чёткого и понятного плана «как сделать это правильно».

Такой план невозможно составить, например, если у вас:

• продукт, которого ранее не существовало на рынке (не подтверждена ценность идеи и нет достоверной информации по размеру рынка);
• технологически сложный продукт, который нельзя собрать из набора готовых компонент.

А может ваши гипотезы о назначении продукта вообще находятся в такой области, где рынок еще не успел сформироваться?

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

Всё, уже можно про Scrum?

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

Agile нельзя внедрить в организации, да и эта фраза лишена всякого смысла. Как можно внедрить ценности, как можно внедрить другое отношение к людям и процессам? Нужно объединить людей, которые видят смысл в описанных ценностях, и помочь им освоить те самые практики из мира Agile, которые позволят им создавать восхитительные продукты. Давайте называть такой процесс трансформацией.

Трансформация компании

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

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

Фундаментально, существует два пути изменить что-либо:

• построить всё заново с нуля;
• плавно меняться, аккуратно убирая или заменяя те участки системы, которые препятствуют положительным изменениям.

Scrum

Как сформировать Scrum команду? Нам нужно помочь людям стать такими:

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

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

Простой пример — компания не отменила персональные KPI, и запускает Scrum. Но в Scrum ответственность командная, вот и «приехали». На практике, успешные истории транфсормации компаний с помощью Scrum:

• либо отмена текущих правил для части коллектива, которая сама проявила инициативу попробовать Scrum;
• либо создание Scrum-команд из новобранцев, для которых изначально не действуют старые правила.

Так что Scrum — это про ломать то, что есть (если есть) и строить с нуля. Это абсолютно точно не плавный переход, а серьёзная встряска, и к этому вопросу нужно подходить с полной осознанностью.

Kanban

С тем как сломать и построить заново всё понятно — искать квалифицированного Scrum-мастера (или своего воспитывать), выявлять инициативных желающих, формировать команды и вперёд на ежедневные тренировки.

Но можно не ломать, а менять последовательно. В интернете часто упоминается фраза «Kanban-доска», увы, к реальному «Канбану» она имеет крайне отдаленное отношение.

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

Kanban — про правильные процессы. Правильные — с точки зрения достижения целей вашей организации. Рельсы, на которых ваша организации будет уверенно двигаться вперёд. Так что не спешите бежать сломя голову в Scrum, как минимум познакомьтесь с плавными методами трансформации.

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

Оказывается, Agile — сложно?

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

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

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

Маркетинг, продажи и Agile

А теперь, внимание. Моя любимая история. «Привет, мы теперь используем Scrum/Kanban/другое слово в ИТ, у нас наладились отношения между закачиком и технической командой, мы “быстрее бежим», и меньше делаем дорогих ошибок, но прибыль что-то у компании не растет».

А еще и затраты стали больше, правда ведь? Консультанты, агенты по трансформации, повышение зарплат и так далее. А чего вы ждали-то? Вы разве к ИТ-отделу ходите за финотчетами?

Да, вы стали быстрее, вы стали делать меньше ошибок. И это только лишь фундамент. В маркетинге и продажах классические подходы тоже стремительно уходят в небытие, там появляются совершенно новые техники и новые иностранные слова:

• Growth hacking.
• Lean startup.
• Lean marketing / UX.

И с этими словами тоже нужно познакомиться, потому что там где заканчивается Agile, начинается Business Agility — а это уже история для отдельной статьи.

В чём же суть Agile

Один из авторов манифеста (Дейв Томас) после его создания не посещал конференции, мероприятия, не интересовался тренингами по Agile. В рамках своего знаменитого выступления «Agile мёртв» он описал, что и как надо делать.

Что делать

1. Понять что сейчас происходит вокруг.
2. Сделать маленький шаг в сторону достижения поставленной цели.
3. Скорректировать текущее понимание ситуации по результатам полученной информации.
4. Повторить вышеописанные действия.

Как делать

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

Что для этого нужно

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

И эти правила не персональные, они должны работать на уровнях:

• человек;
• команда;
• организация.

Так что берите их на вооружение и начинайте меняться уже сегодня.