Получите все материалы с наших тренингов — бесплатно
Что Такое Agile, Кому он Подходит, а Кому Нет 💥 + Кейсы
Что Такое Agile, Кому он Подходит, а Кому Нет 💥 + Кейсы
Что Такое Agile, Кому он Подходит, а Кому Нет 💥 + Кейсы
⚡ Ответим в течение 30 минут — contact@leadstartup.ru
+7 495 150 42 63 — с 8:00 до 21:00 МСК
Катерина Сухих

Что такое Agile, 💥 — ценности, принципы и Agile–манифест + кейсы от компаний, которые применяют Agile

85 отзывов, в среднем 5 из 5
Agile в управлении проектами — это применение принципов гибкой разработки в проектном менеджменте с высокой степенью неопределенности и рисков.

Agile-манифест и все, что его касается на вашем кейсе с детальным разбором

Что такое Agile

Это гибкий подход к организации работы и майндсет (система установок). Agile сфокусирован на командную работу, тесное взаимодействие, личную ответственность. Многие из лучших компаний используют Agile, однако внедрение Agile может быть непростой задачей.

Получите нашу единую MIRO–доску с 100+ инструментами и доступ к Google–диску
Материалы тренингов LeadStartup

Зачем нужен Agile

Чтобы быстрее поставлять продукт на рынок (снижение Time To Market), делать продукт качественнее, улучшать клиентский опыт, сокращать количество нерациональных и неэффективных действий. Особенно хорошо Agile показывает себя в условиях работы в условиях высокой неопределенности.

Как работать по Agile

Сократите количество узкоспециализированных специалистов, начните искать и развивать T-Shaped специалистов. Начните работать кроссфункциональными командами. Сократите количество «компонентных» команд (работающих с отдельными частями продукта) и повысьте количество функциональных команд (которые разрабатывают продукт end-to-end).

Что такое Agile?

Что такое Agile Источник webcatcher.ru

Agile — это гибкий способ управления проектами. Его еще называют гибкой методологией. Гибкость в том, что продукт может меняться в процессе создания. Команда реагирует на пожелания пользователей, клиента и ситуацию на рынке.

Ну а если говорить языком опытных Agile–коучей, Аджайл — это образ мышления, основанный на здравом смысле.

В методологии Agile на первое место выходит клиент. Им может быть заказчик или конечный пользователь продукта, а лучше и те, и другие.

Продукт должен решать задачи клиента и нравится ему. Поэтому Аджайл–команда начинает работу над продуктом с выяснения того, что нужно клиенту. Команда выпускает новый функционал, и каждый раз собирает обратную связь у клиента. Это помогает сделать продукт, который решает поставленные задачи. За такой продукт люди готовы платить.

Негласный девиз гибких методологий: лучше сделать быстро и с багами, но сразу понять, нужен продукт кому–то или нет.

Если объяснять простыми словами, то Agile применяют, когда точно неизвестно, что нужно клиенту, какой продукт будет востребован на рынке. Чтобы узнать это, продукт выпускают частями, по каждой из них собирают обратную связь и проверяют экспериментами.

Примеры Agile

  • Собираете обратную связь у клиента и пользователей на каждом этапе работы над продуктом.
  • Разбиваете работу над проектом на задачи и подзадачи.
  • Меняете нагрузку на членов команды, если кто–то не справляется, разбираетесь в причинах и думаете, как сделать лучше в следующий раз.
  • Показываете часть продукта клиенту, после каждого этапа работы. Один этап длится 2-3 недели.
  • Расставляете приоритеты. То,  что продвинет проект вперед, делаете первым. То, что не так важно для прогресса подождет до завтра.
  • Меняете продукт на любом этапе, если изменился бизнес клиента, требования рынка или он не решает задачи пользователей.

Примеры не Agile

  • Собираете требования клиента на старте проекта и следуете им до его завершения.
  • Работаете по плану: три недели на дизайн, месяц на программирование и верстку, десять дней на тестирование.
  • Заранее планируете нагрузку на членов команды. Объем задач определяете на старте проекта и не отходите от него. Если кто–то не успевает, сдвигаете сроки всего проекта или подгоняете команду.
  • Показываете клиенту продукт, когда все работы по нему завершены. Или демонстрируете результат после каждого большого этапа: сделали дизайн — показали, сделали верстку — показали.
  • Работаете по плану, который согласовали с клиентом на старте проекта. Выпускаете продукт в том виде, в каком он был в самом начале согласован с заказчиком.

История Agile-манифеста

Аджайл состоит из разных методов, фреймворков, правил и инструментов. Большая часть из них появилась задолго до того, как была сформирована методология.

Подход Crystal появился в 1992 году. В его основе лежит  командная работа, обсуждение задач и работы. Важно, чтобы все понимали, кто и что делает. Продукт создают по кусочками, код выпускают через частые поставки.

Метод Scrum появился в 1995 году.  Он основан на отказе от долговременного планирования. Вместо этого Скрам предлагает  делить разработку на короткие этапы. Каждый этап заканчивается экспресс–оценкой и внесением правок. Важное место в Скрам отводят расстановке приоритетов.

Метод экстремального программирования — XP возник в 1996-1999 году.  В этом методе работа над продуктом строится на пользовательских историях — User Stories. Это сценарии, которые пользователь проходит в продукте.  Например,  загрузить фотографию на аватар или оформить заказ товара в корзине. В XP зародились и продуктовые релизы. Это результат каждого этапа работы над продуктом.

У каждого из этих методов есть свои авторы — разработчики и инженеры. Двадцать лет назад они собрались на горнолыжном курорте Сноуберд в США.

В то время IT компании страдали от бюрократии: все этапы разработки жестко документировали. Нельзя было ни на шаг отступать от требований и плана.  Айтишники закапывались в бумагах и забывали о своей главной задаче: приносить радость клиентам. Разработчики манифеста горели идеей: объединить все свои наработки и создать самую крутую  методологию  для айтишников, чтобы ее могли использовать во всем мире и создавать с ней мощные продукты.

Что именно происходило на горнолыжном курорте, одному Богу известно. Но итогом этой встречи стал Agile Manifesto. Документ, который навсегда изменил подход к разработке IT–продуктов.

Что такое Agile Создатели методологии Agile

Что такое Agile Manifesto простыми словами

Аджайл–манифест — это документ, в котором описаны принципы и ценности гибкой разработки. Манифестом его назвали за то, что ценности звучат как боевой клич и противопоставляются традиционным принципам работы.

Agile Manifesto создали 20 лет назад, но он не потерял своей актуальности. Его идеи продолжают менять образ мышления разработчиков.

Манифест построен вокруг четырех ценностей:

  • Люди и взаимодействие важнее процессов и инструментов.
  • Работающий продукт важнее исчерпывающей документации.
  • Сотрудничество с заказчиком важнее согласования условий контракта.
  • Готовность к изменениям важнее следования плану.

В Манифесте сказано, что компания, которая хочет работать по Agile придерживается 12 принципов. Эти принципы определяют то, как строится процесс работы с заказчиком, работа над продуктом и взаимодействие внутри команды.

На первое место встает работающий продукт, а не документы и согласования.

Команда стремится к простоте и самоорганизации, то есть нет руководителя, которые несет за все ответственность и принимает решения. Вся команда отвечает за продукт и хочет сделать его лучше.

Цель разработки  — принести пользу клиентам. Каждая задача дает ценность. Нет разработке ради разработки.

Методы управления проектами

Agile лег в основу разных методов управления проектами. Методы помогают выстроить рабочие процессы в зависимости от продукта, условий, команды и конечного результата.

Методы гибкого управления подходят не только для IT–компаний. Их применяют строительные фирмы, банки, стоматологии, медцентры, бренды одежды и другие бизнесы.

Scrum выбирают для проектов, которые создают с нуля. Команде не от чего оттолкнуться, какой результат будет в конце — неизвестно. Задачи в Скрам делятся на подзадачи, для каждой назначается свой приоритет: делать ее сейчас или позже. Задачи распределяются на спринт, который длится 2-3 недели. В конце спринта команда выпускает готовую часть продукта или функцию.

Фреймворк построен на процессах: обязательные стендапы, митинги и ретроспективы. На этих встречах члены команды обсуждают задачи, ход работы, сложности, с которыми сталкиваются.

В Scrum-команду входит Product owner (владелец продукта) и Скрам–мастер. Product owner выступает в роли руководителя, он общается с заказчиком, ставит задачи команде. Scrum master планирует и организует совещания, он отвечает за соблюдение правил Скрам, устраняет препятствия, которые мешают команде работать.

Пример: разрабатываем приложение онлайн–стилист. Пользователь вводит данные и получает капсулу одежды для нужного случая.

Kanban перешел в IT с заводов Тойота, его использовали в цехах, чтобы контролировать объемы и сроки производства. Канбан помогал производить столько деталей, сколько нужно потребителям.

В айти Канбан-метод применяют для улучшения и поддержки готовых продуктов. Команда понимает, какой результат хочет получить в конце и поэтапно к нему идет. Метод подходит для команд с узким профилем, например, только iOS–разработчики или только аналитики.

В Канбан-методе нет жестких правил и обязательного следования ценностям Agile: совещания, стендапы и ретроспективы можно не проводить, если это не нужно команде и не влияет на разработку. Важный элемент Kanban — доска.  На ней должно быть видно, как идут дела в проекте, на какой стадии находится каждая задача. В Канбан есть ограничение на количество задач, которые можно взять в работу в один момент.

Пример: есть приложение онлайн–стилист. Нужно добавить к нему функционал онлайн–шопинга со стилистом.

Lean применяют, когда есть проблемы с рабочими процессами: команда не успевает сделать задачи к дедлайну, на проект потратили больше денег, чем планировали, привлекли к разработке двух дизайнеров, хотя все задачи мог сделать один специалист.

Метод Lean помогает разобраться, в каком месте компания теряет ресурсы, время и деньги.

В Lean нет готовых инструментов: делай так, а так не делай. В этом методе команда фокусируется на создании ценности для клиента: выяснить, что нужно клиенту, и дать ему именно это. От ненужных процессов отказаться и сэкономить на этом.

Пример: при работе над приложением онлайн–стилист команда потратила время на дизайн кнопок. Для пользователей было важнее наладить поиск одежды по брендовым магазинам.

Когда нужен Agile

Agile — это не универсальный инструмент, который разом решит все проблемы и поможет создать прорывной продукт. Spotify и Netflix работали по Agile с самого начала, это помогло им стать лидерами в своих нишах. Amazon переходил на гибкие методы управления постепенно, и это дало свои результаты. Но есть еще тысячи примеров компаний, которые перешли на Аджайл и закрылись.

Методология подойдет, если у вас есть опытная команда. В команде работают сотрудники–профессионалы, которые готовы, если нужно, подтягивать новичков.

Agile помогает стартапам быстро получить рабочую версию продукта или MVP (минимальный жизнеспособный продукт). Это не гарантирует, что вы не провалитесь через год. Но гарантирует, что этот год вы потратите с умом и получите опыт.

Вам стоит подумать об Аджайл, если вы продуктовая компания и работаете над собственными продуктами, либо ваш заказчик готов погрузиться в проект и активно участвовать в разработке. При этом конкуренты наступают на пятки, а в экономике царит полная неразбериха.

Минусы методологии Agile

Если бы все дифирамбы, что поют гибкой методологии, были правдой, то компании перешли бы на Agile и процветали. Но в жизни все не так. Почему?

Постоянные изменения в продукте = увеличение сроков. Причем вы сами будете умножать все на 2 (а то и на три) для подстраховки. Нечетко поставленные задачи, переподписание контрактов и допсоглашения — это нормально.

Вы начинаете искренне радоваться ошибкам, своим и клиентов. Постоянно извлекать уроки, чтобы учесть все риски в будущих проектах — это для Agile обязательный процесс.

Рискуете, бесконечно набиваете шишки. Потом встаете и все по кругу.

Вы бесконечно тестируете все, что  создаете.

В Аджайл вас ждет много–много общения. И грустные глаза программистов на четырех часовых совещаниях. Ведь если их отвлечь, то на полноценное возвращение к работе может уйти около часа, пока они вернутся к написанному коду, откроют нужные приложения.

При переходе на гибкие методы управления, вам придется довериться команде. Много решений будут принимать сами сотрудники. Или «привет, чайка–менеджмент». Например, когда основатель компании или кто–то из руководства вдруг начинает обсуждать цвет кнопок, которые нарисовал дизайнер.

Вы больше не сможете никого наказывать штрафами, даже если очень хочется.

Будьте готовы отказаться от долгосрочного планирования: завтра проект может свернуть в другую сторону.

Что такое Agile Исследование Scrumtrek за 2019-й год: распространению Agile в России на предприятиях не из IT

Как работает гибрид гибких и негибких методологий

Религиозные войны между адептами Agile и сторонниками негибкой, каскадной модели управления уже в прошлом. Сегодня многие из тех, кто когда–то перешел на «чистый Agile», применяют гибридный подход к управлению проектами. Почему и когда такое происходит?

Каскадная модель Waterfall присоединяется к Agile, когда компания понимает, что запланировать все невозможно. Гибрид подходит проектам, цель которых — выполнять требования клиентов в определенный срок. Вот только сами эти требования постоянно меняются. И на одном этапе проекта все двигаются по шагам и в соответствии с инструкцией. А на другом — становятся гибкими и подвижными.

К примеру, в российском финансовом секторе во многих компаниях по Agile работают менеджеры среднего звена. Линейный персонал и топ–менеджмент остается в привычной каскадной модели.

Такой гибрид Agile и Waterfall применяли и в компании Schneider Electric. Это позволило команде разработчиков программного обеспечения работать независимо от команды, которая отвечала за "железо". Разработчики применяли Agile. А вторая команда не отступала от каскадной модели. Планировали все этапы и следовали жестким срокам.

Кейс гибридного подхода GanttPro

В компании при разработке и развитии продукта используют долгосрочное планирование. Но все стратегии разбивают на задачи, которые, в свою очередь, упаковывают в итерации.

Команды ведут бэклог и берут оттуда задачи, генерируют гипотезы. Задачам присваивают приоритеты. А дальше начинается самое интересное: работа идет по спринтам, но уже из них складывается водопадная модель. Стратегии корректируются на ходу, это сказывается на наполнении спринтов и сроках выполнения. Тем не менее, при любых изменениях в компании всегда есть четкий план, когда и что нужно сделать.

Такой подход позволяет разным командам синхронизироваться. Те, кто непосредственно общается с клиентами и пользователями, в курсе всех планов и процессов, и может из первых рук предоставлять всю нужную информацию.

Во многих продуктовых IT–компаниях был момент полного перехода к Agile, но в процессе работы оставили те методы, которые полезны для компании, а от других отказались. Поэтому чистый Agile сейчас скорее редкость, чем тренд.

Что почитать по методологии Agile

Эта подборка книг поможет разобраться с принципами Agile и «продать» эту философию команде разработчиков.

  • Agile Project Management for Dummies Марка Лейтона. Здесь много практических примеров и реальных кейсов, как компании внедряют и реализовывают проекты по Agile. Можно брать и пробовать у себя. Плюс полезные советы, как прокачать членов команды и руководителей.
  • The Software Project Manager’s Bridge to Agility от Michele Sliger и Stacia Broderick. Эта книга пригодится тем, кто переходит на Agile с традиционных методов управления проектами. Или тем, кто сейчас задумался, а, собственно, надо ли? Авторы подробно рассказывают о разнице между подходами и способах безболезненного перехода.
  • Project Management the Agile Way: Making it Work in the Enterprise, автор John Goodpasture. Здесь много полезного про техники и инструменты, которые нужны под разные проекты. Еще книгу можно смело давать членам команды, чтобы они прониклись философией Agile и точно поняли, чего вы от них хотите.
  • Agile Retrospectives: Making Good Teams Great от Esther Derby и Diana Larsen. Эта книга особенно пригодится тем, кто начинает проводить ретроспективы или не доволен тем, как они проходят сейчас. Тут описаны способы организации этих встреч, причем не только удачные, но и не удачные варианты, рассказано, как мотивировать команду к активному участию в них. И, главное, как сделать ретроспективы реально полезными для всех, а не для «галочки». Еще здесь описаны способы, как усилить вашу и без того классную команду.
Получите единый доступ ко всем нашим 21 курсам, 7 тренингам, 4 профессиям и 126 воркшопам — с сертификацией
⚡ Ответим по электронной почте в течение 30 минут
По телефону — мгновенно, ежедневно с 8:00 до 21:00 MSK
ВТБ
Microsoft
Lanit интеграция
HomeCredit
Сбербанк
Universal University
TUI
LaNature
Альфа Банк
AMS
BAT
Kt.team
IKEA
KT.Team
MTS
OTK
Ростелеком
X5