Для инженерных и продуктовых команд процесс имеет первостепенное значение. Доставка готового проекта — это конечный пункт, но добраться до него можно разными путями.
Многие команды используют в качестве методологии управления проектами фреймворк Agile, но в рамках этого фреймворка существуют свои способы организации работы: Kanban и Scrum.
Здесь мы рассмотрим их различия, чтобы вы могли принять оптимальное решение для своей инженерной команды. Мы также приведем пример построения этих фреймворков с помощью Ноушен.
Сходства Kanban и Scrum
Канбан и Скрам берут свое начало в японской обрабатывающей промышленности. Они были разработаны как способы управления производством на каждом этапе, сохраняя гибкость к потребностям процесса и повышая его скорость.
В конце концов, они перекочевали в программное обеспечение через Agile-методологию, где на протяжении десятилетий определяли подходы к повышению производительности технических команд.
В 90-е годы разработка программного обеспечения не успевала за спросом. Процессы были тяжелыми и негибкими (большинство разработчиков использовали методологию Waterfall — линейный, последовательный подход к управлению проектами). Поэтому в 2001 году группа разработчиков собралась в Сноуберде (штат Юта), чтобы воплотить в жизнь новый процесс. Результатом стал Манифест Agile — совершенно новый подход к управлению проектами с точки зрения разработки программного обеспечения.
Эти итеративные, бережливые подходы как нельзя лучше подходят к новым потребностям разработчиков. Сходство между Kanban и Scrum заключается в следующем:
- Крупные и сложные проекты разбиваются на более мелкие и управляемые задачи.
- Они оба являются легковесными и делают упор на итеративный процесс разработки.
- Непрерывная поставка — это цель.
- Обратная связь с пользователями является приоритетной, поэтому вы знаете, что создаете то, что нужно людям.
- Большое значение придается постоянному совершенствованию программного обеспечения.
- Стремится к оптимизации рабочих процессов и технологических схем.
- Работа отображается в общей базе данных, что позволяет всем быть в курсе состояния проекта.
Различия между Kanban и Scrum
Несмотря на схожесть идеологии, Kanban и Scrum имеют нюансные различия в исполнении, которые следует учитывать, прежде чем принять одну из них. Давайте разберем их, чтобы вы могли принять оптимальное решение для своей команды разработчиков.
Роли и обязанности команды
Возможно, самое большое различие между Kanban и Scrum заключается в ролях, которые требуются от членов команды, работающих в рамках каждой из этих схем.
В методологии Scrum существуют заранее определенные роли и обязанности:
- Владелец продукта — этот человек определяет стратегию. Он отвечает за планирование проекта, расстановку приоритетов в задачах и облегчение коммуникации между членами команды. Другой частью этой роли является защита интересов заказчика, что помогает определить приоритетность работ, выполняемых командой разработчиков.
- Scrum-мастер — этот человек диктует сроки выполнения и отгрузки. Он контролирует процесс, обеспечивая подотчетность команды принципам Scrum (аналогично менеджеру проекта).
- Команда разработчиков — это инженеры, выполняющие работы, которые проводятся в спринтах (подробнее об этом позже).
В Kanban нет никаких структурированных ролей. Конечно, в инженерной команде такие роли могут существовать, например, кто-то отвечает за интервью с клиентами или управление проектами. Но Канбан не диктует их. Это скорее совместный подход.
Для вашей команды: Если у вас уже есть эффективная структура команды и прочные рабочие отношения, то, возможно, Канбан лучше подходит для вашей команды. Если же вам необходимо создать такую структуру, то лучше всего подойдет Scrum.
Каденция работы, планирование и релизы
И Kanban, и Scrum являются итеративными, но каждый из них имеет свою философию в отношении того, как выполняется работа.
Scrum-команды работают по конкретному графику разработки продукта.
- Спринты — двухнедельные периоды, предназначенные для ограничения объема работ, когда необходимо выполнить конкретные задачи, связанные с проектом. Владелец продукта совместно с командой разработчиков планирует эти спринты, извлекая задачи из бэклога продукта и помещая их в каждый спринт в зависимости от приоритета. Релизы обычно делаются в конце каждого спринта или в конце нескольких спринтов.
- Ежедневные Scrum-совещания — обычно владелец продукта также организует Scrum-совещания (например, ежедневные stand-up’ы) для координации работы на каждый день, проверки элементов из бэклога спринта и согласования задач.
- Ретроспективы являются частью каждого спринта — здесь команда оценивает свою работу в ходе обзора спринта, определяет, как ее лучше оптимизировать, и затем переходит к следующему спринту. Ориентируясь на скорость, Scrum-команда должна лучше оценивать, какой объем работы может быть выполнен в каждом спринте. Если команда выполнит 25 задач в течение спринта, она не согласится выполнить 40 задач в следующем спринте. Вот шаблон agile-ретроспективы, который вы можете использовать!
Канбан — это скорее усилия по организации непрерывного потока работ, который может быть адаптирован к конкретным потребностям команды разработчиков и в большей степени самоорганизован.
- Карточки, а не спринты — доска Kanban организована по столбцам, которые команда разработчиков настраивает в зависимости от своего процесса (например, «В работе», «Требуется пересмотр» или «Завершено»). В каждой колонке находятся карточки (задачи), которые команда разработчиков перемещает на каждом этапе своего рабочего процесса. Для выполнения определенного объема работ не существует установленных сроков.
- Выявление улучшений процесса — по своей природе метод Канбан обычно выявляет «узкие места». Если вы видите слишком много карточек в колонке «Требуется рецензирование», возможно, вам необходимо оценить свой процесс рецензирования. Обычно существует «лимит WIP», ограничивающий количество элементов в колонке «Незавершенное производство». Команды назначают максимальное количество карточек, которое может находиться в каждом столбце, чтобы все двигалось вперед.
- Освобождение по мере готовности — карточки перемещаются по каждому этапу на доске Kanban, когда задача готова к следующему шагу процесса. Релизы функционируют аналогичным образом. Когда дело сделано, выпускайте его. Спринты не диктуют рабочий процесс или запуск. Конечно, команда может диктовать и свои собственные запуски.
Для вашей команды: Когда речь идет о рабочем процессе в вашей команде, подумайте о том, как вы в настоящее время выполняете проекты. Если график отгрузки не соответствует желаемому, используйте Scrum, чтобы подтолкнуть команду к более своевременному завершению проектов. Если ваша команда нуждается в улучшении процесса, то Kanban — это метод, который поможет определить, где вы можете стать лучше.
Изменения в процессе
В процессе Scrum вы практически не ограничены в своих возможностях.
Много времени уходит на то, чтобы сделать спринт эффективным — как при планировании спринта, так и при его ретроспективе, — поэтому изменения нежелательны.
Но идея заключается в том, чтобы закрепить объем работ в рамках спринта. Однако, поскольку владелец продукта отстаивает интересы клиента, если он получит информацию о том, что функция или задача менее ценна для клиента, объем работ в спринте может измениться. Но в целом идея заключается в том, чтобы сохранить то, что было определено в начале спринта.
Канбан — почти полная противоположность. Он приветствует изменения.
Проекты, рабочие процессы, задачи — Канбан надеется улучшить процесс, распознавая эти изменения и позволяя постоянно совершенствовать проект по мере его завершения. Если задача блокируется или накапливаются элементы WIP, то на это, скорее всего, есть причина. И ваша команда может реагировать на это в зависимости от гибкости процесса.
Для вашей команды: Если вам нужно что-то более жесткое, поскольку в вашей команде уже сложился устойчивый порядок работы, то вам может подойти Scrum. С другой стороны, Kanban помогает команде сохранять гибкость и находить оптимальный процесс, необходимый для завершения проектов.
Создание доски для Scrum или Kanban
Пока мы обсуждали все различия Scrum и Kanban, в Ноушен можно построить доску, которая возьмет лучшее из обеих практик. Нет необходимости выбирать между инструментами управления.
Канбан и Скрам могут функционировать совместно — Канбан для визуализации работы, а Скрам для ее поэтапного выполнения (иногда это называют «скрамбан»). Конечно, процесс придется адаптировать к требованиям методологии Scrum или Kanban (например, создать мастера Scrum), но вы можете сделать одну доску Ноушен, которую можно приспособить к любой системе.
Этот шаблон дорожной карты поможет вам начать работу, а если вы хотите углубиться и изучить расширенные возможности этой доски, то вот система управления проектами, которая поможет вашим инженерам отслеживать каждую инициативу.
1. Изготовить доску
На новой странице Ноушен создайте доску. По сути, это доска Kanban, поскольку работа представлена в виде карточек, по которым можно перемещаться на каждом этапе процесса — процесса, который вы создаете и настраиваете так, как удобно вашей команде.
2. Настроить его колонки
Щелкните на каждом из столбцов, чтобы изменить их названия. Вы можете даже добавить дополнительные столбцы в зависимости от процесса работы вашей команды.
Рядом со столбцами расположено число. Щелкните на нем, чтобы увидеть различные варианты подсчета того, что находится в каждом столбце. Если вы внедряете систему Kanban, вы можете совместно с командой установить предел количества карточек в колонке «Незавершенные работы».
Если вы работаете в Scrum, то первый столбец может быть назван «Задачи», в котором будут содержаться все задачи, которые вы планируете выполнить в течение спринта.
3. Персонализация карт
Вот где можно работать в спринтах Scrum.
Внутри карточек появится список свойств. Их можно добавить сколько угодно — например, свойство Person для пометки Scrum-мастера или владельца продукта, чтобы они были в курсе состояния всех этих задач.
Сделайте одну из задач свойством Select и создайте различные теги для спринтов, например «Спринт 1», «Спринт 2» и т.д.
Внутри карточки можно хранить всю информацию, относящуюся к данной задаче. Независимо от того, использует ли ваша команда инженеров Scrum или Kanban, объединение всей информации для выполнения поставленной задачи — это способ обеспечить эффективную работу инженеров.
4. Добавьте всю информацию о проекте внутрь карточек
Вместо того чтобы просто направлять вас к работе, Ноушен — это место, где происходит и управление проектами, и работа над ними.
Внутри карточек можно добавить любой контент, который поможет вам выполнить проект или задачу (с бесконечным количеством слоев, если они вам нужны). Страница для кода. Страница для дизайна. Страница для идей и вдохновения. Большинство программ для управления проектами не позволяют выполнять работу. Чтобы что-то сделать, приходится переключаться между вкладками или инструментами.
Но хранение всей информации — от сроков до репозитория кода — в одном месте и в удобном для поиска виде дает огромные преимущества, создавая видимость работы всей команды.
5. Пользовательское представление этой доски для каждого спринта
В Ноушен можно по-разному нарезать одни и те же данные. Так, можно создать представление, в котором будут видны только задачи для «Спринта 1», и совершенно отдельное представление той же доски, в котором будут видны только задачи для «Спринта 2».
Нажмите + Добавить вид рядом с названием доски, выберите Доска и нажмите Создать. Затем нажмите Filter и + Add a filter. На экране появятся все ваши свойства, в которых вы сможете выбрать, чтобы отображались только задачи, помеченные спринтом, в котором вы сейчас находитесь.
6. Оптимизация для более эффективного использования
Когда ваша команда выполнит несколько проектов с использованием этой доски, посмотрите, где ее можно улучшить.
Вы уже знаете, что можете настроить ее в соответствии с потребностями вашей команды, но, зная о том, как ваша команда выполняет свою работу, пришло время оценить, как эта доска может лучше поддержать вашу команду. Если вы используете Kanban, вы можете делать это на протяжении всего процесса выполнения. Если вы используете Scrum, делайте это во время ретро.
Какой бы метод вы ни выбрали, эта доска может поддерживать оба способа, помогая вашей команде оставаться на связи, управлять процессом и быстрее выпускать продукцию.