Канбан на даних: WIP, DoD, дорожня карта

Учора був tasks.json. Сьогодні буде roadmap.html

Тема 6, урок 2 з 2. Онлайн-дошки та управління проєктами. 120 хвилин

Минулого разу ти зібрав tasks.json — беклог із дієсловами, дедлайнами й критеріями готовності. Сьогодні з цього самого файлу сторінка roadmap.html намалює дошку в три колонки.

Різниця між «у мене є список задач» і «у мене є процес» — не в кількості задач. У списку бракує трьох речей. Сьогодні ти додаси всі три.

Перше — обмеження. Це число: скільки задач тобі дозволено тримати в роботі одночасно. Більше не береш, поки не закриєш одну зі старих.

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

Третє — горизонт. Це поділ задач на три купки: що ти робиш зараз, що відкладено на потім і що не робитимеш ніколи. Третя купка потрібна не менше за перші дві.

Після уроку ти вмієш

• ставити собі число задач у роботі одночасно й називати причину, чому воно саме таке;
• писати список умов, за яких задачу дозволено переставити в done, — по пунктах, а не «на око»;
• ділити свої задачі на три горизонти: зараз, далі й колись;
• верстати сторінку roadmap.html, у якій жодної назви задачі не вписано руками — усе читається з tasks.json;
• читати графік, що показує залишок роботи по днях, і бачити на ньому затор.

Слова WIP-ліміт, Definition of Done і burndown поки нічого не означають — розберемо кожне тоді, коли воно знадобиться.

Хід уроку

Канбан: колонка — це стан задачі, а не етап життя

Найчастіша помилка першої дошки — колонки «Понеділок / Вівторок / Середа»

Слово канбан (看板) японською означає «сигнальна картка». На заводах Toyota така картка була дозволом на роботу. Ділянка не бралася за нову деталь, поки не отримувала картку далі по конвеєру.

Картка приходила тоді, коли на наступній ділянці звільнялося місце. Тобто правило звучало не «роби скільки встигнеш», а «роби стільки, скільки сусід здатен узяти». Сучасна канбан-дошка — та сама ідея, тільки для розумової праці.

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

WIP-ліміт: чому пʼять задач одночасно — це нуль задач

Головна ідея уроку, і вона рахується на пальцях

WIP — work in progress, робота в процесі: усе, що почато, але ще не закінчено. WIP-ліміт — число, яке ти сам собі призначаєш: «у колонці “в роботі” не більше трьох карток». Виглядає як зайва бюрократія. Насправді це єдина річ на дошці, яка змушує закінчувати, а не тільки починати.

Арифметика на пʼяти задачах

Уяви пʼять задач, кожна на два дні роботи. Разом — десять днів праці. Розкласти їх можна двома способами, і сумарна праця в обох однакова.

Тепер додай те, чого на схемі немає. Ти повернувся до задачі після перерви — і кілька хвилин просто згадуєш. Де лежав той файл? Що ти вже пробував? Чому відмовився від першого варіанта?

Ці хвилини звуться перемиканням контексту. Голова щоразу робить дві речі: наводиться на нову ціль і піднімає з памʼяті все, що ти знав про задачу.

Рубінштейн, Меєр і Еванс виміряли ці втрати 2001 року. У їхніх дослідах перемикання зʼїдало до 40 % робочого часу. Досліди були лабораторні, не про верстку лендинга. Тому бери 40 % як порядок величини, а не як точне число для себе.

Затор: чому «в роботі» має бути вузьким місцем

Ліміт нічого не прискорює. Він робить проблему видимою — і це його робота

Без ліміту дошка виглядає добре: у «todo» порожньо, у «doing» тісно, усі зайняті. Саме тому вона й небезпечна — відчуття зайнятості і результат перестають бути одним і тим самим. Задача, яка тиждень стоїть у «в роботі», нікому нічого не дала. Її не можна показати, не можна перевірити, не можна викинути. Вона просто займає голову.

Закон Літтла: скільки часу задача житиме на дошці

Є формула, яку не треба вигадувати: WIP = пропускна здатність × час проходження. Математик Джон Літтл довів її 1961 року для черг.

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

Перевернемо її: час проходження = WIP ÷ пропускна здатність. Ти закриваєш дві задачі на тиждень. Отже:

Зверни увагу: пропускна здатність у трьох рядках однакова. Ти не став працювати швидше — ти просто менше почав. А час очікування впав утричі. Це і є вся математика WIP-ліміту.

Твоя дошка, намальована з твого JSON

Встав свій tasks.json — сторінка збере з нього дошку, стежитиме за WIP-лімітом і поверне змінений JSON назад

Це той самий механізм, який за півгодини ти зробиш у roadmap.html. Беремо масив обʼєктів, групуємо за полем status, малюємо три колонки. Тут він уже готовий — щоб ти спершу зрозумів поведінку, а вже потім писав код.

Тренажер працює у твоєму браузері й нікуди нічого не надсилає. Демо-беклог складено автором сторінки за схемою з уроку 9: 12 задач, 4 епіки, дедлайни в жовтні–листопаді. Твої числа будуть свої.

Definition of Done: «зроблено» — це не «я дописав»

Один перелік умов, однаковий для всіх задач, написаний до роботи

Слово «готово» — найдорожче слово в проєкті, бо кожен розуміє його по-своєму. Ти вважаєш задачу готовою, коли код працює в тебе на ноутбуці. Вчитель — коли сторінка відкривається з сабдомену. Однокласник, який робить наступну задачу, — коли він може на неї спертися. Три різні «готово» на одну картку — і картка їздить із «done» назад у «doing» третій раз.

Тому «готово» домовляються заздалегідь і записують. Такий запис зветься Definition of Done, скорочено DoD. Це один перелік умов, спільний для всіх задач проєкту, а не опис окремої картки.

У Scrum Guide 2020 правило суворе. Робота, яка не відповідає DoD, не випускається й навіть не показується — вона повертається в беклог.

Чому DoD пишеться до роботи, а не після

Якщо перелік умов зʼявляється після того, як робота зроблена, він завжди підганяється під результат: «ну, задокументувати можна й потім». Написаний до старту, DoD виконує три функції одразу:

Дорожня карта — це не список задач

Беклог відповідає «що»; карта відповідає «коли й навіщо»

Беклог — усе, що спало на думку, відсортоване за пріоритетом. Дорожня карта — інший документ: вона показує, які проблеми ти берешся розвʼязати найближчим часом і в якому порядку. Тому в карті не 40 рядків, а 6–8, і кожен має причину, а не тільки назву.

Найпоширеніший формат карти сьогодні — три горизонти Зараз / Далі / Колись (now / next / later). Його ввела Джанна Бастоу з ProdPad.

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

Чому дати в шкільному проєкті орієнтовні

Кожен рядок карти спирався б на оцінку часу. А оцінка часу — це прогноз людини, яка ще не робила цієї задачі. У тебе на модуль 14 уроків, між ними тиждень. І саме в цей тиждень трапляється контрольна з хімії. Тому дата в due — це орієнтир і сигнал, а не обіцянка.

Сигнал читається так. Один перенос — буває. А коли дата зсувається вдруге, справа вже не в тому, що ти не встиг. Це означає, що задача більша, ніж здавалося, і її треба розбити.

Чому сторінка тягне JSON, а не переписує його руками

Одне джерело правди. Правка в одному місці, а не в двох

Спокуса зробити roadmap.html просто гарною сторінкою з написаними руками картками величезна: так швидше й видно результат одразу. Проблема зʼявиться через тиждень, коли ти закриєш задачу. Тепер її треба виправити в tasks.json і в roadmap.html. Один із двох файлів рано чи пізно відстане — і сторінка почне брехати.

Це той самий принцип, що й дизайн-токени в brand.css з уроку 5. Там колір записаний один раз у змінній, а не двадцять разів у розмітці. Тут — те саме, тільки для даних.

Каркас roadmap.html

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

<link rel="stylesheet" href="brand.css">
<h1>Дорожня карта</h1>
<p id="err" hidden></p>

<div class="board">
  <section><h2>До роботи <span data-cnt="todo"></span></h2>
    <div data-col="todo"></div></section>
  <section><h2>В роботі <span data-cnt="doing"></span></h2>
    <div data-col="doing"></div></section>
  <section><h2>Готово <span data-cnt="done"></span></h2>
    <div data-col="done"></div></section>
</div>

// нижче — усередині <script>
fetch('tasks.json')
  .then(r => { // 404 не кидає виняток — перевіряємо самі
    if(!r.ok) throw new Error('tasks.json не знайдено: ' + r.status);
    return r.json();                // зламаний JSON кине тут
  })
  .then(draw)
  .catch(e => {                     // порожній екран — найгірша помилка
    const p = document.getElementById('err');
    p.hidden = false;
    p.textContent = 'Дошку не побудовано. ' + e.message;
  });

function draw(tasks){
  ['todo','doing','done'].forEach(st => {
    const box = document.querySelector('[data-col="' + st + '"]');
    const list = tasks.filter(t => t.status === st);
    document.querySelector('[data-cnt="' + st + '"]').textContent = list.length;
    box.textContent = '';
    list.forEach(t => {
      const card = document.createElement('article');
      const h = document.createElement('b');
      h.textContent = t.title;      // textContent, а не innerHTML
      const m = document.createElement('small');
      m.textContent = t.epic + ' · ' + t.priority + ' · до ' + t.due;
      card.append(h, m);
      box.appendChild(card);
    });
  });
}

# PowerShell 5.1 — єдиний надійний спосіб
[IO.File]::WriteAllText("$HOME\tasks.json", $text, (New-Object Text.UTF8Encoding $false))

# Git Bash, macOS, Linux
cat > tasks.json

# перевірити, що файл валідний, перед заливкою
# Git Bash, macOS, Linux — тут && працює
python3 -m json.tool tasks.json > /dev/null && echo "JSON ok"

# PowerShell 5.1 && не розуміє — тільки окремими командами
python -m json.tool tasks.json | Out-Null; if ($?) { "JSON ok" }

Burndown: лінія, яка майже ніколи не буває прямою

Одна діаграма, яка відповідає на питання «ми встигаємо чи ні»

Burndown (буквально «згоряння») показує одне число щодня: скільки роботи ще лишилося. Не скільки зроблено — скільки лишилося. Пряма похила лінія — це план. У спринті 10 днів і 30 одиниць роботи, отже щодня має «згоряти» по 3. Ламана — реальність.

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

Тому графік читають не на «збігається чи ні», а на форму. Рівна полиця — задачі стоять, проблема з WIP. Різкий стрибок угору — роботи додалося, проблема з обсягом. Обрив у самому кінці — усе закрили поспіхом, проблема з якістю.

Симулятор спринту: 10 робочих днів твого беклогу

Тепер найцікавіше. Візьми свій беклог (або демо) і пообіцяй, скільки берешся зробити за 10 днів. Потім прокрути ці 10 днів. Кожні кілька днів трапляється те, чого не було в жодному плані. Твоя справа — вирішити, чим за це платити.

Модель симулятора спрощена й оголошена повністю: швидкість 3 одиниці на день, спринт — 10 робочих днів, отже ємність 30 одиниць. Кожна подія додає роботу, якої не було в плані. Чотири рішення платять за неї по-різному.

Перекинути — робота росте, ємність та сама. Розбити — робота не росте, зате обіцяний обсяг меншає на ту саму величину. Відмовитися від could — робота не росте й MVP цілий, але could-задач у плані стає менше. Тому кнопка працює, лише поки такі задачі там ще лишилися. Зірвати дедлайн — робота росте, зате додається робочий день, тобто +3 до ємності.

Події, їхній порядок і ціни склав автор сторінки. Це навчальна модель, а не вимір реальної команди.

Практика: збираємо roadmap.html

Виконуй по черзі. Галочки зберігаються — сторінку можна закрити.

Автоперевірка check11 6

Перевірка зробить реальний запит на твій сабдомен, прочитає tasks.json і навмисно підмінить у ньому назву задачі, щоб переконатися, що дошка жива. Спроби не обмежені.

Демонстраційний режим: результат згенеровано для показу. На сервері ця кнопка запускає check11 6 від імені учня і читає ~/.progress/11-6.json.

Що вчитель дивиться на екрані

• відкриті DevTools, вкладка Network: під час перезавантаження сторінки видно запит tasks.json зі статусом 200 — дошка справді тягне дані;
• ти зламуєш JSON (стираєш одну кому), перезавантажуєш — і сторінка показує зрозуміле повідомлення, а не порожній екран;
• результати «Симулятора спринту»: два проходи й твоє пояснення, чому другий вийшов кращим — на сервер вони не йдуть;
• твій Definition of Done: ти можеш назвати вголос пʼять умов і показати задачу, яку через нього довелося повернути з «готово».

Шкала виконання

Це те, що бачить учитель, коли виставляє оцінку.

Що лишається з тобою після цього уроку

• WIP-ліміт. Скільки б задач не було, одночасно робиться три. Щоб узяти нову — закрий стару.
• Definition of Done. Пʼять умов, написаних до роботи, однакових для всіх задач. «Я дописав» серед них немає.
• Рендер із даних. Дані живуть в одному файлі. Сторінка їх показує, а не дублює.
• Запас часу. Ємність спринту й обсяг зобовʼязань — різні числа, і друге завжди менше за перше.

Домашнє завдання

1. Доведи до done ще дві задачі — за done_criteria і за своїм DoD, а не оптом. Переконайся, що канбан оновився без жодної правки roadmap.html.
2. Додай у ~/www/kb/ нотатку dod.md із front-matter і пʼятьма пунктами свого Definition of Done — вона підхопиться базою знань із уроків 7–8.
3. Запиши в CHANGELOG.md один рядок про сьогоднішній день: який WIP-ліміт ти собі поставив і яку задачу довелося повернути з «готово» назад.

Звідки взяті факти й формули

Кожне твердження, яке можна перевірити, має посилання. Перевіряти дозволено й корисно.

• Канбан як сигнальна картка й правило «не починай, поки наступний етап не звільнив місце» — опис виробничої системи Toyota від самої Toyota. global.toyota · Toyota Production System
• Явне обмеження WIP як обовʼязкова частина канбан-системи; ліміт може стосуватися однієї колонки, групи колонок або всієї дошки — The Kanban Guide, грудень 2020. kanbanguides.org · The Kanban Guide
• Закон Літтла: WIP = пропускна здатність × час проходження — оригінальна стаття Джона Літтла «A Proof for the Queuing Formula: L = λW», Operations Research, 1961. jstor.org · A Proof for the Queuing Formula
• Втрати до 40 % продуктивного часу на перемикання між задачами; дві стадії — «зміна цілі» і «активація правил» — Rubinstein, Meyer, Evans, Journal of Experimental Psychology: HPP, 2001, і популярний виклад APA. apa.org · Executive Control of Cognitive Processes in Task Switching (PDF), apa.org · Multitasking: switching costs
• Definition of Done — формальний опис стану інкремента; робота, що не відповідає DoD, не випускається й не показується, а повертається в беклог — The Scrum Guide 2020, розділ «Commitment: Definition of Done». scrumguides.org · The 2020 Scrum Guide
• Формат дорожньої карти «Зараз / Далі / Колись» і чому він замінив карти з точними датами — авторка формату Джанна Бастоу, ProdPad. prodpad.com · Now-Next-Later roadmap
• fetch не працює з file:///: браузери вважають локальні файли непрозорими джерелами, CORS-запит дозволений тільки для http і https — MDN. developer.mozilla.org · CORS request not HTTP
• fetch не кидає виняток на HTTP-помилках 404 і 500 — статус треба перевіряти самому через response.ok — MDN. developer.mozilla.org · Window.fetch()
• JSON не допускає BOM на початку документа — RFC 8259, розділ 8.1. datatracker.ietf.org · RFC 8259
• Перетягування карток: HTML Drag and Drop API — developer.mozilla.org · HTML Drag and Drop API

Ілюстративні числа, за які автор сторінки відповідає окремо: «дві доби на задачу» у схемі паралельно/послідовно, сім карток у заторі, форма ламаної на burndown, демо-беклог із 12 задач і всі ціни подій у симуляторі спринту. Вони підібрані так, щоб арифметика сходилася на очах, і не є виміром реальної команди. Модель симулятора (3 одиниці на день, 10 днів, ціни всіх чотирьох рішень) оголошена прямо на сторінці під самим симулятором. Повний список джерел із поясненнями — у файлі urok-10-джерела.md поруч із цією сторінкою.