В чем суть Agile с точки зрения здравого смысла и пользы для бизнеса? Давайте без применения специальных терминов разберёмся, что такое Agile, зачем он нужен, из чего состоит и какими инструментами добивается ключевых целей.
Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?
Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:
- Able to move quickly and easily.
- Able to think and understand quickly.
То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.
Я не случайно беру выражение «методология Agile» в кавычки, потому что его можно часто услышать, но оно не совсем верное. Если не вдаваться в технические детали, то Agile — это не методология, а собирательное название различных методик и подходов к управлению, которые:
- Фокусируют команду на нуждах и целях клиентов.
- Упрощают оргструктуру и процессы.
- Предлагают работу короткими циклами.
- Активно используют обратную связь.
- Предполагают повышение полномочий сотрудников.
- Имеют в своей основе гуманистический подход.
- Не являются конечным состоянием, а, скорее, образом мышления и жизни.
Ничего сверхъестественного, не так ли? Давайте пройдемся по пунктам и разберемся, почему вышеперечисленное важно, для того чтобы быть быстрыми и гибкими, и какими средствами в Agile достигаются эти цели.
Фокусировка на нуждах и целях клиентов
Думаю, не стоит объяснять, почему успешнее тот бизнес, который удовлетворяет нужды своего клиента лучше конкурентов. Интереснее разобраться, какие инструменты в Agile помогают этого добиться.
Самое главное, что фокусировка на клиенте при Agile-подходе появляется не в одной только голове владельца бизнеса (она там и так уже есть), а у всех, кто работает над созданием продукта или сервиса. Каждый участник процесса должен понимать, кто клиент, чего он хочет, какие его проблемы мы решаем своим продуктом, что он любит, чего боится и так далее. Такая всеобщая фокусировка позволяет создавать на порядок более качественные решения. Я неоднократно сталкивался с ситуацией, когда люди, раньше отвечавшие за какой-то маленький кусочек работы, поняв цели клиента, начинали выдавать замечательные идеи, а люди, которые отвечают за разработку продукта, с удивлением за ними записывали. Или — как на групповых сессиях проработки продукта подобные идеи оттачиваются разными людьми и дополняют друг друга, из просто хороших превращаясь в отличные. И, конечно, как они потом реализуются.
«Инструменты работы» в данном случае — это непродолжительные по времени, но насыщенные сессии (встречи) всех участников работы или ключевого большинства, где происходит генерация и тестирование различных идей. Эти же встречи служат для выравнивания понимания и фокусировки: все участники встречи на выходе понимают, что они делают, зачем, и почему это важно для клиента. А демократичный формат воркшопа, в отличие от скучных презентаций, гарантирует большее включение и мотивацию всех участников.
Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие принятые в Agile методы описания гипотез и процессов.
Упрощение оргструктуры и процессов
Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды размером до 9 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 будет планирование ближайшей итерации, а в пятницу в 17-30 — встреча по улучшению процесса работы.
И чем больше организация, тем больше пользы от подобной простоты, потому что сложность имеет привычку расти экспоненциально, а Agile — это хороший способ победить эту сложность или, как минимум, сдерживать ее рост.
Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.
Работа короткими циклами
В мире Agile не принято запираться в мастерской на три года, чтобы точить там что-то интересное. Очень уж велик риск, потратить море сил и времени на то, что никому не нужно или устарело.
Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:
- работа ведётся небольшими фиксированными отрезками времени, например, в одну, две или четыре недели,
- и, главное, в конце каждого отрезка времени создаётся не просто какой-то промежуточный результат, а, пусть маленький, урезанный, куцый, но работоспособный вариант продукта, которым уже можно начать пользоваться.
В качестве самого простого примера такой рабочей модели можно представить себе стандартную для всех компьютеров программу «калькулятор», которая вначале позволяет только складывать два числа, потом мы добавляем туда вычитание, умножение, деление, трансцендентные числа, тригонометрические функции, — и так далее, в порядке частоты применения. В начале функционал невелик, но мы уже можем увидеть, как калькулятор выглядит, насколько удобно им пользоваться, и представить, как развивать его дальше. И, главное, часть клиентов (скажем, школьники начальных классов) уже могут начать им пользоваться.
Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.
Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.
Активное, системное использование обратной связи
Этот пункт, на мой взгляд, самый важный для любого процесса, так как позволяет со временем, опираясь на опыт, корректировать свою работу, удаляя из процесса и создаваемого продукта ошибки и потери и добавляя что-то полезное.
В любой области деятельности человечества, связанной с созданием чего-то нового, вы найдёте подобную работу через эксперимент. Ракетостроение, самолетостроение, фармацевтика, физика, медицина, строительство, психология, экономика — любая область деятельности начиналась с экспериментов и вдумчивой обработки обратной связи от них.
Agile предлагает системное использование такого подхода везде: в создании продукта (мы выпускаем его на рынок, или показываем заказчику, или проводим испытания и используем обратную связь для его коррекции), в построении процессов (периодически мы «останавливаем» работу и подвергаем анализу сам процесс, чтобы улучшить его, избавиться от потерь и проблем), даже в построении структуры организации и «тонкой» настройки взаимоотношений в командах.
Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.
Повышение полномочий сотрудников
Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.
Во-первых, люди, занятые умственным трудом, не любят чувствовать себя мартышками (ну, или роботами), и отбирая у человека возможность принимать решения, мы отбираем у него сам по себе умственный труд. А это, безусловно, демотивирует.
Во-вторых, давая больше полномочий, мы даем больше ответственности, и люди вынуждены учиться принимать решения самостоятельно и, главное, нести за них ответственность. Это долго, сложно, но оно того стоит. Работа не остановится, если самоорганизованная команда столкнется с незнакомой, неизвестной ранее проблемой. Да и кто будет спорить, что на работе от зрелых и ответственных, взрослых людей больше пользы, чем от больших детей, неспособных думать самостоятельно?
В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.
Популярные способы построения работы в Agile, особенно базирующиеся на фреймворке Scrum, предполагают систему самоорганизованных команд и поощряют лидерство на любых уровнях.
Гуманистический подход
Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?
Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.
И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.
Вывод такой: счастливые люди лучше работают, а Agile-технологии помогают наладить процесс, в котором люди чувствуют себя счастливее. И первый пункт манифеста как раз об этом: люди и то, как они общаются, важнее всего остального.
Agile — это не конечное состояние, а образ мышления и жизни
Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.
И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile, работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, а работа будет приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.
На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом ежегодного исследования ScrumTrek об использовании Agile в России.
В 2021 году исполнилось 20 лет «Манифесту Agile». Подход зародился как бунт разработчиков против неповоротливых ИТ-корпораций. Разбираемся, что происходит с Agile сейчас и как его применяют в российских компаниях
1
Что такое Agile
Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.
Термин Agile употребляют в двух основных значениях:
- Система ценностей или философия, которой придерживаются многие разработчики и стартапы.
- Собирательное название для гибких подходов и методик, которые, так или иначе, пересекаются с основными ценностями Agile.
Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.
Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.
2
«Манифест Agile» и основные принципы
Agile-манифест базируется на четырех главных ценностях:
1. Люди и их взаимодействие важнее процессов и инструментов.
Нужно создать такие условия, чтобы инструменты и процессы не ограничивали команду, а позволяли ей работать как можно эффективнее. Каждый может сам решать, какие инструменты и процессы ему подходят.
В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.
2. Работающий продукт важнее документации и отчетности.
Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации. Поэтому в рамках Agile фокусируются на том, чтобы продукт как можно быстрее был готов к использованию, пренебрегая технической документацией и отчетностью.
3. Сотрудничество с заказчиком важнее соблюдения формальных условий.
Даже если перед проектом подписан договор с жесткими условиями и характеристиками, в процессе работы они могут меняться. Например, если некоторые детали окажутся не такими значимыми, и задачу можно решить гораздо проще и эффективнее. Это делается в интересах клиента, которому важен рабочий продукт, а не формальные требования. При этом важно постоянно быть на связи и обсуждать каждое изменение, принимая решение совместно.
4. Готовность к изменениям важнее, чем следование плану.
Изменения можно и нужно вносить на каждой стадии — или итерации, — чтобы не откладывать их на конец, когда сроки и ресурсы уже поджимают. Ради этого вполне можно пожертвовать чем-то из запланированного, если основные задачи будут решены.
Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:
- Главная цель — удовлетворение потребностей заказчика. Все процессы и задачи меняются и подстраиваются под них.
- Разработчики и представители заказчика должны работать вместе ежедневно, обмениваясь идеями и полезной информацией.
- Каждый участник команды должен быть хорошо замотивирован: комфортными условиями, позитивными откликами, финансовыми поощрениями.
- Изменения допустимы на любом этапе, даже перед самым выпуском. При этом за каждую итерацию (от двух недель до двух месяцев) вы должны выпускать рабочий продукт.
- Все должны стремиться к максимальной простоте и самоорганизации.
Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.
3
Что такое Scrum и Kanban
Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.
Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.
В отличие от scrum, kanban:
- не предполагает следование agile-ценностям на 100% и фокуса на самоорганизации, но придерживается принципов клиентоориентированности, сотрудничества и прозрачности;
- применяется не только при разработке, но и при модернизации, поддержке и операционной деятельности;
- внедряется поэтапно и без существенных изменений в текущих процессах и инфраструктуре;
- подразумевает равномерное улучшение, а не только ускорение процессов;
- использует метрики, которые не подразумевают оценку трудоемкости задач.
В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Пример доски Trello, созданной по принципам agile.
Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.
4
В каких компаниях используют Agile
Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.
Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.
5
Существует ли Agile в России
В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.
ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:
- География: 41% Agile-команд, участвующих в исследовании, находятся в Москве, 14% — в Санкт-Петербурге, 6,4% — в Перми, 5,5% — в Казани и Иннополисе (ИТ-кластер), 5,4% — в Новосибирске.
- Отрасли: ИТ — 42% участников, финансы — 18%, промышленность — 8%, ритейл — 7%, телеком — 4,8%, энергетика — 3,2%, консалтинг — 2,8%.
- 33% применяют гибкие подходы во внутренних проектах и услугах для клиентов.
- 41% используют scrum (на 7% меньше, чем год назад и на 9% — по сравнению с 2018 годом), 23% — kanban (на 8% больше, чем в 2019 году и на 13% — по сравнению с 2018-м): то есть, kanban постепенно догоняет scrum по популярности. При этом в мире доля kanban в три раза ниже, чем в России: за год она выросла с 5% до 7%; доля scrum при этом выросла с 54 до 58%.
- 60% компаний применяют несколько подходов одновременно. Доля собственных или комбинированных agile-методик в компаниях составляет 30%.
- 22% компаний оценили свой уровень компетенции в Agile как высокий — это на 9% больше, чем годом ранее. Если год-два назад многие только планировали применять гибкие методики, то сейчас уверенно внедряют их, комбинируя разные методы и даже изобретая свои. Однако три года — период, в который проводятся исследования — все еще слишком малый срок, чтобы говорить о зрелости в плане agile-подходов.
6
Нужен ли вашей команде Agile
Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:
- есть небольшие команды, создающие или улучшающие конкретный продукт (сервис) в условиях неопределенности;
- нужно выпустить первую версию продукта как можно быстрее, чтобы обогнать конкурентов;
- разрабатывают инновационный продукт, не имеющий аналогов, с непредсказуемыми свойствами.
Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.
Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.
Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.
7
Книги про Agile
- «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban». Авторы: Роб Коул, Эдвард Скотчер. Для тех, кто только планирует перейти от классического проектного менеджмента к гибкому.
- «Эпоха Agile. Как умные компании меняются и достигают результатов». Автор: Стивен Деннинг. Описывает работу гибких методов управления на разных уровнях, как правильно ставить цели и как их достигать.
- «Scrum. Революционный метод управления проектами». Автор: Джефф Сазерленд, основатель фреймворка scrum. Необходима скрам-мастерам и тем, кто хочет применять этот метод и понять, в чем его польза и преимущества.
- «Scrum и Kanban: выжимаем максимум». Авторы: Хенрик Книберг, Маттиас Скарин. Сравнение двух методов с практическими примерами, плюсами и минусами.
- «Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте». Сборник статей от специалистов Toyota, посвященных внедрению kanban в компании, синтезе американского и японского подходов и как это повлияло на внутренние процессы.
- «Agile: Оценка и планирование проектов». Автор — Майк Кон. Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. Майк Кон, гуру в области Agile, дает инструменты, необходимые для оценки, планирования и управления agile-проектами любого масштаба.
По данным исследования компании Digital.ai, в 2021 году 86% команд разработчиков программного обеспечения используют Agile-методики. Также, по данным ежегодного отчёта Scrumtrek, 33% финансовых компаний активно пробуют приёмы Аджайл-технологии. В этой статье мы расскажем, что же это такое и почему популярно.
Что такое Аджайл простыми словами
Agile часто называют методологией планирования рабочих процессов. Это неверно. Понятие «методологии» подразумевает некую совокупность приёмов. Agile не даёт никаких точных алгоритмов действий. Agile ― это философия гибкого подхода к созданию продукта. Основная идея подхода в постоянном совершенствовании продукта и активном получении фидбека от заказчиков и клиентов. Поговорим об этой философии подробнее.
Как появился Agile и какие ценности он продвигает
Agile родился в головах IT-специалистов. К 2000-м годам программирование начало активно развиваться. Система создания ПО обросла огромной документацией и длинным путём к созданию готового продукта. Стало ясно, что в индустрии нужно что-то менять. Нужны качественно новые практики организации рабочих процессов. С конца 90-х годов программисты со всего мира делились своими идеями. Уже в то время родилась теория экстремального программирования, о которой мы ещё поговорим подробнее. Но знаковой оказалась встреча в 2001 году, которая и положила начало новой философии.
11-13 февраля 2001 года группа программистов в очередной раз решила собраться для обсуждения проблем. Местом встречи они выбрали горнолыжный курорт Snowbird в горах Уосатч в штате Юта. Они собрались не только покататься на лыжах, отдохнуть, но и общими усилиями найти решения проблем в организации процесса разработки ПО. Из 20 приглашённых приехало 17 специалистов. В результате этой встречи родились не просто идеи нового подхода к программированию, а целый манифест. Тогда же участники и назвали его Agile.
Agile-манифест
Философия Agile, отражённая в манифесте, состоит из 4-х ценностей и 12-ти принципов.
Ценности:
- Взаимодействие с людьми важнее рабочих процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее, чем согласование контракта.
- Быстрая реакция на изменения важнее первоначального плана.
Создатели манифеста не говорят о том, что нужно отказаться от контрактов и документации. Речь о том, что эти вопросы должны отойти на второй план. Главное ― продукт, его полезность и актуальность.
Принципы:
- В приоритете удовлетворение потребностей клиента за счёт поставки ценного ПО.
- Требования всегда можно изменить, даже если продукт находится на последней стадии разработки.
- Готовый продукт нужно постоянно обновлять.
- На протяжении всего проекта разработчики и представители бизнеса должны работать вместе.
- Чтобы работа была сделана качественно, сотрудники должны находиться в приятной атмосфере и мотивированы на работу.
- Только личное общение способствует эффективной коммуникации.
- Показателем прогресса является готовое ПО.
- Инвесторы, разработчики и пользователи должны быть в постоянном рабочем ритме. То есть процесс разработки должен иметь устойчивый цикл.
- Разработчики должны уделять особое внимание совершенствованию проектирования. Это повышает гибкость проекта.
- Простота рабочих процессов является основой. Никакой лишней работы.
- Лучшие решения рождаются у самоорганизующихся команд.
- Чтобы работа была эффективнее, нужно постоянно анализировать работу и её корректировать.
Итак, программисты призывали упрощать процесс работы, создавать комфортные условия для сотрудников, постоянно обновлять продукт, опираясь на мнение пользователей и заказчиков, анализировать рабочие процессы и модернизировать их. Возможно, для современных компаний многие из этих принципов кажутся сами собой разумеющимися, но для того времени это был новый подход.
Принцип Agile и его методики
Итак, для чего нужен Agile? В рамках философии Agile появились конкретные методики, которые должны были помочь компаниям улучшить свои рабочие процессы. В список методик для управления продуктами вошли:
- Экстремальное программирование (XP).
- Kanban.
- Scrum.
- Бережливое производство (Lean).
Теперь по порядку рассмотрим каждую из этих методик.
Экстремальное программирование, или Extreme Programming
Эта методика появилась раньше манифеста Agile (1990-х годах), но отлично вписалась в концепцию. XP предназначена только для разработки ПО. Оно не может быть использовано в другом бизнесе или бытовых задачах. Главная цель методики ― сделать рабочий продукт быстро. В начале планирования итерации решается вопрос, какой функционал должно приобрести ПО в итоге. На этом планировании обязательно присутствует заказчик. Именно он должен согласовать цель итерации.
Внутри этой методологии есть 12 практик, которые позволяют ускорить программирование. Для примера в XP рекомендуют использовать парное программирование, рефакторинг (оптимизация кода), коллективное владение кодом.
Kanban
Kanban ― это подход к визуализации рабочего процесса. В рамках Kanban создаётся рабочая доска, на которой отражены все задачи команды. Доска разделена на этапы работы. Задачи перемещают между этими этапами. Благодаря такой визуализации каждый член команды и руководитель всегда видят, как продвигается работа. В нужный момент любой может присоединиться и помочь. После выпуска продукта можно подробно рассмотреть все этапы работы и выявить недочёты.
Scrum
Весь рабочий процесс состоит из коротких итераций ― спринтов. Спринты обычно длятся 1-4 недели. В начале каждого спринта проходит планирование задач. Команды должны быть маленькие не более 10 человек. В команду входят:
- Product Owner (владелец продукта). Общается с заказчиками и потребителями, планирует задачи.
- Scrum Master. Анализирует выполненные задачи и ищет способы улучшить процесс работы. Также проводит собрания и решает проблемы в команде.
- Development Team (команда специалистов). Это вся остальная команда, которая выполняет задачи по созданию продукта. Состоит из специалистов различного профиля.
Для Scrum характерны некоторые специфические правила и мероприятия.
- Backlog. По сути, это список задач, которые ранжируются по приоритету. Все запланированные задачи команда должна успеть выполнить до конца спринта.
- Sprint Planning Meeting (планирование спринта). Это собрание, которое проходит в начале спринта. На нём команда просматривает задачи и анализирует, сколько она успеет сделать за итерацию, какие задачи стоит разбить на ещё более мелкие.
-
Daily Scrum meeting (ежедневное собрание). Ежедневное собрание на 15 минут, где каждый член команды отвечает на 3 вопроса:
- Что я сделал вчера?
- Что я планирую сделать сегодня?
- Что мне мешает?
- Retrospective meeting (ретроспектива). Проводится в конце спринта. На нём обсуждаются результаты выполненных задач, а также каждый член команды делится своим мнением об итерации. На основе высказанного вносятся правки в дальнейшие спринты.
В общем, Scrum продвигает идею небольших забегов. Цель каждого забега ― создать продукт или модернизировать его.
Бережливое производство, или Lean
Эта практика старше всех. Считается, что её внедрили на заводе Toyota ещё в 1950-х годах. Эта концепция направлена на внимательное отношение к ресурсам, которые тратятся на производство товара. В рамках этой методики советуют не перепроизводить товар, уменьшать путь для транспортировки, оптимизировать работу каждого сотрудника.
Все методы семейства Agile направлены на ускорение, упрощение работы и налаживание взаимодействия со всеми участниками производства. Некоторые из этих методик хорошо уживаются вместе. Можно брать самое подходящее для своей организации. Например, всё чаще вместе используют Kanban и Scrum. Такой тандем в шутку называют Scrumban.
Положительные и отрицательные стороны
Гибкий подход к разработке рабочего процесса приводит к некоторым очевидным преимуществам:
- Продукты быстрее выходят на рынок. За счёт того, что на рынок выпускается более или менее готовый продукт и только потом дорабатывается, прибыль приходит раньше.
- Высокое качество продукта. Из-за постоянно доработки по итогу качество продукта намного выше, чем когда версия продукта выпускается единожды.
- Прозрачность работы. Так как и сотрудники, и заказчики, и пользователи постоянно взаимодействуют, весь процесс создания продукта становится прозрачным.
- Увеличение прибыли. Так как продукт постоянно совершенствуется, в дальнейшем есть возможность легитимно повышать цену.
Несмотря на продвинутость и всеобщее признание подхода, у Agile есть и недостатки:
- Мало предсказуемости. В самом начале проекта трудно понять, сколько времени и ресурсов вы в итоге потратите на разработку продукта. Если команда только переходит к гибкому подходу, это может посеять страх среди сотрудников. Не все готовы оперативно исправлять ошибки и внедрять идеи в продукт.
- Много коммуникации. Не все готовы на постоянное и тесное сотрудничество. Чтобы разработчики быстро могли приступить к обновлениям и доработкам, заказчик должен быть доступен 24/7, ревьюить идеи и работу на каждом этапе. Это занимает много времени, и далеко не каждый к этому готов.
- Есть риск переделывания работы. В любой момент заказчик или пользователь может в корне изменить свои желания и по правилам Agile нужно будет всё переделывать.
- Снижение качества продукта для ускорения выпуска. Пытаясь успеть как можно раньше выпустить продукт, разработчики часто выводят в свет откровенно сырой продукт, который потом собирает негатив от пользователей.
Каким компаниям подходит Agile-подход
Несмотря на то что изначально Agile-система была придумана программистами для программистов, философия подходит абсолютно для любых организаций. Даже среди советов XP есть практики, которые в теории могут применятся и в других профессиях.
Для небольших проектов, например, создание рекламного баннера, скорее всего, внедрение сложных технологий не потребуется. Есть ТЗ и понятные этапы работы. Разве что можно создать доску, если проектов несколько. Такой подход добавит наглядности. Однако необходимости внедрения методологий Agile нет.
Однако есть проекты, которым обязательно нужен помощник в организации работы:
- Проект обещает быть крупным и сложным. В этой ситуации вам нужно будет декомпозировать задачи и пытаться не потеряться в проекте.
- Работа будет долгой. В процессе реализации долгого проекта может понадобиться много изменений. Только гибкий подход к процессам разработки поможет выпустить актуальный для пользователей продукт.
- В проекте много неопределённости. Разработчики и производители гонятся за новизной. А там, где новизна, есть и неопределённость. Вы просто не сможете прописать путь создания продукта от начала и до конца. В этом случае лучше продвигаться маленькими шагами. Так вы точно сделаете меньше ошибок.
Этапы внедрения Agile
- Выберите метод. Подробно изучите каждый метод и определите, какой поможет именно вашей команде.
- Расскажите всей команде об Agile. Каждый сотрудник должен знать, в чём заключается суть концепции. Проведите обучение всей команды. Если есть возможность, пригласите сторонних специалистов, у которых есть опыт по внедрению Аджаил.
- Организуйте процесс. Даже если все сотрудники будут разбираться в Agile-философии, всё равно нужен человек, который возьмёт на себя ответственность организовать процесс. Скорее всего, вам понадобится создать рабочие доски. Это может делать Scrum-мастер или руководитель отдела.
- После первых нескольких итераций проанализируйте эффективность налаженной системы. У вас вряд ли с первого раза получится создать идеальную систему. Первое время придётся постоянно перестраивать процессы.
Гибкие методологии для организации работы ― необходимость для многих компаний. Товары нужно производить быстрее и удешевлять их производство. Учитывая быструю смену повестки дня, реагировать нужно также быстро. Такие особенности бизнеса требуют новых подходов, каковым и является Agile.
Весь мир трясет и переворачивает с ног на голову. Привычная схема работы может в один миг стать убыточной. Компаниям приходится подстраиваться и перекраивать все бизнес-процессы прямо на ходу. Адаптация и трансформация процессов и продуктов проходит легче у тех, кто руководствуется принципами Agile.
Давайте разберемся, что такое методика Agile, кому она поможет в непростое время и как её использовать на примере маркетинга.
Что такое Agile?
Agile (Аджайл) – это подход к управлению процессами, основанный на принципах гибкости и оперативной реакции на изменения среды и запросов аудитории. Изначально принципы сформировались для разработки IT-продуктов, но постепенно стали применяться и в других областях бизнеса.
Немного истории
Понятие Agile как свод принципов появилось в 2001 году в США, штат Юта. Команда разработчиков занималась развитием и внедрением разных методик для роста эффективности работы, например, Каскадной модели и Экстремального программирования. Эти программисты объединили правила реакции на изменения условий и выработали манифест Agile, а затем создали некоммерческую организацию Agile Alliance, цель которой – продвигать и внедрять «гибкие» технологии управления процессами.
Разработчики и инженеры, которые были у истоков методологии Agile
Манифест Agile: 4 основных принципа
Метод управления процессами Agile базируется на четырех ключевых суждениях, которые помогают компаниям стать гибкими:
-
Люди и их взаимодействие важнее, чем рабочие процессы и инструменты.
-
Функционирующий продукт важнее, чем регламенты, написание инструкций, задания.
-
Сотрудничество с заказчиком важнее, чем просто подписание договора.
-
Адаптивность и оперативная реакция важнее, чем слепое следование плану.
Раскроем каждый принцип подробнее.
Принцип 1. Коммуникация важнее инструментов и процессов
Весь бизнес – это не просто набор механизмов и процессов. Любой бизнес состоит в первую очередь из людей. Люди работают с людьми и делают продукт для людей. И их отношения важнее любых регламентов.
На практике внутри компании это выражается в том, что любой сотрудник может обратиться к коллеге за помощью или мнением, несмотря на должности и иерархию.
На отношениях вовне этот принцип реализуется через ориентированность на человека в создании продукта: в центре всех процессов стоят потребности аудитории.
Принцип 2. Работающий продукт важнее документации
Этот принцип говорит, что результат важнее пути к нему. Неважно, каким образом вы решили проблему или задачу, главное, что она решена. Например, в маркетинге вы можете проигнорировать контент-план или перекроить рекламную стратегию под влиянием изменений среды.
Принцип 3. Диалог с заказчиком важнее договоров
Работа над проектом всегда имеет конкретную цель. Но внешние обстоятельства преобразуются, меняются условия, возникают форс-мажоры. Как следствие, поведение потребителя или запрос целевой аудитории тоже может измениться. Заранее этого не предусмотреть. Чтобы окупить потраченные время и ресурсы, вы должны оперативно реагировать на изменения. Плотно работая с заказчиком, вы можете быстро перестроить движение к цели с учетом новых вводных.
Принцип 4. Изменения и адаптация важнее следования плану
Принцип неразрывно связан с третьим постулатом. Гибкость и умение адаптироваться – естественный ответ на изменения условий.
Agile – это постоянное исследование клиента, рынка, конкурентов. Для этого вам нужна отработанная схема непрерывной обратной связи: так вы сможете отслеживать изменения на всех уровнях и вовремя корректировать действия команды. Это не значит, что нужно отказаться от стратегического планирования, но вы должны быть готовы скорректировать планы исходя из ситуации здесь и сейчас.
Диана Тананова, руководитель отдела маркетинга, Веб-Центр
Чем полезна методика Agile для компаний
Отделы или целые компании внедряют принципы Эджайл, чтобы быстро реагировать на изменения внешней и внутренней сред. Строгое следование плану (особенно на длинных временных отрезках) сковывает инициативу сотрудников на местах, которые погружены в текущие дела глубже, чем руководство. А ведь они могли бы предложить более эффективные решения, так как находятся «ближе к земле». Agile позволяет команде адекватно реагировать на трансформацию условий, учитывать в планировании переменные и достигать целей, не смотря на неожиданности и кризисы.
Руководителям часто сложно дать такую свободу своим подчиненным. Но этот шаг полностью компенсируется, если соблюдаются все принципы Agile:
-
люди работают для людей, а значит и линейные сотрудники будут нацелены на конечный результат;
-
постоянная обратная связь поможет руководителю или заказчику вовремя вмешаться и перенаправить работу команды;
-
если члены команды могут обратиться за советом к старшему и более опытному товарищу, то количество неверных решений и затраты времени на исправление ошибок сокращается.
Agile на практике
✔ Цикл работы
Вся работа над проектом – это цикл, который состоит из повторяющихся отрезков – спринтов: планирование, разработка, тестирование или проверка, демонстрация. Чтобы применять принципы Agile, спринты должны быть короткими по времени – от одной недели до месяца. Цикл повторяется, пока команда не достигнет нужного результата, чтобы впоследствии его внедрить.
Цикл работы по Agile
Руководитель команды или заказчик должен иметь соответствующую квалификацию и постоянно быть внутри процессов. Так он будет связующим звеном между другими членами команды и сможет принимать решения о перестройке процессов при необходимости. Руководитель регулярно собирает планерки с командой, чтобы получить обратную связь от сотрудников и оперативно управлять процессом.
✔ Спринты
В начале работы над проектами составляется перечень требований заказчика, а к ним – список рабочих задач. Такой список называют бэклог. Расположите в нем задачи в порядке убывания их важности, чтобы составить дорожную карту к цели. По приоритетности задач в бэклоге команда поймет, какие из них стоит выполнять в первую очередь.
По бэклогу выбирается длительность спринтов и составляется их план. Длина всех спринтов должна быть одинаковой. Чтобы контролировать ход проекта, команда систематически собирается на планерки, обсуждает проект и анализирует возможности улучшения хода работы или продукта.
По итогам руководитель или заказчик изучает результаты спринта и, при необходимости, вносит корректировки в план.
✔ Минимально жизнеспособный, или МЖП
Суть Agile – сделать ровно столько, сколько необходимо для человека. Не нужно пытаться сразу спроектировать и сделать сложный продукт. Выберите конкретную проблему аудитории, которую хотите решить, и работайте с ней. Выпускайте на рынок минимально жизнеспособный продукт – такой, который закрывает потребность ЦА и больше ничего. В процессе работы с каждым спринтом вы сможете его улучшать и дополнять. Вы выпустите на рынок работающий продукт и сможете проанализировать его эффективность в бою, а значит понять, какие нужны доработки в первую очередь, чем можно пренебречь, а что и вовсе убрать.
5 признаков, что внедрение Agile прошло успешно
-
Сократилось количество документации.
-
Информация о проектах внутри команды, между отделами и между исполнителями и заказчиком стала курсировать быстрее.
-
Увеличился темп работы команды.
-
Решения стали чаще появляться не на уровне руководства, а на уровне команд.
-
Работающий продукт или его обновления стали внедряться чаще.
❌ Кому противопоказана гибкая система Agile
Вы можете применять принципы манифеста Agile или просто руководствоваться его философией, если:
- У вас проект, который быстро трансформируется по ходу работы, стартовые условия не четко определены, а объем работы может изменяться.
- Вы работаете в быстро меняющейся нише: телемедицина, Edtech, IT, маркетинг, туризм, онлайн-торговля, логистика, кадровые агентства, консалтинговые услуги.
С той скоростью, с какой сегодня меняется мир, нужно меняться и бизнесу. Трансформируются почти все ниши и их игроки, даже неповоротливые корпорации-гиганты. Если бы я составлял актуальный список изменчивых ниш, там был бы один только пункт: все ниши.
Игорь Баннюк, руководитель отдела продаж, Веб-Центр
- Вы постоянно внедряете инновации в процессы и продукты.
- Вы тесно сотрудничаете с заказчиком на протяжении всё работы.
Вам точно не подойдет и даже будет вреден гибкий подход, если:
-
Вам нужно выдавать один и тот же стабильный результат.
-
В базовых процессах компании заложены неизменно повторяющиеся процессы.
- Ваша команда не понимает сути принципов Agile и не может принимать решения, исходя из ее философии.
- Руководитель не может дать инициативу сотрудникам и не готов глубоко погружаться в проект.
- Сотрудники не могут общаться друг с другом на ежедневной основе. Постоянный обмен информацией – это один из Атлантов Agile.
- Ваши процессы сопровождаются большим объемом документов. Agile подразумевает сокращение отчетности и сопроводительной документации.
Как применять Agile в маркетинге
-
Все, что помогает компании расти и привлекать новые деньги – оправдано и должно быть задействовано. В то же время не забывайте: люди работают для людей, остальное вторично. При разработке стратегии продвижения у вас должны быть ответы на эти вопросы:
• Какие проблемы клиентов мы решаем своим продуктом?
• Как нам стать незаменимыми?
• Почему мы лучше конкурентов?
-
Лучше провести много маленьких экспериментов, чем один большой. Тестируйте гипотезы чаще.
-
Корректируйте стратегию, исходя из данных, а не мнений. Чтобы получать данные, настраивайте каналы обратной связи от вашей команды.
-
Выстраивайте сотрудничество с клиентом, а не стройте жесткую иерархию.
-
Запускайте адаптивные кампании вместо больших и сложных.
-
Изучайте клиентов: отзывы и реакции – основа для изменений.
Все изменения – это проверка бизнеса на прочность и гибкость. Без корректировок смогут выстоять огромные, мощные компании, которые компенсируют неповоротливость системы гигантскими бюджетами. Если это не ваш вариант, становитесь быстрыми, гибкими, адаптивными, чуткими ко всем изменениям. В этом помогут принципы Agile.
Если вы хотите выстроить маркетинг, который быстро реагирует на изменения вокруг вашей компании, напишите нам. Мы работаем уже 18 лет, пережили не один кризис и помогли его преодолеть нашим клиентам. Запросите аудит сайта, контекстной рекламы или соцсетей: мы покажем начальные точки роста и вместе с вами выберем направление развития вашей компании.
Давно слышите о том, что Agile — это классная и удобная методология для разработчиков софта, но вас пугают внушительные и подробные мануалы? В этой статье мы коротко и просто объясним, в чём суть этого подхода.
Agile — итеративный подход при работе над проектом. Знать об Эджайле полезно тем, кто уже работает в IT, и тем, кто только планирует стать айтишником. Ваша команда выпускает проект маленькими шагами с самого начала, а не показывает уже готовый продукт в самом конце.
Википедия описывает гибкую методологию разработки так:
“Серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля”.
TL;DR — чтобы подстраиваться под постоянно меняющиеся требования.
Agile как подход признаёт, что у людей не очень с планированием и оцениванием. И в этом нет ничего плохого. Не имеет значения, насколько вы опытны, всё равно всегда остаётся что-то, что вы не могли предусмотреть или упустили из внимания.
Более традиционные подходы вроде Waterfall (каскадная модель) диктуют тотальное планирование, когда вы ничего не можете сделать, если этого нет в плане.
В любом проекте, будь то программное обеспечение, маркетинговая кампания или рекрутинговая стратегия, появятся дополнительные возможности или поменяются требования. Особенно в случае с крупными проектами. Поэтому новые факторы приходится либо игнорировать (обычно неидеально), либо ужимать план, погружая работу в хаос. Так зачем тогда вообще планировать, правда?
А вот и нет! Предусмотрите всю неизвестность заранее, встроив её в рабочий процесс. Некоторые лучшие идеи не приходят в голову до тех пор, пока вы не зайдёте достаточно далеко.
Что такое Agile?
TL;DR — различные практики, которые помогут вам легче приспосабливаться и убеждать свою команду в том, что она всегда работает над чем-то важным.
Agile — способность меняться легко и быстро.
Эджайл это про то, как разбить ваш огромный проект на ряд маленьких задач (обычно их называют пользовательскими историями) и определить наиболее приоритетные.
Определение приоритетов очень важно, по сути это и есть самое главное в гибкой методологии разработки. Вам нужно убедиться, что команда сфокусирована на одном спринте или на наиболее важном на данный момент результате. Это будет гарантией того, что вы достигнете ваших бизнес-целей. Так ваша команда не потеряется в потоке запросов и требований и будет знать, что каждая подзадача, над которой она работает в данный момент, важна для прогресса всего проекта.
Пользовательские истории поставляются либо непрерывно, либо маленькими циклами, которые называются спринтами.
Как работает Agile?
TL;DR — Требования > План > Работа > Ревью > Повтор
Исходя из требований проекта составьте список всего, что должно произойти. Не переживайте, если забудете что-то, вы сможете добавить это позже.
Оцените каждый этап: по часам или по так называемым story point’ам (относительные оценки, которые выставляются в сравнении и отношении к другим историям). Есть вероятность, что результат будет несколько неточным и даст вам слабое представление о том, сколько времени займёт работа над проектом.
Установите приоритетность задач, самые важные — в начало очереди. Обычно в этой среде всё постоянно меняется, поэтому проверяйте приоритеты быстро и часто. Kanban очень реагирует на эту частоту. Scrum же основан на фиксированных циклах (спринтах), которые обычно длятся две недели.
Проанализируйте уже выполненную работу. Если вы не вписываетесь в план, увеличьте рабочую нагрузку над этим спринтом. Если такое случается постоянно, вы слишком амбициозны.
Scrum vs Kanban
TL;DR — это два основных фреймворка для Agile.
Scrum
- Деление работы на части, которые называются спринтами (обычно в спринте две недели);
- Спринты планируются исходя из требований для этого конкретного момента времени;
- Относительная оценка времени выполнения работ;
- Ревью каждого спринта, чтобы понять, как он прошёл и что можно было бы улучшить;
- Фидбек по поставляемому продукту;
- Ежедневные собрания (очень короткие).
Kanban
- Еженедельные собрания;
- Непрерывная разработка;
- Визуализация процесса на доске;
- Решение сначала самых важных задач;
- Поэтапные улучшения.
Заключение
Самое важное — удовлетворить конечного потребителя, будь то ваш клиент, владелец продукта, ваш босс или вы сами. Охватить все изменяющиеся требования в процессе работы над проектом позволит ранний и многоэтапный выпуск. Это уменьшает риск, потому что вы застрахованы от того, что выпустите неподходящий продукт или в принципе так ничего и не выпустите.
Перевод статьи «What is Agile Workflow? (ELI5)»