Канбан як дозвіл діяти

Канбан — це не методологія життєвого циклу розробки ПЗ і не підхід до управління проєктами. Він вимагає наявності якогось процесу, аби можна було застосувати Канбан для його поступової зміни.

Цей еволюційний підхід, що підтримує поступові зміни, досі викликає суперечки в спільноті гнучкої розробки ПЗ. Річ у тім, що в його рамках команди не повинні брати на озброєння певний метод або ­шаблон процесу.

Індустрія інструментів та сервісів розвивалась навколо доволі ­обмеженого набору практик, зібраних у двох найпопулярніших методах Agile-розробки. Зараз у рамках Канбану розробники та їхні ­команди можуть створювати власні унікальні робочі процеси, що усуває потребу в таких сервісах і вимагає створення нового набору інструментів. І дійсно, Канбан породив нову хвилю компаній-розробників ПЗ, які готові замінити вже наявні інструменти гнучкого управління проєктами на щось більш візуальне і програмоване, таке, що можна легко підлаштувати під будь-який конкретний робочий процес.

У ранні часи гнучкої розробки ПЗ лідери спільноти часто не розуміли, чому їхні методи працюють. Ми говорили про «екосистеми» і радили новачкам впроваджувати усі практики без винятку — інакше рішення не спрацює. Протягом останніх років спостерігається тенденція, що розвиває такий напрям думок. Деякі компанії розробили моделі Аgile-зрілості, які намагаються оцінити опанування певних практик. У Scrum-спільноті, наприклад, існує так званий «тест Nokia», заснований на оцінці практик. Такі тести, що ґрунтуються на практиках, заохочують однаковість і відкидають необхідність адаптації відповідно до контексту. Канбан дає компаніям дозвіл ігнорувати ці схеми оцінювання на підставі практик. Він активно заохочує ­різноманітність.

У 2007 році кілька колег відвідали мій офіс у Corbis, аби побачити Канбан у дії. Зазвичай усі відвідувачі, пов’язані з Аgile-спільнотою, запитували те саме: «Девіде, ми побачили в офісі сім канбан-дошок. Вони всі різні! Кожна команда працює за власним процесом! Як можна впоратися з таким розмаїттям?»

На це питання я здебільшого зневажливо відповідав: «Звісно! Бо ситуація у кожній команді різна. Вони вдосконалюють свій процес відповідно до контексту». Але я знав, що всі процеси беруть початок від тих самих принципів і що члени команд, розуміючи ці базові принципи, можуть легко пристосуватись до нового процесу, переходячи до іншої команди.

Коли Канбан спробувало більше людей, вони зрозуміли, що ця си­стема допомагає вирішувати проблеми управління змінами, із якими вони зіткнулися у своїх організаціях. Канбан надає гнучкості команді, проєкту або компанії.

Ми дійшли висновку, що Канбан дозволяє створити власний процес, оптимізований для конкретного контексту. Канбан дає людям ­дозвіл думати самостійно. Він дозволяє їм бути несхожими: відрізнятися від команди в сусідньому офісі, на іншому поверсі, в іншій будівлі або у конкуруючій фірмі. Він також дає дозвіл відійти від «підручника». Ба більше: Канбан надає інструменти, що дозволяють пояснити (і виправдати), чому відмінності — це добре і чому вибір бути іншими — правильний вибір у таких умовах.

Аби підкреслити цей вибір, я розробив дизайн футболки для «Товариства обмеження WIP». Я надихався постером Шепарда Фейрі для передвиборної кампанії Барака Обами, на який замість президента помістив портрет Таїті Оно, творця канбан-системи в Toyota. Гасло «Так, ми канбанимо!» (YesWeKanban!) мало підкреслити, що у вас є дозвіл. Дозвіл спробувати Канбан, дозвіл змінити свої процеси, дозвіл стати іншими. Ваша ситуація унікальна, і ви можете розробити свій унікальний процес, оптимізований під вашу сферу діяльності, ваш потік створення цінності, ризики, з якими ви стикаєтесь, під навички вашої команди і вимоги ваших клієнтів.