Колонки

Как перейти на agile и каких трудностей можно избежать еще в самом начале

Колонки
Марина Арефьева
Марина Арефьева

Исполнительный директор консалтинга «Двадцать первый век» и спикер курса по управлению продуктом в Binary District

Полина Константинова

Согласно отчету ScrumTrek за 2017 год, agile в России находится в стадии бурного роста. Крупные российские компании, такие как «Тинькофф Банк», «Додо Пицца» и Сбербанк, применяют гибкие подходы на практике. В одном только МТС сейчас работает пять agile-коучей и еще больше scrum-мастеров. Марина Арефьева, agile-коуч в МТС и спикер курса по управлению продуктом в Binary District, знает, с какими трудностями приходится сталкиваться при переходе на новую методологию. Она рассказала, как грамотно перейти на agile, и привела несколько лайфхаков из своего опыта работы с командой «Яндекс.Браузера».

Как перейти на agile и каких трудностей можно избежать еще в самом начале
Присоединиться

Убедитесь, что вам нужен agile

Прежде всего надо понять, в чем проблема, и поможет ли в вашем случае переход на agile. Показателем проблемы является Time-to-Market: за полгода не вышло ни одного нового продукта или даже фичи, либо скорость выхода значительно упала.

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

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

Получите свободу действий

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

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

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

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

Найдите коуча и/или scrum-мастера

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

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

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

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

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

Наберитесь терпения

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

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

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

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

Создайте бонусы для разработчиков

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

Чтобы примирить программистов с новыми процессами, в минском офисе «Яндекса» в свое время мне предложили несколько лайфхаков.

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

Также важно уходить от оценки задач в человеко-часах и переходить к Story Point («в попугаях», как в советском мультике). Если программист работал над задачей шесть часов, хотя обещал сделать за четыре, у него возникает определенный дискомфорт. Story Point — это психологический трюк, который помогает уйти от этого дискомфорта: учитываются не часы, а ценность проделанной работы.

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


Ради чего эти страдания?

Еще до перехода на новый подход следует сделать несколько трудозатратных действий: заказать аудит, провести хакатон, нанять scrum-мастера или переучить кого-то из членов команды и внимательно следить за всеми происходящими процессами. Плюс ко всему на несколько месяцев падает производительность и, вероятно, кого-то придется уволить. Каков тогда положительный эффект?

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

Перед переходом на agile в «Яндекс.Браузере» мажорный релиз был каждые 4 месяца. Спустя полгода настройки мне удалось наладить процессы и выпускать мажорную версию браузера каждые 6 недель, то есть улучшить показатель Time-to-Market практически в 2,5 раза.

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


Материалы по теме:

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 9 из 10 IT-компаний используют Agile. Как понять, нужен ли он вам
  2. 2 Декомпозиция бизнеса: основные способы и инструменты финансового роста
  3. 3 8 российских сервисов на замену Trello и Jira
  4. 4 150 человек и 5 направлений: как дирекция и архитекторы компании «Самолет» перенесли рабочие процессы в Kaiten
  5. 5 Открыт прием заявок на первую в России премию в области применения Agile-подходов
EdTech: карта российского рынка
Все компании и инвесторы в области образовательных технологий
Перейти