Что такое скрам доска

Разбираемся в Scrum и Kanban

Аспирант Нетологии Максим Пименов продолжает рассказ про гибкие методологии создания ПО. На этот раз Максим разбирает Kanban и Scrum — два подхода к работе над проектом, основанных на Agile.

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, о которых я писал в предыдущей статье.

Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.

Обе технологии близки, потому их инструменты можно комбинировать.

Команды в Kanban и Scrum

Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.

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

Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.

А вот дальше в Kanban и Scrum начинаются различия.

Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.

При этом универсальные команды не запрещены.

В Kanban внутри команды нет ролей.

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

Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.

В scrum-команде помимо собственно специалистов есть две роли.

Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:

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

Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.

Как составляют список задач

Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.

Все задачи проекта, которые предстоит выполнить, складывают в общий список — бэклог. Бэклог — это банк задач проекта. Каждая задача должна быть актуальна. Если потребуется, их можно добавлять в бэклог или удалять из него «на лету».

Каждая задача имеет вес — обычно это время, которое нужно на решение. Команда сама оценивает вес всех задач, поэтому если проект не закончен в срок, виновата команда.

Также у каждой задачи есть приоритет. В Kanban приоритеты расставляет команда, в Scrum — владелец продукта. Приоритеты можно и даже нужно пересматривать по ходу проекта — это один из столпов гибких методологий.

Как работают над проектом

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

Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.

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

Спринт состоит из четырех последовательных этапов.

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

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

По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.

Спринтов как таковых нет. Проект обычно делят на итерации, но они могут быть любой длины. Ритмичность Kanban не предписывает.

Вспомним этапы scrum-спринта:

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

Поскольку выраженных спринтов нет, появляются особенности:

Что за доски используют Scrum и Kanban

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

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

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

Карточки — это задачи. На каждой описание, вес и приоритет. Когда задача проходит очередной этап, ее переклеивают в соответствующий столбец. При простом взгляде на доску понятно, как дела с проектом в целом и с каждой задачей.

Доски бывают физические и электронные.

Физическая доска. Часто доска — это действительно доска с клетками из малярного скотча. Задачи — липкие листочки, которые удобно двигать по доске.

Настоящая доска стоит в комнате и каждый в команде видит, как идут дела. Вокруг настоящей доски хорошо собираться во время совещаний.

Электронная доска. Электронная доска под рукой на пляже, на даче, в машине и в метро. Если у вас есть сотрудники, которые работают удаленно, электронная доска — единственный выход.

Я люблю настоящие доски, но без электронных иногда не обойтись.

Источник

Что такое скрам-доска

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

Что такое скрам?

Скрам – это методика менеджмента, помогающая командам разработчиков, исповедующим Agile (то есть гибкую методологию разработки ПО), легче управлять поставленными задачами.

Если вы не знаете, что такое Agile, то вот небольшая справка, вкратце поясняющая суть методологии:

Скрам – это дополнение к Agile, позволяющее сделать процесс разработки нового ПО еще быстрее. Это достигается благодаря четкому формированию, распределению и делегированию задач в команде.

Основные принципы методологии

У методики scrum есть шесть основных сущностей.

1. Анализ пожеланий пользователей

Первое, что анализируют разработчики в команде, – story. Под этим термином подразумевается пласт данных, связанных с функциональностью ПО, в котором нуждаются пользователи. Речь идет о самой функции, особенностях ее реализации, сложности разработки, а также преимуществах, которые дает реализация конкретной функции. Анализ пожеланий пользователей можно упростить, если ответить на три вопроса:

2. Спринт

При использовании скрам-методологии каждый «забег» разработки длится от одной до четырех недель. Это одно из важнейших условий.

3. Бэклог продукта

Бэклог – это список задач, пользовательских пожеланий, улучшений, которые нужно внести в приложение, и ошибок, которые нужно исправить.

4. Бэклог спринта

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

5. Команда спринта

«Забеги» выполняются командами сотрудников, которые делятся на три функциональные группы:

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

Скрам-мастер. Один из лидеров, следящий за тем, чтобы программисты следовали скрам-принципам.

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

6. Ретроспектива спринта

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

Что такое scrum-board?

Мы разобрались с большей частью терминологии. Теперь можем перейти к доскам. Скрам-доска (или спринт-доска, или скрам-борд, или scrum-board, как будет угодно) – это визуальная презентация тех задач, что должны быть решены за один «забег».

Скрам-доска похожа на многоколоночный список элементов, позволяющий команде разработчиков:

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

Контролировать процесс работы. Наблюдать за сотрудниками и грамотно распределять между ними задачи/функции.

Следить за прогрессом текущего спринта. Чтобы задачи вовремя попадали в список выполненных.

Проводить аналитические совещания с целью обсудить успехи компании.

Такая доска может быть как физическим объектом (магнитная доска или доска, на которой пишут маркером), так и цифровой реализацией, т.е. приложением с функциональностью, присущей физическим скрам-бордам.

Структура скрам-доски

Скрам-борд делится на несколько блоков. Мы рассмотрим 6 распространенных блоков (их может быть больше или меньше).

Основные типы скрам-бордов

Тут нет замысловатой категоризации. Доски делят на физические и цифровые.

Физические доски

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

По мере продвижения разработки стикеры мигрируют из одной группы в другую, пока спринт не завершится.

Цифровые скрам-доски

А это приложения, которые имитируют поверхность для стикеров с описанием задач. Принцип работы тот же, но есть свои плюсы:

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

Цифровой доской можно пользоваться хоть вдесятером одновременно. Без помех и неудобств.

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

Визуальную составляющую цифрового скрам-борда можно настроить под свои предпочтения.

Кому стоит использовать скрам-доски?

Читая о том, как scrum-методику используют разработчики, вы уже наверняка попытались примерить ее на свою сферу деятельности (если она, конечно, еще не связана с разработкой ПО в рамках спринтов).

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

Аналогичная ситуация наблюдается у рекрутеров. Они собирают данные о кандидатах на доске и, тестируя их на разных этапах, перераспределяют из одной колонки в другую (проверенные, опрошенные и т.п.).

Но на деле scrum можно использовать в любой сфере деятельности и даже в повседневной жизни. Универсальность методики позволяет применить ее хоть на списке продуктов или же на любом совместном списке задач. Можно выставить в одной колонке цели вашей семьи, задачи, над которыми ведется работа, и то, что уже сделано.

Как правильно пользоваться скрам-бордом

Работа над списком задач формируется в 5 этапах.

Проанализируйте stories пользователей. Сотрудники компании еще на этапе планирования спринта должны выбрать, какие из элементов бэклога продукта должны быть реализованы в ходе надвигающегося «забега». Их добавляют в бэклог спринта.

Распределите задачи. Тимлиды вместе с разработчиками разбивают «хотелки» пользователей на отдельные карточки, чтобы было проще заниматься реализацией намеченных планов. Также они совместно занимаются делегацией задач. Выбирают, кто и чем будет заниматься.

Миграция задач из списка «Надо сделать» в «Делается». В ходе спринта разработчики должны регулярно брать задачи, чтобы не оставаться без дела и ускорять общий поток перехода задач в список выполненных.

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

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

Ключевые преимущества scrum-досок

Мы знаем, для чего нужны скрам-борды и уже умеем применять их на практике (в теории, конечно). Но почему стоит выбрать именно скрам, а не исследовать другие методологии, применяемые в разработке?

Scrum нацелена на увеличение производительности всей команды и упрощение коммуникации между ее участниками. Даже цифровая скрам-доска помогает собрать всех сотрудников вместе в одном пространстве и дать каждому возможность видеть общий фронт работ. Это облегчает понимание ситуации для каждого работника.

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

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

Отличия скрам от канбан

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

Спектр работ – в скрам-доске содержится только информация касаемо грядущего спринта. В 99% случаев задачи строятся вокруг принципов Agile и исключают более глобальные цели. А в канбан «улетают» вообще все задачи, что надо решить. Причем период и масштаб заданных целей не имеют значения.

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

Владельцы доски – скрам-доска привязана к конкретной команде и обособлена от остальной части компании. Канбан-доска может быть достоянием целой корпорации и использоваться всеми ее сотрудниками.

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

Аналитика – еще одна отличительная черта скрам-бордов. Визуализация аналитических данных в виде графиков, таблиц, схем и т.п. Все, что может позволить быстро оценить ситуацию.

Лучшие программы для создания цифровых скрам-досок

При внедрении методики scrum в работу команды, важно выбрать правильный инструмент.

Безусловный лидер, уже ассоциирующийся с Agile-разработкой. Поддерживает все необходимые для разработчиков функции, встроенную систему аналитики, множество механизмов сортировки данных и коммуникацию между сотрудниками.

ClickUp

Продвинутый цифровой scrum-board с возможностью наглядно устанавливать цели, а также находится в постоянном контакте со всеми программистами компании. Комментировать каждую карточку, например.

monday.com

Удобная система взаимодействия в Agile-команде с функцией интеграции других популярных сервисов. Также monday.com любят за обилие готовых шаблонов со всеми необходимыми колонками.

Wrike

Популярный инструмент для менеджмента больших команд в ходе спринтов. Им пользуются крупные корпорации в духе Google и Airbnb. Wrike более универсален и адаптирован не только под решение задач разработчиков.

Вместо заключения

Scrum – неотъемлемая составляющая Agile-разработки. Без этой методологии не получится грамотно и успешно контролировать рабочий процесс, подмечая все проблемные места. Скрам-доска не несет в себе ни единого недостатка, она точно сделает вашу команду эффективнее.

Источник

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

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

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

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

User Story

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Источник