Что значат принципы и ценности Agile манифеста? Зачем их знать и как применять в работе

Среди моих друзей много айтишников и они работают по гибким методологиям. Я спросила, нравится ли им Agile? Ответы всегда были одинаковые — мы пробовали чистый Agile и Scrum, а потом оставили элементы, которые работают для наших проектов.

По данным исследования ScrumTrek, 80% IT–компаний используют хоть что–то из Agile. Например, мои друзья работают в Ultimate Guitar, Belka Games, VIvid Money. Что из гибких методологий  используют в этих компаниях:

• Спринт — временной отрезок, который команда работает над проектом. Длится от 7 дней. Цель спринта — создать кусочек продукта, чтобы показать заказчику.
• Ретроспектива — совещания по итогам спринта. На них обсуждают, что было сделано, какие были трудности, как их исправить и сделать лучше в следующий спринт.
• Бэклог — список задач.
• Стэндап — короткие совещания участников команды (не дольше 15 минут). Каждый говорит, что сделал, что будет делать, какие есть проблемы, вопросы.
• Доска — реальная или виртуальная, куда пишут задачи по спринту и ход их выполнения.

В этом году 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 это звучало примерно так:

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

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

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

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

Для обычных  разработчиков формулировки не так важны. За 20 лет существования Agile-манифеста они впитали эти ценности, вся их работа строится на них без ежедневного проговаривания. И пусть не всегда осознанно, но эта культура гибких методологий уже проросла в них. Поэтому остановимся подробно на ценностях манифеста, и том, как они работают на практике.

Ценности Agile манифеста:

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

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

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

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

Год назад «Мегафон» начал переходить на Agile. Они собрали 50 кроссфункциональных команд. В них объедигили IT–специалистов, продуктологов, бизнес–аналитиков и маркетологов. К каждой команде приставили Agile-коуча. Он занимается менторством и настройкой процессов.

Как говорит Александр Соболев, директор по стратегии и развитию бизнеса МегаФона, лучше всего гибкие методологии показывают себя в продуктовых командах, которые разрабатывают тарифные планы.

«В современном мире нужно много экспериментировать, и для этого отлично подходит agile. Наши команды выдвигают гипотезу и во время коротких «спринтов» подтверждают или опровергают ее. В результате, если говорить о МегаФоне, продолжительность time to market, в зависимости от задач, сократилась в 5-12 раз», — отмечает Соболев в интервью Rusbase.

В компании открыли школу для обучения собственных Agile-коучей внутри компании, чтобы не искать их на стороне. Пока специалистов не хватает, один коуч работает с несколькими командами.

Коучи обучают сотрудников МегаФона по Greenbook. Это свод правил, который прописали вместе с руководством.

Agile нельзя купить или внедрить за день. Переходить нужно постепенно и вдумчиво. Если компания большая, то и времени заложите побольше.

В любом случае начинать лучше с небольших изменений:

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

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

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

С этим проблемам столкнулись в банке «Хоум кредит». Для перехода на  Scaled Agile Framework они составили карту внедрения, разделили процесс на этапы для каждой команды. Начали с тех, кто уже работал по гибким методологиям: направления «Кредиты и депозиты» и  «Карты и лояльность». Затем стали переводить на фреймворк критичные сервисные функции и каналы.

Через год работы по SAFe получили от команд фидбэк:

• Люди в командах начали фокусироваться на общих целях. Раньше этого не было
• Задачи стали прорабатывать эффективнее
• Участникам команд и руководству стало проще общаться друг с другом по рабочим вопросам
• Команды разных блоков перестали жестко конкурировать между собой
• Мотивация сотрудников повысилась, навыки прокачались.

Но всплыли и проблемы. Среди них — команды слишком сильно зависят друг от друга в плане задач. Не всегда понятно, кто над чем работает и где проблема. Не все сотрудники захотели тратить время на погружение в новый фреймворк. Это в среднем занимало 2-3 дня.