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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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