Не секрет, что Scrum подходит не для всех типов проектов. Поэтому часто говорят, что просто работают согласно Agile ценностям и принципам. В тоже время, хочется хоть каких-то, пусть и простых, правил, чтобы наладить работу команды. Все чаще, говорят о Канбан (Kanban), как о подходе, ещё более легковесном, по сравнению с другими Agile методологиями.

Канбан, как и любая другая методология, не является «серебряной пулей». Есть много ситуаций и команд, когда он подходит лучше всего и есть другие ситуации и команды, когда он почти не помогает. Когда же Канбан подходит лучше всего?

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

Микрокоманды

Как написано в книгах по Scrum, он хорошо подходит командам от 5 до 9 человек (7+/-2). Часто Иногда мы имеем дело с маленькими командами, где всего 3 человека. Для таких команд, следовать всем практикам Scrum может быть утомительным. Конечно, здравый смысл может прийти на выручку. И все-таки, даже если вы неформально проводите планирование, обзор и ретроспективы, то часто есть желание выкинуть кое-что из этого и оставить больше времени для нормальной работы.

Частая смена приоритетов

К сожалению, разработка программного обеспечения напрямую связана с огромной скоростью изменения первоначальных идей и планов. Это могут быть новые идеи; проблемы, найденные в работающей системе; смена приоритетов или просто изменение первоначального описания уже на половине готового проекта. Собственно поэтому гибкие (Agile) подходы к управлению проектами и пользуются такой популярностью. Мы пытаемся избежать долгих и затяжных периодов сбора ожиданий и требований и быстрее показать что-то работающее. Для этого мы переключаемся на более короткие циклы разработки – спринты (или проще итерации). Мы даже делаем итерации короче и короче, чтобы успевать реагировать на изменения.

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

Постоянно идущие проекты или поддержка

Типичный проект, такого рода, будет выглядеть так:

  1. Как только находится серьёзная проблема в работающей версии, её нужно чинить как можно скорее (и никого не волнует, что команда себе запланировала)
  2. Некоторые мелкие проблемы становятся важными по мере того, как подходит срок, к которому их пообещали исправить (или когда все больше пользователей обращают на них внимание)
  3. Часто клиенты придумывают мелкие новые пожелания или просят изменить то, что уже давно работает
  4. А иногда пожеланий много и они от разных заказчиков, тогда мы начинаем привлекать менеджера для расстановки приоритетов
  5. Если нет проблем и нет пожеланий, то всегда найдётся, что улучшить в системе :-).

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

Много мелких проектов

Работая одновременно над несколькими мелкими проектами одной командой, часто начинается распадение на подкоманды, и в итоге общую картину составить достаточно тяжело. Обычно, в таких случаях команду увеличивать не собираются, так как может не быть постоянной загрузки для всех. Заказчики готовы ждать чуть дольше в таких ситуациях. Хотя часто, из-за разных приоритетов разных проектов, никто не может чётко предсказать, когда будет готова та или иная функциональность и тут начинаются опять игры с приоритетами, горящими сроками и т.п. При этом ответ типа «мы сосредоточимся на одном проекте и пропустим сроки других» никого не устраивает.

Многие подходы к «управлению проектами», абсолютно не приспособлены для таких ситуаций, так как тут зачастую даже нет понятия «проекта». Здравый смысл и Канбан могут помочь вам организовать общий поток работ, и тогда единственная оставшаяся задача будет расставлять приоритеты в очереди к вашей команде.

Что общего у всех перечисленных случаев?

  • Все приведённые примеры не требуют сложных вариантов организации работы. Им подойдёт меньшая степень формализма – достаточно нескольких правил, как это предлагается при Канбан подходе.
  • В приведённых выше случаях не нужно или невозможно долго- и среднесрочное планирование. Во всяком случае, проблемы оперативного планирования решаются с помощью Канбан, а долгосрочные проекты можно делать и более структурированными и чуть более формальными подходами как, например, Скрам (Scrum).

Буду признателен за комментарии и особенно, услышать, интересуют ли читателей более практические примеры внедрения Канбан. Если же вы просто следите за новыми статьями на сайте, то делать это лучше с помощью нашей RSS ленты или подписавшись на рассылку по e-mail.

Когда лучше использовать Kanban
Tagged on:                 
  • Если честно, я так и не смог получить команду с чистым Канбан — у нас был ScrumBan скорее. Ограничение было 2n+1 и мы его, почти никогда не достигали.
    Нам WIP помогал сам по себе — мы дружно следили за тем, чтобы карточки не задерживались в каждой отдельной колонке.

    Ищу «чистую» Kanban команду в Украине, которая бы поделилась своим опытом 😉

  • При наличие масштабного проекта, несколько Скрам-команд могут чудесно работать. Им Канбан может быть и не нужен.

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

  • starina_bz

    Вопрос: с какой частотой нарушается (и нарушается-ли вообще) правило на ограничение WIP в командах, в которых ты внедрял канбан?

  • Alex Mcgray

    Я бы добавил еще команды, которые больше стандартных Скрамовских. Что-то вроде Микро или Макро команды 🙂

  • Пока, на данный момент, самое полное описание того, как Канбан работает на практике, я встретил у Хенрика Книберга в его книжке. http://www.infoq.com/minibooks/kanban-scrum-min

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

    В книге есть предисловие Дэвида Андерсона, который, собственно, считается папой Канбан для ИТ проектов. Он как раз рассказывает о том, что они стали его внедрять для проектов с поддержкой (т.е. ваш случай, как я понял). В самой книге, вторая часть — это реальная история одного такого проекта и можно сравнить их опыт с вашим.

    Буду признателен за краткий анализ вашего опыта с книгой. Готов опубликовать как пост 😉

  • starina_bz

    Эх, а я и вопрос задавал с целью узнать, существуют-ли такие команды/проекты/деятельность, которым по каким-то причинам не подходит Scrum и подошёл Kanban в чистом виде 🙂 И узнать, как им это удалось.
    Ну, видимо, ни у одного меня не получилось построить сферический Kanban в вакууме 😉 А я уж волновался…
    Мне кажется, наиболее полезным тут является необъявленный напрямую принцип о том, что оставлять незавершённые до конца работы — это плохо (об этом был очень хороший пост у вас в блоге). Kanban-board позволяет очень хорошо показать такие «висяки». Т.е. «Visualize the workflow» получается гораздо важнее чем «Limit WIP».
    P. S. Когда только узнал о Канбане и пробовал его внедрять в одной из своих команд (Scrum отпадал сразу, потому-что 99% работ в ней была поддержка + новые хотелки кучи клиентов, а итерации длиной в день являлись-бы явным извращением) обратился к первоисточникам, почитал Таити Оно и то, как реализован тру-Kanban на Тойоте и понял, что современные Agile-тренеры неплохо поспекулировали на названии 😉 Собственно, кроме WIP и визуализации ничего общего у них нет. И работает Kanban, тот который в разработке ПО, совсем не на вытягивании ценности.
    P.P.S. Тоже хотелось-бы услышать опыт «чистой» Kanban команды 🙂

  • starina_bz

    Ага, спасибо.
    Читал только первую часть, ещё когда она была как просто статья у Книберга. Теперь ознакомимся с полной версией.

  • Мария Евграшина

    Мы сейчас переводим эту книгу на русский язык, она уже подходит к завершающей стадии, так что осенью, надеюсь, уже будет полностью на русском языке:)

  • Алекс, обращаюсь 🙂
    Давайте расскажем людям о том, как вы это организовали. С удовольствием опубликуем рассказ о вашем опыте. Может кому-то еще поможет? 🙂

  • Alex Mcgray

    Переводить не за чем :). Уже давно работаем, больше года. А команда у нас и правда больше 11 человек и будет расти.

  • Alex Mcgray

    Обращайтесь 🙂

  • worksection

    класс, отличный блог. и это не спам ).