Подходы к разработке по фреймворку 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 или заполните форму обратной связи, и мы свяжемся с Вами.
Похожие статьи
Спасибо! Ваша заявка отправлена
В ближайшее время мы с Вами свяжемся!
Капча введена не верно