Этим летом гибкая практика организации производства “Канбан” докатилась и до IT-менеджеров в России. Рассказывать очередной раз, о том “Что такое Канбан?”, наверное, уже не имеет смысла. Тем, кто еще не знает, что это, предлагаю прочитать статью, или сходить на блог Karl Scotland. Полезно так же посмотреть видео Kanban vs Scrum с agilerussia.
Методика безусловно имеет право на жизнь. Чуда она не сделает, но, например, в ситуации, когда задачи поступают непрерывно и их приоритеты меняются часто, канбан можно успешно применять. Но, есть оборотная сторона, о ней и буду говорить.
В канбан легко потерять цель проекта. За счет того, что ограничивается только количество одновременных задач в разработке, всегда можно решением product-owner приостановить выполнение одной работы и начать другую. С течением времени может оказаться, что вы делали много приоритетных задач, которые однако никакого отношения к выпуску продукта не имели. В канбан ценность таких документов как scope, или техническое задание, несколько ниже, чем в том же Scrum, они вас не защитят. Впрочем, в жизни я наблюдал много ситуаций, когда подписанное техническое задание, в дальнейшем игнорировалось заказчиком, и он оказывал давление на разработчика. Никакая методология от этого не защитит.
Нестабильный список задач в разработке. В ситуации ,когда чтоб добавить одну задачу надо выкинуть какую то другую, мы получим списочек недоделанных задач. Недоделанный код будет болтаться в репозитарии, его надо будет поддерживать, а спустя некоторое время, переделывать заново. Более того, ваш топ-менеджер может начать думать, что работы уже выполнены (ведь ему о них рассказывали!), а вы то знаете, как на самом деле. Эта ситуация – прямая потеря денег для разработчика. Нельзя допускать произвол product-ownera! И так как спрингов нет, это становится головной болью руководителя проекта.
А что считать задачей? Основная идея канбан – ограничивать Work In Progress (WIP) В качестве “work” надо выбирать minimal marketable feature (MMF) MMF, как точно отметил bishop, это то “о чем не стыдно написать на блоге”. Однако, не про все нужные задачи вы захотите рассказывать на корпоративном блоге. 
А главное, понятие minimal feature, чрезвычайно относительное понятие. Как пример относительности, один и тот же список MMF можно раздать участникам команды в зависимости от их опыта так, что он будет выполним или невыполним. Так что на практике WIP часто “плывет”. Подбор этого значения для команды часто является непрерывным процессом. Как следствие – руководитель проекта вынужден в каждый отдельный моент заново решать, потянет его команда сейчас “еще одну маленькую но очень важную задачу” или нет.
Примитивное планирование. Да, вы будете нравиться топ менеджеру в моменты, когда надо будет быстро сделать демо-версию чего-нибудь к внезапно объявленной презентации. Но, когда вы не сможете точно ответить, какая функциональность у вас была реализована на момент вчерашнего дня, а какая будет сделана к концу недели, вы будете нравиться намного меньше. Канбан справедливо критиковали на Habrahabr за отсутствие методов оценки эффективности работы команды (правда, это не значит что в Канбан нельзя никак оценить эффективность). Кроме того, канбан часто применяется как раз в ситуации когда, по каким то причинам, недоработали аналитики, требования выяснены не полностью и, соответсвенно, предсказать что либо становится невозможно. Но, это уже не издержки самой практики, а скорее, типичная проблема ситуации, в которой эта практика становится востребованной.
Повышенная нагрузка на менеджера. Меньше правил означает больше персональных решений. Сами решайте, когда надо выпустить новый релиз, когда провести ревизию, какие методики вводить, считать ли фокус-фактор. Все эти решения ложатся на совесть руководителя проекта.
Перечисленные мной проблемы не отменяют Канбан. Эта практика может оказаться полезной во многих ситуациях, только, руководители проектов, будьте бдительны.
Recent Comments