Как создать канбан доску в jira

Узнайте, как создавать agile-доски в Jira Software

Max Rehkopf

Автор: Max Rehkopf

Просмотр тем

Учебное руководство по agile-доскам в Jira

Из этого учебного материала вы узнаете принципы работы с досками в Jira Software.

10 минут на прочтение. Прохождение учебного курса занимает не менее 2 недель

Вы только начинаете знакомство с Jira Software. Вы создали проект (возможно, даже с доской) и хотите научиться создавать доску с нуля.

Вы создали аккаунт Jira Software.
Вы создали проект Jira Software.

Создание agile-доски

Что такое доска?

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

Шаг 1. Создание доски

Чтобы создать доску, выполните следующие действия.

Magnifying glass

ЛупаНажмите Search ()> View all boards (Поиск > Все доски).
Нажмите Create board (Создать доску).
Выберите тип доски (Scrum или Kanban).
Выберите способ создания доски: можно начать создание новой доски с шаблона нового проекта или добавить доску в один или несколько существующих проектов.

Доску какого типа выбрать?

Существует два типа досок:

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

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

Если ваша команда хорошо разбирается в методике Agile, рекомендуется выбрать доску Scrum или Kanban (в зависимости от того, какая лучше подходит для процесса команды). Если ваша команда только начинает знакомство с Agile или вы хотите сразу приступить к работе, не отвлекаясь на настройку, рекомендуется использовать в качестве отправной точки шаблоны проектов команды.

Шаг 2. Настройка доски

Какие параметры следует настроить в первую очередь?

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

Доски scrum и kanban

ЛупаПерейдите на свою доску, нажав Search () > View all boards (Поиск > Все доски) и выбрав свою доску.
Кнопка «. »Выберите () > Board settings (Дополнительно > Настройки доски).

Доски команды

Настраивать доски в шаблонах проектов команды очень просто. Базовые операции, такие как добавление и удаление столбцов, добавление лимитов незавершенной работы и переименование, выполняются прямо на доске, и переключать экраны не требуется. Чтобы включить или отключить agile-возможности, такие как бэклог, спринты и отчеты, перейдите в Settings > Features (Настройки > Возможности).

Шаг 3. Перемещение между досками

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

Agile и Jira Automation

Поддерживать доску в актуальном состоянии проще простого. Используйте функцию Jira Automation, доступную для всех клиентов Jira Software Cloud. Некоторые наиболее распространенные шаблоны автоматизации можно найти в библиотеке шаблонов Jira Automation ниже.

При слиянии запроса pull изменить статус задачи на Done (Завершено). Перейти к правилу.
Ежедневно отправлять сообщение со списком задач в бэклоге. Перейти к правилу.
Когда все подзадачи будут иметь статус Done (Завершено), закрыть родительскую задачу. Перейти к правилу.

Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.

Хотите узнать больше?

Подробнее об использовании досок в Jira Software см. в нашей документации по доскам.

Поделитесь этой статьей

Max Rehkopf

Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни. Для меня истинная радость — делиться этими знаниями с другими людьми, публикуя многочисленные статьи, участвуя в беседах и распространяя видеоматериалы, которые я создаю для Atlassian.

Как настроить Канбан в Jira для разработки своих продуктов, на примере Meetville

18 сентября 2017 года мы запустили Hygger.io — систему управления проектами для IT-компаний, которая состоит из 4х типов досок: Kanban, Sprint, Backlog и Roadmap. Заходите, регистрируйтесь, изучайте!

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

Начало

Начиналось все с банального списка issues и фильтрации с помощью JQL (2010 год). Для расстановки приоритетов мы использовали поле priority, которое позволяет разбить приоритеты задач на 5 групп (trivial, minor, major, critical, blocker). Также использовали Agile плагин Jira Agile (раньше он назывался Green Hopper). Задачи внутри группы делались в произвольном порядке. Например, было 10 задач с приоритетом major и программист брал любую задачу, которая имеет приоритет major, но после того, как все задачи с более высшими приоритетами были готовы. На тот момент мы работали в спринтах, поэтому порядок в целом был не важен. Важен был конечный результат, то есть принятые тестировщиком и залитые на продакшн фичи.

Минусы

Но у этого процесса было много минусов. Вот лишь самые основные:
— тестеры проверяли фичу не тогда когда программист ее закончил, а спустя длительное время. Программист успевал забыть эту фичу и тратил много времени на то, чтобы снова погрузиться в задачу. Сейчас, в канбане, тестер проверяет фичу практически сразу после того, как ее сделал программист;
— фичи заливались на production только в конце спринта, примерно раз в месяц/полтора — сейчас мы их заливаем практически сразу после приемки тестировщиком;
— код фичи попадал в мастер с большим опозданием — в итоге приходилось часто разруливать конфликты. Сейчас код попадает в мастер сразу после приемки тестером, то есть достаточно быстро;
— непонятно чем занят программист в настоящий момент — приходилось заниматься постоянным опросом вида “что делаешь?” и раздачей директив вида “после этой задачи делай вот эту”;
— непонятно, в целом, насколько команда была загружена задачами — кто при задаче, а кто филонит;
— программисты не знали чем заняты коллеги;
— программист мог делать сразу несколько задач параллельно, что повышало издержки на переключение контекста;
— приходилось тратить много времени на оценку фич перед стартом спринта, сейчас потребности в оценке нет — когда сделаем фичу, тогда и сделаем;
— срочные задачи по исправлению багов или по доработке фич на продакшне ломали все сроки спринта — сроки постоянно плавали, что приводило к негативу со стороны “внутренних” заказчиков продукта.

Канбан — спасение

В один прекрасный момент я решил попробовать методологию Канбан, которую как раз добавили в плагин Jira Agile (ранее — Green Hopper). И, практически сразу, пропускная способность команды разработки выросла на порядок. Мы стали выпускать намного больше полезностей в единицу времени. Все были довольны: пользователи продукта стали получать в первую очередь более полезные фичи причем намного быстрее. “Внутренние” заказчики перестали давать кнута за срыв сроков и своими глазами увидели как выросла скорость поставки софта.

Если вы совсем не знакомы с методологией Канбана, то я рекомендую прочитать вот эту статью — http://habrahabr.ru/post/64997/.

Плюсы

Вот плюсы, которые мы получили от внедрения Канбана:
+ мы сразу увидели узкие места — в колонке Testing скапливалась большая очередь задач — наш тестировщик не справлялся с проверкой задач. В итоге программисты успевали хорошенько подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать о чем там шла речь. Решение — взяли второго тестировщика. Бинго.
+ менеджер продукта стал точечно управлять порядком выпуска фич. В этом мире бушующем все ж таки порядок имеет значение. Задача по определению приоритетов — одна из самых важных задач для менеджера в Канбане. Требования, как и реальность, постоянно меняются. Какие-то задачи, полежав в очереди, теряют свою значимость и уходят вниз, туда, где их никто никогда не увидит. Какие-то задачи наоборот из грязи в князи — поднимаются наверх. Се ля ви.
+ мы стали делать только то, что реально добавляло ценности продукту. Мы смогли упрятать подальше от программистов тонны бесполезных багов и доработок. С глаз долой из сердца вон. Тестировщики — молодцы, находят баги, но баг Багу рознь. Отличить баг от Бага — задача для человека, который может и учитывает как интересы пользователей продукта, так и интересы бизнеса. Это работа менеджера продукта.
+ программисты перестали тратить свою энергию на выбор следующей задачи — “взять в работу вот этот баг, или вот эту задачу?”. Этот выбор осложнялся тем, что у обоих задач был одинаковый приоритет. Если тебе вернули задачи, то есть переоткрыли в терминах Jira, будь добр взяться за нее сразу после текущей задачи, а не через 2 недели. Теперь эту энергию программист может тратить на бизнес-логику и программирование. И на чтение новостей на reddit.
+ вся картина — на ладони, можно зайти на доску и увидеть кто чем занят, что уже готово к отправке на продакшн. Большие вещи видятся на расстоянии.
+ мы стали более гибкими — мы стали менять требования “на лету”, причем без какого-либо сопротивления со стороны программистов. Раньше программист не хотел делать “левые” задачи, боясь “завалить” сроки по спринту. С Канбаном программист работает как процессор — тактами, один такт — одна задача. Главное — не трогать его внутри такта. Кстати, чем чаще такты, тем гибче команда разработки. Идеальный такт для нашей команды — 8 часов.

Регламент на процесс

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

Вот главная и единственная иллюстрация — наша структура в Jira.

Вертикальный приоритет задач

Задачи разбиты на три уровня:
1) Уровень Blockers — выполняются в первую очередь.
2) Tasks and Bugs — выполняются при отсутствии задач в группе Blockers.
3) Someday — выполняются при отсутствии задач в группах Blockers и Tasks and Bugs. То есть — никогда 🙂

Правила:
— Приоритет и порядок выполнения всем задачам задает менеджер продукта.
— Выполняя задачи на уровнях Tasks and Bugs или Someday, при появлении задачи на уровне Blockers, в комментариях к Block-задаче, разработчик указывает время, через которое он сможет приступить к выполнению. Менеджер отвечает на данный комментарий согласием или не согласием. Если ответ положительный, то разработчик приступает к Block-задаче не позднее оговоренного времени, если же ответ отрицательный, разработчик приступает к Block-задаче немедленно, остановив текущую задачу на другом уровне. Если комментарий от менеджера не получен, то разработчик действует, как если бы получил положительный ответ. Также данный вопрос можно решить в устной форме с менеджером проекта.
— Пока не будут выполнены все задачи на более высоком уровне приоритета, разработчик не имеет права приступать к задачам находящимся на более низком уровне приоритета.
— Задачи внутри уровня выполняются по порядку — сверху вниз.
— Разработчик не имеет права по своему усмотрению менять приоритет задач.

Горизонтальное движение задач

Команда выполняет задачи и проходит все колонки слева направо.

To Do
— В колонке To Do представлены задачи для разработчика, имеющие статус Jira open.
— Разработчик обязан взять одну верхнюю задачу, при отсутствии задачи в Reopened и присвоить ей статус In progress. То есть перенести задачу в колонку In progress.
— За наполнением задач и их порядком в To Do и их приоритетом следит и отвечает менеджер продукта.
— Если задачу вешает один разработчик другому разработчику, то суть задачи, исполнитель и ее статус должны быть согласованы с менеджером продукта.

In Progress
— В колонке In Progress находятся задачи, имеющие статус Jira in progress.
— Если у разработчика в колонке In Progress нет задачи, то это считается простоем.
— У разработчика в In Progress должна быть только одна задача.
— Максимальное число задач в In Progress равно числу разработчиков, если же число задач превысило максимум, колонка выделяется красным цветом, что сигнализирует о нарушении процесса.
— Разработчик должен проверить, не открыл ли он сразу несколько задач, если лишние задачи есть, разработчик обязан оставить только одну задачу.
— Если разработчик выполнил задачу, он обязан выложить ее для тестирование на закрепленный за ним dev-сервер и присвоить задаче статус Resolved, то есть перенести ее в колонку Testing.

In Testing
— Задачи на этом этапе имеют Jira статус Resolved и проходят тестирование на dev-сервере.
— Тестировщики работаю с задачами из данной колонки до 14.00, если отдельно не оговорен порядок тестирования с менеджером продукта, затем тестировщики обязаны переключиться на колонку Deployed.
— Если задача успешно прошла тестирование, ей присваивают Jira статус Closed, то есть переносят в колонку Ready 4 deployment.
— Если задача не прошла тестирование, ей присваивают статус Reopened, то есть переносят в колонку Reopened.
— Если в данной колонке находиться задача, которую вешал одни разработчик другому, то проверить данную задачу согласно пунктам выше должен разработчик, который создал задачу.
— Если в данной колонке находится под-задача, относящаяся к большой, общей задаче, то менеджер продукта обязан спрятать эту подзадачу с доски (мы прячем так — ставим версию Fake version в поле Fix Version, а эта версия была давно зарелижена, поэтому таск исчезает с доски), а в будущем тестировщики будет проверять эту задачу в рамках общей/корневой задачи.

Reopened
— В данной колонке представлены задачи с Jira статусом Reopened и требующие исправления.
— Разработчик не имеет права брать новую задачу из To Do, пока у него есть задачи в Reopened.
Ready 4 Deployment
— В данной колонке представлены задачи имеющие Jira статус Close и требующие заливки на продакшн или же задачи, которые будут включены в финальный билд и залиты в AppStore/Google Play.

Deployed
— В данной колонке представлены задачи, имеющие Jira статус Deployed и залитые на продакшн или же включенные в билд мобильного приложения, который уже отправили на ревью в магазин.
— менеджер продукта обязан включить задачи, относящиеся к мобильным приложениям, в road map .☆ Apps Versions для последующего контроля версий, а далее убрать их с доски, поставив Fake version.
— Также менеджер продукта обязан актуализировать состояние задач на доске Production в Trello, то есть перенести выполненные задачи из колонки Developing в Live. В этот момент все заинтересованные лица получают уведомление о выпуске новой фичи.
— Задачи, не связанные с мобильными приложениями, обязаны быть приняты отделом тестирования на продакшне.
— Если тестировщики приняли задачу, то ей устанавливается Jira статус Accepted.
— Тестировщики работают с данной колонкой после 14.00, если отдельно не оговорен порядок тестирования с менеджером продукта.
— Технические задачи, которые создают разработчики, обязаны быть приняты авторами и им должен быть присвоен статус Accepted.

Accepted — В данной колонке представлены задачи, имеющие Jira статус Accepted, данный статус тестировщики выставляют после проверки данной задачи на продакшне.
— Менеджер продукта переодически очищает, то есть прячет (ставит Fake version) задачи из данной колонки.

Доски

Узнайте, как построить доску kanban, и посмотрите примеры из Atlassian и других.

Kanban доска — это инструмент управления Agile проектами, предназначенный для визуализации работы, лимита работы в процессе выполнения и максимизации эффективности (или потока). Доски Kanban используют карточки, колонки и постоянное совершенствование, чтобы помочь командам по технологиям и обслуживанию выполнить правильный объем работы и выполнить ее!

ТВИИТ: «Канбан» — это японское слово «визуальный сигнал». Если вы работаете в сфере услуг или технологий, ваша работа часто оказывается невидимой и неосязаемой. Канбан-доска помогает сделать вашу работу видимой, чтобы вы могли показать ее другим и держать всех на одной странице.

Kanban прошел долгий путь от своего происхождения в области бережливого производства благодаря небольшой, но могущественной группе энтузиастов kanban. Работа Дэвида Андерсона по определению метода kanban помогла внести kanban в пространство программного обеспечения и услуг, а Личный (Персональный) kanban, Джим Бенсон и Тонианн ДеМария, помог расширить приложения kanban в места, в которые вы бы не поверили.

Я пользуюсь досками kanban каждый день и не могу представить себе жизнь без них. Идеи и лучшие практики здесь — это мой личный опыт, исследования и разговоры с Заком Нисом, Китом Ноттинсоном и Джимом Бенсоном.

Что заставляет меня возвращаться в kanban, так это ценности kanban и (удивительно) отсутствие правил. Ценности kanban — это уважение к людям и постоянное совершенствование.

Элементы kanban доски

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

Визуальные сигналы. Одной из первых вещей, которые вы заметите на доске kanban, являются визуальные карточки (стикеры, билеты или другое). Kanban команды пишут все свои проекты и рабочие элементы на карточках, обычно по одному на карточку. Для Agile команд каждая карточка может инкапсулировать одну пользовательскую историю. Оказавшись на доске, эти визуальные сигналы помогают партнерам по команде и заинтересованным сторонам быстро понять, над чем работает команда.
Столбцы. Еще одной отличительной чертой kanban-доски являются столбцы. Каждый столбец представляет определенную деятельность, которая вместе составляет «рабочий процесс». Карточки проходят через рабочий процесс до завершения. Рабочие процессы могут быть такими же простыми, как «Сделать», «Выполняется», «Завершено» или намного более сложными.
Лимиты работы в процессе выполнения (WIP — Work In Progress). Лимиты WIP — это максимальное количество карточек, которое может находиться в одном столбце в любой момент времени. Столбец с лимитом WIP, равным трем, не может содержать более трех карт. Когда столбец «исчерпан», команде необходимо наброситься на эти карты и переместить их вперед, прежде чем новые карты смогут перейти на эту стадию рабочего процесса. Эти лимиты WIP имеют решающее значение для выявления узких мест в рабочем процессе и максимизации потока. Лимита WIP дают вам раннее предупреждение о том, что вы взяли на себя слишком много работы.
Точка обязательства. Kanban команды часто имеют список необходимых требований (backlog) для своей доски. Именно здесь клиенты и партнеры по команде предлагают идеи для проектов, которые команда может подобрать, когда они будут готовы. Точка обязательства — это момент, когда команда подхватывает идею и начинает работу над проектом.
Точка предоставления. Точка предоставления — это конец рабочего процесса команды kanban. Для большинства команд точка предоставления — это когда продукт или услуга находятся в руках клиента. Цель команды — как можно быстрее доставить карточки из пункта назначения в пункт предоставления (доставки). Прошедшее время между ними называется временем выполнения. Команды Kanban постоянно совершенствуются, чтобы максимально сократить время выполнения заказа.

Доска kanban с этими пятью элементами, несомненно, настроит вашу команду на успех. Но сейчас я представлю противоположную точку зрения.

Джим Бенсон говорит, что у kanban есть только два правила: ограничивать работу в процессе и визуализировать свою работу. Если вы начнете только с этих правил и примените их к своей работе, ваша доска канбан будет сильно отличаться от описанной выше. И это нормально! Джим выступает за то, чтобы начать с этих двух правил, потому что, по его словам, «чем больше правил вы добавляете, тем меньше контекстов в них вписывается».

Типы и примеры kanban-досок

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

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

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

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

«Optimizely» («Оптимально») создает программное обеспечение, чтобы помочь компаниям узнать, какие варианты веб-страниц или продуктов больше нравятся пользователям. Они используют Jira для отслеживания рабочих элементов больших и малых размеров, но Кит Ноттонсон, старший директор по развитию, увидел пробел.

Отдельные команды общались в Jira, но они не разговаривали друг с другом. Чтобы все были на одной странице, Кит установил огромную физическую доску kanban, называемую «стеной работы».

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

«Сначала стена просто « делала »,« делала » и « делала », но со временем люди начали разговаривать о том, как мы работаем», — сказал Кейт. Далее Кейт поделился тем, что благодаря этим разговорам стена росла и развивалась, и через несколько недель Optimizely получила более четкую картину того, как работа выполняется, чем когда-либо прежде.

Доска Optimizely («Оптимально») особенно хороша, потому что у нее есть обязательство и точка предоставления. Как только проект определен и соответствует определенным критериям, команда инженеров подберет проект и обязуется выполнить его. На данный момент, проект идет в Jira, чтобы они могли собрать все точные данные и взаимодействия, связанные с окончательным предоставлением.

Кейт рекомендует, чтобы команды начинали с физической доски kanban, так как эти ранние разговоры приведут к быстрой итерации рабочего процесса и доски.

Цифровые доски

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

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

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

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

Некоторые цифровые kanban-доски просты, а некоторые более надежны и более настраиваемые. Команды, которым требуются дополнительные функции, такие как лимиты WIP и контрольные диаграммы, должны выбрать более мощный инструмент, такой как программное обеспечение Jira Software. Jira выходит из коробки с шаблоном проекта kanban, который позволяет собрать команду kanban и запустить ее на одном дыхании. Команда может перейти к проекту, а затем настроить свой рабочий процесс и доску, установить лимиты WIP, создать дорожки и даже включить список необходимых требований, если им нужен лучший способ расставить приоритеты.

Kanban против scrum доски

Разница между kanban и scrum на самом деле довольно тонкая. По большинству интерпретаций, команды Scrum используют доску kanban, только вместе с процессами scrum, артефактами и ролями. Однако есть некоторые ключевые отличия.

Спринты Scrum имеет даты начала и окончания, тогда как kanban — это непрерывный процесс.
Командные роли четко определены в Scrum (владелец продукта, команда разработчиков и мастер Scrum), в то время как kanban не имеет формальных ролей. Обе команды самоорганизуются.
Доска kanban используется на протяжении всего жизненного цикла проекта, в то время как доска scrum очищается и перерабатывается после каждого спринта.
На доске scrum есть множество заданий и четкий крайний срок их выполнения.
Доски Kanban более гибки в отношении задач и сроков. Задачи могут быть перераспределены, переназначены или обновлены по мере необходимости.

И kanban, и scrum являются популярными гибкими подходами разработки программного обеспечения. Подробнее об этом читайте в нашем полном разборе kanban против scrum.

Начало работы с досками kanban

Kanban — это метод «начни с того, что ты делаешь сейчас». Это означает, что вам не нужно удалять то, что вы делаете, чтобы начать работать с kanban. Метод kanban предполагает три вещи:

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

Это командный процесс, поэтому первое, что ваша команда должна сделать, это собраться вместе! Вы хотите попробовать разбить свою работу на отдельные действия, составляющие рабочий процесс (столбцы). Отсюда вы можете понять, как и когда на доску добавляются новые работы (карточки). Будет ли у вас служба поддержки, где клиенты будут предлагать идеи, или команда назначит встречу, чтобы записать и опубликовать свои карточки?

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

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

По материалам Agile Coach «Boards»

Изучение того как создать agile доску в программном обеспечении JIRA

Узнайте, как создавать agile доски в программном обеспечении Jira

Пошаговые инструкции по работе с agile досками в программном обеспечении Jira Software

Учебник по Jira Agile доске

В этом уроке мы расскажем, как работать с досками в программном обеспечении Jira Software.

Время:

10 минут чтения. Завершить в течение 2 недель или более

Аудитория:

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

Необходимые условия (Предпосылки):

Вы создали учетную запись Jira Software
Вы создали проект Jira Software

ЧТО ПРЕДСТАВЛЯЕТ СОБОЙ ДОСКА?

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

Шаг 1: Создайте доску

Чтобы создать новую доску:

Нажмите «Поиск ()> Просмотреть все доски» ( Search () > View).
Нажмите «Создать доску» (Create board).
Выберите тип доски ( обе agile, Scrum, или Kanban)
Выберите способ создания своей доски. Вы можете создать новый проект для своей новой доски или добавить свою доску в один или несколько существующих проектов.

КАКОЙ ТИП ДОСКИ Я ДОЛЖЕН ВЫБРАТЬ?

Есть три типа досок:

Доски Scrum

· Управляйте историями, задачами (tasks) и багами в спринтах

· Подходит командам, которые выполняют работу в обычном режиме

Kanban доски

· Управляйте историями, задачами (tasks) и ошибками в непрерывном потоке

· Подходит командам, которые контролируют объем работы из списка основных требований

Доски гибкости(Agility boards)

· Управляйте задачами с помощью гибкой, простой доски

· Подходит командам, которые плохо знакомы с Agile, или командам, которые не хотят тратить много времени на настройку

Если ваша команда имеет правильное понимание того, что такое agile, мы рекомендуем выбирать Scrum или Kanban (в зависимости от того, что подходит вашей команде). Если ваша команда является новичком в Agile, или вы хотите подключиться, не тратя много времени на настройку, мы рекомендуем выбрать доску Agility.

Шаг 2: Настройте свою доску

КАКИЕ НАСТРОЙКИ Я ДОЛЖЕН УСТАНОВИТЬ ПЕРВЫМИ?

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

Scrum/Kanban доски

Перейдите на свою доску, нажав Поиск ()> Просмотреть все доски (Search () > View all boards) и выберите свою доску.

Кликните еще (кнопка «Многоточие»)> «Настройки платы» (Ellipses button > Board settings).

Доски Agility

Настроить доски agility очень просто — базовые функции, такие как добавление / удаление столбцов, добавление лимитов WIP и переименование, выполняются на самой доске, вместо этого приходится менять экраны.

Чтобы включить agile функции, такие как список необходимых требований Backlog и спринты Sprints, перейдите в «Настройки»> «Функции» (Settings > Features). Доски по Agility все еще находятся в стадии разработки, поэтому со временем мы добавим больше возможностей.

Шаг 3: Переход (Навигация) между досками

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

Хотите узнать больше?

Более подробную информацию об использовании досок в программном обеспечении Jira Software можно найти в нашей документации по платам. Есть вопросы? Спросите Сообщество Atlassian.