Подходы к разработке по фреймворку Scrum

В этой статье мы расскажем о том, как команда разработчиков «Компании КомЛайн» выстраивает работу по методологии Scrum с использованием специальных инструментов. В фокусе - приоритизация бэклога, движение пользовательских историй по kanban доске, планирование и выполнение задач спринта.

В своей работе мы используем различные подходы: как классическую каскадную модель реализации проекта Waterfall, так и гибкие методологии, в частности фреймворк Scrum. Грамотное сочетание обоих подходов особенно актуально в сложных, масштабных проектах со сжатыми сроками, когда различные этапы могут проходить одновременно. Для успешного результата в этом случае крайне важно эффективно вести командную работу, быстро реагировать на изменения и оперативно контролировать ход всего проекта.

Остановимся подробнее на инструментах для работы в фреймворке Scrum, которые мы используем в разработке, на примере трекера Devprom.

Бэклог

Рис. Бэклог

В ходе моделирования бизнес-процессов предприятия в новой системе с помощью GAP-анализа происходит выявление функциональных разрывов (гэпов) и заполнение бэклога задачами на доработку — так называемыми user story или историями пользователей.

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

Для них выбирается направление доработки, и задачи передаются исполнителю – тимлиду со стороны «Компании КомЛайн».

В дальнейшем из приоритизированного бэклога будут формироваться спринты.

Жизненный цикл пользовательской истории

Рис. Канбан-доска

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

Бэклог - это полный список сформированных пользовательских историй с приоритетами, которые необходимо выполнить за проект. Квадратик на доске или карточка — это отдельная user story. Его цвет служит индикатором приоритета истории.

• Красный цвет – означает критичный приоритет. Это стопперы - истории пользователей, которые необходимо выполнить в первую очередь, поскольку на них могут быть завязаны основные бизнес-процессы заказчика.

• Желтый цвет – высокий приоритет. Пользовательские истории с высоким приоритетом - это основное, что необходимо выполнить для завершения проекта.

• Фиолетовый – обычный приоритет. User story с обычным приоритетом не мешают завершению проекта, но желательны для выполнения.

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

Приоритеты пользовательских историй могут меняться в зависимости от результатов спринта. Истории утрачивают актуальность, появляются новые. Для смены приоритетов обозначается запрос на проведение встречи backlog grooming, на которой исполнитель совместно с заказчиком актуализирует бэклог.

Из сформированного бэклога история переходит в колонку «Анализ».

На этой стадии происходит анализ функциональных разрывов, формируются технические задания для разработчиков, и предварительно оцениваются трудозатраты на разработку — все фиксируется в задаче с типом «Анализ» внутри истории.

В анализе гэпов принимают участие и функциональный архитектор со стороны исполнителя, и представители заказчика, которые отвечают за заданную user story.

После согласования сформированного технического задания с функциональным и системным архитекторами заказчика user story переходит на следующий этап - «Очередь разработки».

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

По завершении планирования спринта пользовательские истории переходят в колонку «Разработка». Таким образом в ней находятся user story, которые должны быть выполнены в ходе спринта (об этапах планирования спринта и разработки мы подробнее расскажем чуть ниже).

После того как разработчик выполнил задачу по техническому заданию, формируется задача для аналитика со стороны исполнителя на тестирование разработанного функционала — это отражает колонка «Тестирование». Она предназначена для отслеживания динамики выполнения задач по разработке и загрузки специалистов.

Если аналитика удовлетворяет результат выполненной доработки, задача перемещается в колонку «Ждет обновления». На этом этапе выполняется сборка релиза и его передача в базу заказчика.

Файл поставки сформирован, передан заказчику, и тестовый контур заказчика успешно обновлен? Значит, user story переходит в стадию «Приемка».

Когда пользовательская история попадает в «Приемку», назначается встреча, на которой присутствуют заказчик и аналитик со стороны исполнителя. На ней аналитик «Компании КомЛайн» демонстрирует разработанный функционал, проводится его тестирование на данных предприятия. Заказчик дает обратную связь. Если есть замечания, дополнительные требования, то в бэклоге заводится новая user story, приоритизируется и проходит все описанные ранее этапы. А текущая история переходит в колонку «Документация».

Здесь производится описание разработанного функционала и составление инструкции по работе с ним в системе Wiki. Когда все готово, история переходит в колонку «Закрыто» - финальную стадию жизненного цикла пользовательской истории внутри проекта.

Теперь чуть подробнее поговорим о планировании спринта, разработке в ходе спринта и сборке релиза.

Планирование спринта

Рис. Планирование спринта

Планирование спринта проходит по классической методологии фреймворка Scrum.

На совместной встрече собираются тимлиды и функциональные архитекторы «Компании КомЛайн» и заказчика, которые отвечают за определенный блок. В ходе обсуждения выбираются те задачи, которые необходимо решить в течение спринта, с учетом их приоритетов.

Непосредственно из колонки «Бэклог» задачи переносятся в «Спринт».

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

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

Это правило Scrum, которому необходимо следовать, иначе поставленные цели в установленные сроки не смогут быть выполнены.

Выполнение задач спринта

Рис. Движение задач внутри спринта

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

На момент планирования спринта все задачи, которые необходимо реализовать, попадают в колонку «Добавлена».

Техлид или системный архитектор «Компании КомЛайн» назначает ответственных исполнителей на задачи, чтобы сформировать очередь разработки по программистам и их оперативную загрузку на спринт. Сам разработчик в зависимости от приоритета берет задачу в работу, перенося карточку в колонку «В работе».

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

В результате спринта мы получаем пустые колонки «Добавлена» и «В работе» и переходим к завершающему этапу, когда исполнитель формирует файл поставки, который отображает все user story, реализованные за спринт.

В трекере Devprom для этого предусмотрен специальный инструмент — сборка.

После проведения тестирования разработанного функционала история пользователя добавляется в сборку.
Данный инструмент удобен для отслеживания того, какие user story были реализованы в том или ином релизе или сборке.

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

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

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

Есть вопросы? Позвоните нам по телефону +7 (843) 200-11-22 или заполните форму обратной связи, и мы свяжемся с Вами.