Методология Agile

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

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

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

• возникновение идеи;
• формирование технического задания;
• создание дизайн-проекта;
• процесс программирования;
• прохождение тестирования;
• запуск окончательной версии.

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

Читайте также: Оффлайн-реклама

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

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

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

Для систематизации и объединения в одно целое всех подходов к управлению проектами (а их на тот момент насчитывалось больше десяти) разработчики, внедрившие разные «гибкие методы», собрались вместе – всего 17 человек.

Это произошло в феврале 2001 года в горном местечке Сноубёрд (США). Участники встречи согласились, что, несмотря на разное видение самого процесса разработки продуктов, у каждого из них четко просматривается идея о том, что процесс этот непременно должен быть гибким. Считается, что именно на том собрании и было положено начало методологии Аgile, которую нередко считают философией.

Читайте также: Акции для привлечения клиентов

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

Философия и принципы Agile-методологии

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

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

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

• удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения – это один из приоритетов;
• как можно более частая поставка отлаженного программного обеспечения (ежемесячно, еженедельно или даже чаще);
• действующий продукт – основной маркер прогресса;

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

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

Читайте также: Удаленные сотрудники

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

1. Наглядный контроль. По ходу работы над проектом все его участники пользуются разноцветными карточками нескольких разновидностей, каждая из которых – это своеобразный знак, показывающий стадии готовности элементов конечного продукта (что разработано, что спланировано, что завершено и т. д.). Благодаря таким сигналам команда всегда видит реальную ситуацию по продвижению проекта. Причем с помощью данного контроля обеспечивается одинаковая для восприятия всеми участниками общая «картина».
2. Все задействованные в проекте лица, в том числе клиент, трудятся рядом. Такой принцип, во-первых, позволяет ускорить рабочие процессы (например, связанные с донесением информации до каждого участника общего дела), во-вторых, создает хорошие предпосылки для сотрудничества и продуктивной деятельности.
3. Адаптируемое управление. Тот, кто стоит во главе проекта, не просто человек, номинально спускающий директивы, а реальный лидер, который определяет ключевые правила выполнения работы и взаимодействия.
4. Работа в команде. Руководитель, участники проекта и заказчик действуют совместно – благодаря этому исключается возможность искажения информации и непонимания целей. Все рабочие процессы отличаются прозрачностью, что позволяет нивелировать возникающие проблемы и принимать оптимальные решения.
5. Дробление общего объема работы на несколько отдельных частей. Такой подход к делу существенно упрощает задачи проекта, давая возможность членам команды сконцентрировать усилия на каждой составляющей.
6. Работа над ошибками. В процессе одного цикла участники команды овладевают новыми навыками и проводят тщательный анализ случившихся ошибок – это помогает исключить их в следующем цикле.
7. Спринты и кратковременные встречи каждый день. Спринты (временные отрезки, в течение которых команда решает круг задач) дают возможность отчетливо наблюдать за результатами. Если разбить период работы над проектом на спринты, можно получить, к примеру, 10 спринтов продолжительностью две недели каждый. А лучше спланировать индивидуальный план помогут регулярные ежедневные встречи минут на 10–15, чтобы каждый участник команды мог сам себе дать ответ на 3 вопроса: чем я занимался вчера, что буду делать сегодня и что мне не дает выполнять работу?

Итак, чтобы внедрить гибкий метод Agile, должны быть соблюдены условия:

• четкая формулировка значения проекта;
• активное участие в проекте клиента на протяжении всего срока реализации;
• возможность поэтапного исполнения общего объема проекта;
• больший акцент на реальных результатах действий, чем на документации;
• формирование рабочей группы численностью 7–9 человек, не больше.

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

Какие преимущества дает компании работа по методологии Agile

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

1. Обычный хлебозавод в России

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

Читайте также: Теория разбитых окон

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

2. Agile-хлебозавод в России

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

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

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

Может сложиться впечатление, что варианты Аgile-методологий – разработки исключительно для организаций IT-сферы. Но мнение ошибочно. В России принципы гибкого управления используются такими компаниями, как:

• «Альфа-банк»;
•  «Додо пицца»;
• бухгалтерский сервис «Кнопка».

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

Читайте также: Методика тренировки памяти

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

• использование гибких подходов позволяет повысить качество получаемых результатов;
• желаемые цели достигаются намного быстрее и с большим эффектом, это экономит время и ресурсы;
• у компании развивается способность хорошо адаптироваться к переменам (в том числе неожиданным) и конкурентным условиям;
• создаваемые проекты более тщательно планируются и контролируются;
• компания способна выдавать продукты, по-настоящему ожидаемые и востребованные покупателями.

Недостатки методологии Agile

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

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

Надо сказать, что заказчик изначально осознает, чем это чревато, и самостоятельно принимает решение о целесообразности платы за разработку – команда исполнителей только воплощает желания клиента. К чему это приводит? К полной неразберихе, нарушению дедлайнов и авралам, в результате возникают новые претензии, из-за которых продукт изменяется явно не к лучшему. Однозначно страдает качество разработки, потому что в Аgile действует подход: «пожары» надо тушить быстро простыми подручными способами.

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

Читайте также: Внедрение KPI

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

4 мифа про применение методологии Agile

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

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

Спустя 15 минут генеральный, закричав, что демократия закончилась и вернулась диктатура, приступил к раздаче распоряжений, а подчиненные начали старательно записывать их. Изумленный японский гость только и сумел произнести: «Какое же это agile-управление проектами? В Японии каждый рабочий завода может остановить конвейер и внести свои коррективы, не говоря уже об идеях на планерках…» На что получил ответ директора: «Да, это не принципы эджайл! Это Россия, здесь такие гибкие методы не действуют!»

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

Миф № 1: Методология Agile применима для всех проектов

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

Миф № 2: Методология Agile не приемлет ведения документации

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

Миф № 3: Методология Agile и планирование несовместимы

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

Читайте также: Обучение генерального директора

Миф № 4: При внедрении методологии Agile требуется много переделывания (re-work)

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

Часто задаваемые вопросы про методологию Agile

1. Подходит ли Agile малому бизнесу?

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

2. Легко ли внедрить методологию Agile?

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

3. Изменятся ли бизнес-процессы в компании после внедрения гибкой методологии управления?

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

4. Как станут работать люди?

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

Читайте также: Как преодолеть застенчивость

5. Кто должен быть начальником?

Как это ни странно прозвучит, но аgile-компании обходятся без начальников. Руководством занимаются, как правило, кураторы-помощники – они собирают людей в объединенные команды для достижения более успешных результатов.

Краткое описание основных методологий Agile: Scrum, Kanban, Lean

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

 SCRUM

Методология Scrum представляет собой такое управление, где основной акцент делают на качестве контроля за ходом работы. Первыми теоретиками, описавшими данный принцип, были Хиротака Такэути и Икудзиро Нонака. Они сравнили Scrum с регби, назвав его борьбой за мяч.

Еще один исследователь, Джефф Сазерленд, написавший книгу «Scrum. Революционный метод управления проектами», выделяет 8 шагов, которые помогут освоить и использовать данную методику:

1. Выбрать того, кто владеет продуктом, – ему известна цель проекта и ожидаемый результат.
2. Собрать команду – нужно около 10 человек, обладающих навыками, которые требуются для создания конкурентного продукта.
3. Найти скрам-мастера – он будет следить за рабочим процессом и помогать команде проекта преодолевать трудности.
4. Составить бэклог продукта – разместить на Agile-доске приоритеты по каждому из требований к продукту. Здесь большая роль отводится владельцу продукта: он должен собрать все пожелания, чтобы команда оценила бэклог.
5. Запланировать спринты (итерации) – определить временные отрезки, которые отводятся для выполнения конкретных задач.
6. Организовать ежедневные «мит-апы» продолжительностью 15 минут – для опроса каждого участника команды по трем пунктам: что делал вчера, чем занимается сегодня и что мешает выполнению задачи.
7. Делать обзоры рабочих частей продукта – к просмотру и обсуждению должны быть привлечены стейкхолдеры.
8. Проводить ретроспективу – обсуждать проблему и поиск путей решения по окончании каждого спринта. План с полученными коррективами реализуется на следующем спринте.

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

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

Как правило, проектные методологии управления Аgile и Scrum применяют для разработки сложных ПО и продукта с использованием итеративных и инкрементных методов.

Благодаря методике Scrum существенно возрастает производительность и сокращается время по сравнению с классическими процессами waterfall. Практикуя процессы Scrum, организации имеют возможность плавной адаптации к меняющимся требованиям, они могут делать продукт, который отвечает динамичным бизнес-целям. С помощью Scrum:

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

Читайте также: Эффективный тайм менеджмент

Lean

Agile настоятельно рекомендует дробить управляемые пакеты работ на части, но конкретных указаний, касающихся управления разработкой этого пакета, не дает. От Scrum можно взять процессы и процедуры. Тогда как Lean дополняет принципы Agile схемой потока операций (workflow) – чтобы каждая итерация могла выполняться на высоком качественном уровне.

Подобно Scrum, Lean тоже применяет разбивку работы на пакеты поставки, которые реализуются автономно и независимо. Разница в том, что в Lean под разработку каждого пакета поставки предусмотрен поток операций с этапами, похожими на те, которые создавались в рамках проекта «Аполлон». Эти этапы могут быть такими, как в традиционном проектном менеджменте:

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

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

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

Сильные стороны Lean

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

Слабые стороны Lean

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

Читайте также: Методы личной эффективности

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

Kanban

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

В основе метода Kanban лежат три принципа:

1. Визуализация задач: благодаря наглядности всех сведений о проекте можно увидеть недостатки, промахи и неточности.
2. Контроль и ограничение WIP (работы, выполняемой одновременно, англ.: work in progress): это дает возможность балансировки подхода, основанного на потоках, – команды не должны брать чересчур много работы и выполнять больше, чем нужно.
3. Контроль времени на решение задачи и оптимизация работы для сокращения сроков.

«6 сигм» (Six Sigma)

Так же, как и «Тойота», свою лепту в развитие мирового проектного управления внесла компания «Моторола». Один из ее инженеров, Bill Smith, разработал в 1986 году концепцию «6 сигм». Она представляет собой более структурированную, чем Kanban, версию Lean, куда вошло дополнительно больше планирования для экономии ресурсов, повышения качества, уменьшения бракованного материала и разного рода проблем.

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

Для этого предлагается путь, включающий 5 шагов, известных как DMEDI:

Шаг 1. Определение (Define). Начальный этап очень схож с ранними этапами других систем проектного управления. Здесь определяются с содержанием проекта, аккумулируют информацию о его предвестниках, задают цели.

Шаг 2. Измерение (Measure). Six Sigma направлена на сбор и анализ качественных сведений о проекте. На этом этапе решают, от каких показателей будет зависеть успех дела и какую информацию потребуется собрать и оценить.

Читайте также: KPI директора: как правильно формировать

Шаг 3. Исследование (Explore). На этапе исследования менеджер проекта должен решить, каким путем команда придет к поставленным целям и удовлетворит все требования в срок, придерживаясь бюджетных рамок. Особую ценность здесь имеет нешаблонное мышление руководителя проектов, когда требуется разрешить возникшие проблемы.

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

Шаг 5. Контроль (Control). Это главный этап в методологии Six Sigma. Ключевая задача – долгосрочное улучшение процессов реализации проектов. На данном шаге требуется тщательно документировать все усвоенные уроки, анализировать собранные сведения и уметь грамотно воспользоваться приобретенными знаниями как в проектах, так и вообще в компании.

Six Sigma и Kanban сильно похожи, если рассматривать их с установленными этапами реализации задач (планирование, определение целей, тестирование качества). Скорее всего, при использовании «6 сигм» команде придется встречаться чаще, чем при «Канбан», но процесс реализации проектов однозначно будет отличаться большей структурированностью, а участникам труднее будет сбиться с намеченного пути. К тому же «6 сигм», как «Канбан», несложно адаптировать под нужды конкретной компании или команды. Единственное категоричное требование – скрупулезно измерять и контролировать показатели проекта на этапах реализации, без этого планомерное долгосрочное улучшение процессов реализации немыслимо.

Сильные стороны «6 сигм»

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

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

Слабые стороны «6 сигм»

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

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

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

1. eXtreme Programming (XP)

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

Читайте также: Как правильно ставить цели

Сфера применения – исключительно разработка ПО. Внимание сфокусировано на 4 процессах:

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

2. Crystal Methodologies

Представленное семейство методологий нельзя назвать широко распространенным на просторах проектного менеджмента России. Автор методики – Алистер Кокберн, который создал «Манифест гибкой разработки ПО». Предлагаемая Кокберном классификация – по цветам в зависимости от количества участников команды: от 2 (Crystal Clear) до 100 (Crystal Red). Для более масштабных проектов предусмотрены цвета Maroon, Blue и Violet.

3 основных показателя, каким должны отвечать Crystal-проекты:

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

Все детали, касающиеся данного семейства методологий, можно рассмотреть в книге Алистера «Crystal Clear: A Human-Powered Methodology for Small Teams».

3. Dynamic Software Development Method (DSDM)

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

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

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

DSDM делят на версии, обновление которых происходит с развитием технологий, появлением новых требований к ПО. Последняя версия вышла в 2007 году, это DSDM Atern, хотя и ее предшественница, 2003 года, еще работает.

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

• цикл функциональной модели (создается аналитическая документация и прототипы);
• цикл проектирования и конструирования (систему приводят в рабочее состояние);
• цикл реализации (идет развертывание системы).

4. Feature Driven Development (FDD)

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

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

Читайте также: Маркетолог в компании

Feature Driven Development включает цикличные этапы:

• создание единой модели (проект визуализируется на основе предварительных данных);
• разработка списка свойств (нечто похожее на product backlog из методики Scrum);
• технический дизайн и реализация по каждому свойству (финишный этап, в конце которого свойство уходит в продукт, и все повторяется).

5. Lean Software Development

Точнее было бы сказать о Lean Software Development не методология, а принципы бережливого производства – они нацелены повысить эффективность процесса разработки и сократить затраты. В совокупности их 7:

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

Как определить эффективность той или иной методологии управления Agile применительно к вашей компании

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

Большинство проектов может обойтись следующими направлениями метрик:

1. Производительность – сюда подойдут Velocity и WIP (первая применима не для любых проектов, потому что измеряет, сколько выполнено задач в итерацию, а они неравнозначны, метрикой Work-in-Progress определяют лимит задач на разных стадиях: чем выше, тем хуже).
2. Прогнозирование – метрика Сapacity (определяется количество идеальных часов, доступных в следующем спринте, благодаря чему можно понять: какое время отводится для работы, насколько эффективно выполняются задачи, как спланировать их количество для спринта).
3. Качество – к примеру, индекс стабильности требований (его можно рассчитать по формуле: {Общее количество оригинальных бизнес-требований + Число требований, которые изменились к данному времени + Число добавленных требований + Число удаленных требований} / {Общее число оригинальных требований}; метрика помогает вычислить время, потраченное на переделывание задач).
4. Ценности – просчитываются индивидуально в каждом случае и зависят от формата проекта (скажем, для стартапа AirBnb метрикой, определяющей ценность продукта для пользователей, стал объем загруженных фото высокого качества – с его увеличением пропорционально росло число потребителей).

Метрики подчиняются тем же правилам, что и другие инструменты в Agile.

Читайте также: Как рассчитать ROI

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

Особенности внедрения методологии Agile

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

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

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

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

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

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

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

Читайте также: Что такое Upsell, или как научиться продавать больше

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

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

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

Вместо планирования запускается первый поток agile-команд, осуществляется анализ их работы для следующего шага. Это способствует объективной оценке:

• эффективности команд – с точки зрения финансовых характеристик и производительности труда сотрудников;
• издержек – акцент на финансовые вложения и организационные проблемы.

Если налицо выгода, дают старт следующей волне гибких команд, в противном случае проводится анализ: как сделать работу более продуктивной (например, по-другому расставить приоритеты, повысить качество прототипов или пригласить опытных специалистов по Аgile).

Руководители должны определять приоритеты и последовательность работ с учетом таких критериев, как:

• стратегическое значение,
• рамки бюджета;
• издержки;
• риски и т. д.

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

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

Читайте также: Как увеличить конверсию сайта

На смену им пришли agile-отряды: примерно 40 процентам сотрудников предстояло вступить на новые рабочие места, кардинально изменив свое мышление (подробнее: «One Bank’s Agile Team Experiment» HBR, March–April 2018).

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

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

По мнению Джеффа Безоса, основателя и главы Amazon, на полную отдачу уходит от 5 до 7 лет, но маркеры позитивных перемен появляются быстро: работа с клиентами упрощается, продукция выпускается быстрее.

Компания SAP (специализация – корпоративное ПО) приступила к внедрению Agile 10 лет назад. Топ-менеджеры сформировали немногочисленную группу, она занималась консультациями и обучением новым способам деятельности. Создали также трекер результатов команд.

Благодаря демонстрации рабочих достижений и успехов поддерживалась мотивация. Спустя какое-то время 80 % компании уже работало по Agile. Специалисты в секторе продаж и маркетинга тоже испытывали потребность подстраиваться под новые условия и не отставать от передовых тенденций.

Чек-лист, который поможет понять, что команде пора переходить на Agile:

1. Внимание сфокусировано на основных возможностях бизнеса.
2. Есть осознанная ответственность сотрудников за конкретные результаты.
3. Работники, обладая определенными правами на принятие решений, ориентированы на самостоятельность в деятельности.
4. Обеспечено наличие ресурсов и многопрофильных экспертов для сотрудников.
5. Команда разделяет принципы методологии.
6. Сотрудники владеют навыками быстрого создания прототипов и обратной связи.
7. У сотрудников выработана ориентация на поддержку наставников, которые стимулируют работу команды.

С какими трудностями придется столкнуться при внедрении Agile и гибких методологий работы

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

1. Эджайл – не инструмент

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

Читайте также: Анализ потенциальных клиентов

2. Команда

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

3. Свой нос в чужие дела

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

4. Оплата

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

5. Текучка

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