Agile: что это, зачем нужно, конкретные примеры

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

Суть

Agile – это совокупность методов создания программы. Программа же (в самом широком смысле) – заданная последовательность действий. Правильно разработать эту последовательность важно как для всего бизнеса, так и для отдельного проекта. 

У этих методов есть общие признаки: Agile переводится как «подвижный», «проворный», «живой», «верткий», «гибкий», «способный изменяться легко и быстро». Отсюда и 4 ценности agile: 

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

«Важнее» не значит, что нужно забывать про «процессы и инструменты», «исчерпывающую документацию» и т. д. Это значит, что если сроки поджимают, то нужно правильно расставить приоритеты.

Четыре ценности agile поясняются 12-ю принципами. Последовательность их появления будет зависеть от логики повествования. Начнем мы с того, как эти ценности реализуются на практике в каждом методе agile:

• маленькие команды. В agile главное – постоянное живое общение. И чем больше команда, тем сложнее его наладить, создать дружескую атмосферу. Это соответствует первому принципу agile: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды»;
• нет конкретного лидера. Лидерство постоянно перетекает от одного члена команды к другому, в зависимости от того, кто лучше разбирается в решении текущей задачи; 
• короткие, но строгие промежутки работы. Нарушать их можно только в интересах заказчика. Второй принцип agile: «Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев»;
• итеративная работа. Промежутки должны идти друг за другом непрерывно, чтобы не ослабевал темп.

К семейству Agile относится и Scrum, который мы подробно разберем. Стоит отметить, что у него нет четкого определения. Одни называют Scrum методом, другие – фреймворком, то есть набором правил, на котором в индивидуальном порядке создается метод. Думается, определение зависит от того, насколько подробно вы сами будете внедрять этот метод/фреймворк.

Scrum

Третий принцип Agile: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно». У игроков в регби – та же задача. Если игра приостанавливается, то и энтузиазм падает. Для его поднятия используется scrum (схватка): команды вплотную становятся друг напротив друга, а затем начинают толкучку с целью получить мяч. 

Разработчики программ вдохновились этим и назвали свой метод работы Scrum. Как и в регби, главное в методе – команда и отношения внутри нее. Она имеет следующую структуру:

• Product owner («Владелец Продукта»). Он знает, каким должен быть конечный продукт для конкурентоспособности на рынке, и ставит требования по его разработке. Обратите внимание на четвертый принцип agile: «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе».
• SCRUM-мастер. Это – не лидер, а «лидер-слуга». С одной стороны, он направляет команду, объясняет ей суть поставленных задач. С другой стороны, он создает облегченные условия для ее самореализации и самостоятельной работы, удовлетворяя невысказанные потребности. Тут можно ввести пятый принцип agile: «Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд».
• Команда Разработки. Их цель можно выразить шестым принципом agile: «Работающий продукт – основной показатель прогресса». В команде – от 3 до 9 человек – иначе работа будет неэффективна. В нее входят представители всех профессий, необходимых для создания этого продукта. Если команда занимается разработкой сайтов, то в нее будут входить программист, дизайнер, копирайтер и т. д.

Работа Scrum-команды делится на спринты. Sprint – еще один спортивный термин, обозначает он бег на короткую дистанцию. В нашем случае дистанция изменяется не в метрах, а в днях и неделях. Максимальный рекомендуемый размер спринта – один месяц. За это время команда должна сделать готовый продукт.

Делать отсрочку крайне нежелательно. Это отражено в седьмом принципе agile: «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения».

В Спринте выделяются следующие события:

1. Планирование Спринта.
2. Ежедневный Скрам. 15-минутное собрание Команды Разработки, на котором планируется работа на следующие 24 часа.
3. Обзор Спринта. В конце Спринта обсуждаются его итоги.
4. Ретроспектива Спринта. Предлагаются улучшения для следующего Спринта.

События напоминают классический Цикл Деминга (plan – do – check – act), только этап «действие» как бы вбирает в себя все остальные. И это неудивительно: agile – вечное движение вперед. 

Разберем пример, разбивая Спринт на События.

Планирование Спринта

Обратимся вновь к команде, которая занимается разработкой сайтов. Не считая Владельца продукта и Scrum-мастера, в нее войдут: контент-менеджер, SEO-специалист, веб-программист, HTML-верстальщик, веб-дизайнер. Для планирования Спринта им нужно:

1. Бэклог Продукта. Это список требований к продукту, который формирует Product Owner с помощью Команды Разработки. Каждое требование сопровождено необходимым комментарием, оценкой объема работы и ценности среди других требований. Работа с Бэклогом не завершается после Планирования Спринта. Наоборот, постоянное внесение изменений облегчит проведение этого События в будущем. 

Например, готовый сайт должен находится в топ-5 выдачи. У него будет ограниченное количество разделов, чтобы пользователь не запутался. На каждой странице должно быть какое-то минимальное количество картинок. И так – по каждому сайту, который нужно создать или отредактировать. 

1. Последний Инкремент продукта. Инкремент – это все, что удалось сделать по итогам того или иного Спринта. Предыдущий Инкремент нужен для того, чтобы предсказать производительность команды. Например, сколько сайтов удалось создать, сколько было отредактировано, удалось ли ввести сайт в топ-5.

Затем определяется:

• что будет сделано. Здесь последнее слово – за Командой Разработчиков. Она должна взять Бэклог и определить, с какими заказами справится, сколько сайтов успеет сделать; 
• как это будет сделано. Здесь основной метод – декомпозиция. Команда берет то, что выбрано в Бэклоге, и разбивает это на более мелкие задачи. Например, подобрать список ключевых слов, написать текст, проверить его на содержание ключевиков с помощью определенных сервисов.

На Событие уходит максимум 8 часов. И это совсем не много: речь идет о плане на весь месяц. 

Ежедневный Скрам

Впервые это Событие происходит через 24 часа после окончания Планирования Спринта и начала работы. Затем постоянно повторяется с интервалом в сутки: команду будет мотивировать, если Событие будет происходить в одно и то же время.

Зачем это нужно? Ответ кроется в восьмом принципе agile: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».

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

• Если работать так, как в предыдущие сутки, будет ли достигнут заявленный Инкремент продукта?
• Как устранить препятствия, с которыми сталкивались в предыдущие 24 часа?
• Как организовать работу сегодня?
• Сможем ли мы в конце концов достичь заявленного Инкремента?

Копирайтер рассказывает, сколько текстов он написал, как его работа состыковывается с подборкой ключевиков SEO-специалистом. Если не состыковывается, то собрание не превращается в выяснение вопроса: «Кто виноват», но помогает совместно решать вопросы. К тому же, публичность своей деятельности всегда мотивирует, особенно в командах agile, где очень важна сплоченность небольшой команды.

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

Scrum-мастер помогает поддерживать это внимание. Степень его вмешательства зависит от самоорганизации команды. Как минимум мастер фиксирует, что собрание состоялось, как максимум – следит и записывает все за членами команды. Но чтобы помочь им взглянуть на себя со стороны, а не отчитать.

На все собрание дается 15 минут. Но лучше быстрее. Идеал Scrum – это регбисты, которые стоят лицом со лицу со своей проблемой и готовы всегда вступить в бой.

Обзор Спринта

Происходит он в конце спринта, когда Продукт должен быть готов. В нем участвует не только Scrum-команда: 

• владелец Продукта приглашает заказчиков. Именно на основе их заказов он во время Планирования сформировал Бэклог Продукта со всеми требованиями;
• другие Scrum-команды с похожими Бэклогами и Инкрементами.

Сначала говорит Команда Разработчиков. Она рассказывает, как был сделан или недоделан продукт. Почему получился такой результат. Как они боролись с причинами такого результата.

Затем слово берут остальные. Они задают вопросы – Команда Разработчиков на них отвечает.

В конце говорят все вместе. Они решают, как исправить ошибки в будущем. Обсуждают, какие внешние факторы (ситуация на рынке, финансирование) окажут влияние на будущий Спринт и что в связи с этим нужно изменить при его Планировании. Фактически, на месте создается черновик Бэклога Продукта на следующий Спринт.

Проводить Событие нужно в любом случае, так как это – мост между командой и заказчиками. Вспомните 3-ю ценность agile. Обратите внимание на десятый принцип: «Изменение требований приветствуется, даже на поздних стадиях разработки».

Кроме того, работа Команды Разработки становится публичной, а это повышает мотивацию: им будет стыдно демонстрировать неготовый продукт, тем более перед другими командами. Тут уместен одиннадцатый принцип agile: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им».

Как правильно провести Обзор Спринта?

• Помните о дружеской атмосфере, которая должна царить между всеми присутствующими. 
• Помните, что на Обзоре будут присутствовать те, кто совсем не знаком с Бэклогом. Поэтому четко озвучьте его в начале.
• В остальном – не сильно готовьтесь к самому выступлению (создание презентации, распределение ролей и т. д.). Помните, что планированию в agile отводится минимум времени. Лучшее средство – сделать обзор динамичным и ориентированным на конкретный продукт. Вот соответствующий принцип agile, двенадцатый по счету: «Простота – искусство минимизации лишней работы – крайне необходима».
• Если это возможно, дайте заказчикам самим «поиграть» с продуктом: посмотреть готовый сайт, полазить на нем.

Четких временных рамок нет. Но помните: чем лаконичнее Событие в Scrum, тем лучше.

Ретроспектива Спринта

Вот здесь присутствует только Scrum-команда, так как они решают свои, внутрисемейные проблемы. Плана События нет. Главное – помнить, что вы ищете ответ на вопросы: 

• Что было хорошо?
• Что могло бы быть лучше?
• Что будет улучшено?

На эти вопросы все должны ответить по очереди. Затем обобщаем ответы. Допустим, веб-дизайнер считает проблемой слабо развитое общение, а программист с ним не соглашается. Тогда высказаться по этому вопросу должны все, чтобы прийти к общему знаменателю. 

Особое внимание уделяйте последнему вопросу. Хорошо было бы улучшить все и сразу, но нужно расставить приоритеты. Для этого определяется максимальное количество улучшений (максимум 5), и каждый член команды голосует за те, которые кажутся ему более важными. Эта пятерка будет висеть у всех на виду весь следующий Спринт. 

Если Scrum-команд несколько, то они могут учиться на ошибках друг друга. Для этого нужно выбрать человека, который будет посещать Ретроспективы всех команд. Он будет обобщать и передавать опыт от одной команды к другой, задавать редкие, но меткие вопросы для улучшения Ретроспективы.

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

Конечно, полностью agile подойдет не для каждого бизнеса:

• Производство не всех продуктов можно разбить на этапы, которые будут длится максимум один месяц. Допустим, производится сложное оборудование. И через месяц после начала работы заказчики приглашаются на Обзор Скрипта. Что они увидят? Незаконченный механизм? Что они могут попробовать, «потрогать»?
• Трудно соблюсти рамки в 3–9 человек. Например, над созданием сайта могут работать всего лишь копирайтер, занимающийся текстами, и программист, который возьмет на себя верстку. Зачем им Scrum-мастер?

Но элементы Scrum и Agile в целом, идея быстрой, итеративной работы могут вдохновить многих на совершенствование своего рабочего процесса.