Читать книгу Канбан. Успішні еволюційні зміни для вашого технологічного бізнесу - Дэвид Дж. Андерсон - Страница 18

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

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

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

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

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

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

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

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

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