Scrum и Kanban: как джунам не запутаться в процессах и терминах
Привет!
Эта статья по большей части будет полезна людям, которые только начинают погружаться в процессы работы команд, применяющих Agile. После общения со стажерами и джунами в компании сразу становится понятно, что помимо погружения человека в технические инструменты работы конечно важно объяснять и основные методы работы проектных и продуктовых команд, большая часть которых работает по Kanban или Scrum.
Не забываем, чтобы работать по Agile, в первую очередь важно придерживаться Agile-манифеста и его ценностей. Не достаточно просто работать в таск-трекерах и применять Kanban и Scrum.
Имея опыт администрирования Jira, настройкой проектов и досок для многих команд, а также работой на других проектах по Scrum и Kanban подходам, хочу поделиться простым языком терминами и процессами, которые применяются в командах.
Я не буду брать общепринятые термины, которые написаны в книгах по Agile, их вы и без меня можете прочитать. Постараюсь объяснить здесь таким языком, как объясняю это новым специалистам при их онбординге на проекты.
В первую очередь нужно сказать пару слов про Agile.
Agile - это набор методик и подходов для гибкого управления проектом по разработке программного обеспечения. Есть написанный манифест принципов и ценностей, которые описывают этот способ разработки.
Есть разные методики управления проектом: Kanban и Scrum.
Kanban - методология, в которой делается акцент на визуализацию задач, которые сейчас находятся в работе у команды разработки. В зависимости от приоритетов, новые задачи могут поступать и браться в работу каждый день, в Kanban не выставляются итерации работы по времени.
Главным инструментов в работе Kanban команды является Kanban-доска.
Она делится на столбцы со статусами, самым простым набором статусов являются: To Do - In Progress - Done.
По мере добавления и изменения статусов меняется процесс работы над задачами, который называется Workflow. Например, можно сделать гибкий workflow под команду To Do - Analysis - Ready for Development - Development - Ready for Test - Testing - Ready for Deploy - Done (Cancelled, On Hold как вспомогательные статусы). Workflow должен соотноситься с запросами команды и количеством разных ролей. Здесь играет правило простоты: чем меньше и проще флоу, тем эффективней может быть работа и меньше раз нужно отвлекаться на обновление статусов на доске.
В Kanban важно следить за приоритетами и количеством задач, которые в одно время могут находиться в работе. Например, для приоритетов можно использовать шкалу:
Low (задачи на потом, когда будет свободное время и ресурсы).
Medium (запланированные задачи с с подглядывающим в будущем дедлайном).
High (эти задачи как правило еще нужно было сделать вчера).
Blocker (если такие задачи не сделать в первую очередь, то вся остальная работа будет заблокирована. ещё хуже, когда это баги или сбои, которые очень сильно влияют на проект/продукт и его бизнес-ценность).
Для группировки задач по каким-либо признакам (исполнитель, модуль разработки, приоритет) и категориям можно применять swimlanes - горизонтальное разделение и объединение задач на доске.
Какие виды досок можно использовать?
физическая
виртуальная
Метод работы с физической доской уже давно устарел, т.к. есть множество альтернативных систем, да и физические стикеры на доске не так удобны в процессе работы над задачей. Доску можно использовать для знакомства своей команды с Kanban может пригодится, чтобы освоить процесс работы, дальше переходить на цифровые продукты (главное не затянуть это процесс и не остаться жить со стикерами на проекте:).
Если говорим про виртуальные доски, то здесь на помощь приходит множество продуктов, которые готовы предложить разнообразный функционал
Jira - инструмент, который включает в себя как Kanban, так и Scrum доски, множество настроек, а также функционала для технических специалистов с возможностью интеграций с другими системами.
Trello - более простая версия Jira с меньшим функционалом, но более простым интерфейсом для новичков, кто раньше не работал с подобными инструментами.
Miro - доска с возможностью ее использования для написания стикеров и их передвижения как по физической доске. Очень просто и подходит для бизнес-команд.
Переходим к обсуждению Scrum
Scrum - методология для разработки ПО, где где работа идет по итерациям (спринтам), в которые должен выполняться взятый в спринт список задач.
Самые главные определения из Scrum:
Backlog - список задач, который формируется на основе выявляемых запросов на доработку или новых требований. Задачи из бэклога сортируются, приоритизируются по важности и ценности внедрения, оцениваются по трудозатратам, после чего берутся в спринт для выполнения.
Sprint - временная итерация работы над задачами, которые были взяты в работу. Спринты обычно планируются продолжительностью в 2 недели (иногда неделя или месяц), во время спринта все взятые в него задачи должны быть успешно завершены.
Scrum Board - доска, которая напоминает Kanban доску, где есть также столбцы статусов рабочего процесса (workflow), и задачи, распределенные по статусам. Отличие от Kanban заключается в том, что на Scrum доску попадают только те задачи, которые взяты в текущий активный спринт. Все остальные задачи на доску не выводятся и лежат в списке Backlog вне доски.
Оценка задач по трудозатратам:
Story point - единица оценки задач по трудозатратам. Каждая команда вправе выбирать свою шкалу для story point. При оценке задач в story points учитывается количество работы, сложность работы, риски и возможные неопределенности во время работы. Например, 1 story point = собрать пазл из 100 деталей, тогда задача по сбору пазла из 1000 деталей не обязательно должна быть оценена в 10 story points, т.к. сложность пазлов может быть разная, рисков может не быть совсем. Оцениваем работу не по одному показателю, а комплексно по всем перечисленным.
Для каждого члена команды устанавливаются лимит пойнтов, который он может взять в спринт для работы. В зависимости от доступности человека во время спринта этот лимит соответственно меняется пропорционально количеству дней, которые работает член команды во время спринта.
Например, для новеньких членов команды первые несколько спринтов можно устанавливать лимит в 2 или 3 раза меньше чем для других, это время для онбординга. Также не стоит забывать, что senior и junior могут оценивать одну и ту же задачу по разному, т.к. сложность работы и скорость выполнения для них будет разная.
Time Evaluation - метод оценки задач в обычных часах. На виртуальных досках есть обычно поля estimation, где записывают ожидаемое время, которое уйдет на задачу. Далее во время работы над задачей это время можно понемногу списывать.
T-shirt evaluation - еще один способ оценки трудоемкости задач. Идея очень проста, нужно сделать с командой шкалу оценки по названиям размеров футболок. Например, маленькие и простые задачи будут размера S, а более комплексные задачи будут L или XL. Кто забыл ранг, напоминаю: S, M, L, XL, XXL.
Критерии для подготовки и завершения задач
Definition of Ready - критерии готовности задачи, чтобы ее можно было взять из бэклога в спринт. Перед тем как задача попадет в спринт, команда должна заполнить задачу, написать описание, определить исполнителя задачи, проставить зависимости, приоритеты, оценить трудоемкость. DoR определяет набор таких критериев, по которым команда готова взять подготовленную задачу в спринт. В нашей команде определены следующие критерии, без выполнения которых мы не берем задачу в спринт.
понятное название и описание;
указан исполнитель;
написаны критерии приемлемости;
определены зависимости с другими задачами;
поставлена оценка трудоемкости;
задача не является заблокирована другими задачами.
Definition of Done - список критериев, по которым команда определяет успешное выполнение задачи. Если все критерии DoD успешно выполнены, то задача может считаться сделанной и отправиться в Done. Например, такими критериями в аналитической таске могут являться:
контакты бизнес-владельцев продукта определены и зафиксированы в реестре;
текущее состояние функционала описано;
желаемое состояние функционала описано;
все находки и процесс работы задокументированы;
возможные риски определены и донесены до владельца продукта;
задача для разработчиков поставлена и описана.
Ниже приведен пример пользовательской истории, которая заполняется в Jira. Что здесь есть: acceptance criteria, priority, definition of done, description. Что можно добавить: назначить задачку на конкретного исполнителя, чуть подробней сделать description с ссылками на документацию (зависит конечно от задачи), оценить задачу в story points или другим методом оценки
Конечно в настоящих задачах и проектах критерии описываются более точно.
Scrum встречи
Пару слов стоит еще сказать про Scrum встречи, которые проходят регулярно каждый спринт.
Backlog refinement - встреча технической команды, на которой обсуждается план работы на будущий спринт. В процессе встречи планируется список задач из бэклога, который будет взят в следующий спринт. На этом этапе задачи уже должны соответствовать критериям DoR, чтобы попасть в спринт. Также на этой встрече уточняются приоритеты задач с владельцем продукта или менеджером проекта, чтобы следовать общей дорожной карте развития продукта.
Sprint Kick-off - встреча, на которой команда финализирует список задач из бэклога, которые пойдут в спринт. Команда прописывает цели спринта, ставит даты и начинает спринт.
Daily scrum meeting - обычно такие встречи проводятся в ежедневном коротком формате, где каждый член команды может поделиться результатами работы за прошлый день и рассказать о планах на текущий день. Важно на таких встречах подсвечивать возможно возникающие трудности и риски, которые могут повлиять на ход выполнения задач в спринте.
Sprint Review - встреча, которая проводиться после окончания спринта, где обсуждаются итоги работы, которые были достигнуты. Часто на эту встречу приглашают главных стейкхолдеров проекта, чтобы донести до них бизнес-результаты по итогу сделанной работы.
Sprint Retrospective - встреча также проходит после завершенного спринта, на которой техническая команда обсуждает что было сделано хорошо во время спринта, с какими сложностями столкнулись, что можно улучшить в процессе работы. Это важная обратная связь от каждого члена команды, которая позволяет улучшать работу на проекте и делать команду продуктивней.