Система канбан розпочала свій шлях у 1950-х роках на виробничих лініях корпорації Toyota, після чого перекочувала в офіси і стала важливим інструментом для проектних менеджерів.
Безмежна гнучкість практики і її можливості для самоорганізації персоналу дозволили домогтися ефективності там, де інші підходи не працювали. Це той випадок, коли візитною карткою системи стала сама картка — вона утвердилася як внутрішня валюта в організаціях, які впровадили канбан.
Походження
Як і концепція бережливого виробництва (Lean), система канбан була розроблена менеджерами Toyota. Автора системи, японського інженера Тайіті Оно, надихнув принцип роботи американських супермаркетів, де покупець сам вибирав потрібні собі товари. Роль «супермаркету» в корпорації Toyota виконав склад. Там сигнальними картками — а саме так дослівно з японської мови перекладається «канбан»- обмінювалися працівники, власноруч регулюючи виробничий процес.Картки кріпилися до тари з деталями. На таких бірках вказувалася інформація про номер і кількість деталей, який відділ їх відправляє і куди вони повинні прибути.
Працівник, який безпосередньо займався монтажем і складанням машин («нижній потік») забирав деталі з тари, на якій був прикріплений «канбан» із запитом для складу. Картка знімалася і разом з порожнім ящиком передавалася транспортувальником на склад. Там інший працівник уже підготував нову тару з запчастинами, на якій кріпився виробничий «канбан» — бірка з інформацією про проведені запчастинах.
Виробничий «канбан» замінювався на «канбан» із запитом для складу і відправлявся на виробничу лінію запчастин — «верхній потік». Тому вироблялася саме та кількість деталей, яка вказувалася в картці. Тара з новими запчастинами ставилася транспортувальників на монтажну лінію.
Принципи канбана
Менеджери Toyota сформулювали 6 системоутворюючих правил:
- Виконавці з «нижнього потоку» вилучають рівно стільки деталей зі складу, скільки вказано в канбані
- Представники «верхнього потоку» теж постачають запчастини строго відповідно до карток
- Ніщо не виготовляється або не переміщається без канбана
- Канбан має бути завжди прикріплений до деталей
- Браковані запчастини не використовуються в системі
- Зменшення кількості карток канбан робить управління більш чутливим до змін. Але без крайньої необхідності змінювати усталену кількість карток не варто.
Канбан — це «витягаюча» система. У ній створюється баланс між постійним потоком, який усуває витрати на очікування, і мінімальною кількістю роботи в процесі (РВП), що знижує ризики перевиробництва. РВП регулюється за допомогою карток: їх кількість зафіксована, а інструкції в них направляють виконавців «нижнього потоку».
Ліміт РВП складається в пропорції до кількості канбан-карток, яка розраховується залежно від рівня продажів і статистичної варіантності в поточних процесах. Максимальна кількість бирок — та сама «енергія» в системі — закріплює верхній рівень РВП в будь-який заданий час. РВП також обмежується принципом витягування: швидкість виробництва верхнього потоку залежить від швидкості роботи нижнього.
На графіку видно, що одним з базових елементів системи є культура Кайзен. Автономний процес і стандартна варіантність звільняє менеджмент від постійного управління, тому він може зосередитися на поліпшенні роботи співробітників.
Застосування канбан в IT
Система канбан, продовжуючи приносити користь на виробничих конвеєрах, проникла в сферу програмного забезпечення.
Тільки картки, на яких вказані інформація про терміни виконання, опис або номер процесу і ім’я виконавця, тепер прикріплюються не до тари з запчастинами, а до дошки з розкресленими колонками:
- Беклог — задачі, які треба виконати
- Задачі, які на даний момент розробляються
- Задачі, які виконані, але ще не передані тестувальникам
- Задачі, готові до передачі у відділ тестування
- Задачі, які проходять перевірку проект-менеджером (ПМ)
- Виконані задачі
Над колонками зазвичай пишться число — ліміт, який вказує на максимальну кількість процесів в ній. Ліміт беклога вираховується в залежності від провідного часу. Якщо в системі 5 робіт в процесі, і завершення кожної з них в середньому займає 1 день, то й беклог можна обмежити лімітом 5.
Структура вище не є строгою — в залежності від специфіки проекту можуть бути додані імпровізовані колонки. Нерідко зустрічається канбан система, в якій потрібно визначити критерії готовності задачі перед її виконанням. Тоді з’являються дві колонки, які в англійській мові називаються specify (уточнити параметри) і execute (взятися за роботу).
- Ще може додаватися колонка з пріоритетною чергою. Коли виконавець звільняється, то він повинен очистити саме цю колонку з задачами, а потім братися за інші.
- Задачі, які не були виконані, — або повертаються в беклог, або викреслюються зі схеми.
- Канбан не заохочує багатозадачність, тому встановлюється ліміт процесів для одного виконавця.
- Виконана робота краще, ніж декілька розпочатих.
- Братися за другу роботу можна, якщо перша була заблокована.
- Час для виконання задачі має бути збалансованим. Занадто короткий термін відіб’ється на якості. Надто розтягнутий ліміт витрачає ресурси команди і підвищує вартість процесу.
Чому усюди використовується канбан-дошка, а не, наприклад, планшети або величезний монітор? Як відповідають на це питання шанувальники системи, звичайна дошка має дві переваги: вона проста і забезпечує візуальний контроль. На ній легко вносити зміни, і вона забезпечує тактильну і соціальну взаємодію між учасниками команди.
Переваги та недоліки канбан
Kanban має такі переваги:
- Гнучкість планування. Команда концентрується тільки на поточній роботі, пріоритет задачі виставляється менеджером.
- Висока включеність команди в процес розробки. Завдяки постійним зборам, прозорості процесів і можливостям самоорганізації працівники гуртуються і проявляють щирий інтерес.
- Менша тривалість циклу. Якщо потрібний навичок має кілька людей, — тривалість скорочується, якщо ж тільки одна людина — з’являється вузьке місце. Тому співробітники повинні ділитися знаннями і тим самим оптимізувати тривалість циклу. Тоді вся команда зможе взятися за роботу, яку забуксувала, і відновити плавний потік.
- Менше вузьких місць. Ліміти РВП дозволяють швидко знаходити вузькі і проблемні місця, які з’явилися через дефіцит уваги, людей або навичок.
- Наочність. Коли всі виконавці мають доступ до даних, то вузькі місця легше помітити. Kanban-команди, крім самих карток, зазвичай використовують два загальних звіти: графіки управління і сукупного потоку.
На практиці система відмінно себе показує в сферах неосновного виробництва:
- групи підтримки програмного забезпечення або служби підтримки.
- Канбан добре працює при управлінні стартапами без чіткого плану, але де активно просувається розробка.
Канбан має і недоліки:
- система погано працює з командами чисельністю понад 5 осіб
- він не призначений для довгострокового планування.
Відмінності від скрам
Скрам, як і agile kanban, є гнучкою методикою і теж часто застосовується в IT-сфері. Відмінності між ними не очевидні на перший погляд. Існує багато схожості, наприклад, наявність беклога в обох підходах.
Скрам | Канбан | |
Темп | Повторювані спринти фіксованої тривалості | Безперервний процес |
Випуск релізу | В кінці кожного спринту після схвалення проектним менеджером (власником товару) | Потік триває без перерв або на розсуд команди |
Ролі | Власник продукту, Scrum-майстер, команда розробників | Команда під керівництвом ПМ; в деяких випадках залучаються тренери по agile kanban |
Головні показники | Швидкість команди | Провідний час |
Щодо прийнятності змін | У ході спринту зміни небажані, так як можуть привести до невірної оцінки задач | Зміни можуть трапитися в будь-який момент |
Приклади застосування в IT
Відразу з Microsoft: Дебют Канбан в сфері програмних розробок
Використання принципів канбана в сфері інформаційних технологій почалося трохи більше, ніж 10 років тому. Девід Андерсон, один з головних популяризаторів канбана для програмних розробників, консультував в 2005 році компанію Microsoft. Там були незадоволені роботою свого відділу — XIT Sustained Engineering, який усував помилки у внутрішніх додатках. До початку звітного року цей відділ був найгіршим у своєму департаменті. Беклог перевищив допустимий розмір в 5 разів, а час на обробку одного запиту — провідний час — зазвичай займав 5 місяців.
Новий ПМ за допомогою консультацій Андерсона за 9 місяців підвищив продуктивність проблемного відділу на 155%. Провідний час тепер становив 5 тижнів, беклог повернувся до нормального розміру, а своєчасне виконання задач утвердилося на рівні 90%. Всі ці результати були досягнуті з мінімальним залученням нових працівників, персонал продовжував тими ж методами виправляти програмні помилки — змінилися лише підходи до організації роботи.
Цікавий факт: програмний менеджер Драгос Думітріу, який взявся переламати ситуацію в XIT, як раз був захоплений книгою Андерсона. На свій подив, він зустрів ідеолога програмного канбана в самій компанії Microsoft, куди той напередодні влаштувався. Думітріу попросив Андерсона допомогти зі своїм завданням, і останній погодився застосувати принципи своєї книги на практиці.Думітріу застав відділ, який складався з трьох розробників і трьох тестувальників, у яких в беклозі накопичилося 80 запитів. Сам ПМ був призначений тимчасово, так як вимоги до вакансії включали вміння роботи з технологією ASP, адміністрування за допомогою SQL Server і знання MS Project Server. Начальство бачило на цій посаді «технаря», який вміє програмувати, повинен складати звіти і прогнозувати завантаження беклога. Як вважалося тоді, проблема відділу буде виявлена, якщо зібрати великий масив даних. Думітріу ж таким «технарем» не був.
Однак розпочавши разом з Андерсоном аналізувати роботу XIT, він швидко виявив ключові фактори, які негативно впливали на швидкість відділу:
- На прогнозування наслідків (ROM), до яких призведе виконання запиту, йшло дуже багато часу. І розробнику, і тестувальнику доводилося витрачати повний робочий день, щоб провести необхідні обчислення, перевірку коду і заповнити документацію. В середньому щодня приходив один запит. За підрахунками ПМ, на ROM йшло 40% від продуктивності відділу;
- Пріоритет віддавався запитам з більшою вартістю. XIT отримував фінансування за рахунок вартості замовлення. Пріоритетність запитів обговорювалася щомісяця на зустрічі менеджерів відділу з замовниками — менеджерами інших відділів. При розпираючому беклозі при поточний швидкості, коли за місяць оброблялися лише 6-7 запитів, постійно змінювалися пріоритети інших заявок через що проходить часу. Багато з них були відкладені на значне «потім», не рівне навіть наступного місяця.
- На стадії ROM відсівалась половина запитів. Частина з них були занадто великі і перекваліфікувалися в проекти з передачею іншим відділам, інші були занадто дорогими і просто скасовувалися. Деякі запити не брались в розробку через те, що їх впровадження виявилося б занадто довгим. Таким чином, 40% продуктивності відділу йшло на аналіз запитів, 50% з яких були забраковані. Близько 15-20% робочих ресурсів витрачалося даремно.
- Підготовча робота по запиту могла тривати місяцями, перш ніж починалося впровадження. Обчислення на стадії ROM могли за цей час загубитися або забутися. Особливо, якщо впровадженням займався не той розробник, який починав аналіз.
Канбан-рішення для проблемного відділу Microsoft
За підсумками 2005 року продуктивність відділу виросла на 155%. Щоб ще поліпшити роботу XIT, туди залучили двох співробітників: одного розробника і одного тестувальника. Кількість запитів у беклозі знизилася до 10, а один розробник став стабільно обробляти 11 заявок за квартал. В середньому за квартал завершувалися 56 запитів проти 11 раніше. Вартість запитів впала з $ 7500 до $ 2900.
Застосування в компанії Corbis
Домігшись успіху в Microsoft, Андерсон в 2006 році приступив до вирішення нової складної задачі. Тепер він працював в Corbis — інший компанії Білла Гейтса, який тоді ще не покинув MS. Одним з видів діяльності Corbis було ліцензування фотографій. На той момент це був другий найбільший в світі фотостік з базою близько 3,5 тис. Знімків.
Завданням Андерсона було прискорити головні релізи від компанії. Інтервал між їх виходами становив три місяці і міг вирости ще більше. Тільки обговорення плану релізу забирало у менеджменту два тижні. Було потрібно налагодити випуск другорядних релізів або оновлень кожні два тижні. При цьому ключові ресурси повинні були бути направлені на роботу над головним проектом.
В офісі Corbis з’явилася канбан-дошка, у якої Андерсон щодня розмовляв з колективом. Метою ПМ було поліпшити візуальний контроль над процесами, сприятиме самоорганізації і більшої персональної відповідальності виконавців. Також система канбан була спрямована на зменшення нагляду з боку менеджерів і збільшення продуктивності.
Крім різнокольорових карток і графіків, на дошці з’явилася «кошик для сміття» — в неї відправлялися задачі занадто великого розміру.
Фото з офіційної презентації
A Kanban System for Sustaining Engineering on Software Systems by David J Anderson
Система kanban прояснила, коли потік перестає бути плавними і де виникають затримки, так зване пляшкове горлечко. Швидкі обговорення з командою допомагали виявити поточні проблеми. Наприклад, тестування тривало 3 дні, що негативно відбивалося на терміні релізу. Троє співробітників об’єдналися і знайшли спосіб, як зменшити час до однієї доби.
Пляшкове горлечко — ділянка схеми або алгоритму роботи компанії, де обмеження ресурсів або продуктивності людей різко скорочує прохідність потоку задач. Брак робочих рук, поганий інтернет або директор у відпустці блокує або уповільнює виконання задач.
Ліміти для канбан-карток двічі встановлювалися емпіричним шляхом. У колонці «готове для розробки» ліміти були збільшені. Також з’явилася нова колонка — «готове для тестування». Багато запитів для нижнього потоку були некоректно сформульовані, викликаючи зайві витрати часу. Тому ПМ дослідив роботу верхнього потоку і знайшов помилки.
Процедура розгляду запитів могла займати 100 днів, але релізи все одно стали виходити раз на два тижні, як і планувалося. Рішення по вмісту випуску приймалося за 5 днів до публікації. Практика підрахунків, як і в випадку з відділом XIT Microsoft, була відкинута на користь продуктивності. Пріоритет задачам розставлявся згідно «вартості затримок» або готовності ресурсів.
Канбан система не тільки допомогла Андерсону добитися поставленої мети, але і поліпшила настрої в колективі. Завдяки спільним обговоренням і наочності процесів у співробітників утвердилася довіра один до одного. Також персонал долучився до кайзену, тобто, практики постійного поліпшення.
Програми та програми для КАНБАН
Trello
Популярна система канбан для управління задачами. Відрізняється візуальною привабливістю і зручним інтерфейсом. Користувачі відзначають його супергнучкість.
Kanbantool
Безкоштовна дошка для двох користувачів. Підтримка API і touch-інтерфейсів.
Lean Kit Kanban
Безкоштовна дошка для п’яти користувачів з гарною реалізацією спільної роботи. Підтримка API і можливість імпорту/експорту, широка статистика.
Kanbanize
Повністю безкоштовний сервіс з достойною функціональністю. Його власники гарантують приріст в продуктивності на 300% при використанні їх продукту.
Worksection
Український saas — додаток для швидкого відстеження та управління проектами. Зараз у функціях, крім обліку фінансів і термінів, є діаграма Ганта. В найближчі місяці розробники додадуть канбан-дошку з можливістю налаштувать, що зробить сервіс ще більш придатним для канбана.
Вердикт
Канбан — це практика, яка допомагає досягти успіху, при цьому використання тільки гнучких методів є необов’язковим. Важливі зміни досягаються завдяки виключенню втрат часу, управління вузькими місцями і зниження варіативності.
Однак успішні зміни вимагають часу. Вони проходять поступово, при цьому опір команди нововведенням — мінімальний. Канбан-система мотивує персонал вдосконалюватися без змін в інженерних методах.
Книги для статті надані kniga.biz.ua
Пару лет спустя тоже самое))