Как живут IT-специалисты в сервисных подразделениях больших компаний, основной профиль которых напрямую не связан с IT? В этой статье, первой из серии, я расскажу о том, как построена работа айтишников в Sminex. Наша компания специализируется на строительстве дорогой недвижимости в центре Москвы — создаёт коллекцию домов вокруг Кремля в исторических районах города. Компания строит и проектирует более 460 тыс. кв. м элитной недвижимости.
Привет! На связи Александр, ведущий системный аналитик в Sminex. IT для нашей компании — не главное направление деятельности. Однако мы всё равно крутые, работаем с большим стеком технологий и решаем важные задачи. Сегодня я расскажу, как мы применяем Agile-подход в повседневной работе, что у нас получается хорошо, а что планируем развивать дальше. Надеюсь, будет интересно, а информация окажется полезной.
В компании я вхожу в состав группы, занимающейся цифровизацией процессов в строительстве. Моя основная область ответственности — разработка продукта Plan.SX. Я занимаюсь развитием инструмента для управления графиками и планами реализации девелоперских проектов.
Как мы пришли к Agile
Однажды мы осознали, что время, в котором живём, характеризуется постоянными изменениями, и бизнесу нужно быть гибким, чтобы эффективно адаптироваться. Поэтому мы решили перейти на гибкие методологии разработки IT-решений, которые позволяют оперативно корректировать процесс создания программного обеспечения. Несмотря на вызовы, появившиеся при переходе, который начался пару лет назад, мы смогли создать успешно функционирующую систему.
Как устроены команды
Наши команды внедрили ролевую модель, которая обеспечивает эффективное управление продуктом:
Lead Product Owner / руководитель группы: Этот человек выступает в роли руководителя группы и отвечает за общую координацию работ, общение со всеми заинтересованными сторонами и разрешение спорных вопросов;
Product Owner / системный аналитик: Этот специалист управляет своим продуктом, взаимодействует с заказчиками, выявляет их потребности и собирает требования. Product Owner ещё и активно влияет на развитие продукта, например, помогая заказчикам формулировать свои «хотелки» для гармоничного развития продукта и удовлетворения бизнес-потребностей;
Разработчики: Команда разделена на два направления — 1С и web-разработка. Хотя у нас есть формальное распределение по группам, в случае необходимости, например при высокой загрузке или изменении стека технологий, оно может изменяться. Разработчики ведут задачи, поставленные аналитиками в рамках развития продукта. В больших командах так же выделяется роль Team Lead, который координирует разработчиков;
QA Engineer: Эти специалисты ответственны за проверку качества разработки, прорабатывают различные сценарии использования доработок программного обеспечения, пишут баг-репорты, готовят кейсы для автотестирования.
Как ведем задачи
Для управления задачами мы используем:
По инструментам: классическая связка Jira + Confluence;
По методологии: метод Канбан + фреймворк Scrum.
Задачи и ошибки формируют бэклог. Jira выступает в роли системы отслеживания задач — каждая команда имеет свое собственное пространство. Мы усвоили на практике, что задачи, связанные с анализом, трудно администрировать в рамках спринтов, так как их трудоемкость зачастую сложно оценить. Поэтому каждый аналитик использует канбан-доску и перемещает задачи по соответствующим колонкам — от «Бэклога» до «Готово к разработке».
Как только аналитик подготавливает задачи, он составляет черновик спринта, согласовывает его с заказчиком и отправляет на оценку. За два дня до начала спринта черновик должен быть готов к передаче команде разработки. Разработчики с тимлидом проводят оценку задач и общую трудоемкость спринта на сессии планирования.
Для спринтов взяли золотой стандарт — две недели, что так же оптимально легло на наш релизный цикл. И, кстати, у нас есть релиз-менеджер, который ругается (и ещё как!), когда в обновление пытаются накинуть внеплановые задачи.
Для полноты картины перевели входящие от пользователей запросы со старого Manage Engine Service Desck Plus на Jira Service Management. Получилась очень удобная связка: при необходимости разработки тикет привязывается к задаче. Так удалось получить отбивки по статусам жизненного пути заявки. Также настроили крутой дэшборд, который показывает динамику поступления и решения тикетов в разрезе продуктов.
Нравится:
прозрачный процесс;
у каждой задачи есть свой жизненный цикл;
удобный трекинг, всегда можно отследить прогресс.
Точки роста:
всегда может появится «приоритетная» задача, которую могут подкинуть в запущенный спринт;
плохо проработанные на стадии анализа задачи влияют на динамику сгорания спринта.
Что по Scrum мероприятиям?
В Sminex мы практикуем Daily Scrum, Planning Poker и Retro.
Daily Scrum. Дейлики проводим регулярно. Их формат может отличаться в зависимости от размера команды. Раньше дейлики были ежедневными для всех. Сейчас мы их разделили:
Ежедневно для разработчиков: утром собираемся и делимся тем, что удалось сделать, какие были проблемы и что собираемся делать сегодня. Для простоты взяли за привычку ворклогать затраты, так легче вспоминать результаты прошедшего дня;
Через день для аналитиков: всё то же самое — делимся болями, победами и планами.
Немного истории о нашем Daily Scrum. Когда мы только начинали, хорошей идеей показалось создание отдельного пространства в Confluence. В нем каждый член команды заполнял всю информацию перед проведением дейлика. Спустя полгода мы пришли к выводу, что на заполнение дейлика тратится слишком много времени, хоть он и решает вопрос с отчётностью по работе команды.
Параллельно для разработчиков стартовало внедрение учёта рабочего времени, а поскольку в ворклогах разработчик фактически фиксирует, что он сделал вчера, мы решили настроить удобный рабочий стол для проведения дейликов. Это позволило нам уйти от заполнения лишних форм и работать с данными Jira.
Благодаря ведению учёта рабочего времени разработчиками, нам удалось создать пространство для проведения ежедневного совещания по методике Daily Scrum с использованием плагина Worklogs.
На дейлике участники команды рассказывают о:
Своих достижениях за прошедший день, используя Worklogs в качестве подробной справки о проделанной работе;
Планах на текущий день, просматривая доску задач и удостоверяясь в актуальности статусов.
Менеджмент команды получил отличный инструмент, который в рамках ежедневного мероприятия позволяет проинспектировать количество затраченного времени каждого разработчика, оценить качество заполнения Worklog (больше никаких «РАБОТАЛ 6 часов, честно-честно») и убедиться, что статусы задач в спринте актуальны.
Нравится:
помогает совершенствовать самодисциплину;
меньше шансов упустить что-то важное;
через какое-то время понимаешь, что планировать загрузку на день — это здорово;
мы делимся болями, а коллеги могут дать ценный совет.
Точки роста:
бывают периоды, когда дейлики превращаются в рутину, падает мотивация услышать и быть услышанным друг другом, может показаться, что говорим в пустоту.
Planning Poker. Перед стартом спринта команда разработки оценивает его ёмкость, устанавливает сторипойнты в часах. К слову, прямо сейчас, пока я пишу статью, коллеги отправились планировать 6-й спринт.
К устоявшемуся процессу планирования тоже пришли не сразу. Начинали с оценки задач прямо в списке.
В этом варианте обмен мнениями был затруднен, ввиду того, что не было возможности «скрытой простановки оценки», все ставили их, ориентируясь на первого спикера. Затем попробовали онлайн сервис, но из-за того, что в него нельзя было «загнать» задачи из Jira, настройка игры и сохранение её результатов были очень сложными и неудобными.
В конечном итоге пришли к плагину Planning Poker for Jira, который позволил стандартизировать проведение мероприятия и упростить сохранение результатов оценки. Стоит отметить, что помимо инструментальных проблем на самом старте мы совершали типичную ошибку — играли в покер без предварительного ознакомления с задачами. В итоге ребята не успевали их понять, и точность оценки была низкой.
Изначально не все разработчики команды видели практическое применение покера и относились к этому, как к трате времени. Однако практика показала, что это мероприятие повысило точность оценок и как следствие прогнозируемость работы команды.
Retro. Раз в три спринта мы устраиваем ретро, обсуждаем итоги прошедших спринтов, рефлексируем, настраиваемся на новые свершения. Стараемся проводить ретро весело. Например, в прошлый раз в процессе читали гороскопы, решали сканворды и закусывали пиццей.
С форматом ретроспективы экспериментируем: очные или онлайн-встречи с использованием Confluence, Miro или плагина в Jira.
Вариант с плагином показал себя самым последовательным. К тому же он позволяет отслеживать историю. Первенство самого весёлого формата безусловно отдаём очным встречам — гороскопы и пицца, да!
Заказчик в Scrum
Не все заказчики — они у нас внутренние, от бизнеса — умеют в Scrum. И мои заказчики не исключение. Хотя не сразу, но они влились в основные процессы и терминологию. Регулярно мы проводим демонстрации разрабатываемого функционала на демо-сессиях, а также планируем спринты. Коллеги поняли наш подход к разработке и циклу релизов. Интересно отметить, что обычный вопрос «Когда это будет готово?» стал звучать как «В какой спринт мы это запланируем?».
Немного о метриках
Благодаря единообразному подходу к работе у нас появилась возможность отслеживать командные и ролевые метрики. Команды получили инструменты, позволяющие отслеживать, как их действия отражаются на производительности.
Заключение
Для создания красивых домов, в которых комфортно жить, важна работа каждого сотрудника девелоперской компании. В Sminex развитию IT-систем уделяется большое внимание, поскольку они тоже позволяют следовать нашей философии — строить в точности то, что обещано. Так мы можем создавать дома такие же, как на рендерах. Внутри IT мы планируем развивать практику Agile и дальше. Например, хотим внедрить скоринг, выбрать фреймворк масштабирования Scrum и совершенствовать продуктовый подход.
И, конечно, ждём в наших командах новых людей. Актуальные вакансии — здесь )
