Путь к Agile в Galileosky глазами скрам-мастера

Автор

Николай Лукиных

Руководитель проектов в Galileosky.

О компании

Компания Galileosky занимается производством и продажей (по всему миру) GPS-трекеров с возможностью гибко задавать реакцию на внешние события и работать с любой периферией — от простых реле до сложных дизельных генераторов и блоков управления автомобилем или спецтехникой. Производство и команда разработки — собственные. Занимаемся разработкой программного обеспечения для трекеров и разработкой аппаратной части для новых проектов.

Когда и почему решили внедрить Agile-подходы?

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

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

Путь к Agile был немного сумбурным. Изначально все задачи разработчикам давались в системе Wrike. Было жутко неудобно, поскольку там же были и другие документы и задачи всей компании и многое терялось. Чтобы стать лучше, начали изучать мировые практики и перенимать их. В процессе знакомились с новыми информационными системами и фреймворками разработки. Изучив ряд самых популярных подходов (Waterfall, Agile, Lean) и систем (Jira, Hygger, Redmine), решили перейти на Agile и Jira. Agile подходил к гибкости нашего рынка, а Jira из коробки позволяла создавать необходимые отчеты для анализа работы и легко автоматизировать некоторые моменты. Познакомились с двумя подходами: Kanban и Scrum. Испробовали оба. Agile выбрали поскольку наш рынок меняется очень часто, важность доработки может измениться за ночь и необходимо, чтобы команда могла быстро и безболезненно адаптироваться и выполнять задачи с минимальными потерями и стрессом.

Что за чем и зачем внедряли?

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

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

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

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

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

В работу аналитика внедрили практику User Story Mapping, чтобы понимать порядок доработок, которые берём в первую очередь, иметь всю картинку доработки перед глазами и не упускать важного.

Внедрили практику определения и выпуска MVP (Minimal Viable Product), которой раньше у нас не было, чтобы клиент получал результат как можно скорее и применял в своей работе необходимый минимум. А дальше уже обратная связь и последующие доработки на заранее отлаженной платформе.

Как внедрение Agile-практик повлияло на метрики проблем?

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

Благодаря четкому порядку действий и выбору необходимых специалистов, сократили количество возникающих проблем до минимума. Количество старых дефектов стали последовательно сокращать: на начало внедрения открытых дефектов было чуть больше 10, сейчас критичных дефектов нет вовсе, а вновь появляющиеся устраняем в пределах 1-2 дней.

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

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

Практика User Story Mapping позволила нам взглянуть на картину новых доработок сверху и проще выделить нужные моменты, которые стоит включить в работу первыми. Это позволило ускорить процесс выхода нового функционала в трекерах без нагромождения всех «хотелок», оставляя в них только суть для отработки решения.

Одно из последних нововведений — это PBR (Product Backlog Refinement). Проведя его пару раз, увидели огромную пользу: при декомпозиции задачи стали проявляться пункты, о которых ранее не думали на старте, а просто делали в рамках другой задачи. Это приводило к увеличению времени работ и срыву планов и сроков. PBR помог детальнее подойти к планированию и оценке сроков.

Какое отношение ко всему этому имеет ScrumTrek?

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

Также, получив заряд энергией и жажду знаний, пошли дальше и стали применять в работе CJM (Customer Journey Map, карта клиентского пути) и Карту Эмпатии при выезде к клиентам. Эти инструменты сильно продвинули нас в понимании болей клиентов.

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

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

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

Что планируете сделать в ближайшем будущем?

• Будем регулярнее применять PBR (Product Backlog Refinement, практика уточнения бэклога продукта до планирования очередного Спринта) для уточнения сроков.
• Хотим расширить матрицу компетенций, чтобы избавиться от провалов во время отпуска и разгрузить членов команды.
• Планируем активнее использовать USM (User Story Mapping, построение карты пользовательских историй) для определения MVP (Minimal Viable Product, минимально жизнеспособный продукт).
• Хотим расширить работу с клиентами через интервью — несколько поездок к клиентам с заполнением CJM и карты эмпатии, а также же демо перед выпуском (начнём с демо внутри компании и внутренних клиентов).
• Введем практику работы в парах для совместной работы над проектами.