Что же такое Канбан?
Канбан - это метод управления процессами, который представляет собой визуальную систему для отслеживания задач в различных стадиях их выполнения.
Основы ведения учета задач на Канбан-доске включают в себя следующие шаги:
Определение колонок: Разделите доску на колонки (статусы), которые отражают различные этапы выполнения задачи. Обычно используются колонки типа "To Do" (к исполнению), "In Progress" (в процессе выполнения) и "Done" (выполнено). В зависимости от потребностей вашей команды вы можете добавить дополнительные колонки с самого начала, или позже в процессе работы, например, "Тестируется", "На рецензии" и т. д. Более детально вопрос колонок рассмотрим чуть ниже.
Визуализация задач: Напишите каждую задачу на отдельной карточке и поместите ее в соответствующую колонку на доске. Каждая карточка должна содержать краткое описание задачи и любую дополнительную информацию, необходимую для ее выполнения.
Управление потоком работы: Перемещайте карточки по колонкам на доске в соответствии с текущим состоянием выполнения задачи. Новые задачи добавляются в колонку "To Do", затем переходят в колонку "In Progress", а затем в "Done", по мере их выполнения. Если у вас больше колонок, определите допустимые маршруты перемещения задач по ним. Помните, что должен быть один осевой ("главный") маршрут. Отступления от осевого маршрута движения возможны, но чаще всего служат для обходя неожиданных препятствий в работе.
Ограничение рабочего процесса (WIP): Установите ограничение на количество задач, которые могут одновременно находиться в работе в каждой колонке (WIP-лимиты). Это поможет предотвратить перегрузку команды и повысить эффективность работы. Не на все колонки следует устанавливать WIP-лимиты. Самое простое, что вы можете сделать с самого начала - это ограничить количество задач на один рабочий день в колонке "В работе". Это приучит вас разбивать крупные работы на подзадачи таким образом, чтобы одна или несколько задач могли быть завершены сотрудником за рабочий день. В этом случае WIP-лимит колонки будет равен допустимому количеству задач для одного сотрудника умноженному на количество сотрудников. Для примера, если вы допускаете, что один сотрудник может делать одну задачу в день, и у вас три сотрудника, то установите WIP-лимит = 3.
Встречи стендап (stand-up): Проводите ежедневные короткие утренние встречи (не более 15-20 минут), на которых команда обсуждает текущий статус выполнения задач на доске, обнаруживает проблемы и принимает меры для их решения.
Постоянное совершенствование: Постоянно анализируйте процесс работы команды, ищите способы улучшения и внедряйте изменения в методику работы с канбан-доской, чтобы повысить производительность и качество работы.
Соблюдение этих основ поможет вашей команде эффективно использовать канбан-доску для управления задачами и достижения поставленных целей.
Как определить необходимые колонки для канбан доски?
Определение колонок для канбан-доски зависит от конкретного процесса работы вашей команды или проекта. Однако, в большинстве случаев, вы можете использовать следующий общий подход для определения колонок:
Входящие/Новые (Incoming/New): Эта колонка предназначена для всех новых задач, которые поступают в систему и ждут принятия решения о том, что с ними делать. Сюда могут входить новые запросы от заказчиков или идеи для новых функциональностей.
К выполнению (To Do): Задачи, которые были приняты к выполнению, но еще не начаты, помещаются в эту колонку. Это задачи, которые должны быть выполнены в ближайшем будущем.
В работе (In Progress): Эта колонка содержит задачи, которые находятся в процессе выполнения. Когда исполнитель начинает работу над задачей, ее карточка перемещается в эту колонку.
Тестируется (Testing): После завершения работы над задачей она может быть отправлена на тестирование для проверки на соответствие требованиям и исправления ошибок. Задачи, ожидающие тестирования, помещаются в эту колонку.
На рецензии (Review): В эту колонку помещаются задачи, которые требуют проверки или рецензии со стороны других членов команды или руководства перед завершением.
Выполнено (Done): Задачи, которые успешно выполнены и прошли все этапы процесса, перемещаются в эту колонку.
Это основные колонки, которые часто используются на канбан-досках. Однако вы можете настроить доску под конкретные потребности вашей команды, добавляя дополнительные колонки или изменяя существующие в зависимости от специфики вашего процесса работы. Важно помнить, что канбан-доска должна отражать реальный поток работы вашей команды и обеспечивать прозрачность и эффективность управления задачами.
Мы в METEOR приготовили демо-проекты, в которых вы сможете увидеть, как лучше строить доски, выбирая статусы для колонок и формулировать задачи. Регистрируйтесь, изучайте демо, задавайте нам вопросы и стартуйте учет своих проектов.
Какие виды задач бывают на канбан досках?
На канбан-досках могут быть различные виды задач, в зависимости от конкретного проекта, типа бизнеса или потребностей команды. Вот некоторые общие виды задач, которые часто встречаются в IT-проектах на канбан-досках:
Разработка функциональности (Feature Development): Это задачи, связанные с разработкой новых функциональностей или улучшением существующих. Включают в себя задачи по программированию, верстке дизайна интерфейса, разработке базы данных и т. д.
Исправление ошибок (Bug Fixing): Задачи, связанные с обнаружением и исправлением ошибок в программном обеспечении или продукте. Эти задачи могут поступать от пользователей, тестировщиков или автоматизированных систем тестирования.
Технический долг (Technical Debt): Это задачи, связанные с устранением недостатков в архитектуре или коде, которые намеренно с целью ускорения были созданы в процессе разработки и требуют дополнительной работы для улучшения качества продукта.
Дизайн (Design): Задачи, связанные с разработкой дизайна интерфейса пользователя, созданием макетов и прототипов.
Административные задачи (Administrative): Это задачи, не относящиеся напрямую к разработке продукта, но необходимые для обеспечения работы команды. Например, планирование встреч, управление ресурсами или обновление документации.
Исследование и анализ (Research and Analysis): Задачи, связанные с исследованием новых технологий, рыночного анализа или изучением потребностей пользователей для определения будущих направлений развития продукта.
Это лишь несколько примеров задач, которые могут встречаться на канбан-досках. Важно выбрать те виды задач, которые наиболее соответствуют вашему проекту или бизнесу, и адаптировать их в соответствии с потребностями вашей команды.
Epic, userstory, task - что это такое и как правильно выбрать?
"Epic", "User Story" и "Task" - это термины, широко используемые в методологии разработки программного обеспечения Agile, такой как Scrum и Kanban. Вот их определения и различия:
-
Epic (Эпик):
Эпик представляет собой крупное, высокоуровневое требование или задачу, которая обычно слишком большая, чтобы быть выполненной в рамках одной итерации или спринта.
Эпики обычно разбиваются на более мелкие и управляемые части, такие как User Stories или Tasks, чтобы обеспечить более эффективное планирование и выполнение работ.
Выбор эпика зависит от его важности для бизнеса, его приоритета и времени, которое потребуется на его выполнение.
-
User Story (Пользовательская История):
Пользовательская история - это краткое описание требований от пользователя, описывающее функциональность, которая приносит ценность для пользователя или бизнеса.
Они обычно представляют собой короткое описание того, что должно быть сделано, чтобы удовлетворить потребности пользователя, и включают в себя критерии приемки, определяющие, когда задача будет завершена.
User Stories позволяют команде лучше понимать требования пользователей и фокусироваться на создании ценности.
-
Task (Задача):
Задача - это конкретное действие или работа, которую необходимо выполнить для реализации User Story или другого типа задачи.
Они являются более детальным уровнем разбиения User Story и представляют собой конкретные шаги или задания, которые должны быть выполнены для достижения цели.
Задачи обычно составляются на основе User Story и помогают команде более эффективно планировать и отслеживать выполнение работы.
Выбор между Epic, User Story и Task зависит от уровня детализации требований, степени сложности задачи и контекста проекта. Если требуется управлять крупными кусками работы, начинайте с эпиков. Если нужно описать конкретные потребности пользователя или функциональные возможности, используйте User Stories. Затем, для конкретной работы, используйте задачи. Важно поддерживать баланс между высокоуровневым обзором и детальной спецификацией, чтобы обеспечить эффективное выполнение работы.
В общем случае иерархия может быть такая:
-
Epic 1
-
UserStory 1.1
-
Task 1.1.1
Таsk 1.1.1.1
Task 1.1.1.2
Task 1.1.2
-
-
UserStory 1.2
Task 1.2.1
Task 1.2.2
-
-
Epic 2
Task 2.1
Task 2.2
Task 2.3
Чем же отличаются типы Feature, Task, Bug, Design от Epic, UserStory, Task?
В самом начале пути, когда команда не готова в полной мере следовать Agile, мы рекомендуем использовать "говорящие" типы задач - Feature, Task, Bug, Design и так далее. Так вы сможете быстрее "подружиться" с работой на канбан-досках. Более опытным командам лучше следовать нотациям Epic, UserStory, Task, так как это вам даст лучшее взаимопонимание с руководством, другими командами и вашими пользователями.
В следующей статье мы расскажем как правильно декомпозировать крупные задачи и формулировать их, чтобы ваша работа была максимально точной и эффективной.
Поделитесь в комментариях, как вы ведете ваши канбан-доски, какие используете колонки, с какими сложностями сталкивались и как их проходили.
Успехов вам в вашем профессиональном творчестве!
Комментарии (4)
klimkinMD
19.04.2024 09:26С нетерпением жду следующую статью цикла "Как настроить работу на счётах...."
art241111
Мне на самом деле еще нравится столбец "На паузе". Как бы мы не хотели планировать, но бывает так, что задачи пересекаются и нужно понимать чем именно разработчик (аналитик, дизайнер и т.п.) делает.
И вот такой столбец как раз позволяет понимать на сколько мы плохо планируем и сколько задач разработчик отложил.
neonox
Если говорить о том, что канбан-доска визуализирует ваш процесс, то точно у вас в процессе есть пауза? Мне больше нравится блокировка задачи на том этапе процесса, на котором она случилась. И блокер так же показывает, что мы делаем что-то не так. А регулярная работа с блокерами, их кластеризация и оценка влияния, позволяет вносить изменения в работу всей системы, минимизируя частоту их возникновения
art241111
у нас бывает так, что разработчик должен переключится на другую задачу, например на более срочную
Либо на баг
Они могут быть не связаны с основной задаче
Правильно ли это? Нет) но так сложилось, что сталкиваюсь с этим постоянно
А как Вы блокеры отмечаете на канбан доске? Мне кажется это связи между задачами скорее