GraphQL у свiтi компонентiв від Катерини Поршнєвої — React fwdays онлайн | 27 березня
×Закрыть

Что такое Канбан

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

Идея единого потока

Для начала нужно понять, что это вообще такое и для каких целей появилось. Канбан был изобретён проектными менеджерами на заводах Toyota для того, что бы процесс создания продукта (в данном случае, автомобилей) стал более прозрачным. Классическая схема, используемая в то время, предполагала производство огромного количества деталей в разных цехах или даже предприятиях, не связанных между собой. Перед финальной сборкой могли пройти дни, недели и даже месяцы. Таким образом, если один из отделов допускал ошибку, о ней узнавали только через несколько недель, и все это время выпускались бракованные комплектующие. Убытки в данном случае чудовищны: оплаченная работа, испорченный материал, транспортировка, складирование, переработка и время. Спасительной и ключевой здесь являлась идея создания единого потока.

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

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

Как это выглядит на практике

Рассмотрим пример использования Канбана. Допустим, перед нами рядовая IT-компания, которая при производстве применяет итеративную методологию, а для отслеживания оперативной ситуации внутри спринта используется Канбан доска.

To do — спринт бэклог.
In progress — задачи, которые разрабатываются в данный момент.
Ready for deploy — задачи, которые уже выполнены, но не представлены в тестовом окружении.
QA — задачи, готовые к тестированию.
PO/PM approving — готовые задачи проходят проверку project owner-ом или проектным менеджером.
Done — выполненные (завершённые) задачи текущего спринта.

Процессы в спринте здесь проходят таким образом: приступая, разработчик перетягивает задачу из To do в In progress. В один момент времени он имеет только одну задачу, так как параллельное выполнение задач ничем хорошим не кончается. После окончания своей части работы, он перетаскивает её в колонку Ready for deploy.

Начиная с этого момента за дело берётся отдел тестирования. По достижению лимита задач в этой колонке QA инженер инициируют сборку билда, или сервера, или ещё чего-нибудь. В идеале для этих целей хорошо иметь continuous integration инструмент, такой как Jenkins, например. Также допустимо просто попросить разработчика собрать билд или обновить сервер. При успешных результатах тестирования задача отправляется в колонку PO/PM approving, где получает финальное подтверждение и перетягивается в последнюю колонку Done. Если задача не проходит тестирование, она снова попадает в колонку To do с соответствующим комментарием. Багрепорт имеет точно такой же жизненный цикл.

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

Также желательно осуществлять промежуточные поставки кода в колонку Ready for deploy, так как это сможет обеспечить более оперативную обратную связь. Скопление тасок в любой из колонок называется «бутылочное горлышко». Это значит, что пропускной способности на данном участке не достаточно, и нужно найти причину и решить её.

Для быстрой обратной связи QA инженер должен иметь возможность протестировать отдельные компоненты: БД, API, front-end, back-end.

Почему именно Канбан

С таким инструментом компания имеет слаженную работу, где каждый знает свою локацию на общей карте. Перед ней открываются все преимущества Канбана, из которых следует отметить:
— Уменьшение времени прохождения каждой конкретной таски и, как следствие, выполнения всего проекта в целом;
— Быстрая обратная связь от отдела тестирования;
— Раннее вовлечение тестировщиков и, как следствие, никакой головной боли перед релизом;
— Высокое вовлечение команды в процесс разработки;
— Выполнение проекта в срок за счёт уменьшения времени простоев и автоматизации интеграции;
— Высокое качество продукта.

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

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: SoundCloud | Google Podcast | YouTube


46 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Примитивщина
Канбан это не просто доска to do in progress done
Подходящее название статьи это мы используем Jira Kanban board вот так (и то только в разработке, хотя канбан для полного цикла)
Диаграммы, метрики, ограничение, вытягивание, новые роли, statik etc....

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

Вот напишут всякого такого,а потом в слаках/скайпах геволт стоит что «весь этот ваш аджайл — говно полное».

Както процесс похож на waterflow который в софтвердевелопменте мало эфективен и применяется редко

10-15 лет назад применялся еще как. просто сейчас уже не модно, модно скрам. софтверная индустрия вообще подвержена влиянию сиюминутной моды

Если вы разрабатываете БД а не социалочку для лайкания фоток с котиками, то вотерфол в разы лучше.

Для разных проектов, разные методологии

дайте плз пруф
а еще какие проекты вы знаетекроме 2х крайностей БД и котики

Настоятельно рекомендуется ознакомиться с работами Мартина Фаулера или например
«Refactoring Databases: Evolutionary Database Design»
by Scott J Ambler and Pramod J. Sadalage
И не нести пурги.

Может поведаете свое понимание? Ибо ссылка на Фаулера, который энтерпрайзами занимается, и все что он писал тоже о энтерпайзах, и книгу как схему проектировать, не соотносится с написанием БД

У меня сложилось мнение, что при кодировании вы не используете систему контроля версий?
И так сойдет, не Энтерпрайз-же поди, че?
А вот в Энтерпрайзе там уже «да», без этого не обойтись, ведь Энтерпрайз это ого-го какая моща.
«Икона святой программисткой Богоматери», можно сказать? :)

Как объяснить человеку, что проектирование и внесение изменений в схему БД часть одного и того же процесса? Внесение изменений — это трэкинг этих самых изменений со всеми вытекающими. Либо вы понимаете о чем речь и делаете это, либо нет.
Если есть схема БД, есть изменения, есть версии схемы, есть трэкинг этих версий, есть процесс внесения этих измений. Чем короче период времени, требуемый для внесения отдельного изменения, тем эффективней целый процесс, и тем чаще можно вносить эти самые изменения.
И что самое главное, абсолютно «монопенисуально» Энтерпрайз это или нет.

Вы вообще поняли что я написал изначально? Причем система контроля версий к
Agile?

Это сарказм на "

Если вы разрабатываете БД ........ то вотерфол в разы лучше

все что вы написали вообще не имеет ничего общего с разработкой БД.

какие-то высказывание о проектирование БД, о чем не было ни слова. в целом очень сомнительно что вы понимаете в чем разница между этими 2мя понятиями

Картинок может быть великое множество. На проектах покрупней эпики кочуют из менеджерской доски (например) в доски конкретных команд.
Из интересного по топику можно либо посмотреть доклад Девида Андерсона с гибких дней (по-моему 13\14 года) либо доклад Драгоша Димитриу с девпрошной конференции (попиарил).
Оба по большому счету говорят что вот это всеми любимое непрерывное улучшение процессов и уменьшение лид\сайкл таймов это прямой результат кропотливой работы с трекинг тулами (i.e. да, надо тикеты в джире привязывать к компонентам приложения, пользоваться тегами и делать какой-никакой датамайнинг).
В статье вы упустили так волнующий всех менеджеров процесс эстимейтинга и баблоотчета. Канбан как методология предполагает прогнозы (основываясь на параметрических или аналоговых эстимейтах). Чтобы было с чем эти аналогии проводить — надо корректно трекать задачи :) Потом основываясь на исторических данных можно построить распределение по типовым задачам и использовать какой-то confidence level. Очень кстати полезно для аргументирования собственных эстимейтов в глазах клиента.

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

Парень просто описал как это бывает на практике. Команды стремятся к каноническому Agile. Но на деле получается Agile собственного приготовления.

Статья cхожа с тем, что писали Atlassian blogs.atlassian.com/...an-backlog-jira-software

Как тут ниже заметили — в статье не раскрыто ее название. Если кому интересно, то в scrum.org.ua/...ScrumAndKanbanRuFinal.pdf довольно хорошо описан канбан в виде сравнения со скрамом (имеет смысл почитать тем, кто хорошо прочувствовал скрам). И да, канбан можно смело считать методологией IT разработки. И также его можно смело применять при разработке, особенно в продуктовых компаниях, и даже без учета багфикса на продакшене.

Перед тем как писать подобные обзорные статьи — стоит хорошо изучить предметную отрасль, чтобы не попасть в неловкую ситуацию и не сбивать с толку доверчивых читателей. Хотя судя по комментам — они предупреждены =)

Сначала «Кабан» прочитал)

В статье куча ошибок. Канбан — это система бережливого производства. В Канбане нет спринтов — измеряется cycle time — время, которое занимает прохождение задачи от колонки TODO в колонку DONE. Задача РМ-а постоянно уменьшать этот cycle time согласно философии Кайдзен. Также, не согласен со списком колонок в потоке. Ready for Deploy должно быть Ready for Testing, а утверждать выполнение задачи должен product owner, а не проектный менеджер. И последнее — любая задача не может считаться DONE, пока она не на боевой системе, соответственно должна быть колонка Ready to Deploy.

P.S. Continuous Integration следовало хотя бы проверить на в Word на правописание.

система бережливого производства.
это lean manufacturing

ru.wikipedia.org/...i/Бережливое_производство

Задача РМ-а постоянно уменьшать этот cycle time согласно философии Кайдзен.
это как раз противоречит философии Кайдзен, согласно которой в непрерывном улучшении должны участвовать ВСЕ,
а не единичный PM, который даже не знает значения терминов, которые использует
и сократил все непонятные ему аспекты до единственного критерия
ru.wikipedia.org/wiki/Кайдзен

Сказал знаток википедии :)

Kanban (看板?) (literally signboard or billboard in Japanese) is a scheduling system for lean manufacturing.

Олег, задача РМ уменьшать cycle time. Как это противоречит тому что все члены команды должны улучшать процесс?

Сказал знаток википедии
раз пошел переход на личности, то

я, в отличие от липовых РМ-ов, навесивших тайтлов с незнакомыми словами, действительно ранее изучал и использовал lean manufacturing, кайдзен, канбан, 6sigma и еще много чего из Дао Toyota

Канбан — это система бережливого производства.
Kanban (看板?) (literally signboard or billboard in Japanese) is a scheduling system for lean manufacturing
но для липовых сеньоров ведь нет никакой разницы? :-)

Действительно, употребляя термины типа спринт, беклог и пр. стоило говорить ИМХО о скрамбане.

Наверно да, употребляя термины типа спринт, беклог и пр., стоило говорить о скрамбане.

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

Так а что мешает ПМ-у нарезать из Канбана спринты? Особенно если продукт подразумевает поэтапную сдачу или утверждения, требующие паузы/ретроспективы.

Дело вовсе не в прозрачности. Канбан призван увеличить эффективность в цепочках производства. Неэффективности в них, обычно, двух типов — простой и перепроизводство. Вместо планирования предлагается управлять производством с помощью обратной связи (которая осуществлена через карточки). Pull со стороны Demand, вместо Push со стороны Supply. Это, конечно, добавляет прозрачности, но дело тут вообще не в ней.

Я конечно извиняюсь, но откуда в Канбане спринты?

Откуда в Канбане отсутствие спринтов?

Отттуда. Канбан, это непрерывный процесс без четко выраженных итераций. Если в Канбане появляются спринты, то это уже не Канбан.

В Канбане вообще не об этом. Со спринтами, без спринтов. Не та плоскость вопроса.

Это понятно. Я понимаю, что такое бережливое производство. Я всего лишь написал, что в Канбане нет спринтов. Автор статьи написал чушь.

В Канбане нет и ни слова про IT. Это вовсе не означает, что применять его для IT — ошибка. Канбану все равно, если ли спринты. Канбан — это про push/pull. Спринты — из другой вселенной. Настаивать, что их там нет — такая же точно глупость, как и говорить, что они там есть.

КЭП, ясное дело, что в оригинальном Канбане нет ни слова про ИТ. Но мы вроде сейчас общается на сайте DOU.ua, а не в планерке компании Toyota.
Давайте по другому. Ваши слова звучат примерно так: штаны, это штаны, и говорить, что штанов по колено не бывает, это глупо.
Да, штаны по колено бывают, но это уже не штаны, а шорты. Так и Канбан, если в нем использовать спринты, то это будет не Канбан, а Скрамбан, Скрам-но или как так еще эти гибриды называют.

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

Это же просто идеи, чувак. Их можно (и нужно) смешивать. Они не исключают друг друга, они про разные аспекты. Штаны и шорты исключают друг друга — они оба про длину штанин. А Скрам и Канбан — не особо, особенно, что касается спринтов. Разве идея развернуть supply chain и предотвращать лишнее перепроизводство/простой как-нибудь противоречит идее спринтов?

Я понимаю, о чем ты говоришь. Посмотри на статью глазами ПМа: Что такое Канбан.
В этой статье человек с умным видом рассказывает о «спринтах» в Канбане. Я не увидел ни слова о планировании в Канбане. Как задачи попадают в To Do? Ничего не написано об оценке задач. И вообще неясно, что случается, когда задачи выполнены. Также непонятно, какие роли используются в Канбане.

Но мы вроде сейчас общается на сайте DOU.ua,
Посмотри на статью глазами ПМа

Натяк зрозумілий?:-)

Если бы ты понимал, то вдяли привел бы пример с шортами.

Конечно, канбану абсолютно все равно, как задачи попадают в todo, как они оцениваются, и какие роли используются.

Человек, между прочим, написал:

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

И ниже:

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

Так кто тут не понимает?

Я еще раз повторю. Эта статья абсолютно не раскрывает основных процессов использования Канбана при разработке ПО. Описан виртуальный розовый пони в вакууме, двигающий карточки по доске.

Допустим, перед нами рядовая IT-компания, которая при производстве применяет итеративную методологию, а для отслеживания оперативной ситуации внутри спринта используется Канбан доска
 — это вообще бред.

@Eugene_Lymar:
Не придирки ради. Не могли бы Вы расширить Ваше утверждение о невозможности двигать таблички по Kanban доске внутри спринта?

Чого ти до людини причепився? Він тобі про яблука, а ти йому про сливу.

Простите но «ниочьом».
За все хорошее против всего плохого.

Подписаться на комментарии