Что является главной причиной возникновения agile клиент руководство компании команда изменения

Время на прочтение
9 мин

Количество просмотров 12K

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

_{*Из большого ежегодного опроса компаний от VersionOne}

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

Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов

Agile — это не метод разработки программного обеспечения. Википедийные определения плохо годятся для понимания, если ты не разработчик.

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

Противовес Agile — это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в «Что? Где? Когда?» капитан должен был бы раздавать точные задачи — кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.

Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.

Гибкие методологии — это ответ на неопределенность; до конца неизвестно, что нужно сделать и что должно получиться в результате. Казалось бы, а что непонятного в разработке, например, сайта или в строительстве дома или в приготовлении гамбургера в Макдональдсе? Эти проекты поставлены на поток, где неопределенность?

Но. Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

Хорошо, в изготовлении гамбургера в Макдональдсе нет никакой неопределенности. Процесс отработан за 70 лет и воспроизведен в 125 странах. Да, это конвейер, куда лучше не влезать с гибкостью. Agile не применим в хорошо отлаженных годами процессах. Правда, открытие нового ресторана по очень точной франшизе — это всегда уникальный проект. Где к месту будет итеративный подход, сокращение итераций, распределение ролей, открытое взаимодействие, визуализация проекта на Agile-доске, ретроспектива, ежедневные планерки.

Итого ключевые ценности Agile (манифест):

• свободное взаимодействие в команде
• результативность проекта (классный продукт)
• партнерское общение с клиентом
• готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

В упрощенной форме:

Заказчик — рассказывает какой продукт нужен, для чего он нужен, устраивает обсуждения вокруг запросов с рынка, принимает решения по приоритетам.
Методист — следит за тем, чтобы заказчик не превратился в начальника. Ну и еще за выполнением остальных практик, например, чтобы все задачи были с оценкой или чтобы оценки задач не превышали 80% от имеющегося времени, если есть такая договоренность.
Команда — оценивает, распределяет и реализует задачи. Всегда демонстрирует версию продукта, а не отдельные выполненные кусочки.

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).
Если идет обсуждение вопроса «Как реализовать продукт?» на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:

«А как точнее управлять ресурсами?», «Как раньше понять, что в проекте ресурсов стало не хватать для окончания?», «Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?». Что бы рассказать про Agile, можно раскрыть только этот вопрос.

Надо отметить, что вообще весь Agile сконструирован именно для решения вопроса с ресурсами «Как эффективно управлять ресурсами в проекте с непредсказуемостью» Методология бы не родилась, если главной задачей был бы комфорт и свобода людей в команде.

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.

Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

4. Оценка задач в размерах футболок. Люди не слишком любят давать точные оценки задачам, но оценивать примерно, по шкале большая, средняя, маленькая для большинства нормально. Ниже самые популярные в мире способы оценки задач без высокой точности. С процентами по частоте использования.

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь — это график с двумя линиями; первая — сколько времени сгорело и это всегда прямая, на второй — сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

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

• самая частая ошибка — попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход — заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России — они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование — спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом — хорошая практика. Спринт — это несколько недель. Слишком короткие или слишком длинные отрезки — плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.

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

2. Ежедневные планерки (88% команд используют)
Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.

По классическому описанию каждый в команде раскрывает три вопроса:
Что сделано к этому моменту из спринта?
Что планируется на сегодня?
Какие проблемы возникли или что мешает?

По нашей практике это быстро надоедает командам и становится рутиной или формальной отчетностью. Что помогает:

Менять время планерки — 6 мес. утром, 6 мес. вечером.
Каждый раз менять ведущего планерки, не должно быть лица перед которым отчитываются. Отличный вариант если ведущий разыгрывается жребием.
Заказчик продукта, делиться историями о клиентах в начале планерки.
Обсуждать общие темы и только потом переходить к вопросам.
Не пускать на планерки никого кроме участников команды.

3. Ретроспективы (83% команд используют)
Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель — сделать выводы о том, как меняться.

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

Как правило, ретроспективы проходят весело — итерация-то закончилась, можно выдохнуть и обсудить итоги. Хорошая практика что-нибудь пить или есть в перерывах этого процесса.

4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило, в виде выступления. Главный смысл в том, чтобы была «сессия» и ничего страшного, если это станет похоже на отчетность перед руководством.

Главная трудность в том, чтобы собрался кто-то кроме команды, да еще и понимал смысл происходящего. По нашей практике приживается только при очень крутом руководстве.

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании.

Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

Гибкость подхода распространяется и на сам подход. Это первое, что стоит узнать команде, если им предстоит стать гибче. Нельзя быть на 100% Agile, выполняя все предписания. Никто строго не соблюдает правила в чистом виде, на практике у каждой компании есть свои модификации.

Самые популярные методы из Agile внедряются легко, дают результаты и не перевернут компанию с ног на голову. Именно по этой причине 98% использующих что-то из Agile говорят об успешности подходов.

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

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

P.S. Опрос: Agile в России 2017

В статье приводится несколько фактов о распространении Agile в мире, взятых из опроса от компании VersionOne.
Проблема в том, что эти данные имеют мало общего с нашей действительностью.
Мы в YouGile проводим большой опрос о гибкой методологии в России.

Примите участие — пройдите опрос «Agile в России 2017»
10 вопросов, 3 минуты

Результаты обязательно будут опубликованы на Хабрахабр.

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

Где используется? Изначально методика создавалась для применения в сфере разработки ПО. Но очень скоро ее оценили и представители других направлений бизнеса, причем как среднего, так и крупного – предприятий нефтегазовой промышленности, банковского сектора. Более того, принципы Agile взяли на вооружение многие правительственные организации.

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

Данным термином также могут называть:

1. Сформированную ценностную систему внутри одной команды, когда речь идет о принципах организации работы, которых придерживается эта команда.
2. Совокупность различных гибких методологий, объединенных общими ценностями.

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

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

Возникновение идеи Agile обусловлено общей усталостью разработчиков от чрезмерной бюрократии и строгости. В какой-то момент пришло осознание, что создание инновационных продуктов по прежним методикам уже невозможно. И тогда, в 2001 году группа разработчиков мира в составе 17 человек собралась в штате Юта и приняла своего рода манифест, декларирующий принципиально новые правила разработки. Эти принципы и послужили основой современного подхода.

Сферы применения методологии

Изначально методология Agile формировалась специально под отрасль разработки ПО, игр и интерфейсов. В настоящее время она внедрена такими гигантами, как Google, Netflix, Microsoft, Spotify, Ericsson, Dell и Adobe. Подход успешно используется также мелкими стартапами и даже представителями других отраслей.

Скачать файл

Помимо IT данная методология нашла свое применение в организации труда небольших творческих и профессиональных групп, гармонично сочетаясь с либеральными методами менеджмента. Agile, в частности, внедрила одна крупная телекоммуникационная компания, что через 3 месяца привело к следующим результатам:

• продажи оборудования выросли на 45%;
• рекламные кампании стали запускаться в 2 раза быстрее;
• на 20% выросла плановая ежемесячная выручка от разработки продуктов;
• в секторе B2B количество успешных запусков рекламных кампаний увеличилось в 1,5 раза.

Банковская отрасль также активно внедряет похожие принципы управления. Это аналогичным образом отразилось на деятельности ЦБ. Так, проектный офис банка всего за год стал вдвое быстрее достигать поставленных результатов, повысил вовлеченность персонала, повысил прозрачность и управляемость внутренних изменений. Похожих результатов смогли добиться СберБанк и Райффайзенбанк.

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

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

Специалисты, которым будет полезно изучить Agile

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

• Разработчики ПО и веб-интерфейсов

На сегодняшний день практически все прогрессивные IT-компании внедрили в своей деятельности принципы Agile. Это позволяет специалистам легко включаться в любой проект, эффективно взаимодействуя с командой.

• Руководство компаний, менеджеры продуктов и проектов

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

• Стартаперы

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

Манифест, принципы и ценности Agile

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

• Удовлетворение клиентов. В процессе разработки продукта нужно в первую очередь удовлетворять запросы целевого клиента. Разработчики должны предлагать только качественное ПО и своевременно предоставлять обновление для него.
• Гибкость процесса разработки. Приветствуется изменение процессов создания продукта, если это наделяет продукт конкурентными преимуществами.
• Частое снабжение клиента программным обеспечением. Рабочее ПО доставляется покупателям с периодичностью раз в 2-16 недель.
• Совместная работа руководителей и разработчиков в течение всего проекта.
• Обязательная мотивация персонала. Чтобы мотивировать сотрудников к работе, руководству необходимо обеспечить им комфортные условия для этого, доверять им и оказывать необходимую поддержку.
• Личная беседа как наиболее оптимальный канал взаимодействия внутри команды
• Обязательная работоспособность продукта. Программное обеспечение должно безошибочно работать. Этот критерий прогресса более важен, чем трудозатраты, отработанные часы и т. д.
• Гибкость процессов как база для устойчивого развития. Благодаря обеспечению гибкости и изменчивости поддерживается заданный рабочий темп как в краткосрочной, так и в долгосрочной перспективе.
• Стремление к техническому и дизайнерскому совершенству при создании продукта.
• Минимизация лишних действий во избежание переусложнения рабочих процессов.
• Приоритет свободы управления перед микроменеджментом. Как известно, наибольший успех имеют продукты, которые разрабатываются командами с высоким уровнем самоорганизации.
• Обязательная регулярная оценка работы и своевременная корректировка поведения команды.

Из того, что провозглашает манифест Agile, можно выделить 4 ключевые ценности философии.

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

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

Разница между Agile и другими методологиями

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

Более правильно сравнивать данную философию с классическими подходами исходя из основополагающих принципов. В этом смысле уместно привести в качестве примера, например, Waterfall. Рассмотрим главные отличия от этой строгой методологии.

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

  

  Читайте также
• Каждый этап разработки завершается выпуском очередной версии продукта.При этом могут отсутствовать те или иные функции, которые появятся позднее.
• Перед началом нового цикла обязательно учитываются новые требования к продукту.
• Соблюдается гибкость сроков проекта, учитывающая запас на вероятные задержки и внесение изменений.
• Руководство компании принимает непосредственное и активное участие в разработке на протяжении всех этапах работы над проектом.

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

Плюсы и минусы Agile

Начнем с преимуществ.

• Обеспечивается максимальная гибкость процессов.

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

• Снижается вероятность провала.

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

• Практически исключается срыв сроков.

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

• Команда максимально вовлекается в работу.

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

• Персонал быстрее реагирует на возникающие проблемы.

При появлении в программе бага он оперативно устраняется в следующем цикле. Отпадает необходимость в полной переделке проекта и сдвига сроков из-за одной-единственной ошибки.

• Минимизируются рутинные действия.

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

А теперь перейдем к недостаткам.

• Отсутствуют четкая структура и план проекта.

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

• Требуется постоянное взаимодействие с клиентом.

Это необходимо, чтобы своевременно вносить правки и оценивать промежуточные результаты.

• Все процессы завязаны на команду.

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

• Компания слишком сфокусирована на деталях.

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

• Коллективу, работавшему по традиционной модели, вероятно, будет сложно переориентироваться на философию Agile.

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

Основные средства реализации подхода

Наибольшую популярность обрели две методики — Scrum и Kanban.

Scrum

Данный подход подразумевает работу команды, состоящей из узкоспециализированных работников (программистов, тестировщиков, аналитиков и т. д.), совместно с владельцем продукта и scrum-мастером (своего рода модератором). Роль владельца продукта состоит в сборе и формулировании бизнес-требований, в создании связи между исполнителями и клиентами, в общем мониторинге проекта.

Модератор (или scrum-мастер) отвечает за управление процессами компании в соответствии с идеями Agile. А именно, он организовывает командные встречи («митинги») и поддерживает мотивацию членов команды.

Методика Scrum подразумевает также деление всего рабочего процесса на так называемые спринты — равные по продолжительности периоды (по 1-4 недели каждый). Длительность спринтов определяется конкретным проектом и целями команды.

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

Kanban

Данный метод отличается от предыдущего отсутствием ролей владельца продукта и мастера. Также вместо универсальных спринтов здесь используются стадии выполнения задач. Условно весь процесс разделяется на этапы «Планирование», «Разработка», «Тестирование», «Завершено». Каждая стадия фиксируется на специальной канбан-доске, реальной или электронной.

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

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

На практике в последнее время элементы Scrum и Kanban комбинируются. Например, в современных системах управления типа Trello, Basecamp и Битрикс.24 обязательно используются канбан-доски. В тоже время это ПО работает на основе метода Scrum.

Определение целесообразности использования Agile

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

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

Высокая эффективность гибкого подхода возможна при условии:

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

Случаи, когда применение данного подхода нецелесообразно, рассмотрим ниже.

• Четко заданная цель проекта, изменение которой невозможно

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

Читайте также

• Изначальное планирование многократного повторения результатов проекта

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

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

• Принципиальный отказ заинтересованных лиц от внедрения гибкой методологии

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

• Неготовность внедрять гибкий подход самим исполнителем

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

Особенности применения Agile

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

Распределение ролей

Выделяют следующие роли:

1. Собственник продукта. Точно представляет себе цель создания продукта и потенциального потребителя этого продукта. При этом непосредственно в реализацию не вникает.
2. Координатор. Необходим для организации рабочего процесса и для координирования действий сотрудников.
3. Команда специалистов. Фактически разрабатывают продукт.

Иерархическая система

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

Пропускная способность процесса

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

Установка приоритета запланированных задач

Очередность выполнения задач устанавливается в зависимости от конкретной сферы деятельности.

1. Value Based. Задачи оценивают по прибыльности и пользе для бизнеса. Определяют их положительное влияние на репутацию компании и на решение проблем целевой аудитории.
2. Technology Risk Based. Оценивается величина технологических рисков, возникающих при выполнении задачи. Например, предъявляется слишком большое количество требований, оказывают сильное влияние внешние факторы и т. д.

График выполнения задач

Планирование проектов осуществляется с помощью специальных шаблонов. Например, приложение GanttPRO содержит шаблоны, позволяющие устанавливать задачи, строить удобные графики выполнения, выявлять проблемные места проекта.

Алгоритм внедрения Agile

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

• Выбор конкретной методики

Помимо упомянутых выше подходов Scrum и Kanban существуют другие методики. Прежде всего следует изучить каждую из них и сделать выбор в пользу наиболее подходящей для бизнеса.

• Подготовка команды

Следующим шагом необходимо добиться от сотрудников понимания и принятия новых принципов работы. Вероятно, персонал придется заранее обучить командной деятельности, а также привлечь специалистов со стороны — scrum-мастеров, менеджеров с опытом управления проектами.

• Организация рабочего процесса

Далее предстоит четкое распределение ролей в сформированной команде. Нужно будет определиться с наиболее подходящими инструментами для работы. К примеру, выбор сделан в пользу методики Kanban. Прежде всего нужно протестировать существующие сервисы для создания канбан-досок (Trello, Scrumban, Jira и т. п.), выбрать самый удобный из них и обучить команду работе в нем.

• Изучение аналитических инструментов

Анализ эффективности проводится также с использованием специального инструментария. К примеру, среди Scrum-показателей особое внимание стоит обратить на Focus Factor и Velocity. По первому параметру оценивается концентрация команды, определяемая как соотношение запланированных задач и выполненных в итоге. Показатель Velocity служит для определения производительности, позволяя прогнозировать объем задач в следующем цикле.

• Тестирование методологии на первом проекте

Получая первый опыт, команда адаптируется к новым условиям. В будущем, вероятно, что-то придется изменить и от чего-то отказаться. Руководителю необходимо помнить про гибкость данного подхода и не забывать постоянно взаимодействовать с командой, анализируя полученные результаты.

Оценка результативности

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

В частности, оценка может выполняться по следующим критериям:

• Обратная связь

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

• Достигнутые заказчиком цели

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

• Финансовые показатели

Бюджет и окупаемость проекта — одни из важнейших показателей, за которыми нужно постоянно следить.

• Мотивация команды

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

• Время, отведенное на разработку и выпуск продукта

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

Устранение возможных трудностей

После грамотного внедрения Agile команда начинает работать эффективнее, упрощается взаимодействие сотрудников. Однако такой радикальный переход на гибкую методологию может встретить сопротивление как со стороны руководства, так и со стороны персонала. Другими причинами отсутствия ожидаемого результата являются недостаточный опыт команды и нарушение последовательности внедрения нового подхода.

Устранению возникающих по началу препятствий помогут следующие советы:

• Понимание причины

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

Читайте также

• Повышение командного настроя

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

• Привлечение стороннего специалиста

Далеко не всегда требуется зачисление scrum-мастера в штат. В ряде случаев достаточно проконсультироваться у квалифицированного менеджера, имеющего богатый опыт в гибком управлении.

• Организация профессионального обучения

Зачастую персонал не обладает достаточными знаниями и навыками работы в условиях новой методологии. Закрывает эту проблему отправка сотрудников на онлайн-курсы.

Полезные книги по Agile

Существует множество книг, посвященных обсуждаемой философии. Здесь приведены наиболее удачные публикации, достойные прочтения.

• Дженнифер Грин, Эндрю Стиллмен «Постигая Agile»

Здесь не только подробно объясняются принципы Scrum и Kanban, но также приводится информация о двух других полезных методиках — XP и Lean. Читателю нужно лишь выбрать наиболее подходящий вариант. Полезно также использовать эти сведения для расширения кругозора.

• Стивен Деннинг «Эпоха Agile»

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

• Роб Коул, Эдвард Скотчер «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban»

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

• Стивен Деннинг «Эпоха Agile. Как умные компании меняются и достигают результатов»

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

• Джеф Сазерлен «Scrum. Революционный метод управления проектами»

Автор данного издания является и автором самого подхода Scrum. Поэтому книга будет особенно ценной для будущих scrum-мастеров, а также для всех, кто хочет активно внедрять этот инструмент в работе.

• Хенрик Книберг, Маттиас Скарин «Scrum и Kanban: выжимаем максимум»

Здесь сравниваются две популярные методики, описываются их плюсы и минусы, приводятся примеры внедрения.

• Майк Кон «Agile: Оценка и планирование проектов»

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

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

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

Согласно Agile-подходу, вся работа разделяется на короткие циклы — итерации. Во время каждой итерации осуществляется анализ требований, разработка и тестирование.  Это позволяет оперативно вносить корректировки в дальнейшую работу. 

Философия Agile ориентирована на самоорганизующиеся команды, сотрудничество и разделение ответственности за успех проекта между всеми участниками. И здесь возникают закономерные вопросы: А нужны ли в этом случае менеджеры проектов? Какую роль они играют в Agile-командах? 

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

‍

История Agile

При традиционном подходе каждый проект делится на пять этапов: инициация, планирование, выполнение, контроль и завершение. Команды последовательно переходят от одного этапа к другому. Особое внимание уделяется тщательной подготовке и подробной документации. Традиционный подход хорошо работает в таких проектах, где требования к конечному продукту заранее чётко прописаны и не ожидается большого количества изменений. 

Однако в 1990-х годах разработчики и ИТ-специалисты стали говорить о том, что такой метод замедляет их и затрудняет работу в условиях постоянно меняющихся требований или приоритетов. Было очевидно, что назрела необходимость в более гибком подходе.

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

Вот четыре фундаментальные ценности Agile-философии:

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

Как же именно эти принципы изменили управление проектами? 

‍

Каким образом осуществляется управление проектами в Agile?

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

Согласно 15-му отчёту State of Agile, среди наиболее веских причин для внедрения гибкого подхода участники опроса указывали следующее:

• Больше возможностей для управления меняющимися приоритетами.
• Сокращение времени на разработку программного обеспечения.
• Повышение производительности команды.
• Улучшение согласованности между бизнес-требованиями и ИТ-решениями.
• Повышение качества программного обеспечения.

Для реализации философии Agile команды могут использовать разные методы. Ниже приведен краткий обзор пяти популярных фреймворков.

‍

Scrum.

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

‍

Канбан.

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

‍

Экстремальное программирование или XP.

Экстремальное программирование основывается на традиционных методах разработки программного обеспечения, но выводит их на новый — экстремальный — уровень. Отсюда и название. В XP применяются такие практики как простое проектирование, парное программирование, постоянное тестирование, непрерывная интеграция, рефакторинг, стандарты оформления кода, частые небольшие релизы. Такой подход позволяет командам создавать программное обеспечение высокого качества и при этом быстро адаптироваться к изменяющимся требованиям. 

‍

Функционально-ориентированная разработка (FDD).

Фреймворк FDD разбивает проект на двухнедельные отрезки времени, в течение которых команда работает над определённой функцией продукта. Процесс разработки включает в себя пять видов деятельности: 

• Разработка общей модели
• Составление списка функций
• Планирование работы над каждой функцией
• Проектирование функции
• Реализация функции.

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

‍

Метод разработки динамических систем (DSDM)

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

Среди всех Agile-методологий самой популярной является Scrum. По данным отчёта State of Agile, по этому фреймворку работают 66% опрошенных и ещё 15% респондентов используют производные Scrum, такие как ScrumBan и Scrum/XP.   

Давайте подробнее рассмотрим основные принципы Scrum. 

‍

Scrum и Agile

Иногда термины Scrum и Agile используются как взаимозаменяемые. На самом деле, это два разных понятия. Agile — философия или образ мышления, который определяет подход к управлению проектами. Scrum, в свою очередь, это набор конкретных методов, которые позволяют работать над проектами согласно Agile-принципам. Этот фреймворк структурирован вокруг определенных практик и чётко прописанных ролей. Вот краткий обзор основных концепций:

‍

Scrum-команда. 

Фундаментальным компонентом в Scrum является кросс-функциональная, способная к самоорганизации команда. Она состоит из одного владельца продукта (Product Owner), одного Scrum-мастера и нескольких специалистов с различными навыками. Например, в Scrum-команду могут входить разработчики, тестировщики, дизайнеры и UX-специалисты. 

‍

Владелец продукта (Product Owner).

Владелец продукта отвечает за то, чтобы конечный продукт приносил максимальную пользу заказчику. Он анализирует требования, разъясняет бизнес-цели клиента команде и определяет приоритеты задач. 

‍

Scrum-мастер.

Scrum-мастер следит за соблюдением принципов Scrum. Он руководит командой, оптимизирует рабочие процессы, устраняет отвлекающие факторы и организует регулярные совещания.  

‍

Спринты.

Спринты — это повторяющиеся этапы, обычно продолжительностью от одной до четырех недель, во время которых команда работает над определенными задачами. На каждом из таких этап проводится планирование спринта, ежедневные Scrum-совещания, обзор итогов спринта и ретроспективы спринта.    

‍

Бэклоги продукта и спринта.

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

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

‍

Обязанности проджект-менеджеров в Аgile-проектах. 

Существует две противоположные точки зрения на то, нужен ли менеджер проекта компаниям, где внедряется гибкий подход к разработке:

• Одни эксперты отмечают, что роль традиционных проджект-менеджеров заключается в контроле над работой команды, управлении задачами и детальном планировании. Однако Agile-команды самостоятельно планируют работу, распределяют задачи и отслеживают прогресс. Зачем же им тогда менеджер проектов?  
• Другие указывают на то, что даже Agile-проектам нужен специалист, который будет отвечать за составление бюджета, управление рисками и распределение ресурсов. Другими словами, этим проектам нужен проджект-менеджер. 

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

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

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

‍

Ключевые навыки руководителя Agile-проектов.

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

‍

Коммуникационные навыки. 

В Аgile-философии главные акцент делается на совместной работе, поэтому умение эффективно общаться крайне важно для всех членов команды, в том числе и для менеджеров проектов. 

‍

Организационные навыки. 

Менеджеры Agile-проектов должны обладать хорошими организационными навыками и уметь расстанавливать приоритеты. 

‍

Способность управлять рисками. 

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

‍

Адаптивность. 

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

Что касается технических навыков, то от проджект-менеджеров ожидается глубокое понимание принципов Agile, знание Agile-фреймворков (Scrum, Kanban и т.д.) и опыт работы с инструментами для управления задачами (Trello, JIRA и т.п.).

‍

Ресурсы для менеджеров Agile-проектов.

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

• На сайте AgileAlliance есть обширный раздел со статьями, видео и презентациями. 
• Project Management Institute предлагает публикации и руководства по различным подходам к управлению проектами, включая Agile. 
• Множество статей, видеоматериалов и тематических исследований для изучения концепции Scrum можно найти на сайте ScrumAlliance.
• На платформе LeadingAgile есть статьи, подкасты и видеоролики по различным аспектам управления Agile-проектами.
• На сайте Scrum.org есть отличная подборка статей и видео по темам, связанным со Scrum. 
• ‍

Курсы по управлению Agile-проектами. 

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

• edX
• PMI
• Coursera
• LinkedIn Learning
• Scrum.org
• ScrumAlliance

Сертификаты для менеджеров Agile-проектов.

Специалисты в области управления Agile-проектами могут подтвердить свои экспертные знания, получив один из сертификатов: 

• PMI Agile Certified Practitioner (PMI-ACP). Этот сертификат выдаёт Институт управления проектами. Он подтверждает знание основных принципов Agile и различных Agile-фреймворков, таких как Scrum, Kanban, Lean, экстремальное программирование (XP) или разработка на основе тестирования (TDD).
• Certified Scrum Master (CSM) от ScrumAlliance — это всемирно признанный сертификат, который демонстрирует глубокое понимание Scrum-подхода и умение применять его на практике. 
• Международная ассоциация менеджеров проектов (International Association of Project Managers) предлагает три уровня сертификации в области Agile: Certified Junior Agile Project Manager (IAPM), Certified Agile Project Manager (IAPM) и Certified Senior Agile Project Manager (IAPM).
• ICP Certified Professional — это сертификат, который выдаёт Международный Agile-консорциум (International Consortium for Agile). Программа не ориентируется на конкретную методологию, а фокусируется на основополагающих концепциях Agile-философии.
• Широко признаваемый в отрасли сертификат Professional Scrum Master I выдаёт Scrum.org. Его наличие подтверждает экспертное знание основополагающих принципов фреймворка Scrum и способность применять в управлении проектами. 

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

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

‍

Запись на курс Manual QA

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

Давайте разберемся, что такое методика Agile, кому она поможет в непростое время и как её использовать на примере маркетинга.

Что такое Agile?

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

Немного истории

Понятие Agile как свод принципов появилось в 2001 году в США, штат Юта. Команда разработчиков занималась развитием и внедрением разных методик для роста эффективности работы, например, Каскадной модели и Экстремального программирования. Эти программисты объединили правила реакции на изменения условий и выработали манифест Agile, а затем создали некоммерческую организацию Agile Alliance, цель которой – продвигать и внедрять «гибкие» технологии управления процессами.

Манифест Agile: 4 основных принципа

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

Раскроем каждый принцип подробнее.

Принцип 1. Коммуникация важнее инструментов и процессов

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

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

На отношениях вовне этот принцип реализуется через ориентированность на человека в создании продукта: в центре всех процессов стоят потребности аудитории.

Принцип 2. Работающий продукт важнее документации

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

Принцип 3. Диалог с заказчиком важнее договоров

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

Принцип 4. Изменения и адаптация важнее следования плану

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

Чем полезна методика Agile для компаний

Отделы или целые компании внедряют принципы Эджайл, чтобы быстро реагировать на изменения внешней и внутренней сред. Строгое следование плану (особенно на длинных временных отрезках) сковывает инициативу сотрудников на местах, которые погружены в текущие дела глубже, чем руководство. А ведь они могли бы предложить более эффективные решения, так как находятся «ближе к земле». Agile позволяет команде адекватно реагировать на трансформацию условий, учитывать в планировании переменные и достигать целей, не смотря на неожиданности и кризисы.

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

Agile на практике

✔ Цикл работы

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

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

✔ Спринты

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

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

По итогам руководитель или заказчик изучает результаты спринта и, при необходимости, вносит корректировки в план.

✔ Минимально жизнеспособный, или МЖП

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

5 признаков, что внедрение Agile прошло успешно

❌ Кому противопоказана гибкая система Agile

Вы можете применять принципы манифеста Agile или просто руководствоваться его философией, если:

Вам точно не подойдет и даже будет вреден гибкий подход, если:

Как применять Agile в маркетинге

Все изменения – это проверка бизнеса на прочность и гибкость. Без корректировок смогут выстоять огромные, мощные компании, которые компенсируют неповоротливость системы гигантскими бюджетами. Если это не ваш вариант, становитесь быстрыми, гибкими, адаптивными, чуткими ко всем изменениям. В этом помогут принципы Agile.