Чи потрібні які-небудь оцінки задач у Kanban методі?
Іноді буває, що команди йдуть від роботи по Scrum'у до роботи з Kanban'у, або до процесу, який вони називають Kanban'ом. Це відбувається через те, що Scrum дуже вимогливий до поліпшень і дисципліни. А буває так, що їх контекст специфічний і не підходить для Scrum. Про Kanban іноді можна почути таке: “Kanban - це просто. Kanban - це три колонки та жодних проблем. Якщо у Вас не виходить Scrum – спробуйте Kanban, а потім можливо й навпаки. Не потрібно проводити купу зустрічей, витрачати час на оцінювання елементів беклога”. Чи справді це так? Чи можливе оцінювання задач у Kanban все-таки існує? Як команда може прогнозувати завершення проєкту? Чи можна замовникам розраховувати на постачання фічі до потрібної дати? На такі запитання спробую відповісти у цій статті.
Для чого замовнику чи бізнесу потрібно знати, коли роботу буде закінчено? Для чого потрібні які-небудь оцінки задач? Варіантів може бути багато:
для того, щоб приблизно розуміти скільки коштуватиме реалізація в грошах. Те, що команда, наприклад, із п'яти осіб робитиме місяць, крім решти витрат компанії, дорівнює сумі зарплат цієї команди за місяць. Чи готовий бізнес інвестувати стільки грошей у черговий набір фіч? Чи настільки вони потрібні, чи усе це можна буде окупити? А якщо команда робитиме не місяць, а півтора чи більше? Тоді вийде ще дорожче;
можливо, цей набір фіч потрібно встигнути зробити до якоїсь дати, тому що вже є договірні зобов'язання або зовнішні фактори, наприклад, виставка або конференція;
від розуміння того, коли буде виконано роботу, можна планувати суміжні активності, наприклад, постачання фічі клієнту, рекламну кампанію тощо;
для пріоритезації задач, мінімізації ризиків та затримок, для прогнозування виконання тощо.
Ціль використання методу Kanban полягає в тому, щоб оптимізувати потік: робота, яка виконується, має проходити краще завдяки процесам. Якщо потік роботи іде добре, він не застрягне. Результати стають передбачуваними, а час виробництва стає більш коротким.
Існує різниця в підходах оцінювання в Scrum і Kanban. Для оцінки у Scrum-фреймворці на практиці часто використовується розповсюджений додатковий інструмент - Planning Poker і оцінка елементів беклога в Story Points (SP), що є аналітичним підходом. При його використанні ми намагаємося переглянути дані по задачі, які у нас є в результаті обробки елементів беклога (рефайнмента), до того, як ми приступили до її виконання. І приблизно всій командні доводиться гадати, скільки на це потрібно зусиль, зрештою - часу на виконання.
Якщо ви намагалися порівняти план із фактом по задачах у своїх командах, навіть у Story Points на коротких і довгих періодах, обов’язково зверніть увагу на цікаві закономірності, які буде корисно обговорити разом з командою. За допомогою цього можна буде коригувати точність таких оцінок у майбутньому. Самий простий приклад: в одній з моїх команд ми статистично помітили (що здається очевидним, але залежить, звичайно, від контексту), що чим більша оцінка задачі на початку (до прикладу 5, 8 або 13) - тим більше фактичного часу вона займе у підсумку. Чим більша оцінка, тим більше невизначеності та неточності. У свою чергу це привело до командного розуміння важливості декомпозиції (існує купа способів декомпозиції) і тепер навіть є командна домовленість, що будь-яку задачу з оцінкою понад 2 SP - ми розбиваємо на менші - і тоді точність оцінки у нас фактично збільшується від 20 до 50%.Оцінка ж в Канбані заснована на статистиці. Існують базові метрики й базові графіки, на основі яких можна оцінювати задачі не аналітично, як часто буває в Scrum, а емпірично. Взагалі цих показників набагато більше і там насправді цілий світ, але давайте почнімо з базових, з якими можна почати вже сьогодні при аналізі вашого процесу, навіть якщо ви працюєте за допомогою Scrum.
Типова дошка Kanban в Jira виглядає наступним чином:
Червоною лінією на початку тут позначено точку прийняття зобов'язань - те, що команда бере в роботу. У цей момент приймається зобов'язання щодо постачання робочого елемента. З цього моменту починається відлік виконання робочого елемента.Чорною лінією позначено точку постачи - після якої елемент роботи вважається виконаним.
Для того, щоб оцінювати задачі Kanban і планувати майбутні ітерації, потрібно збирати та враховувати набір метрик, хоча б базовий. Розумітися на метриках потрібно, щоб можна було далі орієнтуватися в графіках і діаграмах. Базовий набір складається з наступних метрик:
Throughput (пропускна спроможність) - скільки задач проходить через дошку або через систему від точки прийняття зобов'язань до точки постачи. Ця метрика відповідає на запитання: ”скільки елементів ми виконуємо за одиницю часу?”. Наприклад, команда виконує 20 елементів беклогу ітерації за два тижні. А в опрацьованому загальному беклозі 100 елементів - грубо кажучи, ще є роботи на 5 ітерацій, але це не дуже точно без урахування всіх інших показників.
Lead Time (час виробництва або час виконання) - час, протягом якого робочий елемент переходить від точки прийняття зобов'язань до точки постачи. Наприклад, це може бути 5 днів.
Cycle time (час циклу) – час, протягом якого робочий елемент проходить через частину процесу, наприклад, через аналіз та розробку, але без тестування. Наприклад, це може бути 3 дні.
Flow efficiency (ефективність потоку, %) – розраховується за формулою:
Джерело зображення: https://getnave.com/blog/flow-efficiency/
Active time – час безпосередньої роботи над здачами;Waiting - час очікування, у колонці (статусі) очікування.
Візуалізація цих усіх метрик на графіках та діаграмах дозволяє наочно побачити залежності, тенденції та загальний стан ефективності потоку. Існує три основних діаграми в Kanban методі: CFD, CC і LTDC. Далі я опишу їх по черзі.
1. Cumulative Flow Diagram (CFD) - накопичувальна діаграма потоку в теорії, наприклад, на три колонки To Do, In Progress, Done - виглядатиме ось так:
Джерело зображення: https://getnave.com/blog/how-to-read-the-cumulative-flow-diagram-infographic/
Tasks - кількість задач;
Time – час;
To Do – зробити (зелений колір на діаграмі);
WiP – Work in Progress – робота в процесі (бірюзовий колір на діаграмі);
Done – зроблено (синій колір на діаграмі);
Apprx. Average Cycle Time – приблизний середній час циклу;
Average Throughput - середня пропускна спроможність;
Arrival Rate - швидкість переходу з To Do до Done;
Departure Rate – швидкість переходу з In Progress до Done.
На практиці в Jira без додаткових плагінів, якщо у вас немає можливості використовувати інший інструмент типу swiftkanban або kanbanize, CFD може виглядати наступним чином:
Тут діаграма побудована за період понад три роки (з 01.04.2017 до 28.06.2020), але показує загальну картину за весь період. Її можна зумити, зменшувати діапазон та аналізувати докладніше. Хоча краще використовувати звичайно плагін Nave, який можна ставити на Jira і будувати дуже багато корисних звітів та дашбордів автоматично. Ця діаграма дуже корисна для пошуку вузьких місць, затримок, неефективності процесу.
2. Control Chart (СС) – контрольна діаграма показує час циклу (Cycle Time) або час виконання (Lead Time) для вашого продукту, версії чи спринту. Для побудови беремо час, витрачений кожним елементом роботи у певному статусі (або статусах), і відображаємо протягом певного періоду часу. Контрольна діаграма показує нам момент події, яка виникла в конкретну дату.
Контрольна діаграма допомагає визначити, чи можна використовувати дані поточного спринту для визначення майбутньої продуктивності. Чим менша різниця в часі циклу елемента роботи, тим вища впевненість у використанні середнього значення (або медіани) як показника майбутніх результатів.
Наприклад, я взяв Control Chart тієї ж команди, яка працює з Kanban board в Jira більше ніж три роки. При наведенні курсора на червону лінію можна побачити підказку з метриками - Rolling average (середнє ковзне значення, синя лінія на графіку) і Standard Deviation (стандартне відхилення). Якщо скласти ці два числа, то ми отримаємо значення, яке знаходиться на верхній межі діапазону або на нижній. Average (червона лінія) – це загальне середнє значення, яке знаходиться між усіма задачами у вибраному діапазоні за часом.
По вертикалі Elapsed Time – нелінійна шкала, яка показує витрачений час або Circle Time у вибраних колонках на дошці.
По горизонталі Issue Transition Date – показник дати останньої події зміни стану.
У цьому прикладі ми бачимо, як ці показники змінювалися за 3+ роки. У підсумку через систему пройшло 1996 задач - це пропускна спроможність (Throughput) за цей період. У середині періоду було погіршення показників, а потім покращення, але все-таки у результаті трохи гірше ніж на старті роботи команди. Це середні значення часу, за які елемент проходить через систему, і значення відхилення від цього показника. І тут межі системи від In Progress (точка прийняття зобов'язань) до Done (точка постачи). Ці цифри можна брати до уваги під час прогнозування.
У самій Jira є підказки – лінк у верхній частині екрана “How to read this chart” – пояснює як правильно читати та аналізувати цей графік:
Visibility - це видимість, наочно видно задачі, Lead Time яких значно більше за інших. Точково можна аналізувати їх, виявляти причини та працювати над тим, щоб у майбутньому не допускати подібних відхилень.
Приклад: якщо клацнути на гурток події, з'явиться попап в якому можна побачити скільки часу завдання знаходилося на кожному з етапів роботи.
Efficiency - ефективність процесу. Синя лінія є відображенням Rolling average (ковзне середнє значення). Вона повинна з часом опускатися, що сигналізуватиме про те, що ви працюєте над покращенням ефективності потоку, скорочуючи Cycle Time елементів. У реальному прикладі Control Chart вище ми бачимо, що з часом ближче до середини вона росла, що сигналізувало про погіршення ефективності потоку. А потім лінія почала плавно спадати, що говорить про покращення. Але, можна і потрібно проводити аналіз на більш коротких проміжках часу і тоді усе буде точніше і зрозуміліше. Наприклад, можна робити щомісячний аналіз цієї діаграми та порівнювати місяці.
Predictability - передбачуваність, тут зображується, що необхідно з часом прагнути до звуження стандартного відхилення при коригуваннях процесу, що в свою чергу дозволить поліпшити передбачуваність часу циклу (Cycle Time) і прискорити систему. Знову таки у прикладі вище до середини періоду відбулося розширення, а далі - плавне звуження, яке повернулося до початкових показників. В цілому значного покращення чи прискорення системи за цей період не сталося. Якщо синя лінія близька до червоної, статистично це приблизно +/- стабільна система.
Додатково в нижній частині під Control Chart є "Refine report", де можна налаштувати фільтри Columns, Swimlanes, Quick Filters. Виглядає це наступним чином:
Це дозволяє більш детально вибрати необхідні рамки меж аналізу системи та заглибитись у деталі. Загалом контрольна діаграма – дуже потужний інструмент, який може допомогти системно знаходити проблемні місця у процесі та покращувати їх. Звичайно, важливо розкласти ваш процес на колонки зі статусами робіт, щоб деталізація була достатньою для докладного аналізу.
3. Lead Time Distribution Chart (LTDC) – спектральна діаграма розподілу часу виконання. Цієї діаграми в стандартних звітах Jira немає, але вона дозволяє побачити розподіл частоти того, як часто елементи роботи виконуються за різних значень часу виконання. Її можна будувати в Excel за завантаженнями із Jira. Виглядає вона наступним чином:
Якщо ми почнемо вимірювати та аналізувати те, як довго і в якій кількості задачі проходять через нашу систему, нам стане візуально зрозуміло, який min, avg, max у нас буває Lead Time в цілому.
Наведу приклад: на діаграмі вище видно, що через систему пройшло 200 елементів роботи. Максимальний Lead Time в одній із задач був 9 днів, а більшість задач - 90 штук виконуються за 3 дні. З цього випливає, що на момент складання цієї діаграми ми можемо обіцяти тим, кого обслуговує наш сервіс, що запит буде оброблений в період від 1 до 9 днів, але найчастіше це від 2 до 4 днів, якщо з відсотками точності (20+35+90+30=175 і 175/200=0.875) з ймовірністю 87.5% ми вкладемося в 4 дні. А з ймовірністю в 100% вкладемося в 9 днів. Звичайно важливо регулярно знімати та аналізувати ці показники, перед тим як щось комусь обіцяти, але основний принцип, думаю, зрозумілий. За допомогою LTDC можна давати прогнози виконання завдань із певною точністю виходячи зі статистичних даних.
Звичайно ж такий підхід не може існувати сам по собі, і він безпосередньо залежить від того, що у вашу систему потрапляє на вхід і наскільки передбачувано.Є такий Канбан анекдот: "Коли Білл Гейтс входить на стадіон, то в цей момент, у середньому, усі на стадіоні - мільйонери". Завдання менеджера який відповідає за елементи беклогу, що потрапляють в систему - не пускати Білла Гейтса :) Тобто не пускати в систему величезні довгограючі завдання, які на порядок відрізняються від звичайного діапазону, в прикладі вище це значення від 1 до 9 днів. Або якщо все ж таки пускати, то враховувати це при точності вашого прогнозу.
Найпростіший спосіб з чого можна почати?
Якщо все спростити, то для початку можна вважати пропускну здатність (Throughput) вашої системи за однаковий обраний період - тиждень, спринт, місяць. Спробуйте проаналізувати дані за минулі періоди, які вже є - цікаві інсайти для роздумів забезпечені. Є реальні Scrum-команди, які виміряють velocity команди у штуках закритих задач і цього їм достатньо для планування. Формальної попередньої оцінки задач там немає, але ефективне опрацювання та декомпозиція елементів беклога майбутніх ітерацій обов'язково присутня.
Підсумки
Оцінювання завдань у Kanban методі ґрунтується на статистиці та аналізі даних. Використовуючи основні метрики та пару стандартних графіків можна отримати розуміння про середню оцінку елемента роботи та про продуктивність системи, ґрунтуючись на середніх показниках проходження цих елементів роботи через Kanban board. Це є більш точним та передбачуваним емпіричним підходом, ніж при оцінюванні аналітичним способом, який має набагато більшу похибку та непередбачуваність.
Регулярно аналізуючи навіть тільки описані вище основні діаграми в Jira та метрики й поступово покращуючи процес еволюційно, можна досягти покращення показників та підвищити передбачуваності доставки елементів роботи. Jira - не є найкращим інструментом для роботи по Kanban, тому що погано забезпечує всю повноту можливостей для застосування методу. Але в наших реаліях найчастіше в наявності в організаціях, в яких ми працюємо, є саме Jira. Kanban University рекомендує використовувати такі інструменти: Nave (плагін на Jira), swiftkanban і kanbanize, інші інструменти поки що не акредитовані та не дозволяють повною мірою використати потенціал методу.
У Kanban методі є ще багато корисного для покращення розуміння роботи вашої системи, яка, до речі, повинна рухатися вверх, мати явні правила роботи системи, WiP ліміти, поділи на класи обслуговування тощо. У наступних статтях спробую докладно розписати деякі моменти з корисних підходів Kanban методу, які можна застосовувати навіть у процесі Scrum. Адже Kanban не можна впровадити з нуля – його можна застосувати до якогось робочого процесу, який у вас вже є і який ви хочете покращити. Дякую за увагу! Сподіваюся, матеріал був вам корисний.
Comments