Когда лучше использовать Kanban

Создано Тимофей Евграшин, 09/07/2010 в рубрике Управление проектами | View Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи по теме

• Когда и как выбирать пилотные команды (часть 2)
• Когда и как выбирать пилотные команды (часть 1)
• Электронные доски: как бороться с информационными холодильниками
• Один из возможных форматов ретроспективы
• Как это было в Харькове 2 недели назад

blog comments powered by Disqus