Кілька слів про книжку Девіда Андерсона

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

Карл Скотланд, старший консультант "EMC Consulting"

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

Кріс Сіммонс, менеджер із розвитку в компанії "Sophos"

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

Крістин Скасків, Agile-коуч

Найкраща нова методологія змін у галузі розробки програмного забезпечення, яку я бачив за останнє десятиліття.

Девід А. Булкін, віцепрезидент "LitheSpeedLLC"

Частина перша. ВСТУП

- Розділ 1 - Розв'язання дилеми Agile-менеджера

У 2002 році я був менеджером із розробки у віддаленому офісі підрозділу мобільних телефонів Motorola PCS у Сіетлі, штат Вашингтон. Мій відділ був частиною стартапу, який Motorola придбала роком раніше. Ми розробляли мережеве ПЗ для бездротової передачі даних на кшталт бездротового завантаження та управління приладами. Ці серверні застосунки були частиною інтегрованих систем, які працювали разом із клієнтськими застосунками на мобільних телефонах, а також з іншими елементами в телекомунікаційних мережах та операційній інфраструктурі, на кшталт білінгової системи. Дедлайни призначалися менеджерами, які не звертали уваги на інженерну складність проєкту, його ризики та обсяг. Наш код розвивався від початку стартапу, при цьому ми зрізали багато кутів. Один старший розробник наполягав на тому, щоб наш продукт називався прототипом. Ми мали відчайдушну потребу в підвищенні продуктивності та якості продукції, аби відповідати потребам бізнесу.

У власній повсякденній діяльності того року, а також під час роботи над моєю попередньою книжкою{1) мене турбували переважно два питання. Перше - яким чином захистити команду від постійно зростаючих запитів бізнесу і досягти того, що сьогодні в Аgile-співтоваристві зветься сталим темпом? І друге - чи зможу я успішно запровадити Аgile-підхід у масштабах всієї організації, долаючи неминучий опір змінам?

Мій особистий пошук сталого темпу

У 2002 році Аgile-спільнота сприймала сталий темп просто як "сорокагодинний робочий тиждень"{2). Agile-маніфест, зі свого боку, зазначав: "Аgile-процеси сприяють оптимальному розвитку. Спонсори, розробники і користувачі мають бути готові підтримувати постійний ритм протягом необмеженого часу"{3). За два роки до цього моя команда в Sprint PCS повсякчасно чула від мене, що "розробка великих за обсягом програмних продуктів - це марафон, а не спринт". Якщо членам команди потрібно підтримувати сталий темп під час здійснення півторарічного проєкту, то дуже важливо завадити їхньому вигоранню за місяць-другий від початку роботи. Проєкт потрібно розпланувати, бюджетувати, розписати за часом і оцінити так, аби члени команди щодня витрачали на роботу розумну кількість часу і не надто втомлювалися. Переді мною як менеджером постало завдання досягти цієї мети і задовольнити всі вимоги бізнесу.

У 1991 році, коли я працював на своїй першій менеджерській посаді в стартапі зі створення плат відеозахоплення для ПК та більш дрібних комп'ютерів, СЕО повідомив мені, що в керівництва склалося про мене "вкрай негативне враження". Причина? Я завжди відповідав "ні", коли від моєї команди вимагали все більше продуктів або функцій, а наші потужності як розробників уже були майже вичерпані. До 2002 року це стало моєю звичкою: понад десять років поспіль я відмовлявся виконувати незліченні примхи власників бізнесу.

Загалом команди розробників ПЗ і IT-відділи компаній неабияк залежали від інших груп, що повсякчас торгувалися, просили, погрожували і вимагали переробити навіть найбільш обґрунтовані та об'єктивно розроблені плани. До переліку вразливих потрапляли навіть ті плани, що ґрунтувалися на ретельному аналізі та багаторічному досвіді. Більшість же команд, які не володіли переконливими методами аналізу й певним досвідом, були безсилі перед тими, хто намагався примусити їх узяти на себе невідомі (і переважно нездійсненні) зобов'язання.

Отже, співробітники поступово змирилися з шаленим навантаженням, і надмірні обсяги роботи перетворилися на норму. Скидалося на те, що інженери-програмісти взагалі не потребують спілкування з друзями або сімейного життя. Звучить несправедливо, бо так воно і є! Мені відомі численні приклади, коли надмірне виробниче навантаження руйнувало сімейні стосунки.

Водночас неможливо було співчувати типовому розробнику ПЗ тих часів. У моєму рідному штаті Вашингтон інженери-програмісти посідали друге місце за рівнем річного прибутку після стоматологів. Як і за часів Генрі Форда, тобто в 1920-х роках, коли люди на його автомобільних заводах заробляли уп'ятеро більше, ніж у середньому по країні, нікому навіть на думку не спадало поскаржитися на монотонність роботи або відсутність дозвілля, оскільки їхня праця щедро оплачувалася. Важко уявити собі діяльність профспілок у таких інтелектуальних галузях, як розробка ПЗ, тому ніхто й не намагався всерйоз дослідити причини фізичних і психологічних недуг, від яких потерпають розробники. Більш відповідальні роботодавці згодні сплачувати додаткові медичні послуги на кшталт масажу або психотерапії, або надавати працівникам "дні психічного здоров'я" замість того, аби приділити увагу виявленню основних причин проблеми. Технічний письменник, співробітник відомої фірми-розробника ПЗ, якось сказав мені: "Немає нічого страшного в тому, що я вживаю антидепресанти, адже так роблять усі!" Стикаючись із такими зловживаннями, інженери-програмісти зазвичай погоджуються з усіма вимогами, отримують непогану зарплату й страждають від наслідків психологічного вигорання.

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

Мій особистий пошук успішного управління змінами

Друга проблема, якою я переймався,- це прагнення кинути виклик великим організаціям для здійснення змін в управлінні. Я був менеджером із розробки в Sprint PCS і згодом у Motorola. У цих компаніях існувала нагальна потреба в переході на більш гнучкі методи роботи. Але в обох випадках було складно застосовувати Аgile-методи більш як до однієї-двох команд.

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

Процес дійсно потребував адаптації для кожної конкретної ситуації. А також вимагав активного керівництва кожною з команд. Проте саме його часто не вистачало. Навіть за умови належного керівництва я не мав цілковитої впевненості, що суттєві зміни можуть відбутися без відповідного фрейморку, а також без принципів та рекомендацій щодо того, як адаптувати процеси для будь-якої ситуації. Якщо керівнику, ­коучу або інженеру-технологу бракує чіткого уявлення про те, що робити, будь-яка адаптація, найвірогідніше, відбудеться на його власний розсуд, ґрунтуючись на його власних переконаннях та забобонах. Це з тією ж імовірністю викличе хвилю нарікань і заперечень, як і використання недоречних шаблонних процесів.

Я спробував висвітлити цю проблему в книжці Agile Management for Software Engineering, над створенням якої працював саме тоді. Я ставив питання: "Чому гнучка розробка дає кращі економічні результати, ніж традиційні підходи?" і прагнув застосувати в пошуках відповіді структуру теорії обмежень{4).

Під час досліджень і створення тексту я зрозумів, що кожна ситуація певною мірою унікальна. Хіба ж може той чи інший стримуючий фактор або вузьке місце виявитися однаковим для будь-якої команди і проєкту в будь-який час? Кожна команда унікальна: різні навички, можливості, досвід. Кожен проєкт відрізняється від інших бюджетом, обсягом і ступенем ризиків. Не схожі одна на одну й організації: у них різні ланцюжки створення цінності, вони працюють на різних ринках (рис. 1.1). Мені здалося, що це може пояснити причини виникнення опору змінам. Якщо запропоновані зміни методів роботи і моделей поведінки не дають, на думку членів команди, очевидної переваги, то вони не сприймають їх. Якщо ці зміни не впливають на те, що сприйма­ється командою як обмеження або стримуючий фактор, то команда намагається чинити опір. Інакше кажучи, зміни, запропоновані без урахування контексту, будуть відкинуті людьми, які краще за всіх знають контекст проєкту.

Рис. 1.1. Чому універсальна методологія розробки не працює

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

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

Нарешті я зрозумів, що можна поєднати цей підхід із деякими прийомами зі сфери ощадливого виробництва. Змоделювавши робочий процес розробки ПЗ у вигляді потоку створення цінності, а потім створивши систему відстеження і візуалізації стану робіт відповідно до того, як вони "протікають" крізь систему, я зміг побачити її вузькі місця. Здатність ідентифікувати обмеження є першим кроком у моделі, яка є підґрунтям теорії обмежень. Ґолдратт уже розробив метод за­стосування цієї теорії для проблем потоку - він носить незграбну назву "барабан - буфер - канат"{6). Незважаючи на незручність назви, я відчув, що спрощений варіант цієї системи можна запровадити у сфері розробки ПЗ.

Загалом "барабан - буфер - канат" є прикладом класу рішень, відомих як "системи витягування". Як ми побачимо в Розділі 2, канбан теж є одним із прикладів такого штибу систем. Цікавий побічний ефект систем витягування полягає в тому, що вони обмежують обсяг незавершеної роботи (WIP) до заздалегідь встановленого обсягу, запобігаючи перевантаженню працівників. Цілковито завантаженими залишаються лише працівники, які безпосередньо працюють у вузькому місці; у всіх інших має залишатися вільний час. Я зрозумів, що системи витягування здатні вирішити обидві проблеми, якими я переймався. Система витягування дозволить мені робити покрокові зміни, що (як я сподівався) істотно зменшить опір, а також полегшить досягнення сталого темпу. Я вирішив перейти на систему "барабан - буфер - канат" за першої-ліпшої нагоди. Мені хотілося поекспериментувати з покроковою еволюцією процесу й подивитися, наскільки вона забезпечує сталий темп і зменшує опір змінам.

Така можливість з'явилася восени 2004 року в корпорації Microsoft, що докладно описано в Розділі 4 цієї книжки.

Від "барабана - буфера - канату" до канбану

Застосування системи "барабан - буфер - канат" в Microsoft спрацювало відмінно. Опір був незначним, продуктивність зросла більш як втричі, час виконання задачі скоротився на 90 %, а передбачуваність підвищилася на 98 %. Восени 2005 року я повідомив про досягнуті ­результати на конференції в Барселоні{7), а взимку 2006 року зробив ще одну доповідь. Моя робота привернула увагу Дональда Рейнертсена, який спеціально завітав до мене в офіс в Редмонді. Він спробував переконати мене, що майже все готово до цілковитого переходу на канбан.

Канбан - японське слово, що дослівно перекладається як "сигнальна картка". У промисловому виробництві ця картка використовується, аби дати сигнал попередньому етапу процесу, що треба виробити ще одну партію продукії. Робітники на кожному етапі процесу не можуть працювати, доки не отримають сигнал - канбан-картку - від наступного етапу процесу. Хоч мені і був відомий принцип цього механізму, я мав сумніви щодо його користі або навіть життєздатності в інтелектуальній праці, особливо у сфері розробки ПЗ. Я розумів, що канбан забезпечує сталий темп, але не знав про його гарну репутацію як метода стимулювання покрокового поліпшення процесів. Я не знав, що Таїті Оно, один із творців виробничої системи Toyota, зауважив: "Два основні принципи системи виробництва Toyota - це JustinTime і автоматизація за участю людини, або автономізація. Для управління си­стемою використовується інструмент - це і є канбан". Інакше кажучи, канбан життєво важливий для процесу кайдзен ("безперервного вдосконалення"), що застосовує Toyota. Це механізм, що змушує всю систему працювати. Уже зараз, маючи п'ятирічний досвід, я сприймаю це як абсолютну істину.

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

Знову проаналізувавши реалізоване в Microsoft рішення, я зрозумів: якби ми одразу спроєктували його як канбан-систему, результат був би аналогічним. Мені здалося цікавим те, що два різні підходи ведуть до того самого результату. Отже, оскільки виходив той самий процес, я не відчував себе зобов'язаним сприймати його виключно як результат впровадження системи "барабан - буфер - канат".

Я надав перевагу терміну "канбан" перед цим складним словосполученням. Він використовується в ощадливому виробництві (те саме, що й "виробнича система Toyota"). Ця сукупність знань зазнала значно більшого поширення і визнання, ніж власне теорія обмежень. Канбан, незважаючи на своє японське походження, менш метафоричний, ніж "барабан - буфер - канат". Це слово легше вимовляти, пояснювати і, як виявилося згодом, викладати і впроваджувати. Саме тому воно й закріпилося.

Виникнення методу Канбан

У вересні 2006 року я звільнився з Microsoft і очолив відділ розробки ПЗ у Corbis - приватній компанії, розташованій у центрі Сіетла, що займалась стоковими фотографіями та захистом інтелектуальної власності. Надихнувшись досягнутим у Microsoft, я вирішив впровадити систему витягування канбан у Corbis. Знову ж таки, результати були обнадійливими, саме вони призвели до розвитку більшості концепцій, представлених у цій книжці. Дещо розширений набір цих концепцій - візуалізація потоку робіт, типи задач, ритми, класи обслуговування, особлива управлінська звітність та огляд роботи - і визначають метод Канбан.

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

Схвалення Канбан Agile-спільнотою

У травні 2007 року Рік Гарбер і я представили перші результати роботи в Corbis на конференції в Чикаго, присвяченій питанням розробки нових продуктів. Доповідь слухали приблизно 55 осіб. Улітку того ж року на конференції Agile-2007 у Вашингтоні я запропонував провести "відкритий простір" з обговорення системи канбан - його відвідало близько 25 осіб. Два дні по тому один із присутніх, Арло Бельші, виголосив стислу промову, у якій розповідав про свій метод "оголеного планування"{8). Виявилося, що й інші компанії впроваджують у себе системи витягування. Так, в Yahoo! була створена дискусійна група, що швидко набрала сотню членів, а на момент написання книжки її склад налічує понад тисячу осіб. Деякі з учасників мого "відкритого простору" вирішили спробувати Канбан у своїй роботі, часто з командами, які мали проблеми зі Scrum. Найвідоміші з моїх ранніх послідовників - Карл Скотланд, Аарон Сандерс і Джо Арнольд, усі з Yahoo!. Ця компанія швидко впровадила Канбан у понад десяток команд на трьох континентах. Ще один помітний учасник круглого столу - Кендзі Хіранабе - розробляв канбан-рішення в Японії. Невдовзі після конференції він написав на цю тему дві статті для InfoQ{9), що викликали неабияку зацікавленість. Восени 2007 року Санджив Огастайн, автор Managing Agile Projects{10) і засновник Мережі гнучкого проєктного лідерства (Agile Project Leadership Network, APLN), відвідав Corbis у Сіетлі та описав наші канбан-системи як "перший новий Аgile-метод, який я побачив за п'ять років".

Наступного року на конференції Agile-2008 у Торонто відбулося шість презентацій застосування канбан-рішень у різних умовах. На одній із них Джошуа Керієвські з Industrial Logic, компанії з навчання та консалтингу в галузі Екстремального Програмування, показав, як він сам дійшов до подібних ідей, аби вдосконалити Екстремальне Програмування та адаптувати його до контексту свого бізнесу. Того року Agile Alliance вручив премію Гордона Паска Арло Бельші і Кендзі Хіранабе за їхній внесок у Аgile-спільноту. Він складався в одному випадку з безпосереднього впровадження Канбан, а в іншому - із розробки і пропаганди напрочуд схожих ідей.

Цінність Канбан є контр-інтуїтивною

Багато в чому інтелектуальна праця протилежна монотонній виробничій діяльності. І вже зовсім точно розробка ПЗ не схожа на промислове виробництво. У цих галузей абсолютно різні властивості. Промислове виробництво переважно незмінне, а розробка ПЗ зазнає частих змін і прагне використовувати цю варіативність, аби завдяки новим розробкам збільшити рівень прибутку. Англійська назва ПЗ software має елемент soft ("м'який"): програмні продукти можна легко й безболісно трансформувати, а виробництво концентрується на "жорстких" речах, які важко змінювати. Тож цілком природно мати сумніви щодо цінно­сті канбан-систем у розробці ПЗ та інших IT-сферах. Велика частина з того, що наша спільнота засвоїла останніми роками про Канбан, супе­речить інтуїції. Ніхто не міг передбачити той вплив, який Канбан справив на корпоративну культуру та на поліпшення крос-функціональної співпраці в Corbis (див. Розділ 5). Я сподіваюся довести, що "Канбан спроможний!". Прагну переконати вас, що, впровадивши прості правила Канбан, ви зможете підвищити продуктивність, передбачуваність і задоволеність клієнтів, а також скоротити час виконання задач. ­Завдяки цьому зміниться культура вашої організації, оскільки зростання співпраці дозволить встановити кращі, більш функціональні робочі відносини.

ПІДСУМКИ

- Канбан-системи належать до сімейства підходів, відомих як системи витягування.

- Застосування Еліягу Ґолдраттом теорії обмежень, відомої як "барабан - буфер - канат", є альтернативним способом впровадження системи витягування.

- Мотивація до переходу на системи витягування двояка: необхідно було знайти системний шлях досягнення сталого темпу роботи і такий підхід до запровадження процесуальних змін, який зазнав би мінімального опору з боку команд.

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

- Перша віртуальна канбан-система у сфері програмування впроваджувалася в компанії Microsoft із 2004 року.

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

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

- У цій книжці термін "канбан" (із маленької літери) стосується сигнальних карток, а "канбан-система" (з маленької літери) - до си­стеми витягування, що використовує (віртуальні) сигнальні дошки.

- Слово "Канбан" (із великої літери) стосується методології еволюційного покрокового поліпшення процесу, що зародилася в Corbis в 2006-2008 роках і продовжувала розвиватися в ширшому співтоваристві розробників, пов'язаних із ощадливим програмуванням.

- Розділ 2 - Що таке метод Канбан

Навесні 2005 року мені пощастило провести відпустку в Японії. Був початок квітня, сезон цвітіння сакури. Аби помилуватися цим видовищем, я вдруге в житті завітав до Східних садів Імператорського палацу в Токіо. Саме там мені спало на думку наступне: канбан - це не лише виробництво.

У суботу, 9 квітня 2005 року, я увійшов у парк із північного входу, подолавши міст над ровом неподалік від станції метро "Такебасі". Багато токійців вирішили цим сонячним ранком завітати до парку, насолодитися спокоєм і видовищем цвітіння сакури.

Звичай улаштовувати пікнік під сакурами, коли починають опадають їхні квіти, японці називають "ханамі" ("квіткове свято"). Це давня традиція, що надає можливість поміркувати про красу й нетривалість життя. Недовгий період цвітіння сакури - це метафора людського існування, короткого, прекрасного й крихкого посеред неосяжного Всесвіту.

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

Провівши чудовий ранок на осонні, за дві години ми зібрали приладдя для пікніка та попрямували до Східних воріт - у бік станції "Отемачі". Біля виходу стояла черга до невеликого кіоску. Коли вона трохи просунулася вперед, я зрозумів, що люди повертають пластикові картки - саме вони слугували вхідними квитками. Я витяг із кишені наші картки. У кіоску сиділа японка в уніформі. Нас відділяла скляна перегородка з напівкруглим вирізом над стійкою, як у касі кінотеатру або парку розваг. Я передав через цей отвір наші картки. Жінка взяла їх і поклала в стос до інших. Потім злегка кивнула і подякувала мені усмішкою. Жодних грошей не знадобилося. Жодних пояснень щодо того, навіщо я дві години поспіль, відтоді як увійшов до парку, носив із собою ці білі пластикові картки, я також не почув.

Що ж це за квитки? Навіщо їх видавати, якщо вони безкоштовні? Спочатку я припустив, що це якось пов'язане з безпекою. Підрахувавши повернені картки, адміністрація могла переконатися, що всередині парку не залишилося жодного відвідувача після зачинення на ніч. Однак згодом я зрозумів: якщо йдеться про безпеку, то це якась надто сумнівна схема. Як їм стало відомо, що мені дали не одну картку, а дві? Моя тримісячна донька - це відвідувач або вантаж? Система здавалася надто варіативною - надто багато можливостей для помилки. Якщо це дійсно був захід безпеки, то, безумовно, він був приречений на провал і щодня видавав би хибно позитивні результати (коли квитки здані не всі, відвідувачів у садах, проте, немає). (До речі, зазначу, що подібна система не може видавати хибно негативні результати (коли всі квитки здані, але відвідувачі у садах все одно залишились), бо це вимагало б друкування додаткових вхідних квитків. Це загальна корисна властивість будь-яких канбан-систем). Але щовечора охорона нишпорила парком у пошуках заблукалих туристів. Отже, справа в чомусь іншому. І тільки тоді я нарешті зрозумів, що в садах Імператорського палацу реалізується канбан-система! Це осяяння дозволило мені зрозуміти, що канбан-системи корисні не лише у виробництві. Схоже, канбан-картки або жетони допомагають у всіх типах управлінських ситуацій.

Що таке канбан-система

В обіг запускається деяка кількість канбан-жетонів (або карток), що еквівалентна (заздалегідь узгодженій) потужності системи. Одна ­картка відповідає одному елементу роботи. Кожна картка діє як сигнальний механізм. Нову задачу можна розпочинати лише тоді, коли є вільна картка. Ця вільна картка прикріплюється до задачі та супроводжує її під час руху крізь усю систему. Коли вільних карток немає, нові задачі розпочинати не можна. Будь-яка нова робота має чекати у черзі, доки картка не звільниться. Коли якусь задачу завершено, картка звільняється й знову запускається в обіг. Тепер можна розпочинати роботу над новим елементом із черги.

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

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

Застосування канбану в розробці ПЗ

У розробці ПЗ з метою обмеження кількості незавершеної роботи (work-in-progress,WIP) ми застосовуємо віртуальну канбан-систему. Хоча слово "канбан" перекладається як "сигнальна картка" і у більшо­сті варіантів канбану для розробки ПЗ дійсно використовують картки, це не сигнальні картки для отримання нових завдань. Ці картки символізують елементи роботи, а сигнал для витягування нової роботи - це похідна від візуальної кількості WIP, яку треба відняти від якогось ліміту (або місткості системи). Звідси термін "віртуальний".

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

Дошки з картками стали популярним механізмом візуального конт­ролю в гнучкій розробці ПЗ (рис. 2.1). Зазвичай для візуалізації WIP використовують коркову дошку з приколотими до неї картками або білу дошку з клейкими стікерами. Слід зауважити, що ці дошки з картками самі по собі не є канбан-системами, хоча дехто стверджує зворотне. Насправді це лише системи візуального контролю. Вони дозволяють ­командам стежити за WIP і самоорганізовуватися, призначати собі завдання та переносити роботу з беклогу без підказок менеджера проєкту або безпосереднього керівника. Однак якщо немає явно визначеного обмеження WIP і не визначено сигнал для "втягування" нової роботи в си­стему - це не канбан-система. Детальніше про це йдеться в Розділі 7.

Рис. 2.1. Стіна з картками канбан (із дозволу SEP)

Навіщо застосовувати канбан-систему?

Із подальших розділів стане зрозуміло: ми використовуємо канбан-­систему для того, аби обмежити кількість WIP команди відповідно до заданої місткості і досягти балансу між навантаженням на команду та її пропускною здатністю. Тим самим ми можемо домогтися сталого темпу розробки, щоб усі члени команди змогли дотримуватись балансу між роботою та особистим життям.

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

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

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

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

Канбан як складна адаптивна система для ощадливого виробництва

Канбан як метод упроваджує складну адаптивну систему, що спрямована на стимуляцію переходу організації до ощадливого виробництва. Для того, аби у складних адаптивних системах з'явилися складні, адаптивні, новітні шаблони поведінки, ці системи повинні мати певні початкові умови і прості правила. Для сприяння появі навичок ощадливого виробництва в організації Канбан використовує п'ять ключових властивостей. Ці властивості наявні в усіх успішних впровадженнях Канбану, серед яких і впровадження в компанії Microsoft, описане у Розділі 4. Ось ці п'ять властивостей:

1. Візулізація потоку робіт.

2. Обмежити WIP.

3. Вимірювати потік робіт і керувати ним.

4. Зробити процесні правила явними.

5. Застосовувати моделі{11) для розпізнання можливостей удосконалення.

Нова поведінка і Канбан

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

1. Процеси, що унікально адаптовані під особливості кожного проєкту/потоку створення цінності.

2. Окремі ритми планування і випуску релізів (або розробка взагалі без ітерацій).

3. Розклад виконання задачі базується на (альтернативній)

вартості їхньої затримки.

4. Оптимізація постачання цінності за допомогою класів обслуговування.

5. Управління ризиками через перерозподіл виробничих потужностей.

6. Терпимість до експериментів над процесами.

7. Управління на підставі кількісних показників.

8. Вірусне поширення (Канбану) по всій організації.

9. Злиття невеликих команд для більш гнучкого перерозподілу працівників.

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

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

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

Кінець безкоштовного уривку. Щоби читати далі, придбайте, будь ласка, повну версію книги.