Цифровые технологии все больше проникают в нашу жизнь. И дарят нам не только новые сервисы и новые возможности собственно в Интернете и телекоммуникациях. Для того, чтобы новые сервисы, интернет-магазины, crm-системы, мобильные приложения, мессенджеры и прочие цифровые площадки максимально отвечали запросам пользователей, приходится думать не только над технической частью. И даже не только над методами разработки, а еще и над такими глобальными вещами, как философия.
Так, из IT-сферы к нам пришла философия Agile, основные принципы которой вполне пригодны для многих других областей. Что за философия и где она может быть полезна? Этому и посвящена наша сегодняшняя статья.
А прежде, чем мы перейдем непосредственно к теме, советуем обратить внимание на наши программы «Лучшие техники самообразования» и «ТРИЗ на практике: творческий подход на работе и в жизни». Это как два колеса у «велосипеда знаний», которые позволят вам удержать баланс между теорией и практикой и уверенно двигаться по дороге познания, наслаждаясь как непосредственно процессом получения новой информации, так и достигаемыми целями. «Изобретать велосипед» вам не придется – достаточно лишь изучить то, что изобрели до нас, и на этой базе двигаться вперед.
Что такое Agile: немного истории
Простой механический перевод слова «agile» вряд ли откроет полную картину того, что же это такое. Google-переводчик переводит «agile» как «гибкий», однако при обратном переводе тут же предлагает совсем другое слово «flexible», которое тоже означает «гибкий».
Разница тут, пожалуй, в том, что «flexible» подразумевает гибкость механическую, а термин «agile» гораздо шире и предполагает гибкость мыслительную или, если хотите, ментальную. В зависимости от контекста, «agile» можно понимать как «быстрореагирующий», «подвижный», «проворный», «маневренный».
Если попытаться представить все вышеперечисленное разом, это и будет наиболее адекватное понимание термина «agile». Причем тогда тут философия? Разобраться в этом нам поможет «История создания Agile-манифеста» [Д. Блинов, 2021].
Для начала вкратце, что такое Agile-манифест. Это документ, в котором закреплены основные принципы и ценности, которых следует придерживаться при разработке программного продукта. Далее мы расскажем о манифесте подробнее, а сейчас, как и обещали, акцентируем внимание на истории вопроса.
С развитием IT-технологий разработки становятся все масштабнее, и в этих условиях внятно сформулировать техническое задание (ТЗ) все сложнее. Заказчики зачастую сами не до конца понимают, что им нужно. И даже если бы существовала условная волшебная кнопка «Сделайте все хорошо», многие затруднились бы пояснить, что значит для них «все хорошо» и что именно должна выдать эта чудо-кнопка после нажатия.
Разработчики стали массово сталкиваться с ситуацией, когда доскональное следование пунктам ТЗ никак не гарантирует, что клиент останется доволен. В то же самое время, если клиенту вдруг придет в голову, что он запросил что-то не то, и нужно было бы запросить что-то другое, правки в ТЗ займут определенное время.
А еще они потребуют соблюдения определенных формальностей, потому что разработчики начали страховать себя от возможного недовольства клиентов путем фиксации всех требований в форме договора. К тому же остается неясным, что в этом случае делать с уже завершенным объемом работ и достигнутым результатом, если он «не вписывается» в новую концепцию.
Стало понятно, что «разруливать» сложившуюся ситуацию нужно на уровне общего подхода, а не просто локального оперативного решения проблем, возникающих в ходе конкретного проекта. Ввиду того, что ситуация обрела достаточно серьезный масштаб, и в ее решении было заинтересовано немало практикующих разработчиков, в начале «нулевых» в IT-кругах развернулась горячая дискуссия по данному вопросу.
Итогом стал Agile-манифест, который составили 17 основных инициаторов дискуссии, объединившихся в Agile Alliance. Окончательные детали Agile-манифеста были доработаны в ходе живой встречи на горнолыжном курорте Юта в феврале 2001 года. Итоговый документ был подписан 13 февраля 2001 года. Что он собой представляет? Давайте посмотрим.
Agile-манифест: 12 принципов и 4 ценности
Итак, Agile-манифест фиксирует основные ценности, которых следует придерживаться при разработке программного обеспечения и взаимодействии с заказчиками, и главные принципы, на которые следует опираться в процессе работы [agilemanifesto, 2001]. Какие же ценности проповедует Agile-манифест?
4 ценности Agile:
- Человек важнее, чем процесс и/или инструмент.
- Функционирующий продукт важнее, чем описывающая его документация.
- Сотрудничество важнее, чем согласование условий договора.
- Готовность меняться и менять важнее, чем первоначальное ТЗ.
Как метко замечено авторами манифеста, «при всем понимании важности того, что написано справа, более важным является то, что написано слева» [Agilemanifesto, 2001]. Вкратце это все можно представить так, что человек первичен, а то, что в компьютере, вторично. Поэтому сначала нужно решать вопрос с заказчиком, а потом уже что-то делать на уровне разработки, т.е. «в компьютере». Собственно, именно на это и указывают основные принципы Agile, которые мы представим в кратком изложении.
12 принципов Agile:
- Наивысшим приоритетом является удовлетворение запросов заказчика.
- Изменения допустимы на любой стадии.
- Новые функциональные продукты нужно выпускать по возможности чаще.
- В ходе проекта разработчики и заказчики должны работать сообща.
- Для профессионалов следует создать условия, обеспечить поддержку и доверять их профессионализму.
- Лучший способ коммуникаций – это непосредственное общение.
- Если продукт работает – это и есть основной показатель правильного направления усилий.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный устойчивый ритм.
- Необходимо постоянно уделять внимание качеству и совершенствованию.
- Простота как искусство минимизации излишней работы является важным условием достижения результата.
- Самые лучшие требования, архитектурные и технические решения рождаются в команде, способной к самоорганизации.
- Команде следует постоянно искать способы повышения эффективности.
Таим образом, Agile-манифест утверждает итеративный подход в разработке программного обеспечения, при котором процесс работы идет параллельно с перманентным анализом полученных результатов и корректировкой последующих этапов работы. Каждая фаза проекта представляет собой повторяющуюся последовательность действий PDCA:
- Plan (планирование).
- Do (реализация).
- Check (проверка).
- Act cycle (корректировка при необходимости и последующий цикл действия).
По сути, Agile-разработка – это гибкий подход к решению задач и ориентация на клиента и его запросы как основополагающий фактор. В принципе, так или иначе, по данному пути должны идти все сферы бизнеса, заинтересованные в улучшении сервиса и обслуживания клиентов.
В некотором смысле философия Agile – это и есть философия бизнеса. В такой сугубо прикладной сфере, как бизнес, говорить о философии можно только в сочетании с конкретными методами, посредством которых реализуется Agile-проект.
Agile-методы и управление Agile
На бескрайних просторах Интернета время о времени появляются изыскания на тему «Что такое Agile: методология или философия?» [РБК, 2019]. В качестве примера можно еще привести «Обзор Agile. Что это: методология, метод или философия?» [А. Евдокимов, 2020].
Самым разумным будет разделять Agile как общность гибких методов или подходов и Agile-философию как таковую. Рассмотрим основные методы и подходы, применяемые в Agile-проектах.
Основные методы Agile:
- Scrum.
- Kanban.
- eXtreme Programming (XP).
- DSDM.
- FDD.
Теперь подробнее о каждом методе.
Scrum-метод
Своим названием Scrum обязан популярной в Америке игре – регби. По аналогии с тем, как в этом виде спорта строятся линии обороны и нападения, а успех зависит от слаженной работы команды, так и в бизнесе все или почти все зависит от командной работы.
Впервые данный термин в контексте управления проектами применили японские исследователи Хиротаки Такеучи и Икуджиро Нонаки примерно в 80-х годах 20 столетия. Собственно как метод, Scrum представлен в 1993 году американским программистом Джефом Сазерлендом.
Свой метод он подробно описал в книге «Scrum. Революционный метод управления проектами» [Д. Сазерленд, 2017]. Данный метод взяли на вооружение такие гиганты рынка, как Microsoft, Amazon, Yahoo, Siemens Healthcare и другие.
При всей разнице специализаций и нюансов реализации Scrum имеет общие ключевые моменты, которых следует придерживаться независимо от того, торгуете ли вы промышленными товарами или производите медицинскую аппаратуру.
Основы 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» [Д. Андерсон, 2017].
eXtreme Programming (XP)
Тут название говорит само за себя. Все процессы, которые обычно занимают несколько дней, а то и недель, становятся экстремально быстрыми и короткими. Так, в eXtreme Programming (XP) практикуется «парное программирование», когда один разработчик пишет код, а второй тут же просматривает написанное на предмет ошибок и неувязок. Тестирование проводится сразу после того, как написан самодостаточный блок кода, и тут же вносятся правки, если что-то не работает.
Более подробно метод описан автором в его книге «Экстремальное программирование. Разработка через тестирование» [К. Бек, 2002]. Мы вкратце изложим основные принципы метода:
- Оформление кода ведется согласно единым для всей команды стандартам.
- Тесты для тестирования кода пишутся до того, как будет написан код.
- Так называемое «слушание» проводится с участием и разработчиков, и клиента, что позволяет «снять» все вопросы и удостовериться, что все друг друга поняли правильно.
- Планирование следующего этапа делается как по окончании предыдущего, так и в ходе реализации текущего, если в этом есть необходимость.
Все эти меры позволяют справиться с меняющимися требованиями к разработке программного продукта и выдать оптимальный для заказчика результат.
DSDM
DSDM расшифровывается как Dynamic Software Development Method (метод разработки динамических систем). Он предполагает предпроектную стадию с планированием целей и ресурсов, собственно проект и постпроектную стадию, обеспечивающую успешное функционирование разработки.
9 принципов DSDM:
- Максимальное вовлечение заказчика как будущего пользователя.
- Право команды разработчиков самостоятельно принимать максимум решений без дополнительного согласования с руководством.
- Стремиться сделать хорошо и раньше всегда лучше, чем сделать идеально, но поздно.
- Обеспечить максимально быстрое решение критических проблем функционала программы принципиально важно.
- Обратная связь с заказчиком является ключевым фактором для достижения оптимального результата.
- Любые изменения являются обратимыми.
- Базовые требования устанавливаются до старта проекта.
- Тестирование должно быть максимально «вплетено» в процесс разработки.
- Тесное сотрудничество между участниками процесса – залог успеха.
Как видим, тут много общего с прочими методами, о которых мы говорили чуть раньше. Это вполне естественно, потому что все они относятся к Agile. Более подробно о методе можно прочитать в книге, которая так и называется «DSDM: Dynamic Systems Development Method» [J. Stapleton, 1999]. Невзирая на давность издания, основные постулаты актуальны и сегодня.
FDD
FDD расшифровывается как Feature Driven Development. Интересно, что метод появился раньше, чем Agile-манифест, однако полностью «вписывается» в философию Agile.
Этапы FDD:
- Разработка общей модели, определение круга задач, которые должен решить продукт.
- Составление списка необходимых функций системы на основе круга задач, для решения которых она предназначена.
- Планирование разработки каждой функции.
- Проектирование всех ранее определенных функций.
- Собственно разработка.
Отметим, что в FDD уделяется заметно больше внимания предварительному моделированию системы, нежели в прочих методиках Agile. Что, впрочем, никак не умаляет достоинств и преимуществ прочих методов Agile.
Преимущества Agile
Главное преимущество Agile – это возможность быстро реагировать на изменения, коих в современном мире превеликое множество. Поскольку цифровой мир, так или иначе, является отражением реального мира, здесь изменения тоже происходят постоянно.
Оптимальный вариант применения Agile – это небольшие команды разработчиков, когда сотрудники занимают одно на всех помещение, и компании-заказчики, где решения принимает один человек.
Основные плюсы Agile-разработки:
- Высокий уровень вовлеченности в процесс со стороны всех заинтересованных сторон, что исключает взаимонепонимание и проволочки.
- Быстрые и предсказуемые сроки разработки.
- Возможность сразу исправить то, что не работает или работает не так, как ожидалось.
- Фокусировка на результате и ценности для бизнеса без риска скатиться в «искусство ради искусства».
И конечно, говоря о достоинствах, нужно сказать и о недостатках.
Недостатки Agile
Следует сразу сказать, что, говоря о недостатках, мы сфокусируемся исключительно на недостатках методов, потому что сама по себе философия Agile, предполагающая клиентоориентированность и гибкий подход к решению задач, вряд ли может считаться нерациональной хоть в какой-то части.
А недостаток Agile-методов, пожалуй, всего один: слабая применимость для больших проектов и организаций со сложной иерархией. Проще говоря, если каждый «чих» нужно согласовывать сначала с отделом маркетинга, потом с бренд-менеджером, затем с PR-директором, далее с генеральным директором компании-заказчика, и после этого еще ждать, когда все утвердят на заседании совета директоров, проводимом раз в месяц, ни один из Agile-методов тут не сработает.
Кроме того, реализация Agile-методов требует совместной работы всей команды, постоянного живого общения, а также частого личного присутствия заказчика, поэтому использование Agile-методик в условиях удаленной работы затруднено. Впрочем, руководители IT-компаний и так находят массу аргументов «Почему из офиса работать лучше и эффективнее» [В. Калитка, 2021].
Иногда к недостаткам Agile-разработки относят вероятность никогда не выпустить окончательный вариант программного обеспечения, потому что Agile предполагает постоянную корректировку планов и улучшение результата, что повышает риск избыточного стремления к перфекционизму в ущерб срокам [Я. Борута, 2017].
Эти опасения в известной степени надуманные. Если изначально четко прописана бизнес-цель, требования к продукту и критерии, на которые нужно ориентироваться при разработке, перфекционизм вряд ли кому-то грозит, и заказчики вполне будут удовлетворены работающим продуктом, «закрывающим» их «боли» и потребности, ради которых затевался проект.
Заметим, что «принцип минимальной готовности» полезен всегда, когда нужно опередить конкурентов и выпустить на рынок продукт, который рынок давно ждет. И как раз философия Agile и все методы Agile на это и нацелены.
Как бы там ни было, достоинства Agile явно перевешивают недостатки. Сфера применения Agile давно вышла за рамки IT-сферы, и теперь «гибкие методы» широко используются для разработки производственного оборудования, промышленных механизмов и даже товаров народного потребления. Так, примером может служить детская коляска Britax B-Agile с бескамерными колесами и складной рамой:
Эта коляска, а также ее модификация B-Agile М, давно полюбилась малышам и их родителям.
В целом, философия Agile для бизнеса – это:
- Фокус на нуждах и целях клиентов.
- Максимально простая структура команды.
- Работа укороченными циклами.
- Постоянная обратная связь с заказчиками.
- Большой объем полномочий полномочия сотрудников.
Как говорится, «будь гибким, или твой бизнес умрет» [atlanty, 2021]. Мы желаем, чтобы ваш бизнес был бессмертным, непотопляемым и, конечно же, гибким и адаптивным ко всем изменениям. Мы приглашаем вас на наши программы «Лучшие техники самообразования» и «ТРИЗ на практике: творческий подход на работе и в жизни». А еще предлагаем подумать и ответить на вопрос по теме статьи:
