Использование методики Kanban при разработке ПО
Повысьте эффективность до максимума, отслеживая и выполняя наиболее важную работу.
Kanban — это популярный подход к реализации принципов Agile и DevOps при разработке ПО. Он предполагает обсуждение ресурсов в реальном времени и полную прозрачность процессов. Рабочие задачи выводятся на доску Kanban, благодаря чему участники команд могут просматривать статус каждой из них в любой момент времени.
Наглядные рабочие процессы Kanban, лежащие в основе методологий Agile и DevOps, повышают эффективность работы за счет последовательного продвижения по заданиям. Процесс Kanban аналогичен отлаженному процессу управления запасами в супермаркетах: задания передаются на следующий этап разработки именно тогда, когда это необходимо.
На досках Kanban задания представлены в виде карточек, что помогает визуально отслеживать прогресс и быстро выявлять узкие места. Команды ограничивают объем незавершенной работы (WIP), чтобы оптимизировать распределение ресурсов и поддерживать стабильность рабочего процесса. Чтобы непрерывное совершенствование оставалось в центре внимания, в Kanban используют такие показатели, как контрольные графики и сводные диаграммы процессов, позволяющие командам постепенно улучшать рабочие процессы.
При разработке программного обеспечения процесс Kanban способствует динамичному управлению заданиями, ускоряет циклы поставки и повышает удовлетворенность клиентов за счет целенаправленной и бесперебойной работы. По сути, он воплощает в себе эффективность — гармоничное сочетание прозрачности, адаптируемости и непрерывного совершенствования, раскрывающее весь потенциал гибких методологий разработки.
Для эффективного внедрения методологии Kanban в команде разработчиков программного обеспечения важно соответствующим образом систематизировать их работу. Это позволит выполнять задания в равномерном темпе и оптимизировать управление рабочим процессом. Вот как можно структурировать процесс Kanban.
Визуализируйте. Для начала наглядно представьте рабочий процесс команды на доске Kanban, физической или виртуальной. Отразите каждый этап разработки — от создания заданий до их завершения.
Стандартизируйте. Определите и стандартизируйте этапы рабочего процесса в соответствии с методами и требованиями вашей команды. Обычно используют этапы «К выполнению», «В работе» и «Готово», но при необходимости их можно адаптировать под особенности вашего рабочего процесса.
Определите блокеры и зависимости. Важно, чтобы по доске Kanban можно было мгновенно выявить блокеры и зависимости. Такая прозрачность позволяет без промедления решать проблемы и предотвращать перебои в рабочем процессе.
Ограничьте объемы незавершенной работы. Предусмотрите ограничения для каждого этапа, чтобы избегать перегрузок и поддерживать стабильный рабочий процесс. Это поможет оптимизировать распределение ресурсов и реже работать над несколькими задачами одновременно, что способствует повышению производительности.
Поощряйте совместную работу. Развивайте культуру сотрудничества в команде, чтобы участники сообща устраняли узкие места и продвигались по этапам рабочего процесса в равномерном темпе. Это способствует эффективному и быстрому выполнению заданий.
Используйте карточки Kanban. Представьте каждое задание на доске в виде карточки Kanban с важными сведениями, такими как описание задания, исполнитель и предполагаемое время выполнения. Карточки Kanban помогают визуально отслеживать прогресс и способствуют прозрачности в команде.
Структурировав процесс Kanban таким образом, вы сможете оптимизировать разработку программного обеспечения, укрепить сотрудничество в команде и добиться максимальной эффективности в управлении заданиями.
Методика Kanban очень популярна среди современных agile- и DevOps-команд разработчиков ПО, однако она существует уже более 50 лет. В конце 1940-х годов компания Toyota начала оптимизировать свои технологические процессы, взяв за основу принцип заполнения полок в супермаркетах.
В таких магазинах на витрины выкладывается ограниченное, но достаточное для удовлетворения потребительского спроса количество товаров. Это помогает оптимизировать поток продукции между супермаркетом и покупателем. Так как уровень запасов соответствует потребительскому спросу, управление складом становится намного эффективнее благодаря снижению объема избыточных запасов, которые необходимо где-то хранить. При этом в супермаркете по-прежнему есть все необходимые покупателю товары.
Компания Toyota применила эту систему в своих цехах, чтобы привести в соответствие огромные складские запасы и реально используемые материалы. Для отслеживания уровня запасов в цехе и взаимодействия с поставщиками в реальном времени рабочие передавали между командами специальную карточку под названием «канбан».
Когда на производственной линии заканчивались материалы, на склад передавали карточку, в которой указывалось название необходимого материала, его количество и т. д. На складе была уже готова новая корзина с этим материалом: ее отправляли в цех, а сотрудники склада отправляли свою карточку поставщику. Несмотря на то что с 1940-х годов процесс усовершенствовали, его суть не изменилась: в сердце методики Kanban лежит концепция своевременной (just in time, JIT) поставки.
В наши дни agile-команды разработчиков ПО стремятся найти баланс между объемом незавершенных задач и производительностью команды, чтобы внедрить принципы JIT. С ними коллектив получает больше гибкости при планировании, быстрее добивается результата, заостряет внимание на непрерывном совершенствовании и обеспечивает прозрачность всего цикла разработки.
Ключевые принципы методологии Kanban не устаревают, их можно применить практически в любой отрасли, однако особым успехом эта разновидность Agile пользуется среди команд разработчиков ПО. Для внедрения Kanban в цехах требуется изменить физические процессы и приобрести дополнительные материалы, а командам разработчиков нужны только доска и карточки заданий, да и те могут быть виртуальными.
Работа всех kanban-команд строится вокруг доски Kanban — инструмента визуализации и оптимизации рабочего процесса. Хотя некоторые команды предпочитают физические доски, виртуальные доски обязательно есть в любом инструменте agile-разработки ПО: с ними можно отследить процессы, организовать совместную работу и доступ из разных мест.
Независимо от того, какую доску Kanban, цифровую или физическую, использует команда, она позволяет сделать работу нагляднее, стандартизировать рабочий процесс, а также мгновенно выявлять и устранять все блокеры и зависимости. На стандартной доске Kanban процесс состоит из трех этапов: «К выполнению», «В работе» и «Готово». Однако в зависимости от размера, структуры и целей команда может составить собственный план рабочего процесса по своим методам.
Поскольку методология Kanban основана на полной прозрачности работы и общении в реальном времени, доска Kanban служит единым достоверным источником информации о работе команды.
В переводе с японского слово Kanban означает «вывеска». Команды Kanban представляют каждую рабочую задачу в виде отдельной карточки на доске. Для чего это делается? Благодаря такому наглядному представлению участникам команды проще и удобнее отслеживать прогресс рабочего процесса.
Карточки Kanban содержат важную информацию о заданиях проекта и наглядно демонстрируют, кто отвечает за какие задания, дают краткое описание заданий и предполагаемый срок выполнения. На виртуальных досках Kanban в карточки также часто добавляют снимки экрана и другие полезные для исполнителя технические детали.
Возможность в любой момент узнать статус каждого задания и всю связанную с ним информацию повышает сосредоточенность участников команды, делает процесс прозрачным на всех этапах и помогает быстрее выявить блокеры и зависимости.
На сегодняшний день Kanban — одна из самых популярных методологий разработки ПО среди agile-команд. Kanban предоставляет командам всех размеров ряд дополнительных преимуществ, касающихся планирования заданий и обеспечения производительности.
Kanban-команда сосредоточена только на текущей работе. Как только коллектив завершает работу над заданием, участники выбирают следующий элемент из бэклога. Владелец продукта может менять приоритет заданий в бэклоге, не мешая работе команды, поскольку изменения происходят за пределами текущих задач.
Если владелец продукта следит за тем, чтобы наверху бэклога были самые важные задачи, значит, можно не сомневаться в том, что разработчики приносят бизнесу максимальную пользу.
Опытные владельцы продуктов обязательно привлекают команду разработчиков к редактированию бэклога. Например, если в бэклоге описаны пользовательские истории 1–6, оценка истории 6 может быть основана на стадии готовности историй 1–5. Во избежание неприятных сюрпризов все изменения лучше согласовывать с разработчиками.
Время цикла — ключевой показатель для kanban-команд. Под временем цикла понимается время прохождения задачей жизненного цикла, от начала работы до поставки. При оптимизации этого показателя команда сможет с уверенностью предсказывать срок выполнения задач в будущем.
Если теми или иными навыками обладает несколько сотрудников, время цикла сокращается, а если только один — в процессе появляется узкое место. Именно поэтому команды стремятся делиться знаниями и внедряют такие практики, как проверка кода и наставничество. Благодаря обмену знаниями участники команды могут браться за самые разные задачи и оптимизировать время цикла еще эффективнее.
Кроме того, при таком подходе команда может совместно устранять любые узкие места, что способствует быстрому решению проблем и равномерному продвижению работы по процессу. Например, ответственность за тестирование лежит не только на инженерах по контролю качества, но и на разработчиках, то есть эффективность поддерживается совместными усилиями. В системе Kanban все участники команды следят за тем, чтобы работа продвигалась в равномерном темпе на протяжении всего процесса.
Многозадачность снижает эффективность. Чем выше рабочая нагрузка, тем чаще приходится менять контекст, что затрудняет выполнение заданий. Вот почему важнейший принцип Kanban заключается в ограничении объема незавершенной работы. Он позволяет быстро выявлять в деятельности команды узкие места, вызванные нехваткой внимания, сотрудников или навыков.
К примеру, в рабочем процессе типичной команды разработчиков ПО может быть четыре статуса: To Do (К выполнению), In Progress (В работе), Code Review (Проверка кода) и Done (Выполнено). Для этапа проверки кода можно задать ограничение в две задачи. Оно может показаться чрезмерно жестким, однако это значение выбрано неслучайно.
Нередко разработчикам больше нравится писать собственный код, чем проверять чужую работу. Жесткое ограничение стимулирует команду уделять особое внимание задачам, находящимся на этапе проверки, а также просматривать работу коллег, прежде чем создавать свои задачи на проверку кода. В итоге такой подход позволяет сократить общее время цикла.
Одна из основных ценностей заключается в предельном внимании команды к повышению эффективности с каждой рабочей итерацией. Графики служат наглядным инструментом, благодаря которому участники всегда будут стараться улучшить результат.
У команды есть доступ к данным, а потому заметить (и устранить) узкие места в процессе становится проще. Kanban-команды часто применяют два вида отчетов: графики управления и сводные диаграммы процесса. На графике управления указано время цикла по каждой задаче и скользящее среднее значение для всей команды.
Цель команды — сократить время прохождения задачи по этапам рабочего процесса. Если среднее время цикла на контрольном графике снижается, команда на верном пути.
На сводной диаграмме процесса отображается количество задач в каждом состоянии. Выявить блокеры не составит труда: когда количество задач на одном из этапов растет, что-то идет не так. Промежуточные состояния, такие как «В работе» или «На проверке», указывают на то, что задача еще не поставлена клиенту. Блокеры на этих этапах могут повысить вероятность серьезных конфликтов при интеграции в процессе слияния кода, отправленного в вышестоящий репозиторий.
Непрерывная поставка (CD) предполагает частый выпуск релизов продукта для клиентов. Непрерывная интеграция (CI) — это практика инкрементной автоматизированной сборки и тестирования кода в течение дня. Вместе эти методики образуют конвейер CI/CD, без которого командам DevOps было бы сложно ускорить поставку ПО, сохранив при этом его высокое качество.
Kanban и CD отлично дополняют друг друга, поскольку обе практики основаны на своевременной (Just-in-time) и последовательной поставке ценных возможностей. Чем быстрее команда сможет довести инновации до рынка, тем более конкурентоспособным будет ее продукт. Таким образом, kanban-команды стремятся оптимизировать поставку продуктов клиентам.
Некоторые концепции Kanban и Scrum совпадают, однако в этих методиках используются совершенно разные подходы, в связи с чем их нужно четко разграничивать.
SCRUM | KANBAN | |
Ориентация на релизы | Регулярные спринты с фиксированной продолжительностью (например, 2 недели) | Непрерывный процесс |
Роли | Владелец продукта, scrum-мастер, команда разработчиков | Поставка выполняется непрерывно или на усмотрение команды |
Ключевые показатели | Скорость | Время цикла |
Отношение к изменениям | В ходе спринта командам следует избегать изменений в прогнозах по спринту: изменения могут исказить оценку задач. | Изменение может произойти в любой момент |
Некоторые команды объединяют идеалы Kanban и Scrum в метод под названием Scrumban. Из Scrum берут роли и фиксированные по длительности спринты, а из Kanban — пристальное внимание ко времени цикла и ограничение объема незавершенной работы.
На начальных этапах знакомства с Agile мы настоятельно рекомендуем выбрать одну методику и придерживаться только ее. А коллективам, уже готовым внедрить Kanban, мы предлагаем сегодня же воспользоваться нашим бесплатным шаблоном доски Kanban!
Повысьте эффективность до максимума, отслеживая и выполняя наиболее важную работу.
Методология Agile оказала на меня огромное влияние как в профессиональном, так и в личном плане. Я понял, что и в программировании, и в жизни оптимальный подход — гибкий. Мои интересы лежат на пересечении технологий, фотографии и мотоспорта.