​Кейс: Как дойти до скрама своим умом

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

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

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

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

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

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

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

Дело пошло. Второй спринт уже планировали всего четыре часа и заранее. Начали проводить ретроспективы, обсуждать, что нам не хватает уже в новом процессе. Подняли дополнительный стенд для предварительной (до передачи в тест) интеграции фронта и бекенда, стали даже робко посматривать в сторону Test Driven Development.

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

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

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

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

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

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

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

Сегодня мы все еще оцениваем задачи в человеко-часах и не можем уйти от довольно узкой специализации разработчиков. Каждый из них хорошо знает 1-2 модуля и плохо понимает что-то про остальные модули-программы. Несколько спринтов назад мы открыли для себя Burndown chart в джире и ужаснулись тому, как он у нас выглядит. Теперь работаем над внутренней культурой ведения задач в джире: вовремя открыть/закрыть спринт, вовремя занести в него задачи и списать время. Выделяем время на обсуждение новых фич «с высокой степенью неопределенности» на все более ранних этапах. Дизайнер начал разговаривать с разработчиками чуть ли не ежедневно и учитывать их замечания до финализации макетов. Каждый день у команды появляются новые идеи, как применить ту или иную практику скрама, так что нам приходится выбирать, что раньше внедрить и превратить в привычку, прежде чем двигаться дальше.

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

После нескольких спринтов поймите вашу действительную загрузку по времени. У нас так:

Сейчас в двухнедельном спринте мы накидываем задач для каждого на 48-50 часов. Еще 8 часов в общей сложности уходит на планирование спринтов. Мы делаем две-три общекомандных встречи по полтора — два часа, плюс отдельные обсуждения: дизайн с фронт-разработчиками, структурные изменения с архитектором и бек-разработчиками.

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

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

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

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

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