Сегодня мир изменяется с такой скорость, что кажется, невозможно за ним успеть. Новые условия требуют новых подходов. Одним из них стала методология Agile. Давайте же разбираться, как она помогает идти в ногу со временем и создавать продукты, которые точно будут востребованы у пользователей.
Что такое Agile?
Agile (от англ. «гибкий») — изначально гибкий подход к разработке софта, который сегодня применяется не только среди разработчиков. Простыми словами, аджайл — это концепция подхода к работе, когда итоговый результат значит больше, чем выполнение различных условностей в процессе создания чего-либо.
Сам термин может употребляться в двух значениях:
- Философия эффективного взаимодействия в команде для быстрой и качественной разработки продуктов, обладает своей системой ценностей, которой должны придерживаться все участники процесса.
- Собирательное название для гибких подходов и методик, которые, так или иначе, пересекаются с основными ценностями Agile.
Команды, которые работают по Agile, состоят из специалистов, равноценных между собой и сотрудничающих в едином рабочем пространстве онлайн или офлайн. Постоянная личная коммуникация между членами команды значительно сокращает время принятия решения по текущим процессам. Однако для того, чтобы создание или разработка продукта были действительно эффективными, необходим человек со стороны заказчика, от которого команда должна регулярно получать обратную связь.
.jpg)
Особенности методологии: преимущества и недостатки
В феврале 2001 года в США встретились 17 разработчиков из разных стран и решили бороться с устаревшими подходами и душащей бюрократией в сфере IT-разработки. Был создан манифест, который включал в себя принципы и подходы, помогающие создавать по-настоящему инновационные продукты. Невозможно создавать новое, если опираться только на старое.
Таким образом появилась методология Agile. По сути, это философия, а в ее основе система ценностей, которая помогает держать фокус только на главном, без лишних формальностей, и создавать продукты намного быстрее и эффективнее.
Преимущества методологии:
- Возможность любых изменений. Та самая гибкость, которая лежит в основе, позволяет быстро вносить в момент разработки новые вводные от заказчика, изменять продукт в ответ на действия конкурента, а также выстраивать процесс создания в нестабильных условиях.
- Снижение рисков. Анализ результатов, тестирование и коммуникация с заказчиком происходит на протяжении всего процесса разработки. Исключен момент с тем, когда итоговый продукт может оказать никем не востребован.
- Отсутствие срывов дедлайнов. Если затянулась разработка какой-либо фичи (дополнительной функции), можно в процессе пересмотреть ее значение для продукта, перестроить срок выпуска или отказаться совсем, но выпустить готовый продукт к назначенной дате.
- Мотивированность команды. Тесное сотрудничество всех ее членов не только друг с другом, но и с руководством, и с заказчиком, помогает по-настоящему ощутить личный вклад в проект.
- Решение проблем в краткие сроки. За счет циклов разработки нет необходимости перерабатывать проект целиком или откладывать решение до выполнения запланированных работ. С проблемами можно справится сразу же, включив решение в ближайший цикл, или, опять же, пересмотрев значение этой фичи, переросшей в баг (ошибку) — просто отказаться от нее.
- Сокращение отчетности. Сама концепция предполагает оценку только по результатам и эффективности произведенного продукта.
Недостатки методологии:
- Отсутствие четкого плана разработки в начале. Однако это недостаток скорее для заказчиков — госкомпании не ценят такой подход.
- Необходимость тесных коммуникаций. Опять же, заказчику нужно быть готовым быть всегда на связи, корректировать требования и оценивать промежуточные результаты.
- Зависимость от команды. Сложно заменить рабочее звено в этой цепочке, так как придется заново погружать нового сотрудника во все предыдущие этапы.
- Фокус на мелочи. За постоянной доработкой и исправлением функций можно потерять финальную цель проекта.
- Усложненное внедрение. Если компания изначально работает по традиционной системе, то переход на новую методологию будет связан не только с потерей времени, но и с отрицанием каких-либо ключевых ценностей. Для внедрения будет необходим специалист, который уже великолепно разбирается в гибких методология, так называемый Agile-коуч.
Если грамотно не выстроить рабочий процесс в соответствии с эджайл-ценностями, вся система может потерпеть фиаско. Но нужно понимать, что здесь вина не методологии, а неправильного ее внедрения.
Отличия Agile от других методологий: почему не стоит класть в одну корзину со Scrum и Kanban
Если говорить именно об отличиях в основополагающих принципах гибкой разработки, их можно наиболее ярко выделить в сравнении с классической строгой методологией Waterfall:
- Итоговая цель проекта может кардинально измениться. И это нормально, требования клиентов должны меняться, ведь и мир постоянно меняется.
- Меньше трат времени на планирование, больше — на достижение совершенства продукта.
- Во время разработки в конце каждого цикла уже получаются готовые продукты, правда с меньшим количеством функций.
- Если у заказчика возникают новые требования, они должны быть добавлены в процесс разработки с началом нового цикла.
- Сроки должны быть выставлены с запасом на непредвиденные задержки и возможные изменения.
- Руководитель должен активно коммуницировать с командой, а не просто приходить с требованиями и проверками.
Гибкая методология построена на том, что эффективность рабочего процесса оценивается готовым продуктом. Вместо документации необходим работоспособный прототип. Постепенно реализуя функции в рабочем прототипе можно добиться идеального продукта в итоге.
Каждый такой этап разработки называется итерацией, в рамках него выполняется конкретная задача, которая должна привести продукт к новой версии и увеличить его эффективность. Основываясь на этом, и формируется список задач на следующий этап.
Гибкость заключена в том, что несколько процессов идут параллельно, и даже неполноценный продукт создается намного быстрее, чем при стандартном подходе. Да, разработка полнофункционального итогового продукта может занять больше времени, но первые варианты уже встретятся с клиентами, а несколько циклов доработок помогут добиться настолько качественной проработки отдельных элементов, которой никогда нельзя было бы достичь при плановом подходе.
Кроме того, важная ценность Agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области: ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть продавцом, а дизайнер — маркетологом, однако иметь базовые знания о смежных специализациях в гибкой разработке необходимо.
Также важно понимать, что Agile — это философия и принципы, но кроме этого, еще и целое семейство методологий со своими инструментами и подходами. Это, по сути, рабочие фреймворки, которые в своей основе придерживаются ключевых принципов гибкой методологии. Сравнивать их между собой — как сравнивать пользу от употребления в пищу орехов и миндаля: одно без другого и невозможно, и непонятно по ценности применения. Наиболее часто применяемые в работе методологии на основе Agile — это Scrum и Kanban.
Scrum — методология, включающая в себя небольшие команды, их кураторов и Scrum-мастеров. Он выстраивает весь процесс спринтами — короткими отрезками времени, за которые должны быть выполнены определенные задачи.
Методология Kanban как фреймворк включает в себя команду, представляющую единое целое, без неформальных лидеров, а сам процесс делит не на спринты, а этапы или стадии проекта. Показатель эффективности канбана — наиболее оперативное завершение этапа, отсутствие простоев, переработок и возвращений на предыдущую ступень. При возникновение любых проблем команда совместно решает, как с ней справиться.
Чтобы не получить в компании «стыд и скрам» вместо эффективной работающей системы, необходимо запомнить: методология Agile без работающего фреймворка внесет в процессы только хаос, а фреймворк без понимания сотрудниками ценностей методологии не будет эффективен и даже, наоборот, нагрузит лишними задачами.
.jpg)
Как внедрить Agile в своей компании
Первое, с чего стоит начать, — определить, будет ли эффективным внедрение Agile-методологии именно в вашей компании. Для этого надо ориентироваться на то, с какими проектами работают Agile-команды. В них обязательно присутствуют два элемента: множество изменяемых в процессе работы условий и необходимость искать решения, которые еще не изобретены. Именно поэтому гибкая методология зародилась в IT-пространстве, а сегодня так часто используется в стартапах.
Если ваша компания удовлетворяет обозначенным выше условиям, вы можете с легкостью начать внедрять гибкую методологию в свои рабочие процессы, как это, например, делают компании в сфере маркетинга и даже HR. Они используют совершенно новые подходы, улучшают качество своих продуктов и выстраивают более эффективные бизнес-процессы.
Шаг 1. Оцените готовность компании к работе по гибкой методологии
Есть несколько признаков того, готова ли ваша компания к гибкому подходу:
- В центре внимания находится клиент и его удовлетворенность вашим продуктом, с ним выстроены тесные коммуникации.
- Сотрудники ориентированы на самостоятельную работу, могут принимать определенные решения, способны создавать прототипы, давать обратную связь и несут ответственность за конкретные результаты.
- Работники компании знают принципы манифеста и придерживаются их в работе.
Кроме того, многие руководители сомневаются, что если их компания станет придерживаться гибкого подхода, маленькие команды не смогут работать с долгосрочными крупными проектами. Не нужно волноваться: они будут декомпозировать — разбивать на несколько частей — задачи, обсуждать промежуточные результаты и приходить к наиболее эффективному решению. Также важный момент заключается в том, что нет никаких ограничений количеству команд, работающим над единым продуктом.
Шаг 2. Поверьте в Agile
Руководителям над такими командами необходимо понять, что Agile подразумевает высокий уровень самоуправления. Необходимо разъяснять сотрудникам, что от них требуется, но не ставить строгие рамки и алгоритмы по тому, как именно этого добиться. Лидеры должны решать возникающие проблемы, обучать и помогать членам команды, следить за результатами, но не перекладывать свою зону ответственности на сотрудников и не регламентировать обязанности сверх необходимых требований.
Эджайл-команды должны нести ответственность за рост прибыли и лояльности клиентов, нежели за количество написанных текстов в день или придуманных в месяц фич. Именно поэтому каждый сотрудник при внедрении Agile должен быть ознакомлен с ценностями и принципами в манифесте и неукоснительно им следовать.
Яркий пример компании, которая понимала необходимость гибкого подхода в выстраивании процессов, но не сразу пришла к принятию целой концепции — Bosch. Внутри компании долго еще был традиционный процесс управления при наличии кросс-функциональных команд, что не давало развития и сбивало с толку сотрудников. Выходом стало разделение членов правления на группы, в каждой из которых свои методы к гибкому подходу. Это идеальное сочетание гибкого и традиционного подхода.
Шаг 3. Проведите необходимые изменения
Необходимо подготовить компанию к приближающимся изменениям и провести работу в следующих областях.
Ценности и принципы
Нужно провести подготовительную работу и разъяснить ценности и принципы гибкой методологии всем сотрудникам компании. Даже если в процессах компании будет выстроен гибридный подход, все должны понимать причину и цель таких изменений.
К примеру, бухгалтер будет возмущаться, почему у всех ежегодное распределение бюджета, а у эджайл-команды ежемесячное. Не зная ценностей, сотрудникам сложно принять корректировки в своем рабочем процессе.
Управление и общение между различными структурами
Здесь нужно провести работу в трех направлениях:
- Подготовить к тому, что некоторые члены традиционных структур могут быть включены в кросс-функциональные команды или станут выполнять некоторые их запросы.
- Объяснить свое решение провести реорганизацию процессов и рассказать, как это повлияет на глобальную стратегию компании.
- Поработать с руководителями направлений, показывая на примерах эффективность от сокращения контроля и увеличения ответственности их сотрудников.
Мотивированность и одаренность сотрудников
Желание развивать компанию по Agile невозможно исполнить без выдающихся сотрудников и тех, кто не может нести ответственность за результат. Все это подразумевает изменения и реорганизацию в работе HR-отдела.
Необходимо оценить текущих сотрудников и выяснить, есть ли у них необходимые качества. А также набрать новых, которые отличаются мотивированностью и ярким видением концепции и результатов работы в рамках эджайл-команд.
Финансовая сторона проектов
Необходимо заранее выстроить алгоритм финансовой поддержки Agile-команд. Ежегодное распределение бюджета в этом случае не подойдет, ведь из-за нехватки финансирования доработка определенных функций может встать, что приведет к слому всей концепции таких команд.
Шаг 4. Начните с демо-версии
Грамотные руководители запускают первые волны эджайл-команд, чтобы избежать рисков, проанализировать эффективность такого подхода и спрогнозировать будущие издержки. Однако к этому шагу надо подойти очень тщательно: необходимо сделать правильный выбор сотрудников для первых «гибких» команд. Если преимущества такой работы видны сразу, их количество увеличивается, если нет — идет выдвижение предположений по повышению эффективности.
Обычно первая такая команда формируется из сотрудников, которые непосредственно связаны с клиентом или заказчиком, с бизнес-процессами и технологическими системами. Когда такие специалисты начинают плотно сотрудничать друг с другом и быть заинтересованными в конечном результате, эффективность их работы вырастает в разы. Кроме того, часто членами команды делают специалистов, ответственных за прибыль и убытки, чтобы остальные кросс-функциональные сотрудники понимали свое влияние на итоговый результат.
Например, в 2015 году ING Netherlands, предупреждая взрыв спроса на цифровые решения и активизацию конкурентов, по-новому перестроила свои структуры развития технологий, управления и маркетинга, разбив их на кросс-функциональные Agile-команды. Таким образом были выбраны именно те сотрудники, которым гибкий подход в работе был важнее всего, а компания получила прибыль и более эффективно выстроенные процессы.
Конечно, можно и сразу глобально провести изменение во всей компании. Однако в этом случае будет необходимо, чтобы все сотрудники безоговорочно подчинялись руководству, а в штате уже были опытные Agile-специалисты. Но риски просчитать в этом случае очень сложно.
Запуская реорганизацию плавно, по несколько эджайл-команд в пару месяцев, можно оценить эффективность методологии и вовремя скорректировать возникающие ошибки. Чем больше таких команд появляется, тем более гибким становится ваш бизнес. Не нужно стремиться к глобальному перевороту: даже такие Agile-гиганты как Google и Netflix сочетают в работе гибкий и традиционный подход.
Примеры проектов: кому подходит и не подходит Agile
Когда гибкая методология только появилась, в своей работе ее использовали только разработчики, среди них Google, Dell и Riot Games. Сегодня же возможности Agile оценили представители и других сфер: Saab использует методологию для создания новых истребителей, а John Deere для сельхозтехники.
К нам в отечественное пространство гибкая методология пришла на пару лет позже, но активно использует в различных сферах: от гипермаркета электроники «М.Видео» до металлургического концерна НМЛК.
Отдельные принципы семейства методологий, принадлежащих Agile, так или иначе используются повсеместно. Возможности канбана уже оценило множество маркетологов и активно использует при работе в Trello.
Гибкая методология подходит тем сферам, которые ориентированы на предложение клиенту лучшего продукта из возможных и создание инновационного или креативного решения в своей работе.
Даже если вы занимаетесь выпечкой пирожков и хотите, чтобы покупатели выбирали именно вас, стоит задуматься о гибком подходе. Однако если происходит работа с госструктурами и тяжело внести изменения в уже утвержденную структуру или договор, от этой методологии придется отказаться.
Agile-манифест: главное
В основе манифеста лежат 4 ценности, которых должны придерживаться сотрудники, работающие по гибкой методологии.
1. Люди и коммуникации между ними важнее инструментов и процессов
Самостоятельный выбор членом эджайл-команды инструментов и решений, приводящих к результату, не должен быть ничем затруднен. Команда не должна быть ограничена в своем использовании инструментов, а процессы должны быть выстроены так, чтобы не влиять на эффективность конкретных сотрудников. Кроме того, участники процесса не только должны плотно коммуницировать между собой, но и с заказчиком напрямую. Видеочаты и интерактивные доски намного лучше почты и мессенджеров.
2. Работающий продукт важнее постоянных отчетов
Красивые отчеты и презентации о том, как классно работает команда, не заменят клиенту уже работающего продукта. В рамках методологии важно, чтобы прототипы после каждого этапа могли уже работать и дорабатываться в процессе. Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации.
3. Коммуникация с заказчиком важнее формальностей
Даже договор с самыми жесткими условиями можно дополнять и изменять в процессе работы, если это понадобится в интересах клиента. Иногда некоторые этапы, согласованные на старте могут не понадобиться, или задача может быть решена качественнее совершенно другими методами.
4. Необходимость изменения важнее следования плану
После каждого этапа можно и нужно вносить изменения, которые необходимы для более эффективно работающего продукта.
Также манифест включает 12 принципов, которые можно свести к следующему ряду смыслов:
- Основная задача — удовлетворить клиента. Процессы и задачи могут изменяться для достижения этого результата.
- Сотрудники и заказчик (или его представитель) должны выстраивать работу совместно и в тесном взаимодействии — желательно ежедневно, и обмениваться идеями и полезной информацией.
- Сотрудники должны быть замотивированы.
- Изменения можно вносить на любом этапе, но результатом каждого этапа должен быть рабочий продукт.
- Каждый участник процесса должен стремиться к упрощению и самоорганизации.
Что почитать про Agile
Если вам интересно узнать больше про гибкий подход, следующая подборка книг и ресурсов именно для вас.
Mark C. Layton, Agile Project Management for Dummies
«Гибкое управление Agile-проектами для чайников» не оправдывает свое название, т. к. содержание этой книги будет интересно не только новичкам. Она написана довольно давно, но не теряет своей актуальности. Scrum-тренер Марк Лейтон потрудился от души и создал потрясающий гайд для всех, кто работает с эджайл-проектами, объясняя даже малейшие нюансы работы на захватывающих историях и практических примерах.
Lyssa Adkins, Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition
Этот труд поможет тем, кто находится в процессе внедрения новой методологии в компании. Автор пошагово объясняет, как выбрать инструменты для управления тем или иным проектом. Здесь глубоко раскрыта важность Agile-коуча в компании, а также дано множество интересных решений из личной практики автора для грамотного выстраивания гибкого процесса.
Приобрести и ознакомиться с книгой
Esther Derby, Diana Larsen, Agile Retrospectives: Making Good Teams Great
Пригодится для разработчиков ПО. Книга актуализирует необходимость ретроспективы в рамках этапов, а не после их прохождения. Авторы делятся своим опытом, как можно раскрыть потенциал Agile-команды и сделать ее работу максимально эффективной.
Agile Alliance Blog
Ссылка на ресурс: https://www.agilealliance.org/community/blog/
Настоящие фанаты гибкой методологии, те самые 17 компаний, которые участвовали в создании манифеста, делятся новостями, достижениями и вариантами реализации гибкого подхода. Блог, который будет интересен каждому, кто погружен в Agile.
Коротко о главном
- Agile — это своеобразная философия ведения бизнеса и семейство методов, опирающихся на единые ценности.
- Не дает увязнуть в формальностях и позволяет сосредоточиться на главном.
- Для воплощения в рабочих процессах потребуются определенные фреймворки. Согласно исследованию, самые популярные в России — Scrum и Kanban.
- Гибкая методология не подходит проектам, которые тяжело подвергать изменениям.
- Если выстроить гибкую методологию грамотно, бизнес будет быстрее реагировать на изменения рынка, разрабатывать уникальные решения и получать лояльных клиентов.
.png)
.png)
.png)
Комментарии