Скрам-доска, или Scrum board, показывает работу, выбранную командой на один спринт: что ещё не начато, что выполняется, что проверяют и что готово. Scrum — подход к созданию продукта короткими циклами; доска служит способом видеть план, но не заменяет цель, договорённости и проверку результата.
Допустим, небольшая команда должна за неделю подготовить импорт цен из CSV-файла. Для работы достаточно обычных колонок и карточек, если участники согласовали результат и обновляют состояния вручную. Работа разделена на четыре задачи; ожидание уточнения формата отмечено как блокировка. Часы и обстоятельства вымышлены, а экраны Канбано сняты на отдельной демонстрационной доске.
Что подготовить для одного спринта
Для одного спринта подготовьте цель, границы по времени, доступность участников и работу, которую команда понимает достаточно для начала. Выбор колонок имеет смысл после этих договорённостей: иначе на доске окажутся пожелания, не связанные общим результатом.
В Scrum план создают и меняют Developers — участники, которые выполняют работу по созданию продукта. Product Owner отвечает за продуктовую ценность, Scrum Master — за применение Scrum. Доска не передаёт их ответственность руководителю, который раздаёт карточки. Перед настройкой полезно сверить первичные правила, чтобы не принять привычку конкретной команды за требование метода.
Какой инструмент нужен для выбранного цикла
Инструмент для выбранного цикла должен показывать согласованный план и фактическое продвижение работы. Бесплатная онлайн-доска подходит для ручного ведения: участник открывает карточку, читает результат и меняет состояние после действия. Наличие специального поля «Спринт» для самого изображения плана необязательно.
Набор колонок не превращает работу в Scrum. Если в команду непрерывно поступают независимые обращения, а общей цели на цикл нет, спринтовая схема может оказаться искусственной. Сначала стоит сопоставить рабочие подходы, а не переименовывать входящую очередь в спринт.
Для учебного примера выбор уже сделан: команда ведёт одну цель в течение недели. От инструмента требуется показать четыре задачи и их состояние, а не автоматически оценивать сотрудников или объявлять цель достигнутой.
Как связать цель с выбранной работой
Цель связывают с выбранной работой через пригодный для пользователя результат. В примере оператор должен загрузить CSV с ценами, увидеть ошибки, подтвердить корректные строки и получить обновлённый прайс. Отдельная просьба выгрузить прайс в PDF в эту цель не входит.
Спринт длится не больше месяца; неделя здесь — условие примера, а не обязательный срок для каждой команды. Из Product Backlog, общей продуктовой очереди, выбирают работу для этой цели. До отбора нужно подготовить общую очередь, не перенося на доску все пожелания.
Sprint Backlog, план спринта, включает цель, выбранную работу и способ её выполнения. Одна колонка с названием «Бэклог» не содержит всех этих договорённостей. Их нужно сохранить так, чтобы участники могли свериться с ними во время работы.
Как проверить выполнимость плана
Выполнимость плана проверяют по доступности нужных специалистов и зависимостям задач. Допустим, разработчику серверной части, backend, доступны 24 часа, разработчику интерфейса, frontend, — 16, специалисту по проверке качества, QA, — 10. Всего получается 50 часов.
Выбранные задачи занимают соответственно 22, 12 и 8 часов: 42 часа, остаток — 8. Общая сумма не означает, что любой свободный час заменит работу специалиста. Четыре свободных часа frontend не устранят перегрузку backend без соответствующих навыков.
До старта согласуйте структуру CSV, пример ошибочной строки и ожидаемое поведение подтверждения. QA может готовить проверки параллельно разработке, но проверка всего пути зависит от соединённой функции. Для своего календаря нужно отдельно сверить доступную мощность.
Оценки в часах — договорённость учебной команды. Остаток не является нормативным резервом Scrum, а часы не переводятся автоматически в story points, условные оценки сложности.
Как заполнить доску на примере импорта прайса
Доску импорта прайса заполните четырьмя карточками, которые вместе приводят к одной работающей функции. Технические части плана не стоит выдавать за четыре самостоятельных результата для оператора: чтение файла без проверки и сохранения ещё не завершает импорт.
Для условной команды план выглядит следующим образом. Backend, frontend и QA обозначают ответственность по навыкам, а не отдельные встроенные роли Канбано.
| Карточка | Оценка, часы | Ответственность | Проверяемый результат |
|---|---|---|---|
| A. Прочитать согласованный CSV | 12 | Backend | Корректная строка читается по согласованному формату |
| B. Показать ошибки строк | 12 | Frontend | Оператор видит номер и причину ошибки; корректные строки не теряются |
| C. Сохранить подтверждённые цены | 10 | Backend | Подтверждение обновляет только корректные цены, отмена не меняет прайс |
| D. Проверить путь импорта | 8 | QA | Проверены корректный файл, ошибка строки, подтверждение и отмена |
Карточка C зависит от согласованной проверки данных и поведения интерфейса. QA начинает со сценариев, а заканчивает проверкой связанного пути. Перестановка карточек не отменяет эти зависимости.
Какие состояния нужны выбранным задачам
Выбранным задачам нужны состояния, по которым участники различат ожидание старта, выполнение, проверку и завершение. В примере используются четыре колонки; условия перехода записаны отдельно, чтобы одинаковый статус означал одинаковое положение дел.
| Колонка | Условие перехода | Что остаётся видимым |
|---|---|---|
| Выбрано на спринт | Работа поддерживает цель и включена в выполнимый план | Выбранный объём отдельно от общей продуктовой очереди |
| В работе | Исполнитель действительно приступил | Блокировка, причина ожидания и ближайший шаг |
| На проверке | Результат передан вместе с материалами для проверки | Кто проверяет и какие условия ещё не подтверждены |
| Готово | Согласованные критерии выполнены, проверки пройдены | Подтверждение результата |
Заблокированную начатую карточку не убирают обратно в очередь, будто работа не начиналась. Она остаётся на текущем этапе с пояснением ожидания. Колонка на каждого сотрудника для этого не требуется.
Если нужен маршрут для другого процесса, можно подобрать процессную заготовку. Схема спринта не обязана подходить для согласования документов или входящих заявок.
Какие сведения добавить к карточке
К карточке добавьте ожидаемый результат, условия проверки и зависимость, без которой работу нельзя закончить. У карточки C «Сохранить подтверждённые цены» описание должно объяснять, когда прайс меняется и когда остаётся прежним.
Например: «Сохранить только подтверждённые корректные строки. Отмена не меняет цены. Формат данных согласован с карточками A и B. Проверить подтверждение, отмену и исключение ошибочной строки». Назначьте исполнителя и срок, а проверяемые действия перенесите в чек-лист. Пример согласованного файла можно приложить к карточке.
Идентификатор C и оценка 10 часов — ручные записи. Они не означают, что в Канбано появились специальные поля оценки спринта или автоматическая связь между задачами. Для блокировки нужен текст с причиной и следующим действием; цвет без пояснения не показывает, кто должен ответить.
Почему непроверенная функция остаётся незавершённой
Непроверенная функция остаётся незавершённой, потому что наличие кода ещё не подтверждает рабочий путь оператора. В примере недостаточно прочитать CSV: нужно проверить ошибки, подтверждение сохранения и отмену без изменения прайса.
Критерии импорта относятся к конкретной функции. Definition of Done, или DoD, задаёт общий стандарт качества команды. Перед завершением нужно согласовать стандарт завершения, а затем проверить оба набора условий, не подменяя один другим.
Допустим, чтение файла проверено, а отмена сохранения — нет. Карточка A может быть завершённой частью плана, но пригодный результат всего импорта ещё не подтверждён. Даже четыре карточки в правой колонке не доказывают, что оператор получил функцию. Результаты проверки сохраняйте ссылкой или вложением, доступным участникам.
Как вести спринт в Канбано
Спринт в Канбано ведут на обычной доске: создают колонки, записывают выбранную работу и вручную обновляют карточки. Онлайн-версия сейчас бесплатна, поэтому учебный план можно проверить в совместной работе без оплаты облачной доски. Соблюдение правил спринта при этом остаётся задачей команды.
На реальном учебном экране ниже показана середина цикла: чтение файла завершено, интерфейс и проверки в работе, сохранение цен ожидает уточнения. Колонка «На проверке» пока пуста. Пустое состояние не требуется заполнять ради симметрии.
Как собрать рабочую доску вручную
Рабочую доску соберите с названием результата и границами спринта, затем добавьте четыре колонки из таблицы и четыре карточки A–D. Даты 26–30 октября на демонстрационном экране — условная неделя примера, а не обещание фактического выпуска продукта.
В отдельной карточке «Правила спринта» запишите цель и ссылку на общий стандарт готовности. Инструкция не является пятой рабочей задачей: не учитывайте её как выполненную функцию. Текущие состояния храните только в рабочих карточках, без второго списка статусов в описании правил.
Для сохранения собственной доски нужен аккаунт; проба на главной служит знакомству с продуктом. Конкретный встроенный Scrum-шаблон здесь не предполагается — маршрут собирается вручную.
Как сверять продвижение к цели на Daily
На Daily Scrum участники выполнения за 15 минут каждого рабочего дня сверяют продвижение к цели и адаптируют ближайший план. Доска даёт предмет разговора: какая работа близка к завершению, что мешает проверке и какое действие требуется дальше.
Можно начать с правой колонки и двигаться к началу, но порядок обхода — приём команды, не обязательное правило Scrum. Встреча не должна превращаться в индивидуальные отчёты начальнику. Длительный разбор технической ошибки продолжите отдельно с теми, кому он нужен.
В примере QA может попросить пример файла с неверным разделителем, пока frontend показывает ошибки строк. Договорённость сразу меняет ближайшую работу. Карточки обновляют при фактическом изменении, а не только перед утренней встречей.
Как обновлять план во время работы
План обновляют при появлении новых сведений, сохраняя цель и согласуя изменение объёма с Product Owner. Допустим, уточнение разделителя CSV добавило backend два часа. Его оценка выросла с 22 до 24 часов, а общий план — с 42 до 44 из доступных 50.
Карточка C остаётся в работе с ручной меткой «Блокировка». В описании указаны причина ожидания, участник следующего действия и момент проверки ответа. В примере нужно согласовать формат; после ответа метку снимают вручную.
Проверьте, входит ли повторный тест в восемь часов QA. Если нет, пересогласуйте план: шесть оставшихся часов команды нельзя автоматически считать свободным временем QA. Запрос PDF оставьте в общей очереди. При избытке начатого полезнее ограничить начатую работу, чем открыть ещё одну карточку без возможности закончить прежние.
Как поступить с незавершённым объёмом
Незавершённый объём возвращают в Product Backlog для дальнейшего решения, а в следующий спринт выбирают заново. Автоматическое копирование недоделанного скрывает необходимость проверить актуальность и выполнимость нового плана.
Если связанный путь импорта не прошёл проверки, не объявляйте цель достигнутой. Сохраните датированное состояние прошедшего цикла и причину незавершённости. Дальнейшая оценка должна учитывать оставшуюся работу, включая повторную проверку, а не только часы написания кода.
На Review обсуждают получившийся продуктовый результат; на ретроспективе — изменение способа работы. Для примера улучшением может стать согласование образца CSV до следующего планирования. У действия должны быть ответственный и способ проверить выполнение; один разговор о проблеме ещё не меняет процесс.
Доска спринта полезна, если по ней видно, какой результат команда собирается получить и что пока мешает его использовать. Зафиксируйте цель и условия завершения, затем создайте спринтовую доску для одного цикла. Перемещайте карточки по факту, а завершение подтверждайте проверкой функции, не видом правой колонки.