До и после: как Agile поменял процессы в команде разработки

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

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

Кто мы?

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

Положение дел до внедрения Agile-подходов

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

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

Почему выбрали Agile?

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

Поэтому мы решили познакомиться с другими информационными системами и фреймворками разработки. Изучили ряд самых популярных подходов (Waterfall, Agile, Lean) и систем (Jira, Hygger, Redmine). Остановились на Agile и Jira.

Agile подходил к гибкости нашего рынка: он меняется часто, важность доработки может измениться за ночь и необходимо, чтобы команда разработки быстро и безболезненно адаптировалась и выполняла задачи с минимальными потерями и без стресса. А Jira позволяла создавать необходимые для анализа работы отчёты и автоматизировать некоторые моменты. Обучение проходили в компании Scrumtrek.

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

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

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

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

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

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

Наконец, мы внедрили ретро, чтобы в конце каждого спринта обсуждать проблемы и оперативно решать их. А также ввели практику определения и выпуска MVP (Minimum Viable Product), чтобы клиент получал результат как можно скорее и применял в своей работе необходимый минимум.

Что изменилось после внедрения Agile-практик?

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

Также мы сократили количество проблемных мест в прошивках к минимуму. Сейчас критичные дефекты устранены. Вновь обнаруженные устраняем в течение 1-2 дней.

Мы научились эффективнее работать по спринтам. Благодаря графикам из Jira понимаем причины, почему не закрыли спринт. После внедрения решения три спринта были с положительной динамикой. А благодаря практике User Story Mapping ей ускорили процесс выхода нового функционала в GPS-трекерах без нагромождения всех «хотелок», оставляя в них только суть для отработки решения.

Наконец, PBR (Product Backlog Refinement) помог детальнее подойти к планированию и оценке сроков.

Что дальше?

Мы будем регулярнее применять Product Backlog Refinement, чтобы точнее планировать и устанавливать сроки. А также активнее использовать User Story Mapping для определения Minimum Viable Product.

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

Наконец, мы введём практику работы в парах для совместной работы над проектами.