Как сделать доску канбан
Kanban: принципы и возможности в управлении проектами
Натали Азаренко
Методология канбан — это система постановки задач, при которой все этапы проекта визуализируются на специальной доске. Члены команды могут видеть текущее состояние задачи на любой момент времени. Это предполагает полную прозрачность работы. Kanban относят к agile-подходам — «гибким» технологиям, предназначенным для разработки программного обеспечения.
Что такое kanban
Цель kanban — сделать проект наглядным, отследить готовность работ и проконтролировать нагрузку специалистов.
Для упрощения контроля рабочий процесс визуализируют на доске, поделенной на колонки. Каждая колонка — это текущее состояние работ. Непосредственно задачи отображают в канбан-карточках — там можно прочитать их описание, уровень важности и дополнительную информацию. Когда задача завершает определённый этап, карточку с её описанием переносят в соответствующую колонку. Взглянув на доску, можно сразу понять, как обстоит ситуация с проектом.
Пример структуры канбан-доски
Канбан-доски бывают физическими и электронными. В первом случае это обычная доска со столбцами. Задания пишут на стикерах и наклеивают в нужный раздел, перемещая по мере необходимости. Электронные доски обладают аналогичными функциями, но по сравнению с физическими, всегда доступны — удалённые сотрудники могут непрерывно участвовать в рабочем процессе.
Пример виртуальных kanban-досок:
В самом простейшем варианте канбан-доску делят на три столбца с задачами:
Приведённая структура kanban — всего лишь образец. Для разных проектов можно добавлять другие столбцы. Например, в сфере разработки программного обеспечения канбан-доска может иметь следующие колонки задач:
Например, представим, как сделать почтовую рассылку с помощью канбан. Сначала нужно выделить отдельные задачи. Это может быть план конкретной серии писем, создание текстов, разработка дизайна email-рассылки и прочее. Далее все задания заносят в бэклог и определяют этапы рабочего процесса, визуализируя их в виде колонок с соответствующими названиями.
Команда, работающая над созданием рассылки, видит на доске текущее состояние проекта.
За ведение доски ответственны все члены команды. Любой вовлечённый в процесс сотрудник может перемещать готовые карточки по доске. Такая структура обеспечивает наглядность выполнения. Можно посмотреть текущий статус задачи и своевременно выявить «заторы».
Нюансы постановки задач
Каждая задача должна быть актуальна, при необходимости разрешено пополнять или «чистить» бэклог. Все задания сортируют с учётом приоритета. Причём степень важности определяет сама команда. Приоритеты можно менять по мере необходимости — это одна из особенностей «гибких» технологий.
Основной принцип kanban — объём незавершённой работы необходимо ограничивать, чтобы не допускать «зависания». При этом в работе одновременно может быть и несколько задач. Главное — ограничить их количество.
Над каждым столбцом обычно указывают лимит — максимальное число задач в этой колонке. Лимит бэклога высчитывают исходя из средних показателей. К примеру, в процессе 5 заданий и на выполнение каждого уходит 1 день — недельный бэклог можно обозначить лимитом 5.
Выяснить нужный предел можно опытным путём. Например, если в колонке бэклога скопилось большое количество задач, столбец «В процессе» забит под завязку, а колонка «Выполнено» чаще всего пустует, то налицо перегруженность команды. Желательно ограничить количество поставленных задач.
Более точно установить оптимальное количество задач для бэклога помогает метрика Flow Efficiency (эффективность потока). Она позволяет определить соотношение между стадиями ожидания и активной работы. Расчётными показателями выступает время выполняемых процессов. Для определения коэффициента флоу применяют такую формулу:
Время активной работы ÷ (время активной работы + время ожидания) × 100% = эффективность потока
Например, вы работали над задачей 2 дня, а в режиме ожидания она провела 3 дня. Значит:
2 ÷ (2 + 3) × 100 % = 40%
Получается, что на задачу уходит 40% времени, на протяжении которого она присутствует на доске до выполнения. Остальные 60% времени работа простаивает. Соответственно, лимит бэклога можно немного снизить.
Kanban обеспечивает свободу в принятии решений. Если при установленном ограничении не удаётся уложиться в график — уменьшите лимит. Когда у команды остаётся много свободного времени — лимит можно увеличить.
Особенности работы по kanban
При работе по kanban команда едина — все решения принимают совместно. Есть менеджер проекта, но он не руководит, а организует работу. Проект делят на итерации, длина которых может различаться. Для kanban не характерна ритмичность процесса.
Также по канбан-методологии не предусмотрено чёткого соблюдения конкретных этапов. Команда сама определяет, что и когда ей удобнее делать. Например, подведение итогов осуществляют в конце каждого месяца, планирование бэклога — по завершении заданий, совместные обсуждения — по мере необходимости. Но работа над проектом идёт непрерывно.
Из-за гибкого подхода к организации рабочего процесса возникают такие особенности:
Основной показатель эффективности в kanban — среднее время прохождения по доске. Быстрое решение задачи указывает на слаженную и продуктивную работу команды. Когда возникают задержки — нужно поискать их причины и оптимизировать процесс.
Как внедрить kanban-систему
Пример физической канбан-доски (источник Pinterest)
Для правильной организации работы по kanban-системе существует шесть основных правил.
1. Визуализируйте поток работы
Запишите все задачи, текущие и планируемые. Для каждой из них определите статус. Карточки с заданиями разместите на доске — физической или виртуальной.
2. Ограничьте число одновременно выполняемых задач
Скорее всего, первая же визуализация покажет, как команда непродуктивно тратит силы на параллельное ведение множества задач или, наоборот, простаивает из-за неравномерной загрузки. Обсудите совместно с командой, какое количество работ по каждому статусу оптимально вести одновременно и проставьте приоритеты. Над каждым столбцом доски укажите лимит.
3. Управляйте потоком задач
Своевременно меняйте статусы задач и отслеживайте движение. Если где-то возник «затор», нужно его оперативно разрешить. К примеру, если один сотрудник не справляется, он может попросить помощи у менее занятых коллег.
4. Обсудите правила работы
Команда должна чётко понимать, как обращаться с доской, когда можно брать новые задачи, что делать при возникновении сложностей, как определять готовность работы.
5. Анализируйте деятельность
Регулярно собирайте команду и обсуждайте нюансы работы, успехи и неудачи. Чёткого расписания нет, как нет и ограничений по формату. Можно собираться еженедельно или проводить общий созвон ежедневно, встречаться раз в месяц или собираться онлайн по мере необходимости. Главное — на каждой встрече команда решает, как оптимизировать процессы. Дополнительно обсуждают прочие насущные вопросы.
6. Экспериментируйте и улучшайте рабочие процессы
Любая канбан-команда всегда пребывает в поиске идеальной системы. Цель — ускорить движение карточек по доске. Для этого постоянно проводят какие-то эксперименты: меняют лимит, пересматривают приоритеты и прочее. Чтобы система действительно менялась, изменения нужно вводить для всей команды разом. При этом не нужно всё изменять кардинально. Внедрите одно нововведение, отследите эффект и только после этого переходите к следующему эксперименту.
Преимущества и недостатки канбан
Kanban — удобный инструмент, который применим почти при любом подходе к работе. Он делает рабочие процессы более наглядными, отображает производительность в режиме реального времени и помогает контролировать нагрузку сотрудников.
Где можно применять канбан-методологию
Впервые kanban начала применять компания Toyota в 1950-х годах. Автор метода Тайити Оно вдохновился схемой супермаркетов, когда покупатель сам выбирает необходимые товары. Рабочие компании стали обмениваться сигнальными карточками с подробным описанием «задачи» — номер и численность деталей, кто отправляет или производит, кто получает.
Карточки клеили на тару, которую, исходя из цели, перемещали на склад, на производственную или монтажную линию. Таким образом работники самостоятельно регулировали процесс. Например, монтажник приходит на склад и видит, какое количество каких деталей ему нужно забрать. Или на производство приходит пустая тара с прикреплённой карточкой о численности и виде необходимых деталей.
Метод kanban стал частью одной из базовых систем бережливого производства Toyota «точно-во-время». Эта система подразумевает синхронную поставку достаточного объёма нужных материалов надлежащего качества в нужное время.
Руководствуясь опытом Toyota, kanban на производстве стали применять и другие компании. С его помощью удалось организовать рабочие процессы по типу конвейера — каждый последующий цех назначал план по производству продукции предыдущему цеху. Это помогало снизить перепроизводство и излишнее затаривание складов.
Несколько позже канбан-методологию начали применять для управления проектами. А в 2007 годах kanban пришёл в сферу программирования: вслед за тем, как менеджмент-менеджер и консультант технологичных компаний Дэвид Андерсон провел презентации по этому методу управления в Microsoft. Дэвид был первым, кто использовал канбан в разработке программного обеспечения — в 2005 году.
Постепенно kanban стали использовать и в других областях. В основном выделяют три kanban-направления — производственная, софтверная и персональная.
К примеру, можно применять канбан-доску для управления личными задачами. Такой подход нередко используют фрилансеры, чтобы контролировать поток задач и не пропускать дедлайны.
Пример канбан-доски фрилансера по отдельному проекту
В целом методология kanban не предусматривает ограничения — любой проект, в том числе не связанный с производством либо программированием, можно поделить на задачи, определить статусы и этапы, а затем работать и визуализировать выполняемые процессы.
Простая Kanban-доска для Jira
Здесь я расскажу, как сделать канбан-доску для проекта в Jira, пользуясь только QML и JavaScript. С небольшими доработками вместо Jira вы можете использовать любой другой трекер, имеющий REST API.
Предыстория
Некоторое время назад, теперь уже практически в другой жизни, в мою бытность руководителем проекта, я понял, что теряю представление о занятости участников нашего проекта. Кто-то занимается Большим и Важным делом, кто-то исправляет срочные баги, а может быть кто-то, извините, балду пинает, а я об этом не в курсе и задачи ему не ставлю. И мне захотелось иметь наглядную картинку текущих дел.
Если у вашей организации уже диагностировали kanban в хронической стадии и вы тяготеете ко всему натуральному и осязаемому, то, скорее всего, ваша доска выглядит вроде этой, и у нее тоже есть разделение по этапам процесса:
В моем случае такой вариант не прокатил бы по нескольким причинам.
Во-первых, вся команда, за исключением пары человек, находилась в другом городе, а устраивать видеомитинги мне не казалось рациональным.
Во-вторых, у меня есть стойкое отвращение ко всякому ручному труду и вручную нацеплять бумажки на доску (а больше было некому, см. предыдущий пункт), отслеживать движение задач в трекере и соответственно передвигать бумажки на доске мне претило. Можно было нарисовать карточки в компьютере, в Excel или в Trello, но следить за задачами и передвигать карточки опять пришлось бы самостоятельно.
В-третьих, и самое главное, глядя на эту доску, можно видеть общее состояние дел, находить узкие места на участках конвейера по производству ПО, но в ней совершенно не видно людей и их загрузки.
Поэтому мне нужна была доска:
а) электронная
б) связанная с трекером, т.е. отражающую текущую ситуацию
в) и чтобы столбец на доске соответствовал конкретному человеку
Короче говоря, эту задачу я на тот момент решил, сделал представление на web-страничке. Но о ней ничего вам не расскажу — и трекер тот (PVCS Tracker) не слишком распространен, API у него на dll, да и код странички сейчас не найти.
А сейчас я решил повторить упражнение, взяв в качестве инструментария QML. Выбор объясняется просто — мне он чуть более знаком, чем веб-технологии, и я знаю, как встроить получившийся модуль в свой инструмент, написанный на Python и PyQt.
Альтернативы для умных и богатых
Да, я знаю, что для Jira существует энное количество плагинов, в которых есть Kanban-доска — поиск в marketplace по слову «kanban» находит 33 варианта.
Но использовать плагин означает, что нужно выбить у руководства его покупку по цене соответствующей числу всех пользователей на Jira, договориться с админами, что они поставят его на сервере и будут поддерживать, и… невозможность его кастомизации под мои нужды, т.к. плагин будет общим для всех. А мне хотелось иметь инструмент, который можно использовать независимо от того, установлено что-то на сервере или нет, и менять, ни на кого не оглядываясь.
Необходимые оговорки
Чтобы не утяжелять статью, здесь не будет сказано о том, как сделать:
— авторизацию в Jira
— операции над карточками в QML с передачей вызова в JIRA — редактирование, смена статусов и исполнителей путем drag&drop и т.п.
— работа с фильтрами Jira
Если что-то из этого вам действительно интересно — отпишите об этом в комментариях. Не буду обещать, что немедленно сделаю и распишу в деталях, но, как сказал nmivan, «поставлю в план».
Терминология еще не устоялась, так issue в одних компаниях называют запросом, в других задачей, еще бывают тикеты и заявки. Для сущности filter, которым в Jira отбирают issues, тоже есть куча названий — фильтр, запрос, выборка, список.
Я буду использовать терминологию, принятую в локализованной Jira: issue буду называть запросом, а filter — списком.
Начало работы с Jira REST API
Типичный адрес запроса в веб-интерфейсе Jira выглядит так:
Полное описание Jira REST API на сайте Atlassian. Там много всяких функций, которых с каждой версией становится все больше, но реально требуется знать лишь небольшое количество методов:
POST https://jira.mycompany.ru/rest/api/2/issue
Создать новый запрос. В теле вызова передается JSON с заполняемыми полями запроса. Те поля, что вы не передали, заполнятся значениями по умолчанию.
PUT https://jira.mycompany.ru/rest/api/2/issue/PROJECT-1234
Изменение (редактирование) полей в запросе. В теле вызова передается JSON, в котором есть два блока — «update» с инструкциями по изменению полей, и «fields» с новыми значениями полей.
Изменяемое поле должно быть только в одном из этих блоков.
GET https://jira.mycompany.ru/rest/api/2/search?jql=. — получить список запросов, соответствующего условиям на языке JQL
POST https://jira.mycompany.ru/rest/api/2/search — тоже самое для сложных условий, не умещающихся в строку URL
GET https://jira.mycompany.ru/rest/api/2/field — получить описания всех полей, которые могут использоваться в запросах.
Пока хватит на первое время.
Поскольку мы ничего менять и редактировать пока не собираемся, то работать будем анонимно, с запросами на сервере Jira в Atlassian, в проекте «JIRA Server (including JIRA Core)», то есть, фигурально выражаясь, в Самом Главном Проекте Jira. Тем более, что там тоже есть наши люди:
Первым делом рекомендую зайти в веб-интерфейс проекта и сделать поиск запросов по какому-либо условию, например:
project = JRASERVER and updated
Это нужно для того, чтобы убедиться, что вы запрос составили правильно — если это не так, то веб-интерфейс вам скажет.
Условие копируем и подставляем в параметр jql функции search, получится такой URL:
https://jira.atlassian.com/rest/api/2/search?jql=project = JRASERVER and updated гифка
Сохраните его под другим именем. C полученным файлом удобнее работать, находить в нем нужные поля и смотреть, в какой структуре находится нужное значение. Оригинальный файл нам пригодится в качестве тестового источника, чтобы лишний раз не ходить на сервер Atlassian.
Создаем проект в Qt Creator
Для создания проекта в Qt Creator воспользуемся стандартным шаблоном «Qt Quick Control Application».
Получится проект, состоящий из main.cpp и main.qml в файле ресурсов qml.qrc.
Их мы трогать пока не будем, займемся более насущными проблемами.
Рисуем дизайн карточки с запросом
Создаем новый файл IssueCard.qml, визард по умолчанию закинет его в файл ресурсов.
Дизайн карточки, которой будет отображаться запрос, я сначала по быстрому накидал в режиме дизайнера Qt Creator, затем доработал QML вручную.
Кстати, дизайнер QML относительно неплох, особенно по сравнению с первой версией. Наглядно показывается и легко меняется binding положения элементов, автоматом подтягивает компоненты из других qml-файлов в проекте. Почти не падал — всего два раза валил QtCreator, когда я пытался задать градиент (ничего страшного не случилось — автосохранение работает), и еще не смог пережевать DelegateModel — наверное, среду стоило обновить. У дизайнера QML, как и у дизайнера Qt Widgets, есть функция предпросмотра:
В результате получился QML карточки с запросом, файл IssueCard.qml
Для заполнения карточки по запросу добавим новое свойство (property) issue. Свойство даст нам возможность передавать в карточку запрос со всем его содержимым извне за одно присвоение.
И в сигнале на его изменение напишем код, разбирающий значения и распихивающий их по нужным визуальным компонентам.
Как видите, здесь я часто использую функцию JS.getValue, я ее написал для упрощения выборки значения из сложной структуры JSON (если оно там есть), хотя сама функция довольно проста:
Функция лежит в файле methods.js, подключенном в начале IssueCard.qml
Описываем колонку карточек
Теперь нужно карточки организовать в прокручиваемую по вертикали колонку. Прокрутка очень удобна, когда карточек много. Для прокрутки нужен ListView. Среди примеров, идущих в комплекте с Qt есть пример «QML Dynamic View Ordering Tutorial 3 — Moving Dragged Items», в нём dynamicview.qml — это практически то, что нам нужно, копируем его в проект под именем KanbanColumn.qml.
Только нужно сделать пару доработок
1) Добавить к колонке заголовок и сделать у объекта верхнего уровня свойство, чтобы присваивать название колонки извне.
2) Так как карточка запроса у нас теперь отдельный цельный объект, то заменяем вывод, сделанный в примере через Column и несколько Text, на наш IssueCard
С колонкой дизайнер нам не поможет, потому что он не переваривает DelegateModel. С другой стороны, нам не особо он и нужен, всё можно сделать вручную.
Окно для доски
Теперь нужно собрать колонку в общее окно. Создаем файл KanbanWindow.qml, в нем дизайнером размещаем нужные поля.
В простейшем виде получается так:
Выше я еще создал свойство mainModel — оно нам послужит для временного хранения данных.
И не забыть вставить KanbanWindow в окно приложения:
Пишем код для вызова REST API
Самое время сделать код, который будет получать список запросов из Jira и заполнять модели в QML.
В QML имеется, хоть и ограниченная, но поддержка XMLHttpRequest и JSON-парсер (на хабре есть подробная статья BlackRaven86). Поэтому у нас есть всё, чтобы написать обращение к серверу и разбор ответа.
Функция запрашивает с сервера (или из локального файла) список запросов, парсит json из ответа, группирует запросы по исполнителям и заполняет модель в QML.
Подключаем функцию к кнопке
И проверяем работу:
В принципе, доска готова. Далее можно заниматься ее улучшениями и развитием.
Как видите, здесь ComboBox содержит модель с возможными вариантами группировки, и в каждом элементе прописан путь в JSON к значению, которое будет использоваться для определения группы. Таким образом количество вариантов группировок по желанию можно расширить.
На верхнем уровне определены свойства, два из которых — алиасы к внутренним значениям. Алиасы нужны, чтобы можно было присвоить нужное значение, начитанное из LocalStorage. Что же касается свойства groupValuePath:
то оно просто возвращает путь к значению для текущего варианта группировки.
Вставляем KanbanParams в KanbanWindow и у нас получается такое окошко:
Я не буду подробно расписывать, как обрабатываются параметры, потому что мне надоело писать эту статью, смотрите в коде.
Что дальше?
Получившейся доской уже можно пользоваться для просмотра текущей ситуации с запросами, но можно ее улучшить: