Канбан в IT: чертова дюжина преимуществ от внедрения Канбан досок для разработки ПО

Александр Сергеев, основатель и руководитель Hygger делится своим опытом перехода на Канбан в управлении IT проектами.

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

Теперь представьте себе салон-магазин Toyota. Вы присмотрели себе Toyota Camry и внесли оплату. На складе салона не было вашего цвета/комплектации и поэтому заказ отправился на завод Toyota в Санкт-Петербург. Вам сообщили когда машина прибудет к вам. И только сейчас машину начали делать для вас. То есть работает принцип - сначала продай, а потом произведи. Или JIT - just in time - точно в срок. Сначала срок и цель, потом план и работа, необходимые чтобы благодаря составленному плану достичь нужную цель.

На заводе Toyota складские запасы близки к нулю и нет нужды хранить заранее произведенные запчасти . Почему? Потому что все, что производится сейчас на линии - все необходимо для какой-то уже проданной машины. Одним из ключевых элементов в системе JIT является Канбан (KAN означает «визуальный» и BAN означает «карточки» или “визуальные карточки”). Эти карточки являются светофорами для JIT системы.

Например, представьте, что вы ставите коробки передач на Toyota Camry на главной соборочной линии. Рядом с вашим участком лежат 8 коробок передач. Вы ставите одну коробку, потому вторую, потом третью и когда у вас остается в наличии 4 коробки передач, вы берете Канбан карточку и пишете на ней заказ на 8 новых штук и передаете ее тому, кто делает коробки. Ибо вы знаете, что ваш коллега сделает и привезет вам эти 8 коробок именно тогда, когда вы поставите в машину последнюю 8 коробку. И так по кругу - вы заказываете новые коробки передач только тогда, когда они вам нужны. Вспоминаем салон Toyota - они заказывают машину на заводе только тогда, когда вы ее оплатили.

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

Мой пример был из производства, теперь посмотрим как это работает в разработке ПО. В качестве запчастей у нас - задачи на разработку или баги. Тестировщик берет у программиста несколько задач для проверки (по аналогии со сборочной линией, где мастер брал коробки передач для установки в машины). Когда у QA заканчиваются задачи на проверку, он должен сообщить об этом программистам, чтобы они поторопились и дали ему новые задачи. Если программисты не успевают закончить новые задачи, то тестировщик остается без задач и простаивает. Бывает и обратная ситуация - когда у тестировщика скапливается очень много задач и он не успевает их все проверять. И в таком случае срок выпуска продукта (машины) откладывается, потому что тестировщик не успевает с надлежащим качеством проверить все задачи.

Сбалансировать Канбан в разработке ПО намного сложнее чем на производстве из-за специфики работы: если станки клепают однотипные детали, то программисты пишут код своей головой, в которой примерно 100,000,000,000 нейронов и один, но большой и пресловутый человеческий фактор.

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

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

В списке я привожу преимущества от внедрения Канбан в IT компании, которая занимается разработкой ПО:

1. Выявление узких мест. После перехода с обычных списков задач на Канбан доски мы сразу увидели наше узкое место - в колонке Testing скапливалась большая очередь задач - наш тестировщик не справлялся с проверкой задач. Он брал задачи на проверку с большой задержкой. В итоге после того, как QA возвращал задачу на доработку, программист уже успевал ее хорошенько подзабыть. Раз забыл, значит надо смотреть код и вспоминать о чем там шла речь. А это - драгоценное время. Решение - взяли второго тестировщика. Бинго.

Канбан доска позволяет увидеть места в вашем процессе, где образуются очереди. WIP лимиты позволяют находить такие узкие места на Канбан доске.

2. Точный порядок выпуска фич. Часто порядок выпуска фич имеет большое значение. В списках, построенных на приоритетах (major, minor, critical, etc.) тяжело точно управлять порядком. Ну будет у программиста 5 задач с приоритетом “major” и какую из этих 5 задач ему нужно взять в работу?

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

3. Главное внимание главным вещам. После перехода на Канбан мы стали делать только то, что реально добавляло ценности продукту. Мы смогли упрятать подальше от программистов (читай - опустить вниз) тонны бесполезных багов и доработок. С глаз долой из сердца вон.

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

Чтобы отделить зерна от плевел, мы используем Swimlanes или горизонтальные колонки на Канбан доске. У программистов на доске как правило есть такие Swimlanes:

• Blockers - для задач и багов, которые надо править в режиме реального времени, например, сломалась регистрация.
• Tasks and Bugs - обычные задачи и баги.
• Someday - задачи, которые или потеряли свою актуальность или никогда не были актуальными.

Чем-то наша система похожа на квадрант Эйзенхауэра. Важные и срочные - это Blockers. Важные, но несрочные - это Tasks and Bugs. Неважные и срочные, а также неважные и несрочные - это все Someday.

4. Концентрация на работе. Программист видит свою очередь и не думает что делать дальше - за него уже сделал выбор его менеджер. Больше не надо тратить время на выбор следующей задачи — “взять в работу вот этот баг, или вот эту задачу?”.

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

Установить фокус на свои задачи помогает фильтр My Tasks:

5. Панорамный вид. Вся картина по проекту - на вашей ладони, можно зайти на доску и быстро получить ответы на важные вопросы:

• Кто чем занят сейчас?
• Что они будут делать дальше?
• Какие задачи были переоткрыты из-за багов?
• Кто простаивает без работы?
• Где скопилась большая очередь задач?
• В каких задачах произошли какие-либо изменения за последние сутки?
• Кто простаивает без работы?
• Когда будет сделана задача X?
• Как скоро закончатся задачи у сотрудника? (как скоро ему нужно описать/спроектировать новые задачи).
• На какие задачи уже потрачено больше времени, чем было запланировано?

6. Больше гибкости. Мы стали более гибкими — мы стали менять требования “на лету”, причем без какого-либо сопротивления со стороны программистов. Это особенно нужно, когда продукт выходит в свет и у него открываются чакры, в которые поступает много полезной обратной связи: поведенческая аналитика, обращения в саппорт, результаты а/б тестирования, отзывы и прочее. Поэтому как только мы заливаем новую фичу на продакшн, так сразу и начинаем ее менять на основе обратной связи. Раньше программист не хотел делать “левые” задачи, боясь “завалить” сроки по спринту. С Канбаном программист работает как процессор — тактами, один такт — одна задача. Главное — не трогать его внутри такта. Чем чаще такты, тем гибче команда разработки. Идеальный такт для нашей команды — 8-12 часов. Поэтому крупные задачи мы обязательно декомпозируем.

7. Нет нужды оценивать фичи. В скраме приходилось тратить много времени на оценку фич перед стартом спринта, сейчас потребности в оценке нет — когда сделаем фичу, тогда и сделаем.

8. Больше дела, меньше трепа. В Scrum много времени уходит на общение. Перед началом спринта идет его планирование: анализ задач, оценка задач. Во время спринта ежедневные стэндапы. После окончания спринта проводится ретроспектива. В итоге все издержки на коммуникации в сумме забирают порядка 30% времени, которое команда могла бы инвестировать в работу.

9. Слаженность команды. Тестеры стали проверять фичи практически сразу после того, как они были закончены программистами. Раньше QA проверяли фичу не тогда, когда программист ее сделал, а спустя длительное время. Программист успевал забыть эту фичу и тратил много времени на то, чтобы снова погрузиться в задачу. Сейчас, в Канбане, тестер проверяет фичу практически сразу после того, как ее сделал программист. Аналогично на всех других участках - у дизайнеров и UX, у редакторов, у сейлзов. Команды начинают работать более согласованно, как будто под общий метроном, который отбивает общий такт: раз-два-три, раз-два-три.

10. Чаще и быстрее ошибаемся. Когда мы работаем по Скраму, то мы заливаем фичи на production только в конце спринта, примерно раз в 3 недели. На Канбане мы их заливаем практически сразу после приемки тестировщиком - раз в несколько дней. Так мы быстрее узнаем зашла фича юзерам или нет. Если не зашла - значит мы где-то ошиблись. А мы хотим ошибаться первыми! Это не значит, что мы любим ошибаться, но если мы первыми ошибёмся — мы первыми получим опыт и первыми будем знать, куда идти дальше.

11. Больше потока. Не надо постоянно пинговать программистов - че делаешь - че делаешь. Зашел на Канбан доску, быстро окинул взором кто что делает и пошел дальше делать свои темные менеджерские делишки. А программист продолжает оставаться в состоянии потока, получая кайф от работы и от взятия новых вершин.

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

13. Концентрация на одной задаче. Раньше программист мог делать сразу несколько задач параллельно - то ли он выбирал задачи по настроению, то ли он просто забывал по понедельникам, какую именно задачу он делал в пятницу. Но суть от этого не меняется - он переключался с одного таска на другой и тратил море времени на эти переключения. Почему море? А вы представляете, что нужно держать программисту голове, чтобы программировать? Названия переменных, структуры данных, АПИ вызовы, алгоритм, и еще кипу важных мелочей. И каждый раз надо заново вникать в задачу: пересматривать ТЗ и прототип, прочитывать существующий код и строить его внутреннюю репрезентацию, чтобы потом оперировать им в голове. Сейчас благодаря WIP лимитам и панорамному виду программист не может делать более одной задачи сразу.

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

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

Канбан - это то, что помогает вашим IT воинам работать слаженно и максимально эффективно.