Привет, Хабр! Scrum — хороший фреймворк, позволяющий наладить эффективную работу отдела разработки. Он четко распределяет ценности, роли и этапы работы, но не очень подходит для небольшой команды разработчиков, как у нас. Но для начала расскажем вводные данные.
Наша компания с 1999 года занимается разработкой и внедрением ПО для бизнеса. В 2017 году мы разработали REST API приложение для Битрикс24, позволяющее организовать работу поддержки внутри привычного интерфейса Битрикса. Приложение стало востребованным, поэтому в 2021 году нами был выпущен сервис-деск Admin24, а совсем недавно, всего за полгода мы выпустили его коробочную версию. Почитать подробнее о пути разработки вы можете в нашей предыдущей статье.
Мы провели интервью с руководителем нашего отдела разработки, занимающегося созданием всех наших продуктов. В ходе интервью он рассказал об использовании кастомизированного фреймворка Scrum для слаженной работы команды программистов. И вот что из этого получилось:
Как устроено планирование в отделе разработки?
Перед началом разработки мы проводим исследование: собираем обратную связь от клиентов, выслушиваем пожелания владельца продукта. Перед отделом разработки выставляются задачи по реализации необходимого функционала. Исследуются возможности реализации, проверяется, возможно ли создать необходимый функционал при помощи штатных средств разработки. На основании обсуждения, формируется документ с описанием того, что мы планируем реализовать на проекте (Бэклог продукта).
Документ формируется в виде пользовательских историй с перечнем начальных прототипов экранов реализации. Для прототипов экранов проекта мы используем продукт https://moqups.com/, а также навыки работы в графических редакторах и инструментах отладки по типу Chrome DevTools. На этом этапе мы также определяемся с общей концепцией дизайна проекта. Предпочтение отдаем уже готовым наборам библиотек, благодаря которым настраиваем презентабельный внешний вид продукта, чтобы не тратить на это лишнее время.
Каждая пользовательская история представляет собой описание будущего функционала простыми общими словами. Сюда, как правило, входит описание MVP продукта, а также описание функционала, который будет добавляться в дальнейшем с каждым новым релизом обновлений проекта.
После формирования документа, он обсуждается с владельцем продукта и командой разработки. При необходимости в него вносят дополнения и правки. На обсуждение мы стараемся тратить не более 2-3 часов.
После утверждения плана реализации проекта, teamlead с командой разработки обсуждает нюансы реализации архитектуры проекта и перечень технологий который будет использоваться на проекте. В основном мы работаем со стеком технологий Laravel, Vue, Mysql.
Devops разворачивает необходимое для реализации проекта окружение на сервере, производит настройку. Создает для каждого разработчика среду разработки и тестирования с необходимым ПО и настройками.
Как реализован фреймворк Scrum в отделе?
У нас в отделе не классический Scrum, но мы взяли все основные принципы и внесли ряд собственных изменений, которые положительно показали себя в работе над проектами.
Формируем Бэклог спринта (в него входят пользовательские истории, которые будут реализованы в рамках спринта) и сам спринт проекта. Спринт мы формируем, используя task-менеджер Youtrack. В него попадают все необходимые задачи для реализации MVP (это является нашим первым инкрементом при старте проекта), которые реально выполнить за время действия спринта. Спринты у нас длятся на протяжении двух недель.
Обычно первые 2 спринта мы тратим на реализацию MVP продукта. В конце первого спринта формируется реализация, содержащая в себе основу проекта, т.е. некий внешний и архитектурный каркас, без которого выполнение основных целей проекта невозможно. Во второй спринт мы добавляем функционал, который должен быть в MVP, но не смог попасть в первый спринт.
Каждый день проводится митинг с командой, на котором каждый из разработчиков отвечает на 3 вопроса:
Что я сделал сегодня?
Что я буду делать завтра?
Какие проблемы возникли в ходе реализации задач?
Scrum-митинг мы проводим в конце рабочего дня, поэтому и первый вопрос отличается от классического первого вопроса к Scrum-митингу. Нашей команде хватает 30 минут (в классическом подходе не более 15, но мы сознательно увеличили данное время, так как оно показало большую эффективность на дистанции реализации проекта), чтобы каждый ее участник смог ответить на вопросы и обсудить все возникшие на проекте сложности.
Если требуется уделить больше времени, то согласовываем время проведения дополнительного обсуждения. По результатам ежедневной планерки формируется отчет о результатах работы команды за день, который предоставляется владельцу продукта (в этом отличие от классического Scrum, так как добавляется еще один механизм контроля ситуации на проекте, несмотря на самоорганизованность команды).
В конце каждого спринта проводится сборка выполненных задач в единое решение на боевом сервере, тестировщик проверяет сценарии, которые мы планировали выполнить в рамках спринта. Вносятся финальные правки по выявленным багам, или фиксируются к выполнению на следующий спринт.
По результат проводится ретроспектива с командой и владельцем продукта, на которой мы демонстрируем ему результаты команды за время действия спринта. В рамках двухнедельных спринтов на ретро хватает 1-1,5 часов, его цель — показать выполненный за спринт результат и понять, что мы двигаемся в нужном направлении, а при необходимости также кратко зафиксировать изменения на следующий спринт.
Какие элементы фреймворка Scrum ты считаешь излишними или нереалистичными в условиях дистанционной работы?
Все элементы Scrum можно использовать в условиях дистанционной работы, только личные встречи заменяются на личные онлайн-встречи при помощи разнообразия инструментов коммуникаций на рынке. Мы используем Skype и инструменты Битрикс24 (в зависимости от необходимого функционала).
Одним из факторов, влияющих на успех корректной работы Scrum в организации, является команда. Она должна состоять из самоорганизованных , кросс-функциональных специалистов, обладающих всеми навыками, необходимыми для разработки проекта.
Если ваша команда еще не достаточно самоорганизована, то требуется внедрение дополнительных элементов контроля, которые должны поддерживать комфортную среду для работы команды, доверительную атмосферу и ментальное состояние каждого из участников команды.
Под доверительной атмосферой мы подразумеваем, что специалист самостоятельно занимается рабочими задачами в течении рабочего дня, а в конце дня фиксирует результаты без постоянного контроля со стороны руководителя. Да, это то, что не используется в классическом Scrum, но это позволяет мягко и эффективно следить за показателями специалистов, давая четкие сигналы, если требуется внести корректировки или дать рекомендации по работе.
В нашей организации введено правило, что специалисты уделяют 15 минут в конце рабочего дня на логирование своих результатов за день. Логирование происходит непосредственно в карточке задачи.
Специалист кратко, но емко описывает действия, которыми он занимался в течение рабочего дня. В рамках логирования он фиксирует время потраченное как непосредственно на задачу по разработке, так и на все остальные активности, которые у него были в течение дня (для этого у нас заведены задачи для логирования под все необходимые случаи, включая форс-мажорные обстоятельства).
Он может залогировать не менее 6,2-7 рабочих часов в день (мы понимаем, что сотрудник не может работать, не отвлекаясь на чай, туалет, маленькие перерывы).
По результатам месяца составляется отчет, в котором видно, сколько всего времени было потрачено специалистами на рабочие задачи и дополнительные активности. Мы считаем их положительными, если они равны или превышают 130 часов в месяц. Если результаты ниже 100 часов в месяц — это сигнал для руководителя, что требуется его активное внимание для корректировки работы специалиста. Хочу отдельно отметить, что внедрение такого правила со временем показывает результаты у специалистов выше 130 часов (у нас показатели уже доходят, в среднем, до 145+ часов).
К одним из ключевых факторов ментального здоровья специалистов можно отнести следующее правило: «Специалист занимается рабочими задачами в рабочее время и не занимается принудительно задачами после его завершения».
Если специалист самостоятельно проявляет инициативу уделить проекту больше своего времени, включая личное время, эта инициатива поддерживается и не должна оставаться без внимания руководства. Несоблюдение этого правила рано или поздно приведет к выгоранию специалиста и принесет больше вреда компании, чем пользы, особенно, если это небольшая компания.
Какие элементы фреймворка Scrum дают наибольший результат?
Наилучший результат дает комплексное использование элементов фреймворка Scrum. Каждый из элементов можно адаптировать в процессе, учитывая особенности вашей команды и вашей организации. При этом важно понимать, что целью является результат, а не сам процесс.
Поэтому, если в вашей команде требуется внести корректировки в подход — это нормально. Главное следить за показателями эффективности этих изменений и вовремя их корректировать, если они не оправдывают себя.
Как работа по фреймворку Scrum повлияла на результаты отдела?
После того, как мы стали применять в основе фреймворк Scrum, показатели эффективности стали расти. После внесения ряда небольших корректировок в классический подход они продолжили свой рост, дойдя до перспективных для нас значений на данном этапе развития компании.