Упровадження канбан

Складання карти потоку створення цінності

Канбан є  підходом, що сприяє змінам, оптимізуючи ваші процеси. Головне на початку застосування методу Канбан  — упроваджувати якомога менше змін у  робочий процес. Варто протистояти спокусі цілковито перебудувати робочий потік, переглянути штатний розклад, ролі, відповідальність і  конкретні методи роботи. Усе, що впливає на самооцінку, професійну гордість і «его» членів команди, співробітників компанії і зацікавлених осіб, має залишитися незмінним. Зміни мають спрямовуватись на кількість WIP і точки взаємодії із сусідами вище і нижче за течією потоку створення цінності. Тому вам потрібно разом із командою створити схему наявного потоку створення цінності. Намагайтеся нічого не змінювати і  не винаходити під час пошуку шляхів удосконалення.

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

Визначення стартової і фінішної контрольних точок

Необхідно визначитися зі стартовою та фінішною точками візуалізації процесу, а  також із  точками взаємодії з  партнерами, які перебувають вище і  нижче вздовж потоку створення цінності. Треба відповідально поставитися до цієї початкової стадії впровадження Канбан, оскільки неправильний вибір може призвести вас до провалу. Успішні команди зазвичай починають із  переходу на візуалізацію за допомогою карток і  обмеження кількості WIP у  межах своєї сфери контролю, а  також із обговорення нових способів взаємодії з безпосередніми партнерами по потоку створення цінності. Наприклад, якщо ви контролюєте відділ проєктування або розробки ПЗ і  маєте вплив на аналіз, дизайн, тестування і  написання коду, то складіть схему цього потоку створення цінності й  розпочніть переговори щодо нового стилю взаємодії з  розташованими вище за потоком діловими партнерами, від яких залежать вимоги, встановлення пріоритетів і  управління портфелем, а  також із  партнерами нижче за потоком, які займаються системними операціями і  підтримкою продукту. Окресливши тим самим межі, запропонуйте лише своїй команді перейти на обмеження кількості WIP. Інші не зобов’язані змінювати усталені методи роботи, обмежувати кількість WIP і впроваджувати систему витягування. Однак попросіть їх взаємодіяти з вами іншим способом — задля дотримання принципів системи витягування, яку ви намагаєтесь реалізувати в себе.

Типи робочих елементів

Обравши початкову точку для робочого процесу або потоку створення цінності, визначте, які типи робіт стосуються цієї точки, а які існують в  робочому процесі й  мають піддатися обмеженням. Наприклад, виправлення помилок радше належить до робіт, що існують переважно в  межах робочого процесу. Можливо, ви виявите й  інші типи діяльності, пов’язані з  розробкою: рефакторинг, технічну підтримку систем, оновлення інфраструктури та інші переробки. Для вхідної роботи це можуть бути користувацькі історії, створення прецедентів, функціональних вимог або функцій тощо. У  деяких випадках вхідні типи роботи можуть бути ієрархізовані  — наприклад, епік, тобто добірка користувацьких історій.

Перелік основних типів робочих елементів у командах, що використовують Канбан, складається, але не обмежується, із  таких:

1.     вимога; 
2.     функція; 
3.     користувацька історія;
4.     користувацький сценарій; 
5.     запит на зміни; 
6.     виробничий дефект; 
7.     підтримка;
8.      рефакторинг через помилки; 
9.     несправність; 
10.     пропозиція з удосконалення; 
11.      проблема блокування.

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

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

Створення стіни карток

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

Перед створенням стіни карток для візуалізації робочого потоку іноді корисно схематично окреслити його або змоделювати. На рис.  4.4 (с. 62) наведена дуже формальна модель бажаного робочого потоку, створена за допомогою діаграми станів необхідного робочого процесу. До неї додані черги на запити щодо змін і функціональні текстові змі­ни, оброблювані командою технічної підтримки XIT у Microsoft. Цілком можливим є й менш формальний підхід. Іноді достатньо навіть малюнка на кшталт тих, що фігурували в Розділі 4, блок-схеми чи її аналога. 

Коли усвідомлення робочого потоку за допомогою схем або моделювання вже відбулося, починайте роботу над стіною карток. Насамперед розбийте її на стовпчики, що відповідають виконуваним діям і  розташовані в послідовності їхньої реалізації (рис. 6.1). Малювати стовпчики краще маркером. Однак у  процесі використання намальовані лінії все одно зітруться. У  перші кілька тижнів ви, найвірогідніше, забажаєте впровадити до робочого потоку низку змін, тому продовжуйте користуватися маркером. Але з часом знадобиться щось більш стійке, наприклад вузькі рулони кольорової вінілової клейкої стрічки, що продаються в  магазинах канцтоварів (рис. 6.2). У Corbis ми зазвичай розбивали стовпчики і рядки на стіні з картками, використовуючи саме такі стрічки. Зараз це рутинна практика, і  команди застосовують для розмітки стрічки різних кольорів і  ширини.

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

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

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

•     Перша концепція полягає в тому, щоби відкинути намагання передбачити можливу локалізацію «вузького місця» або джерела варіативності, що вимагатиме буфера. Впроваджуйте систему та чекайте, поки вузьке місце не дасть знати про себе, а  потім внесіть зміни, запровадивши буфер. Варіант цього  ж підходу пропонує спочатку довільно встановити обмеження кількості WIP, аби варіативність, марнотрати й вузькі місця не чинили істотного впливу на систему витягування під час її першого впровадження. Детальніше це буде описано в Розділах 10, 17 й 19. 

•     Інша концепція передбачає наступний підхід: замість упровадження довільних обмежень кількості WIP кожна стадія роботи має бути піддана буферизації, а  етапи продуктивної роботи слід обмежити доволі жорсткими рамками. Вузькі місця і  варіативність проявлять себе в тому, наскільки суттєво будуть наповнюватися буфери. Після цього можна впровадити деякі зміни: поступово зменшувати розміри буферів, а  згодом остаточно видалити непотрібні буфери.

    На час написання цієї книжки відсутній достатній обсяг даних, аби вирішити, який підхід є ефективнішим.

Деякі команди дійшли згоди позначати буферні стовпчики й стовпчики черги завдань за допомогою карток, повернених на 45 градусів (рис. 6.4). Це потужний візуальний індикатор того, скільки робочих елементів виконується кожної конкретної миті, а не перебуває в черзі. Отже, команда та інші зацікавлені особи безпосередньо бачать розмір оптимальних (або не дуже) витрат системи.

Аналіз попиту

Аналіз попиту необхідно здійснювати для кожного певного типу роботи. Якщо у  вас накопичилися дані, проведіть на їх підставі кількісний аналіз. Якщо їх немає, то згодиться навіть аналіз на підставі особистого досвіду. Наприклад, у прикладі з Microsoft, наведеному в Розділі 4, мова йде про два види робіт: запити на зміни і функціональні текстові зміни (PTC). Можливо, запити на зміни теж слід розбити на два підвиди: виробничі дефекти і  власне запити на зміни (для нової функціональності). Будь я  зараз коучем цієї команди, рекомендував  би їм розрізняти чотири типи робіт: запити на зміни, виробничі дефекти, функціональні текстові зміни і  помилки (або «неминучі» дефекти).