Глава 13 Масштабирование канбана

До сих пор примеры и истории о внедрении Канбана, представленные в этой книге, касались исключительно поддержки программ – небольших системных изменений, выходивших в быстрых и частых релизах. Есть множество систем, которые нуждаются в поддержке, и многие читатели, занимающиеся разработкой ПО, найдут здесь полезные советы и планы действий. В сфере IT важную роль играют также обслуживание и эксплуатация, где тоже распространены системы заданий на краткосрочные работы. Канбан-подход очень полезен и в этом случае. Однако есть и другие отрасли, в которых нормой считается разработка проектов существенного масштаба. Если вы, читая эту книгу, задаетесь вопросом, зачем и как использовать Канбан в работе над крупными проектами и всем портфелем проектов, то надеюсь, глава 5 убедила вас: Канбан приводит к значительным положительным культурным сдвигам. Преимущества, которых можно достичь благодаря Канбану, настолько желательны, что нельзя не задуматься над тем, как совместить его с большими проектами.

Крупные проекты сопровождаются заметными проблемами. Многие требования должны быть реализованы и выпущены одновременно. До первого релиза обычно проходит много времени – порой несколько месяцев. Возрастает и число участников команды. Параллельно ведутся работы в самых разных направлениях. Нужно объединить большие куски заданий, хотя не все они имеют отношение к разработке ПО. Например, документацию и дизайн программного пакета нередко требуется интегрировать в итоговую сборку программ до выхода релиза.

Как справиться с этими проблемами?

Ответ прост: вспомнить о главных принципах Канбана – ограничении числа незавершенных заданий и вытягивании работы при помощи визуальной сигнальной системы. Помимо этого, стоит учесть принципы бережливого программирования, agile-принципы, а также особенности рабочего потока и процессов, которые внедрены на текущий момент. Итак, мы хотим установить WIP-лимиты, использовать средства визуального контроля и сигналов и вытягивать работу, только когда обладаем достаточной мощностью. Однако нужны также переносы небольших пакетов, расстановка приоритетов по ценности, управление рисками, прогресс при неполной информации, создание культуры высокого доверия и оперативный и адекватный ответ на изменения, которые происходят в течение проекта.

При работе над большим проектом, как и в случае с обычным обслуживанием, нужно достичь соглашения по поводу каденции расстановки приоритетов для пополнения входящей очереди. Следует учесть, что чем чаще происходят собрания, тем лучше. Но вернемся к принципам. Каковы операционные и координационные издержки на обсуждение с маркетологами или руководителями направлений следующих элементов очереди? На другом конце цепочки создания ценности у вас будет несколько точек интеграции или синхронизации, необходимых для релиза, а не единая точка релиза. Поэтому, исходя из главных принципов, оцените операционные и координационные издержки интеграции и синхронизации и установите каденцию. Чем она чаще, тем лучше. Кроме того, спросите себя: «Что нужно для демонстрации на совещании с руководством последних выполненных задач и их интеграции при подготовке релиза?»

Затем переходите к соглашению по WIP-лимитам. Принципы при этом также не изменяются. Не менее полезны классы обслуживания, которые помогут вам справляться с изменениями на протяжении всего проекта.