Слушай аудиоверсию этой статьи в нашем подкасте:
Не хочется читать? Тогда можешь посмотреть про Agile наш ролик на YouTube
История Agile
Гибкий подход начинает своё существование где-то с первой половины XX века (хотя, есть мнение, что что-то на него похожее было и раньше). Примерно в 30-х физик Уолтер Шухарт применяет итеративный подход Plan-Do-Study-Act, которым делится со своим учеником Ульямом Демингом (сейчас мы знаем этот подход к управлению, как Цикл Деминга). После окончания Второй мировой, компания Toyota (та самая, где придумали Lean, Kanban и много чего ещё, связанного с Agile) нанимает Деминга обучить своих менеджеров.
Компьютерная среда развивалaсь, и перед инженерами-компьютерщиками встал вызов — как-то унифицировать методики разработки, чтобы повысить уровень и систематизировать сферу.
Появилась ряд моделей управления — но, вот что странно, они не привели к улучшению качества работы. Появилась череда довольно формализованных методик, которые работали против скорости и качества продукта. Проекты по разработке занимали уйму времени, и формальные требования успевали устареть, пока продукт разрабатывался.
Тем временем небольшие команды, которые не пользовались формализованными методами, выпускали на рынок продукты быстрее, качественнее и дешевле.
Это была революция, вызов бюрократическому миру разработки. Как пишет Юрген Аппело в книге «Agile-менеджмент»: «Эволюция взрастила динозавров, но вся пища досталась муравьям».
Потом лидеры группы основали Agile Alliance и стали продвигать методы гибкого управления в мире. Появилась целая экосистема из конференций, книг, кейсов применения — и спустя два десятка лет она продолжает расти.
В чём суть Agile
Гибкую методологию управления придумали, чтобы решить ряд проблем классической/каскадной/водопадной методологии (Waterfall). Например, слишком большой упор на планирование и влияние задержек в одних командах на работу других. Для этого, как я уже сказал, пришлось полностью пересмотреть взгляд на проектную работу, а не менять какие-то отдельные механики.
«Гибкость» заключается в способности agile-команды постоянно адаптироваться к изменяющимся условиям и достигается за счёт трёх вещей:
- Итеративность. Вместо того чтобы долго-долго прорабатывать план, а потом ещё дольше делать идеальную версию продукта, agile-команда старается как можно раньше выпустить работоспособный прототип, а затем раз за разом его тестировать и допиливать. Итеративность может негативно повлиять на продолжительность разработки, но зато у тебя почти сразу есть более или менее рабочий продукт.
- Самоорганизация. В команде все равны, нет руководителей и управляющих, значит, нет и адских согласований. Это экономит ресурсы, особенно время.
- Взаимопроникновение знаний. Любой специалист в agile-команде должен иметь хотя бы базовые знания о смежных специальностях. Помимо кросс-функциональности, постоянно погружение в новые темы позволяет держать мозг в тонусе.
4 ценности и 12 принципов Agile-методологии
Давай разберём, что входит в Agile? В статье про методы управления проектами я дал такое определение:
Методология — набор методов и принципов, подкреплённых теорией.
Так вот Аgile методология — это ценности, описанные в Agile Manifesto или принципы Agile:
- Люди и взаимодействие важнее процессов и инструментов. Если в твоей команде есть принципы, традиции, структуры, инструменты или условия, которые явно мешают работе — от них следует избавиться. Люди сами должны выбирать способ организации, набор процессов, используемые инструменты. В конце концов, всё это должно помогать работе, а не мешать.
- Работающий продукт важнее документации. Это не значит «работать по Agile — работать без документов». В agile-командах тоже есть документация, но на неё не тратят огромное количество времени и ресурсов.
- Сотрудничество с заказчиком важнее согласования условий контракта. Посмотри немного дальше согласования ТЗ и сметы. Нет смысла портить отношения с заказчиком, пусть и ценой своевременной оплаты. Если ты не можешь согласовать работы и портишь общение, в итоге потеряешь и этого клиента, и, возможно, следующих. Любые контракты, документы и соглашения должны идти на руку твоим взаимоотношениям с клиентами, а не портить их
- Готовность к изменениям важнее следования первоначальному плану. Даже если есть план проекта, в него, почти наверняка, со временем придётся внести изменения — в этом суть Agile.
В Манифесте описаны ещё и принципы — их 12. Они даны скорее в попытке разжевать ценности. Так что пробежимся по ним кратко:
- 1. Удовлетворение клиентов — главная задача разработки
- 2. Изменения в процессах — это даст продукту конкурентное преимущество.
- 3. Работающее программное обеспечение должно доставляться до клиента часто — в период в 2–16 недель.
- 4. Руководители и разработчики должны трудиться вместе весь рабочий процесс (не понятно, а как ещё-то)
- 5. В основе проектов и процессов — мотивированные люди. Им надо обеспечить условия и интерес
- 6. Лучший способ передать информацию — поговорить лично
- 7. Мерило успеха — работающее ПО. Не часы, не трудозатраты. Только итог
- 8. Гибкость — основа развития
- 9. Надо уделять внимание техническому совершенству и хорошему дизайну продукта
- 10. Устранять лишнюю работу и не усложнять проект и процессы
- 11. Самоорганизация — это хорошо. Такие команды делают лучшие продукты. И долой микроменеджмент!
- 12. Регулярная оценка и саморефлексия — это хорошо. Это команда должна делать регулярно
Ну вот, те же ценности, только поставленные на почву практики.
Подходы, методы и инструменты Agile
В гибкой методологии управления проектами появились и утвердились инструменты, которые последователи метода внедрили в работу — или вывели в процессе работы. Расскажу про главные.
Scrum
Метод Scrum — это когда владелец продукта или заказчик формирует набор требований к продукту и передаёт его разработчикам. Те делят работу на этапы — спринты: такие короткие отрезки, от одной недели до четырёх.
У спринта есть цель, так что команда выполняет набор задач для её достижения. Список всех этапов — это бэклог проекта. Задачки берутся оттуда, и из них уже формируется бэклог на спринт.
Команда работает по нему, в конце есть результат, который оценивается — и после формируется новый спринт. Такая коробка с детальками пазла — берёшь горсточку, собрал кусочек, достал новую, собрал ещё.
У нас есть подробный текст про метод Scrum. И ролик на YouTube.
Канбан-доска
Второй инструмент — Канбан-метод. Этот инструмент невероятно популярный, потому что очень гибкий. Более гибкий, чем Scrum.
Суть в том, чтобы использовать Канбан-доску — можешь воспользоваться нашим сервисом WEEEK — и работать с ней по шести принципам:
- 1. Визуализируй задачи в столбцах доски. Появилась новая задача — сразу на доску!
- 2. Ограничь количество задач — в каждом столбце определённое количество задач
- 3. Управляй потоком работы — смотри, как задачи движутся по доске. Помни, определённое количество для каждого столбца, нигде не должно копиться пробок из задач, всё движется и меняется
- 4. Используй понятные для всех правила добавления и движения задач
- 5. Делайте встречи с обратной связью — чтобы контролировать работу в реальном мире
- 6. Улучшай процессы везде, где только можно
Мы в WEEEK в разработке тоже используем канбан — и это помогает нам каждую неделю делать обновления. Канбан прижился у нас и в других отделах — например, сценарий к этому ролику тоже когда-то двигался по Канбан-доске контент-отдела.
У нас есть подробный текст про метод Канбан-досок. И ролик на YouTube
XP — экстремальное программирование
Экстремальное программирование (от англ. XP, eXtreme Programming) — ещё одна гибкая методология разработки ПО. Экстремальное программирование отлично подходит для комплексных продуктов и неопределённых процессов.
Цель метода — справиться с быстрыми изменениями в требованиях к продукту — и в результате повысить качество и процессов, и результатов.
В основе XP 4 главных составляющих:
- кодирование,
- тестирование,
- дизайн,
- слушание (то есть получение обратной связи от юзеров).
Тут в основе ценности простоты, коммуникации, простоты, уважения — и доля смелости.
Lean
Это методология выхода с продуктом на рынок. Очень прижилась в стартапах, поскольку подошла под теорию работы в условиях неопределённости — и когда надо минимизировать потери, работать без прибыли и снизить издержки.
Тут всё крутится вокруг термина MVP — minimum viable product, минимально жизнеспособный продукт.
Суть подхода в том, что авторы продукта не должны выходить на рынок с вылизанным, завершённым продуктом — а должны как можно скорее выходить на рынок с продуктом с минимальной функциональностью. Такой продукт поможет протестировать идею и гипотезу о ценности продукта, быстро сделать вывод, а нужен ли он на рынке, и найти первых последователей.
Lean гласит — покажи на рынке продукт, пойми, нужен ли он, а потом улучшай в зависимости от реальных требований рынка. Про механизм работы Lean подробно и интересно пишет Эрик Рис в книге Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.
Плюсы и минусы Agile
Плюсы
- Адаптивность к переменам
- Высокая вовлечённость команды
- Помогает соблюдать сроки
- Помогает делать реально нужный продукт
Минусы
- Всё завязано на команде и на мотивации
- Нет чёткого плана
- Не получится быстро перестроиться с негибких методологий на гибкие — и обратно
Применение Agile
Agile хоть и был разработан для управления проектами в сфере разработки программного обеспечения, нашёл применение и в других областях.
Agile в разработке
Собственно, Agile-методология — это детище сферы разработки, и к этому моменту в тексте я уже много про это рассказал. Так что очень коротко пройдёмся по принципам:
Разработка цифрового продукта по принципам гибкой методологии корректируется с учётом отклика от пользователей. Обновления продукта выходят в короткие сроки — итерациями; первоначальные планы корректируются с учётом новых вводных; источником изменений становится обратная связь от клиентов; команда внутри часто рефлексирует над происходящим.
Примерно на те же принципы можно ориентироваться в других сферах жизни, если хочется внедрить гибкий подход.
Agile-маркетинг
Agile-маркетинг — подход к маркетингу на базе принципов и практик методологии Agile. Это означает появление самоорганизации в командах, кросс-функциональность, работа с обратной связью внутри команды, частые эксперименты по гипотезам, быстрая адаптация и корректировка идей, частые итерации маркетинговых кампаний.
У Agile-маркетинга есть отличительные черты:
- Целенаправленные эксперименты. Agile-маркетолог работает по гипотезам: выдвигает гипотезу — тестирует её — делает выводы — выдвигает новую гипотезу
- Частые релизы маркетинговых компаний. Потому что продвижение к цели в гибкой методологии требует постоянной сверки и корректировки промежуточных шагов. Грубо говоря — если хочешь тестировать много гипотез, надо совершать частые итерации.
- Стремление удовлетворить целевую аудиторию. Современный клиент и пользователь — требовательный. Кто не умеет приносить пользу и прислушиваться к мнениям аудитории, тот не выживет на рынке.
У Agile-маркетинга есть даже свой манифест. Вот его ценности:
- Ценность для клиентов и бизнес-результаты важнее активности и промежуточных результатов.
- Оперативная и частая поставка ценности важнее совершенства.
- Учиться нужно на экспериментах и данных, а не на домыслах и мнениях.
- Совместная работа многофункциональных команд выгоднее разобщённости и иерархии.
- Готовность к изменениям важнее следования жёсткому плану.
Управление продуктами
На тему управления продуктами по Agile перекладываются многие принципы в разработке ПО. Правда, тут надо посмотреть, какой продукт развивается.
- Если это цифровой продукт — то применяются все те же принципы, что и в разработке. Собственно, продакт-менеджер и будет лицом, который реализует ценности гибкого подхода, продвигает изменения, собирает и транслирует запросы аудитории, курирует спринты и итерации. И использует инструменты SCRUM, Канбан, custdev.
- Если продукт физический — например, линейка одежды. Как тут можно применить Agile? Ну, например, можно оперативно пересматривать содержание линейки одежды. Допустим, какая-то единицы не продаётся — можно пересмотреть линейку и убрать висящий товар. Или можно пойти и спросить клиентов, что они покупают, почему, чего бы им хотелось добавить.
Личная жизнь и саморазвитие
Agile — гибкая методология, так что гибко подстраивается под разные сферы жизни, в том числе под личную жизнь и личное развитие. Как?
- Ты можешь также визуализировать свои дела, планы, цели на Канбан-доске, разделив продвижение на подпроцессы. Например, в сервисе WEEEK ты можешь разделить сферы жизни на проекты: Дом, Работа, Хобби. Внутри проектов создать доски, допустим, для проекта Дома: Ремонт, Купить, Заменить. Внутри доски Ремонт сделать вот такие колонки: Надо починить, Чиню, Готово. А уже внутри ставить себе задачки — и продвигать их по доске.
- Применять принципы тайм-менеджмента и приоритизации, ориентируясь на изменения внешней среды. Например, ты можешь решить — Сейчас для меня приоритетнее выстроить рабочий день так, чтобы не умирать, поэтому я буду делать перерывы в течение рабочего дня.
- Ставить изменения в планах выше следованию первоначальному плану, если об этом намекает контекст. Например, вот запланируешь на вечер посиделки с котом под пледом с чайком. А тут в город внезапно приехал старый друг. Стоит подкорректировать план — выйти из комнаты, угнать в бар, круто пообщаться. Утрирую, конечно — но суть в том, чтобы гибко корректировать планы, а не упираться в первоначальный план, если оно того не стоит или есть вещи важнее.
- Внедрять итеративность. Например, улучшать дома что-то постепенно. То тут новый стул прикупить, то лампочки поменять, то вытереть, наконец, пыль за шкафом. Совершать небольшие шаги к улучшению жизни.
- Ориентироваться на развитие. Мы тут сейчас зайдём на территорию психологии, но так надо. Попробуй отделаться от фиксированного мышления (что ничего не изменить) и ориентироваться на развитие и перспективу (что тебе подвластны перемены в жизни). Даже можем посоветовать послушать подкаст Катерины Ленгольд «Просто космос» — история успеха этой девушки, которая в 23 года попала в Кремниевую долину, очень вдохновляет.
Что не относится к практикам Agile
Если сейчас тебе показалось, что Agile — это про «бери и делай», не запаривайся о результатах, не отслеживай показатели, не веди документацию, а просто адаптируйся, то нет.
Возьмём хотя бы процесс проработки гипотез. Кажется, что суть гибкого подхода — попробовать всё, что подворачивается или приходит в голову, но это не так. Построение гипотез должно на чём-то основываться — на метриках и видимых узких местах в них, на интервью с пользователями, на возникающих проблемах.
Если просто выполнять всё, что требует окружение, если разрабатывать каждую фичу, которую требуют пользователи — и загружать этими заданиями сотрудников, то гибкого подхода не получится. Получится ерунда какая-то.
Так что вот, что не относится к практикам гибкой методологии Agile:
- Полное отсутствие планирования и документации — это не Agile.
- Отсутствие планирования и слепое следование изменениям во внешней среде — это не относится к Agile.
- Мнимое следование ценностям — например, декларирование ценностного подхода к сотрудникам без реального хорошего отношения к ним — это не Agile.
- Метания из стороны в сторону, от одной цели, гипотезы, идеи к другой — это не Agile.
- Говорить, что ценишь клиента (пользователя, читателя, себя) — а на деле забивать на обращения целевой аудитории — это не про Agile.
- Не рефлексировать над результатами, не следить за показателями бизнеса, не спрашивать у команды о положении дел — и это тоже не Agile.
❗️Ещё раз: суть Agile в том, чтобы адаптировать свой проект под изменения во внешней среде, ориентируясь на контекст бизнеса, на команду, на целевую аудиторию. Тут для успеха, конечно, должна быть своя стратегия.
Кому подходит Agile и какие могут быть проблемы
Ай, какой классный Agile, да? Увы, хотя управление Аgile и можно применять в любой компании (даже если ты — прости, Господи — банк), подходит он далеко не всем. Да ещё и его внедрение может быть крайней болезненным.
Я вижу четыре проблемы (хотя, вполне может статься, что их больше), из-за которых нельзя советовать переходить на Agile всем подряд:
- Сложно отказаться от концепции «начальник — подчинённый». Ведь Agile — это не способ планирования, а философия работы всей команды. Далеко не каждая компания сможет спокойно пережить подобную трансформацию
- Не все готовы к по-настоящему командной работе. Многим людям комфортнее работать в одиночку, отчитываться перед руководством и никуда не лезть. А в случае с Agile всем придётся во всём разбираться и постоянно участвовать в чужой работе
- Не все готовы к тому, что часть времени может просто пропасть. Допустим, команда работала над задачей, а потом оказалось, что цели проекта поменялись и продолжать почти законченную работу нет смысла. Все твои усилия были напрасны. Это психологически сложная ситуация, которая может запросто убить всю мотивацию
- Тебе надо подобрать команду, которая будет обладать высокими компетенциями (или будет готова их качать), дисциплиной (или будет готова прокачать её), высокой мотивацией (ну, ты уже понимаешь, к чему я клоню). Для внедрения гибких методологий, тебе понадобится команда гибких ребят. А поди найди таких, да чтобы сразу на собеседование разобрать, кто там гибкий, а кто нет.
Но если твоя команда работает над кучей проектов, хорошо знает дело и топит за идеальный результат, возможно, Agile — это ваше.
Не обязательно сразу переносить манифест Agile на свою работу, даже всем принципам разом следовать не к чему — можно ориентироваться на ценности. В конце концов, если ты вдруг начнёшь больше ценить своих сотрудников, позволять им креативить и расширять полномочия — разве это не сделает из тебя босса-пусечку, вокруг которого соберётся мотивированная и заряженная команда? А у такой команды дело спорится!
Подписаться 
