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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Перенести рабочие места команды по возможности рядом, в одну комнату или хотя бы часть офиса. Это необязательно, но очень удобно, когда вопрос можно задать вслух человеку, сидящему в метре от тебя, а не идти на другой этаж.
• В самую середину посадить человека, представляющего бизнес-экспертизу и имеющего права принимать решения по продукту. Если этого права нет — стоит его сначала добиться, иначе любые вопросы команды могут потянуть за собой волокиту согласований. Этого человека (знакомьтесь: ваш Product Owner) еще желательно освободить от 70% текущих обязанностей на ближайшие 2-3 месяца.
• Определить длительность спринта и назначить скрам-мастера. Лучше, чтоб это был человек, имеющий авторитет и внутри команды, и снаружи. Внутри он будет напоминать о приоритетах и дирижировать скрам-процессами, а снаружи должен иметь достаточно веса в компании, чтобы отогнать от членов команды их непосредственного начальника с «очень важным заданием». Например, у нас в эту роль прекрасно вписался проектный менеджер.
• Собрать первую 4-часовую встречу по разбору беклога. Я называю эту встречу «крушение надежд». На ней команда слушает мои планы и задает мне вопросы по задачам, которые мне в голову не приходили, оставляя меня в глубокой задумчивости и согласии, что эту задачу в этот спринт не сделать.
• Найти несколько задач, которые сделать кажется возможным всей команде. Взять одну из них и ;попросить рассказать будущих исполнителей, что и как он будет делать. В процессе рассказа родятся отдельные задачи, скрам-мастер только и будет успевать записывать и спрашивать волшебное «сколько же это займет времени?»
• Также для задач очень помогает простой чек-лист, эти вопросы следует задавать к каждой, даже казалось бы самой простой строчке беклога: что сделать на фронте; что сделать на бекенде; какие ручные тесты написать или переписать; какие автотесты исправить; какие данные в базе менять или мигрировать; что задокументировать?
• Нагрузку на первый спринт рассчитывать так: количество рабочего времени каждого из команды за полспринта, минус еще немного. То есть если спринт двухнедельный, то загружайте команду где-то на 35 рабочих часов каждого. Остальное время уйдет на недооцененные доработки задач, блоки, совещания и т.п. Эта цифра чуть вырастет на следующие спринты, но не сильно.

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

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

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

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

• · Не расстраивайтесь, когда в конце спринта вы все равно все не успели. Сноровка приходит с опытом.

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

• 60% — выполнение запланированных задач;

• 10% — планирование и организация следующего спринта, разбор/оценка задач из беклога;

• 5-10% — подготовка и демонстрация результатов спринта. У нас это — сборка версии и накат на отдельный стенд, проверка конфигов, правки в последнюю минуту, пересборка;

• 20-25% — запас на риски: болезнь или внезапное отсутствие членов команды, обнаружение критичного и срочного дефекта, устранение которого нельзя отложить на потом, нашествие марсиан и другие возможные неурядицы. Если случается, что все задачи спринта сделаны, в это время всегда есть чем заняться — отлов багов, обновление документации, автотесты.

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

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

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

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

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

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