Что такое канбан
Владимир Олохтонов о работе старшего разработчика в Авито Зачем устанавливать Ubuntu
Что такое канбан

Если зай­ти в любой айтиш­ный офис, где-нибудь на стене вы уви­ди­те дос­ку со спис­ком задач и цвет­ны­ми сти­ке­ра­ми. Это канбан-система: её исполь­зу­ют для управ­ле­ния проектом:

  • Про­ект делит­ся на эта­пы и задачи
  • Зада­чи мар­ки­ру­ют­ся цвет­ны­ми карточками
  • Про­цесс рабо­ты раз­де­лён на эта­пы: как мини­мум на три, но мож­но и больше
  • По мере готов­но­сти кар­точ­ки дви­га­ют­ся сле­ва напра­во меж­ду этапами.

Теперь посмот­рим глуб­же на весь этот процесс.


В канбан-системе вы дели­те про­ект на эта­пы и зада­чи, мар­ки­ру­е­те зада­чи цвет­ны­ми кар­точ­ка­ми и дви­га­е­те их сле­ва напра­во по тем пра­ви­лам, кото­рые вам удобны 

Подготовка задач для очереди

Зада­чи нель­зя про­сто взять и сде­лать. Сна­ча­ла их нуж­но сфор­му­ли­ро­вать — так, что­бы испол­ни­те­лям было всё понятно.

Напри­мер, заказ­чи­ку нужен сайт. Для его созда­ния нуж­но сде­лать несколь­ко после­до­ва­тель­ных вещей: при­ду­мать дизайн, свер­стать, натя­нуть на систе­му управ­ле­ния кон­тен­том, под­го­то­вить кон­тент и всё про­те­сти­ро­вать. Каж­дая из задач тре­бу­ет каких-то ввод­ных. Эти ввод­ные нуж­но собрать, согла­со­вать с кли­ен­том, сфор­му­ли­ро­вать чёт­кое задание:

  • Каким дол­жен быть дизайн? На что похож? Какие тех­ни­че­ские ограничения?
  • Для каких стра­ниц нужен кон­тент? О чём он дол­жен сообщать?
  • Какие воз­мож­но­сти нуж­ны в систе­ме управ­ле­ния контентом?
  • Кто и как будет под­дер­жи­вать этот сайт?

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

👉 В иде­аль­ной ситу­а­ции в рабо­чий про­цесс долж­ны попа­дать толь­ко согла­со­ван­ные зада­чи, кото­рые тре­бу­ют от испол­ни­те­лей толь­ко тех­ни­че­ских навы­ков. Раз­ра­бот­чик берёт свою «кар­точ­ку», испол­ня­ет всё чёт­ко по зада­нию, отда­ёт её даль­ше. Так мы полу­ча­ем эффек­тив­ную и быст­рую разработку.

❌ В реаль­но­сти ред­ко быва­ет, что зада­ние сфор­му­ли­ро­ва­но пря­мо иде­аль­но, поэто­му коман­де всё-таки при­хо­дит­ся уточ­нять. Чем боль­ше такой рабо­ты на них выпа­да­ет, тем мед­лен­нее дви­га­ет­ся разработка.

Рабочий процесс

Теперь нам нуж­но раз­бить рабо­чий про­цесс на ста­дии, через кото­рые долж­на про­хо­дить каж­дая зада­ча. Напри­мер, без дизай­на нель­зя начи­нать раз­ра­бот­ку, а без раз­ра­бот­ки пере­хо­дить к вёрст­ке, созда­нию кон­тен­та и тести­ро­ва­нию сайта.

На этом эта­пе за каж­дой зада­чей закреп­ля­ет­ся испол­ни­тель и могут вво­дить­ся лими­ты на коли­че­ство выпол­ня­е­мых задач — если на ста­дии «Дизай­на» сто­ит лимит «2», то толь­ко два маке­та могут нахо­дить­ся на руках у дизайнеров.

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

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


Коли­че­ство рабо­чих ста­дий и лими­ты задач коман­да опре­де­ля­ет само­сто­я­тель­но. Глав­ное пра­ви­ло: не брать новую зада­чу, пока не выпол­не­на теку­щая, и не отка­зы­вать­ся от теку­щей, пока она не пере­ве­де­на на новую ста­дию. Как имен­но опре­де­лять сте­пень готов­но­сти зада­чи — решай­те сами 

Завершение

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

Ана­ли­зи­руя вре­мя, мы видим ско­рость выпол­не­ния задач и можем зара­нее пла­ни­ро­вать про­ек­ты. Если мы зна­ем, что дизайн такого-то объ­ё­ма был сде­лан за 7 дней, мы не будем в сле­ду­ю­щем про­ек­те пла­ни­ро­вать дизайн за 2 дня. Это даст нам боль­ше уве­рен­но­сти в сле­ду­ю­щих проектах.

Важ­но фик­си­ро­вать вре­мя, пото­му что через месяц мене­джер и дизай­нер уже сами не вспом­нят, сколь­ко они сиде­ли над каж­дой зада­чей. А когда всё запи­са­но — мож­но отследить.

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


В канбан-системах обя­за­тель­на ана­ли­ти­ка, посколь­ку толь­ко с её помо­щью мож­но непре­рыв­но совер­шен­ство­вать рабо­чий процесс 

Легенда карточек

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

Если у вас слож­ный про­цесс и нуж­ны допол­ни­тель­ные обо­зна­че­ния — исполь­зуй­те знач­ки или икон­ки. Напри­мер, воз­ле задач со стро­гим дед­лай­ном мож­но ста­вить часы ⏳, а воз­ле задач, раз­де­лён­ных на несколь­ко испол­ни­те­лей, — мет­ки с фла­гом 🚩 Огра­ни­че­ний нет, поэто­му выби­рай­те любые обозначения.


При­ме­ры цвет­ных мар­ки­ро­вок, на кото­рые вы може­те ориентироваться 

Запомнить

Канбан-система — это спо­соб орга­ни­за­ции рабо­че­го про­цес­са, когда вы не хва­та­е­тесь за всё под­ряд и выпол­ня­е­те про­ек­ты в стро­гой последовательности.

Канбан-доски мож­но рисо­вать на ват­мане или в онлайн-приложениях типа Трел­ло — здесь поду­май­те, как будет удоб­но рабо­тать вам и участ­ни­кам команды.

Если вы не хоти­те делать замет­ки вруч­ную и не понра­ви­лось Трел­ло — попро­буй­те JIRA Software. Это более слож­ный инстру­мент управ­ле­ния про­ек­та­ми, кото­рым поль­зу­ет­ся стар­ший раз­ра­бот­чик в Ави­то Вла­ди­мир Олох­то­нов.

Текст и схе­мы:
Алек­сандр Бабаскин
Редак­тор:
Мак­сим Ильяхов
Кор­рек­тор:
Ира Михе­е­ва
Вёрст­ка:
Маша Дро­но­ва
Худож­ник:
Даня Бер­ков­ский
Достав­ка:
Олег Веш­кур­цев