Как и зачем создавали Agile манифест, почему его так назвали + расшифровка всех ценностей и принципов

В этом году Agile манифесту стукнуло 20 лет. С юбилеем! Как говорится, годы идут, а гибкие методы разработки не теряют своей актуальности. В этой статье разберемся в принципах Agile и вспомним историю создания манифеста.

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

• Crystal — самый ранний. Появился еще в 1992 году. В основе этого подхода — командная работа, много общения внутри нее, чтобы все понимали, кто и что делает. Продукт делают по кусочками, принята частая поставка кода. В дальнейшем многие из этих принципов лягут в основу Agile–манифеста.
• В 1995 году появился метод Scrum. Он про отказ от долговременного планирования и деление разработки на короткие этапы. Каждый этап заканчивается экспресс–оценкой и внесением правок. Важно место в Скрам отводят расстановке приоритетов.
• В 1996-1999 появился метод экстремального программирования — XP. Именно отсюда вышли пользовательские истории — User Stories и продуктовые релизы.

У каждого из описанных выше методов (и еще многих других) есть свои авторы. И вот однажды, точнее в феврале 2001-го, эти великие мужи решили затусить на горнолыжном курорте Сноуберд недалеко от Солт–Лейк Cити. Всего их было 17:

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

Чуваки горели идеей: объединить все свои наработки и создать наикрутейшую методику для айтишников, чтобы ее могли использовать во всем мире и создавать мощные продукты.

И вот они собрались в комнате у доски. Первым взял слово Боб Мартин, активный практик метода экстремального программирования XP. Он предложил выделить и записать общие принципы уже существующих легковесных подходов. Легковесные — то бишь те, где все участники процесса работают с первичными требованиями от пользователей, заказчика или стейкхолдеров. Эти требования могут быть заявкой, хотелкой, пользовательской историей или выражены еще в какой–то форме удобной людям. Легковесные подходы как альтернатива тяжеловесным — где очень и очень много документации и жестких регламентов.

Но вернемся к событиям той судьбоносной Agile–встречи. Кто–то из участников не особо верил в успех мероприятия. Например, Alistair Cockburn говорил, что не ожидал, что конкретно эта группа людей сможет договориться о чем–то значительном.

Однако дела пошли на лад и уже в этот день Martin Fowler сформулировал первые 4 принципа манифеста. Остальные добавили еще два. Но один потом решили убрать. Как вспоминал Jim Highsmith это звучало примерно так:

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

Группа еще поработала с формулировками и зафиксировала 4 ценности в Agile манифесте. До нас они дошли в таком формате:

• Люди и их взаимодействие друг с другом важнее, чем процессы и инструменты. Документы, инструкции, субординация, регламенты, работа от звонка до звонка — это не про людей и не для них. Agile project management это про сотрудников с горящими глазами, которые реально болеют за продукт. Они могут чего–то не уметь, но знать, как надо. Они выпустят тестовый продукт, и пока тот будет приносить клиентов и собирать обратную связь, прокачают свои компетенции, чтобы следующую версию сделать мощнее и круче.
• Работающий продукт важнее исчерпывающей документации о нем. Представьте, что в компании работают над мобильным приложением по продаже товаров. Разработчики выпустили тестовую версию, маркетологи корпят над разделом вопрос–ответ. Но потом вдруг выясняется, что часть вопросов касается функций, которые внедрят через месяц–полтора. А пользователи, которые скачали тестовый продукт жалуются на глюки и баги. Так, может, маркетологам лучше заняться сбором обратной связи для их устранения? А вопрос–ответ оставить напоследок, когда у пользователей накопятся вопросы, а разработчики выкатят весь функционал продукта. Вот это будет по agile.
• Отношения с клиентом важнее юридически выверенного и подробного контракта. Если вдруг в контракте написано про SEO, но в процессе работы вы поняли, что клиенту важнее простота и удобство сайта, пойдите навстречу. Лучше довольный клиент и хороший, работающий сайт, чем «все по документам».
• Готовность к изменениям важнее, чем слепое следование первоначальному плану. В Agile project management команда может быстро (и безболезненно) повернуть в другую сторону, поменять маршрут, если заказчику или пользователям это нужно или меняется ситуация на рынке. Представьте, что вы готовите контент–план по продвижению продукта в соцсетях на месяц вперед. Но перед публикацией очередного поста узнаете, что ваш конкурент выкатил обновление продукта и получил массу негатива от пользователей в первые сутки. Быть Agile — значит реагировать на ситуацию на рынке. И срочно готовить свою публикацию о приложении конкурента, и чем оно так не зашло людям.

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

На второй части встречи они дополнили ценности 12-ю принципами.

• Наивысший приоритет — удовлетворение потребностей заказчика. Чем быстрее он получит ценность от разработки, тем лучше.
• Изменение требований даже на поздних стадиях разработки — это вполне нормально. В принципе на любых стадиях изменения — это ок.
• Работающий продукт надо выпускать как можно чаще, с периодичностью от двух недель до двух месяцев.
• На протяжении всего проекта команда разработчики и заказчики должны работать вместе. Лучше ежедневно.
• Над проектом должны работать мотивированные профессионалы. Им нужно создать условия. Работу построить на поддержке и доверии.
• Непосредственное общение — это самый практичный и эффективный способ коммуникации с командой разработки и внутри нее.
• Работающий продукт — это главный и самый важный показатель прогресса.
• Инвесторы, разработчики и пользователи должны поддерживать этот рабочий ритм постоянно. Это залог устойчивого процесса разработки.
• Постоянное внимание к техническому совершенству и качеству повышает гибкость проекта.
• Лишней работы должно быть минимум.
• Самоорганизующееся команды дают лучшие решения (самые эффективные и качественные).
• Команда должна регулярно анализировать и думать, как еще она может улучшить свою работу, повысить эффективность. Этот процесс непрерывных улучшений должен стать системным.

В нашей базе знаний много статей по Agile, например, Agile в HR, Agile Supply Chain, Agile лидерство и другие. Начните с них.

А вот эта подборка книг поможет вам разобраться с принципами Agile и «продать» эту философию команде разработчиков.

• The Software Project Manager’s Bridge to Agility от Michele Sliger и Stacia Broderick. Эта книга пригодится тем, кто переходит на Agile с традиционных методов управления проектами. Или тем, кто сейчас задумался, а, собственно, надо ли? Авторы подробно рассказывают о разнице между подходами и способах безболезненного перехода.
• Project Management the Agile Way: Making it Work in the Enterprise, автор John Goodpasture. Книгу удалось отыскать в наличии на Amazon. Здесь много полезного про техники и инструменты, которые нужны под разные проекты. Еще книгу можно смело давать членам команды, чтобы они прониклись философией Agile и точно поняли, чего вы от них хотите.
• Agile Retrospectives: Making Good Teams Great от Esther Derby и Diana Larsen. Эта книга особенно пригодится тем, кто начинает проводить ретроспективы или не доволен тем, как они проходят сейчас. Тут описаны способы организации этих встреч, причем не только удачные, но и не удачные варианты, рассказано, как мотивировать команду к активному участию в них. И, главное, как сделать ретроспективы реально полезными для всех, а не для «галочки». Еще здесь описаны способы, как усилить вашу и без того классную команду.
• User Stories Applied: For Agile Software Development от Mike Cohn. Книга про работу с пользовательскими историями (user story). Автор научит делать их хорошо, и сразу видеть, где что–то в истории хромает. Много полезного про жизненный цикл пользовательских историй, мозговой штурм по ним, приоритезацию, правила разработки и тестирование.
• Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition, автор Lyssa Adkins. Если вам нужно нанять или вырастить внутри компании скрам–мастера, менеджера продукта или Agile–коуча, эта книга то, что надо. Книга дает глубокое понимание об этих ролях, кто и зачем нужен компании, какие их методы работают, а какие нет.