Философия Agile: от слов к делу
Цифровые технологии все больше проникают в нашу жизнь. И дарят нам не только новые сервисы и новые возможности собственно в Интернете и телекоммуникациях. Для того, чтобы новые сервисы, интернет-магазины, crm-системы, мобильные приложения, мессенджеры и прочие цифровые площадки максимально отвечали запросам пользователей, приходится думать не только над технической частью. И даже не только над методами разработки, а еще и над такими глобальными вещами, как философия.
Так, из IT-сферы к нам пришла философия Agile, основные принципы которой вполне пригодны для многих других областей. Что за философия и где она может быть полезна? Этому и посвящена наша сегодняшняя статья.
Что такое Agile: немного истории
Простой механический перевод слова «agile» вряд ли откроет полную картину того, что же это такое. Google-переводчик переводит «agile» как «гибкий», однако при обратном переводе тут же предлагает совсем другое слово «flexible», которое тоже означает «гибкий».
Разница тут, пожалуй, в том, что «flexible» подразумевает гибкость механическую, а термин «agile» гораздо шире и предполагает гибкость мыслительную или, если хотите, ментальную. В зависимости от контекста, «agile» можно понимать как «быстрореагирующий», «подвижный», «проворный», «маневренный».
Если попытаться представить все вышеперечисленное разом, это и будет наиболее адекватное понимание термина «agile». Причем тогда тут философия? Разобраться в этом нам поможет «История создания Agile-манифеста».
Для начала вкратце, что такое Agile-манифест. Это документ, в котором закреплены основные принципы и ценности, которых следует придерживаться при разработке программного продукта. Далее мы расскажем о манифесте подробнее, а сейчас, как и обещали, акцентируем внимание на истории вопроса.
С развитием IT-технологий разработки становятся все масштабнее, и в этих условиях внятно сформулировать техническое задание (ТЗ) все сложнее. Заказчики зачастую сами не до конца понимают, что им нужно. И даже если бы существовала условная волшебная кнопка «Сделайте все хорошо», многие затруднились бы пояснить, что значит для них «все хорошо» и что именно должна выдать эта чудо-кнопка после нажатия.
Разработчики стали массово сталкиваться с ситуацией, когда доскональное следование пунктам ТЗ никак не гарантирует, что клиент останется доволен. В то же самое время, если клиенту вдруг придет в голову, что он запросил что-то не то, и нужно было бы запросить что-то другое, правки в ТЗ займут определенное время.
А еще они потребуют соблюдения определенных формальностей, потому что разработчики начали страховать себя от возможного недовольства клиентов путем фиксации всех требований в форме договора. К тому же остается неясным, что в этом случае делать с уже завершенным объемом работ и достигнутым результатом, если он «не вписывается» в новую концепцию.
Стало понятно, что «разруливать» сложившуюся ситуацию нужно на уровне общего подхода, а не просто локального оперативного решения проблем, возникающих в ходе конкретного проекта. Ввиду того, что ситуация обрела достаточно серьезный масштаб, и в ее решении было заинтересовано немало практикующих разработчиков, в начале «нулевых» в IT-кругах развернулась горячая дискуссия по данному вопросу.
Итогом стал Agile-манифест, который составили 17 основных инициаторов дискуссии, объединившихся в Agile Alliance. Окончательные детали Agile-манифеста были доработаны в ходе живой встречи на горнолыжном курорте Юта в феврале 2001 года. Итоговый документ был подписан 13 февраля 2001 года. Что он собой представляет? Давайте посмотрим.
Agile-манифест: 12 принципов и 4 ценности
Итак, Agile-манифест фиксирует основные ценности, которых следует придерживаться при разработке программного обеспечения и взаимодействии с заказчиками, и главные принципы, на которые следует опираться в процессе работы. Какие же ценности проповедует Agile-манифест?
- Человек важнее, чем процесс и/или инструмент.
- Функционирующий продукт важнее, чем описывающая его документация.
- Сотрудничество важнее, чем согласование условий договора.
- Готовность меняться и менять важнее, чем первоначальное ТЗ.
Как метко замечено авторами манифеста, «при всем понимании важности того, что написано справа, более важным является то, что написано слева». Вкратце это все можно представить так, что человек первичен, а то, что в компьютере, вторично. Поэтому сначала нужно решать вопрос с заказчиком, а потом уже что-то делать на уровне разработки, т.е. «в компьютере». Собственно, именно на это и указывают основные принципы Agile, которые мы представим в кратком изложении.
- Наивысшим приоритетом является удовлетворение запросов заказчика.
- Изменения допустимы на любой стадии.
- Новые функциональные продукты нужно выпускать по возможности чаще.
- В ходе проекта разработчики и заказчики должны работать сообща.
- Для профессионалов следует создать условия, обеспечить поддержку и доверять их профессионализму.
- Лучший способ коммуникаций – это непосредственное общение.
- Если продукт работает – это и есть основной показатель правильного направления усилий.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный устойчивый ритм.
- Необходимо постоянно уделять внимание качеству и совершенствованию.
- Простота как искусство минимизации излишней работы является важным условием достижения результата.
- Самые лучшие требования, архитектурные и технические решения рождаются в команде, способной к самоорганизации.
- Команде следует постоянно искать способы повышения эффективности.
Таим образом, Agile-манифест утверждает итеративный подход в разработке программного обеспечения, при котором процесс работы идет параллельно с перманентным анализом полученных результатов и корректировкой последующих этапов работы. Каждая фаза проекта представляет собой повторяющуюся последовательность действий PDCA:
- Plan (планирование).
- Do (реализация).
- Check (проверка).
- Act cycle (корректировка при необходимости и последующий цикл действия).
По сути, Agile-разработка – это гибкий подход к решению задач и ориентация на клиента и его запросы как основополагающий фактор. В принципе, так или иначе, по данному пути должны идти все сферы бизнеса, заинтересованные в улучшении сервиса и обслуживания клиентов.
В некотором смысле философия Agile – это и есть философия бизнеса. В такой сугубо прикладной сфере, как бизнес, говорить о философии можно только в сочетании с конкретными методами, посредством которых реализуется Agile-проект.
Agile-методы и управление Agile
На бескрайних просторах Интернета время о времени появляются изыскания на тему «Что такое Agile: методология или философия?». В качестве примера можно еще привести «Обзор Agile. Что это: методология, метод или философия?».
Самым разумным будет разделять Agile как общность гибких методов или подходов и Agile-философию как таковую. Рассмотрим основные методы и подходы, применяемые в Agile-проектах.
Теперь подробнее о каждом методе.
Scrum-метод
Своим названием Scrum обязан популярной в Америке игре – регби. По аналогии с тем, как в этом виде спорта строятся линии обороны и нападения, а успех зависит от слаженной работы команды, так и в бизнесе все или почти все зависит от командной работы.
Впервые данный термин в контексте управления проектами применили японские исследователи Хиротаки Такеучи и Икуджиро Нонаки примерно в 80-х годах 20 столетия. Собственно как метод, Scrum представлен в 1993 году американским программистом Джефом Сазерлендом.
Свой метод он подробно описал в книге «Scrum. Революционный метод управления проектами». Данный метод взяли на вооружение такие гиганты рынка, как Microsoft, Amazon, Yahoo, Siemens Healthcare и другие.
При всей разнице специализаций и нюансов реализации Scrum имеет общие ключевые моменты, которых следует придерживаться независимо от того, торгуете ли вы промышленными товарами или производите медицинскую аппаратуру.
- Product Backlog (требования к проекту).
- Sprint Backlog (требования, которые нужно выполнить в ближайший блок времени или этап, условно именуемый «спринт»).
- Sprint Goal (цель «спринта»).
- Sprint Burndown Chart (диаграмма, обновляемая по мере выполнения требований).
Чтобы метод работал, нужно определиться с несколькими ключевыми позициями:
- Владелец продукта (Product Owner) или лицо, принимающее решение – крайне желательно, чтобы заказчика представлял кто-то один, и этот кто-то был уполномочен принимать решения, вносить правки и утверждать результат.
- Команда разработчиков (Delivery Team), лучше до 10 человек, но не больше, чем число Данбара, что дает возможность быстрой координации.
- Скрам-мастер (Scrum Master), который следит за ходом проекта.
- Четкие требования к продукту (Product Backlog), как минимум на стартовом этапе, и приоритеты для каждого требования.
- Отрезок времени (Sprint Backlog) на выполнение каждой задачи или блока родственных задач.
- Ежедневные совещания не дольше 15 минут, где каждый отвечает на три вопроса (что сделано вчера? что планируется сегодня? что мешает выполнению задач?)
- Обзоры готовой рабочей части программного продукта с участием всех заинтересованных сторон.
- Подведение итогов после каждого блока задач.
Scrum – это один из основных Agile-методов, но далеко не единственный.
Kanban
В отличие от Scrum, в Kanban не важны такие нюансы, как Product Owner и Scrum Master. Если Scrum можно условно охарактеризовать как «подход структуры», в Kanban реализуется «подход баланса». Kanban предполагает полную прозрачность процесса и равномерное распределение обязанностей.
Такой подход практически исключает как простои, так и авралы. Вся «линейка процессов» делится не на фазы или циклы, а на стадии выполнения конкретных задач:
Кстати, часто по такому принципу проектируются crm-системы, и там сразу видно, в какой стадии находится та или иная операция: продажа, закупка, согласование проекта и т.д. По такому же принципу строится диаграмма Ганта, которая визуально синхронизирует основные составляющие процесса и стадию, в которой находится каждая из задач:
Автор метода Дэвид Андерсон подробно описал все нюансы своего детища в книге «Канбан. Альтернативный путь в Agile».
eXtreme Programming (XP)
Тут название говорит само за себя. Все процессы, которые обычно занимают несколько дней, а то и недель, становятся экстремально быстрыми и короткими. Так, в eXtreme Programming (XP) практикуется «парное программирование», когда один разработчик пишет код, а второй тут же просматривает написанное на предмет ошибок и неувязок. Тестирование проводится сразу после того, как написан самодостаточный блок кода, и тут же вносятся правки, если что-то не работает.
Более подробно метод описан автором в его книге «Экстремальное программирование. Разработка через тестирование». Мы вкратце изложим основные принципы метода:
- Оформление кода ведется согласно единым для всей команды стандартам.
- Тесты для тестирования кода пишутся до того, как будет написан код.
- Так называемое «слушание» проводится с участием и разработчиков, и клиента, что позволяет «снять» все вопросы и удостовериться, что все друг друга поняли правильно.
- Планирование следующего этапа делается как по окончании предыдущего, так и в ходе реализации текущего, если в этом есть необходимость.
Все эти меры позволяют справиться с меняющимися требованиями к разработке программного продукта и выдать оптимальный для заказчика результат.
DSDM
DSDM расшифровывается как Dynamic Software Development Method (метод разработки динамических систем). Он предполагает предпроектную стадию с планированием целей и ресурсов, собственно проект и постпроектную стадию, обеспечивающую успешное функционирование разработки.
- Максимальное вовлечение заказчика как будущего пользователя.
- Право команды разработчиков самостоятельно принимать максимум решений без дополнительного согласования с руководством.
- Стремиться сделать хорошо и раньше всегда лучше, чем сделать идеально, но поздно.
- Обеспечить максимально быстрое решение критических проблем функционала программы принципиально важно.
- Обратная связь с заказчиком является ключевым фактором для достижения оптимального результата.
- Любые изменения являются обратимыми.
- Базовые требования устанавливаются до старта проекта.
- Тестирование должно быть максимально «вплетено» в процесс разработки.
- Тесное сотрудничество между участниками процесса – залог успеха.
Как видим, тут много общего с прочими методами, о которых мы говорили чуть раньше. Это вполне естественно, потому что все они относятся к Agile. Более подробно о методе можно прочитать в книге, которая так и называется «DSDM: Dynamic Systems Development Method». Невзирая на давность издания, основные постулаты актуальны и сегодня.
FDD
FDD расшифровывается как Feature Driven Development. Интересно, что метод появился раньше, чем Agile-манифест, однако полностью «вписывается» в философию Agile.
- Разработка общей модели, определение круга задач, которые должен решить продукт.
- Составление списка необходимых функций системы на основе круга задач, для решения которых она предназначена.
- Планирование разработки каждой функции.
- Проектирование всех ранее определенных функций.
- Собственно разработка.
Отметим, что в FDD уделяется заметно больше внимания предварительному моделированию системы, нежели в прочих методиках Agile. Что, впрочем, никак не умаляет достоинств и преимуществ прочих методов Agile.
Преимущества Agile
Главное преимущество Agile – это возможность быстро реагировать на изменения, коих в современном мире превеликое множество. Поскольку цифровой мир, так или иначе, является отражением реального мира, здесь изменения тоже происходят постоянно.
Оптимальный вариант применения Agile – это небольшие команды разработчиков, когда сотрудники занимают одно на всех помещение, и компании-заказчики, где решения принимает один человек.
Основные плюсы Agile-разработки:
- Высокий уровень вовлеченности в процесс со стороны всех заинтересованных сторон, что исключает взаимонепонимание и проволочки.
- Быстрые и предсказуемые сроки разработки.
- Возможность сразу исправить то, что не работает или работает не так, как ожидалось.
- Фокусировка на результате и ценности для бизнеса без риска скатиться в «искусство ради искусства».
И конечно, говоря о достоинствах, нужно сказать и о недостатках.
Недостатки Agile
Следует сразу сказать, что, говоря о недостатках, мы сфокусируемся исключительно на недостатках методов, потому что сама по себе философия Agile, предполагающая клиентоориентированность и гибкий подход к решению задач, вряд ли может считаться нерациональной хоть в какой-то части.
А недостаток Agile-методов, пожалуй, всего один: слабая применимость для больших проектов и организаций со сложной иерархией. Проще говоря, если каждый «чих» нужно согласовывать сначала с отделом маркетинга, потом с бренд-менеджером, затем с PR-директором, далее с генеральным директором компании-заказчика, и после этого еще ждать, когда все утвердят на заседании совета директоров, проводимом раз в месяц, ни один из Agile-методов тут не сработает.
Кроме того, реализация Agile-методов требует совместной работы всей команды, постоянного живого общения, а также частого личного присутствия заказчика, поэтому использование Agile-методик в условиях удаленной работы затруднено. Впрочем, руководители IT-компаний и так находят массу аргументов «Почему из офиса работать лучше и эффективнее».
Иногда к недостаткам Agile-разработки относят вероятность никогда не выпустить окончательный вариант программного обеспечения, потому что Agile предполагает постоянную корректировку планов и улучшение результата, что повышает риск избыточного стремления к перфекционизму в ущерб срокам.
Эти опасения в известной степени надуманные. Если изначально четко прописана бизнес-цель, требования к продукту и критерии, на которые нужно ориентироваться при разработке, перфекционизм вряд ли кому-то грозит, и заказчики вполне будут удовлетворены работающим продуктом, «закрывающим» их «боли» и потребности, ради которых затевался проект.
Заметим, что «принцип минимальной готовности» полезен всегда, когда нужно опередить конкурентов и выпустить на рынок продукт, который рынок давно ждет. И как раз философия Agile и все методы Agile на это и нацелены.
Как бы там ни было, достоинства Agile явно перевешивают недостатки. Сфера применения Agile давно вышла за рамки IT-сферы, и теперь «гибкие методы» широко используются для разработки производственного оборудования, промышленных механизмов и даже товаров народного потребления. Так, примером может служить детская коляска Britax B-Agile с бескамерными колесами и складной рамой:
Эта коляска, а также ее модификация B-Agile М, давно полюбилась малышам и их родителям.
В целом, философия Agile для бизнеса – это:
- Фокус на нуждах и целях клиентов.
- Максимально простая структура команды.
- Работа укороченными циклами.
- Постоянная обратная связь с заказчиками.
- Большой объем полномочий полномочия сотрудников.
Как говорится, «будь гибким, или твой бизнес умрет». Мы желаем, чтобы ваш бизнес был бессмертным, непотопляемым и, конечно же, гибким и адаптивным ко всем изменениям.
P.S. Если вам понравился этот список, поделись с друзьями. Пусть они скажут тебе «Спасибо!»