SCRUM, здравствуйте! Как разработчики Аспро работают по гибкой методологии

Если задать программисту вопрос «Чем ты занимаешься на работе?», он ответит что-то вроде: «Работаю» или «Да я просто кнопочки раскрашиваю». Зависит от настроения. На самом же деле такие простые ответы — результат хорошо организованного рабочего процесса. Создать среду, в которой программист может просто заниматься своим делом — задача любого тимлида. В идеальном сценарии разработчик чувствует себя в команде так же комфортно, как если бы он работал сам на себя.

На деле же создание коммерческого продукта в IT-компании имеет мало общего с самостоятельной разработкой. Работа в команде подразумевает зависимые друг от друга задачи. Также есть куда более строгие дедлайны и разные приоритеты. Поэтому важно видеть общую картину и грамотно распределять ресурсы.

Но вот незадача: код не похож на готовые детали из станка. Как посчитать продуктивность сотрудника, оценить время на задачу и избежать простоев? От этого зависит, уложится ли команда к дедлайну. А увеличение сроков — это всегда увеличение затрат, которые продукту еще предстоит отбить.

По системе SCRUM работает немалая часть IT-компаний в наше время. Не вдаваясь в историю — это способ гибко создавать продукт. Подразумевается, что разработка разбивается на короткие отрезки — спринты. Обычно это неделя, но длительность каждая команда определяет самостоятельно. Благодаря этому можно адаптироваться к обстоятельствам и вести непрерывный процесс разработки.

Для планирования спринтов нужно понимать трудозатраты: сколько задач сотрудник может выполнить за указанный срок. Также важно учитывать сложность. Хотя бы потому что на сложную задачу уйдет больше времени. Так что одним количеством не обойдешься. Поэтому каждая задача оценивается в Story Points. Они же сторипоинты. Они же фантики, листики, тугрики. Называйте как хотите.

Оценку задач предлагается производить с помощью покера планирования. Для этого используется специальная колода с числами Фибоначчи. Команда собирается, разбирает задачу и затем каждый участник кладет карту со «стоимостью» задачи рубашкой вниз. После этого все карты разом вскрывают. Участники с высокой и низкой оценкой высказываются. Карты забирают и выкладывают заново, пока не будет достигнут консенсус.

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

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

Мы разрабатываем софт уже более 9 лет, поэтому расскажем именно об отделе разработки. Для всех проектов мы используем методологию SCRUM. Тем не менее в процессе работы мы поняли, что некоторые элементы системы все-таки нужно адаптировать под себя.

Команда отдела разработки

Спринты занимают одну или две недели в зависимости от сложности конечной цели. Чтобы задачи не путались, придерживаемся принципа: один программист может участвовать только в одном проекте.

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

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

Система

Сперва мы пользовались сторонними таск-трекерами. Но вскоре мы разработали свою платформу — Аспро.Agile.

Систему создавали для себя более пяти лет. Что-то дорабатывали, что-то убирали и совершенствовали. Сейчас решили поделиться. Это платформа с простым и понятным интерфейсом и своими фишками. Например, база знаний. Мы используем ее, чтобы опыт решения задач не терялся. Также это полезно для Junior-разработчиков, которые могут не спрашивать старших коллег по типовым вопросам. Если столкнулись с необычной проблемой, стараемся записать ее решение в базу знаний.

Задачи

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

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

Стендапы

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

Закрытие спринта

По итогам спринта получается готовый продукт или его часть. При грамотном менеджменте поставленная цель будет достигаться всегда. Также перед закрытием спринта специалист из другого проекта проводит код-ревью. Получаются своего рода кросс-проверки.

Также подсчитываем сторипоинты. Так продакт-менеджеру проще следить за производительностью команды и распределять нагрузку. Чем больше мы работаем, тем точнее получается рассчитывать сроки и ресурсы на проект. Да и присутствует некий элемент соревновательности между ребятами.

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

Разумеется, мы посоветуем воспользоваться нашей платформой Аспро.Agile. В ней есть все, что нужно для рабочего процесса, который мы описали. Также предусмотрен прямой импорт из Jira, встроенный мессенджер, уведомления и комментарии к задачам.

Но Аспро.Agile — это лишь набор инструментов, которые помогут выстроить гибкий рабочий процесс в вашей команде. Платформа не будет функционировать сама по себе: команда должна проводить стендапы и оценивать типовые задачи. Чтобы Аспро.Agile стал вам по-настоящему полезен, вам нужно выстроить весь рабочий процесс по методологии SCRUM. И эффективность команды будет зависеть только от вас.