Технологии agile: Гибкая методология разработки — Википедия – преимущества, пути внедрения и подводные камни

Содержание

Как рассказать что такое Agile на заводе? Топ 5 самых популярных Agile-практик

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 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 / Habr

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

Несмотря на то, что Agile появился около 20 лет назад, более-менее активно применять его начали только в течение последних восьми лет. Гибкие принципы возникли как альтернатива традиционным методам разработки с целью уменьшения затрат на производство ПО, готового для отправки заказчику (potentially shippable software), за счёт повышения эффективности совместной работы и клиентоориентированности. То есть набор принципов формировался под решение задач бизнеса – для ускорения процесса разработки и достижения максимального результата от команды без увеличения затрат на производство.
Да, гибкая методология позволяет выжать из команды максимальный КПД, но есть два нюанса, которые при сложившихся обстоятельствах снижают Agile-эффект. Во-первых, принципы действительно работают только в небольших командах. Кроме того, если в команде все специалисты очень сильные, то совершенно не факт, что получится существенно увеличить их производительность.

Как это работает?

Сегодняшний процесс разработки можно разделить на три этапа: написание кода, подготовка его к запуску и продакшен.

Традиционно целью Agile был первый этап разработки – написание кода. В конце далёких 90-х именно этот этап рассматривался как требующий улучшения и серьёзных изменений. Тогда же получила известность одна из наиболее распространённых имплементаций Agile — Scrum. Справедливости ради стоит отметить, что Scrum вышел в свет в 1986 году, за 15 лет до того, как был адаптирован для Agile в 2001 году.

Scrum приносит выборку того, что нужно писать, позволяет отследить процесс разработки, выявить недостачи и противоречия на начальных этапах. Без технического задания программист не знает, какой именно продукт должен получиться в результате. Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным. Другое дело, например, система биллингa. Программист не знает того огромного количества нюансов, которые необходимо учесть для корректной работы сервиса как регуляционных, так и маркетинговых, как, например, различные модели расчётных операций.

Пионерами Agile были маленькие компании, которые не боялись применять передовые технологии – им нечего было ещё терять! По понятным причинам написание кода в подобных организациях составляет основную часть процесса (процессы подготовки и запуска практически отсутствуют). Эффект был потрясающий! Однако через несколько лет применения традиционного Agile в более развитых организациях стали замечать, что проблемы, связанные с сокращением выпуска на рынок новых продуктов, не исчезли. Agile передвинул затор на следующий этап – на подготовку нового продукта к выпуску. Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.

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

Например, в июле 2015 после очередного обновления ПО были остановлены торги на Нью-Йоркской фондовой бирже. Этот сбой сотряс мировую экономику, в частности, снизил на 1% фондовый индекс США на весь день, а также затормозил переговоры Греции с ее кредиторами на целую неделю! Ещё один яркий пример – обновление системы продажи авиабилетов в компании «Дельта». После выпуска нового ПО в продакшен информация вообще перестала поступать в диспетчерскую службу. В результате авиакомпания отменила все рейсы и понесла существенные финансовые и репутационные потери. Несомненно, в обоих случаях многие проверки перед запуском были пройдены и, тем не менее, ещё многие были бы сделаны, если бы занимали меньше ресурсов и времени.

Пробел с обеспечением качества кода сегодня очень актуален и он будет постепенно заполняться. По оценкам Gartner, в ближайшие три года по крайней мере 75% IT–корпораций будут вынуждены развить автоматическое тестирование, интегрирующее бизнес-процессы. Определенные надежды на решение проблемы качества возлагаются на такие технологии и методологии, как контейнеры и BDD (behavior driven development) – Docker, Cucumber и прочие.

У кого это работает?

На сегодняшний момент принципы Agile имплементированы в большинстве компаний, где это было возможно сделать без особых рисков для бизнеса. И все, кто смог выстроить новые процессы, в целом довольны результатами, например: Google, Zara, Ikea. Однако стоит обратить внимание, что эти компании действуют по принципу «разделяй и властвуй» — то есть работа разделена на проекты, которыми занимаются относительно небольшие самостоятельные команды. Кроме того, по Agile в этих компаниях работает в первую очередь бизнес-подразделение (особенно это касается Zara и Ikea), а не только отдел разработки. Они изменили не только организацию процесса, но и бизнес, поэтому естественным образом соответствуют Agile-модели.

Но есть часть компаний, где полноценно адаптировать гибкие методологии пока не удаётся – результатов либо нет вообще, либо они не соответствуют ожиданиям бизнеса. Например, ING и Citibank считаются самыми продвинутыми в банковской сфере по части адаптации Agile. Однако далеко не все отделы этих финансовых гигантов работают по гибким методологиям. На Agile перешли, в основном, те подразделения, которые занимаются поверхностными оболочками, мобильными приложениями или другими передовыми разработками. Иными словами, отделы, не связанные с основными бизнес-процессами, сбой которых может поставить под удар годовые доходы и привести к краху всей корпорации.

То есть в тех областях, где цена ошибки очень высока, компании пока опасаются что-то менять. Да, они понимают, что Waterfall себя изжил и, работая по-старому, можно в какой-то момент остаться далеко позади от конкурентов и всё потерять. Они бы и рады перейти на новые методы работы, но пока риски гораздо выше, чем потенциальная выгода от нововведений. Кроме того, зачастую необходимы большие вложения, чтобы перевести бизнес на гибкие методологии и далеко не факт, что всё сразу заработает хорошо. Это касается в первую очередь тех компаний, где большинство бизнес-процессов построено на ПО, написанном десятки лет назад на языках программирования, не столь модулярных, как Java, Scala, GO и пр.

Но те компании, которые пытались внедрить Agile и не получили ожидаемых результатов, всё больше и больше проявляют недовольство. Им обещали, что после имплементации гибкой методологии КПД увеличится, а time-to-market и вместе с ним затраты на производство сократятся. Однако ожидаемого эффекта не возникает, так как код выходит быстрее и всё больше и больше проблем появляется на продвинутых этапах разработки. КПД в некоторых случаях повышается, однако заметного сокращения затрат не происходит. Но чаще всего случаются откаты из продакшена, которые бьют по времени достижения целей, бьют по time-to-market и стоят очень дорого, так как исправление багов в продакшене требует гораздо больших затрат ресурсов разработчиков. Цена ошибки возрастает не только из-за позднего обнаружения, но и из-за высокой скорости разработки. Этот эффект можно сравнить с турбулентностью в потоках, когда скорость потока превышает максимально допустимую для данной среды.

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

Как повысить эффективность?

Облака очень активно развивались в последнее десятилетие и частично открыли шлюзы для проведения тестирования в больших масштабах. Однако проблема полностью не была решена – несмотря на все преимущества, облачные технологии относительно дороги. Кроме того, не всегда просто построить необходимые среды проверок в cloud. Сегодня, в среднем, каждому разработчику необходимо 10 сред — таким образом цена среды может сравниться с бюджетом оплаты труда самого разработчика.

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

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

На чем стоит и куда движется Agile

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

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

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

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

1. Появление возможности для запуска бизнес-тестов без особых затрат,

2. сдвиг интегрального и бизнес-тестирования как можно ближе к источнику изменений.

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

Когда наступит «золотой век» Agile?

С начала своего существования Agile перевоплотился из набора принципов в ассортимент методологий, процессов и даже стандартов. Сегодня поле деятельности этих методологий не ограничено командами разработчиков. Гибкие процессы успешно внедряются практически во все отделы IT и даже бизнес руководствуется стандартами Agile. Среди наиболее известных можно отметить Scrum, Scrumban, SAFe, ScaleAgile@Spotify, Continuous Delivery, Lean, Prince2 Agile и многие другие.

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

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

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

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

методология, команда, оценка эффективности — статьи на Skillbox

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

Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

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

Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это — как в знаменитой мотивирующей формуле «сделано — это лучше, чем идеально». Реализуйте первую функцию и начните тестировать ее, создавая следующую, и так раз за разом — вот главное правило.

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

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

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

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

Еще одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.

Важно!

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

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

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

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

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

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

Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается «Манифест гибкой разработки»:

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы, вы сможете, пройдя курс «Управление digital-проектами» от Skillbox.

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

Живая обратная связь с преподавателями
Неограниченный доступ к материалам курса
Стажировка в компаниях-партнёрах
Дипломный проект от реального заказчика
Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Лучшие приемы и практики Agile для технических и нетехнических команд

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

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

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

С 2001 года Agile-принципы оформили в знаменитый манифест Agile, а сама методология стала стандартным процессом разработки ПО.

Каковы ключевые практики Agile сделали методологию столь известной и востребованной?

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

Список лучших практик Agile

Очередь задач

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

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

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

В управлении бэклогом определяющую роль играет собрание backlog grooming, во время которого представители Agile команды обсуждают детали бэклога продукта и готовят очередное планирование спринта.

Итерации

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

Клиентоориентированность

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

User stories

В Agile описывается функциональность по общению с клиентами, а затем с позиции продукта определенным образом (помните формулу “Я как , хочу , потому что ”?). История пользователей в Agile project management означает единицу работы, которая должна быть завершена в одном спринте.

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

Agile-роли

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

Team Lead, Project Lead и Скрам мастера

Членов команды

Собственника продукта для Scrum и On-site customer для XP

Заинтересованные стороны (stakeholders)

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

Value stream analysis

Анализ потока ценностей — это метод управления для анализа текущего состояния и разработки будущего состояния продукта. Цель анализа в том, чтобы идентифицировать и удалять «отходы» в потоках создания ценности, тем самым повышая эффективность потока данных.

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

Timeboxing

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

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

Ежедневные собрания

Например, Scrum meeting — это ежедневное мероприятие, короткая утренняя или дневная встреча, обычно организованная менеджером продукта или владельцем продукта. Длится 10-15 минут и требует присутствия Скрам-мастера и всей команды. Такая встреча организуется, чтобы:

вспомнить, что было сделано вчера

определить, что будет сделано сегодня

выявить любые препятствия, если такие есть

Sprint demo meeting

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

Retrospective meeting

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

Тестирование

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

Burndown chart

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

Приоритизация требований

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

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

Планирование релиза

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

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

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

Этот список можно продолжать и дополнять другими интересными практиками. Однако какие же практики могут быть использованы нетехникеской командой?

Яркий пример — использование бэклога и приоритизация задач командой авиатранспортной компании Air Methods, которая специализируется на оказании скорой помощи.

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

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

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

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

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

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

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

Как использовать Agile и Scrum для управления проектами — руководства на Skillbox

запись вебинара

1ч. 40 мин.

статья

10 мин.

Экономия времени

1ч. 30 мин.

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

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

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

Плюсы методологии:

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

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.

Минус водопадной схемы — процессы идут друг за другом. Это замедляет разработку

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

Удобно вести бэклог задач в Trello или Excel.

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

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

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

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

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

Так выглядит бэклог со спринтами.

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

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

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

Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.

Команда разработки

Люди, которые непосредственно создают и тестируют код.

К разработчикам есть несколько требований:

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

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

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Так выглядит диаграмма сгорания в реальных проектах.

Контролируйте работу команды с помощью двух scrum-показателей:

Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

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

В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:

Что сделано вчера?
Что будет сделано сегодня?
Какие есть проблемы и препятствия для выполнения задач?

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.

Попробуйте такой шаблон для ретроспективы.

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

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

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

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

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

Trello — подходит для маленьких проектов, быстро и удобно.
Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

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

Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.

Курс «Руководитель digital-проектов»

Живая обратная связь с преподавателями
Неограниченный доступ к материалам курса
Стажировка в компаниях-партнёрах
Дипломный проект от реального заказчика
Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

особенности внедрения гибкой разработки / Mail.ru Group corporate blog / Habr

Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.

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

О компаниях, использующих Agile

— Есть ли «отраслевые предпочтения» в гибких методологиях?

Как показывает исследование Agile Russia, которое мы проводим второй год подряд, в сфере разработки ПО преимущественно используется Scrum, в финансовых организациях — Канбан, а в телеком-индустрии — и то, и другое.

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

Скорость изменений в IT значительно выше, чем в финансах. Поэтому там предпочтителен Scrum как подход, позволяющий за счёт быстрых экспериментов гибко управлять приоритетами и менять направление в зависимости от изменений внешней среды и условий «на входе». Финансы более консервативны.

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

Телекому Канбан тоже подходит. Хотя бы потому, что вектор развития отрасли — цифровизация. Однако пока мало кто понимает, как конкретно она должна выглядеть. Кроме того, в телекоме «быстрая» часть работы (разработка ПО) соседствует с «медленной» (поддержка и развитие аппаратной инфраструктуры). Поэтому наряду с экспериментами, которые проводятся по Scrum, имеет смысл эволюционно ускорять текущие процессы с применением Канбана.

Методики гибкой разработки, принятые в разных отраслях. Суммы не равны 100 %, потому что можно было выбирать более одного пункта. Изображение/ScrumTrek

— А как дела у мобильных разработчиков? Есть ли у Agile специфика в мобильной разработке?

С моей точки зрения, основная трудность при разработке мобильных приложений — выявление требований к приложению, потому что бывает сложно идентифицировать заинтересованных лиц. Эти трудности преодолимы, если использовать customer development для исследования потребностей клиента и Scrum для быстрой проверки продуктовых гипотез.

Customer developmentCustomer development, custdev, кастдев, развитие клиента (интересно, а так вообще кто-то говорит?) — это подход к созданию продукта через постоянное тестирование на реальном рынке и улучшение по результатам этих экспериментов. Это сближает кастдев с научным методом, делает создание продукта «научно обоснованным».

CustDev — один из элементов методологии Lean Startup, которая, в свою очередь, является одним из Agile-подходов при создании продуктов.

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

Кроме Scrum здесь можно использовать и ориентированные непосредственно на мобильную разработку подходы. Например, Mobile-D базируется на XP, Crystal и RUP — подходах достаточно древних и хорошо отработанных. Главное отличие Mobile-D от Scrum: наличие четких фаз и главенствующий акцент на инженерной стороне развития продукта. Если Scrum уделяет больше внимания управлению и поставке продукта, то Mobile-D сосредоточен на процессе производства и включает практики XP, существенно улучшающие качество конечного продукта. В то же время сказывается влияние RUP, поэтому процесс довольно формализованный.

Другой, наиболее современный подход к мобильной разработке — SLeSS, совмещающий Scrum и Lean Six Sigma. Сперва он реализует постановку рабочего процесса по Scrum, а затем применяет подходы Lean Six Sigma для статистического управления качеством. Мне кажется, SLeSS сочетает в себе необходимую гибкость с механизмами обоснованного принятия решений на основе статистики.

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

— Насколько гибкие методологии поддаются модификации под частные условия?

Здесь надо рассматривать по отдельности Scrum и Канбан.

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

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

— Какие типичные ошибки при адаптации Scrum совершает бизнес?

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

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

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

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

Скорее всего, как и прежде, участники команды будут заняты и в других проектах. В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта. Если люди «поделены на проценты» между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлеченность, так и эффективность работы над каждым конкретным проектом/продуктом.

Негативных последствий у такого неумелого «внедрения» множество, а начинаются они с попытки воспроизвести механику, но не суть Scrum. Основные ошибки в реализации Scrum я подробно описал в своём докладе «Стоп-сигналы для Agile» на конференции CodeFest 2017.

— Как оценить, насколько грамотно гибкие методологии внедрены в компании?

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

Мы используем собственную методику, которую воплотили в сервисе ScrumTrek Diagnostic Tool. Работает она так. Команде и заинтересованным лицам вне её задаётся ряд вопросов о том, как они оценивают уровень командного взаимодействия, планирование своей работы, ценность поставляемого заказчику результата, взаимодействие с другими командами и так далее. По каждому параметру высчитывается медиана мнений и строится комплексная круговая диаграмма — Радар, который отображает взгляд как изнутри команды, так и снаружи.

Радар ScrumTrek. Смотрим на разброс оценок

Радар ScrumTrek. Смотрим на медианы

Схема содержит много полезной информации.

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

Разброс оценок в команде — интересная вещь. Когда он очень большой, есть повод договориться о том, что мы как команда подразумеваем под тем или иным аспектом нашей работы. Что мы имеем в виду под «ценностью для клиента», например? А «скорость поставки»? Большой разброс свидетельствует о том, что в команде не сформирована единая позиция по ряду вопросов.

Маленький разброс говорит о консенсусе и хорошем взаимодействии внутри команды.

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

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

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

О командах, внедряющих Scrum

— От кого в компании должна исходить инициатива внедрения методологий гибкой разработки?

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

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

Идеально, когда инициатива исходит от топ-менеджмента. Подвижки в эту сторону на российском рынке заметны.

— Какие новые роли и функции возникают в организации или команде с внедрением гибких методологий? Какие из них обязательны, какие опциональны?

В случае со Scrum это роли Scrum-мастера, владельца продукта и команды разработки. Все они обязательны. Команда разработки тоже считается «ролью», так как объединяет в себе не только разработчиков, но и всех, кто нужен, чтобы продукт в принципе появился: аналитиков, дизайнеров и так далее.

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

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

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

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

Пример. Приходит подчиненный к руководителю, и говорит: «Я не могу выбрать из двух вариантов реализации какой-то наилучший. Реши ты!»

Если использовать коучинговый подход, то руководитель начнет задавать вопросы: почему именно эти два варианта ты выбрал? А из чего ты исходил? В чем для тебя трудность в выборе между ними? Кто тебе может помочь еще? И так далее. Через вопросы руководитель-коуч помогает человеку исследовать возможные варианты. В итоге человек уже сам понимает, как ему лучше поступить, и руководителю останется только договориться о сроках, когда подчиненный придет и расскажет, что у него получилось.

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

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

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

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

SAFeSAFe, или Scaled Agile Framework — фреймворк для применения Agile в крупных командах по разработке ПО. В самой простой реализации подход предполагает два уровня: командный и программный (Team и Program соответственно), по мере усложнения оргструктуры и продукта к ним добавляются Portfolio и Large Solution. Работа по SAFe опирается на такую сущность, как ART (Agile Release Train) — «поезд релиза». Она, как правило, объединяет несколько команд и заинтересованных лиц в структуру, на протяжении длительного времени сообща создающую продукт или часть продукта, которая представляет ценность для заказчика.

— Как разграничиваются функции владельца продукта и Scrum-мастера «в идеальном мире»?

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

ПримерЧтобы это не было абстрактным, вот выдуманный микродиалог внутри команды. Посмотрите, что говорит каждый из своей роли:

Владелец продукта: Так! Нам надо будет сделать воооот такую фичу! Вы в прошлый спринт отлично поработали, так что, я думаю, вы всё успеете!

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

Владелец продукта: Неужели всё так серьезно? Если да — давай с командой обсудим, что можно сделать за спринт, не выжигая людей. В этой фиче есть часть, которую надо будет сделать обязательно, она не выглядит сильно сложной.

Scrum-мастер: Давай обсудим с командой. Ты знаешь, что только она может сказать, «сложная» это задача или нет.

Владелец продукта: Давай.

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

По части бизнес-компетенций всё «по классике», как с обычным менеджментом, за исключением необходимости определять приоритеты по этапам и теснее взаимодействовать с командой.

Владельцу продукта стоит освоить Lean Startup, customer development и другие современные подходы к созданию продуктов.

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

— Действительно ли коллективное владение кодом снижает зависимость компании от «звёздных» разработчиков? Не падает ли их мотивация?

Коллективное владение кодом осуществимо и без гибких методологий. Достаточно договорённостей о code review и других формальных правил, а разработчики могут действовать атомарно.

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

Это дилемма: или краткосрочный, или долгосрочный успех. Кажется, что наём «звезды» — благо для бизнеса. Но что будет через три года, через пять, через семь лет после того, как такой профи присоединился к компании? Он станет незаменимым. И как минимум с тремя негативными последствиями.

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

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

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

— Что предпринять, чтобы всё-таки перейти к командному подходу?

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

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

Среди «звёзд» найти тех, кто хочет расти, и помочь им освоить навыки менеджмента, фасилитации, коучинга. Открыть им новые горизонты. Не все на это согласятся. Зато те, кто согласится, будут лучшими приверженцами новых принципов работы.

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

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

Материал подготовила команда Mail.Ru Cloud Solutions.