Kanban як основа для виробництва software

Привіт! Я Сергій Алексєєв, автор п'яти, на мій погляд, цікавих статей зі світу IT . У цій статті розповім про Kanban з прикладами і описом. Це допоможе вам впровадити методологію у себе або трохи поліпшити те, що є у вас зараз.

Передмова

Задайте собі питання: за якою методологією або фреймворку ми ведемо розробку програмного забезпечення? Напевно багато хто з вас скажуть: Scrum. Це можна пояснити декількома фактами:

Переконав? А тепер задайте ще кілька запитань собі або своєму менеджеру:

І так далі про все, що пов'язано з метриками та процесами.

Давайте я розповім трохи про те, як я бачу картину світу, де є 3 підходи в розробці software, і про те, для чого потрібен кожен з них (моя скромна думка):

Звичайно ж, їх більше, але поки що поговоримо про ці.

Назва Моя думка
Waterfall

Бачив і брав участь при впровадження в держпроектах. Це були рішення на різних платформах типу CRM, ERP від потужних постачальників, таких як IBM, SAP, Microsoft.

Непридатний в поточних реаліях українського IT-ринку і вимог західних клієнтів.

Особливість : кожен наступний етап SDLC не виконується до тих пір, поки поточний етап не закінчиться і не здасться під підпис.

Вже давно не зустрічав.
Scrum

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

Наприклад, у вас є 2 і більше повноцінні команди, один Project Manager і один проект.

Приклад складу команд:

  • FE — 2 FTE;
  • BE — 2 FTE;
  • QA — 1 FTE;
  • BA — 1 FTE.

Підвищення продуктивності можна досягти при масштабуванні кількості команд і накопиченні доменної експертизи. Основний принцип — ітераційність.
Kanban

Використовується, коли немає певної кількості проектів: вони то з'являються, то зникають. Є більш або менш стабільна команда. Відповідно, є просто потік завдань, які необхідно зробити, ґрунтуючись на пріоритетах проектів.

Пріоритетом може служити дедлайн або обурення клієнта.

Підвищення продуктивності можна досягти збільшенням пропускної спроможності сервісу (QA/BE/FE) або формуванням скоупа для розробки з горизонтом 2-4 тижні вперед.

Проблематика

Цю статтю я почав писати не для того, щоб розповісти примітивні речі про Kanban. Наша команда зіткнулася з різного роду завданнями, і я хочу поділитися способом вирішення деяких з них.

Stakeholder Проблема Статус
Менеджмент Зрушення в термінах по взаєморозрахунках з клієнтами In Progress
Відсутність розуміння співвідношення виконуваних робіт у проекті (BE/FE/CRZ/QA/BA) Done
Project Manager Немає розуміння завантаження команди в цифрах. Є розуміння на рівні gut feeling і тільки на сьогодні In Progress
Відсутність розуміння готовності проекту в певну точку часу Done
Всі проекти здаються не вчасно In Progress
Команда розробки Немає чіткого розуміння процесу взаємодії між учасниками команди (хто, з ким, коли і що робить) Done
Немає розуміння, яка різниця між Task/Story/Sub-Task Done
Немає розуміння, які завдання необхідно робити сьогодні і який план на завтра In Progress
Погано описані або відсутні User Story In Progress
Проблема Причини Причини другого рівня Рішення
Немає чіткого розуміння процесу взаємодії між учасниками команди (хто, з ким, коли і що робить) Відсутність лідера з баченням процесу delivery Найнятий лідер з таким баченням і всіма повноваженнями
Немає розуміння, яка різниця між Task/Story/Sub-Task Відсутність правил ведення backlog Була розказана ідея ведення backlog і потреби кожного типу в ньому. Проведені воркшопи
Немає розуміння, які завдання необхідно робити сьогодні і який план на завтра Відсутність затвердженого backlog з горизонтом хоча б на тиждень вперед

Проведені воркшопи з BA на тему утвердження User Story в найкоротші терміни, а також утримання backlog-горизонту.

Були створені Kanban-борди, які дозволяли бачити завдання в різних угрупованнях:

  • by assignee;
  • by project
Погано описані User Story Низька кваліфікація BA Воркшопи/лекції/менторинг
Немає розуміння завантаження команди в цифрах. Є розуміння на рівні gut feeling і тільки на сьогодні Відсутність створених сабтасков.
Відсутність планових оцінок в годинах		 Планування в Tempo
Відсутність розуміння, наскільки виконаний проект/реліз в певну точку часу Немає даних оцифрованих Ведення всіх завдань через сабтаски + налаштування дашбордов в Jira
Всі проекти здаються не вчасно Погане планування Погане розуміння доступності ресурсів Планування в Tempo
Зрушення в термінах по взаєморозрахунках з клієнтами Несвоєчасна здача проектів Погане планування Планування в Tempo
Поганий контроль виконання Дашборды в Jira
Погане розуміння доступності ресурсів на період (тиждень/два тижні/місяць) Звіти у Tempo
Несвоєчасна оплата клієнтами Помилки персоналу на стороні клієнта ...
Помилки персоналу на нашій стороні ...
Відсутність розуміння співвідношення виконуваних робіт у проекті (BE/FE/CRZ/QA/BA) Немає даних оцифрованих Ніхто не знав, як оцифрувати дані Створена спеціальна структура в Jira, яка дозволяє побачити кількість запланованих і витрачених ресурсів по кожному з видів робіт (BE/FE/CRZ/QA/BA)

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

Роздуми

Кейс. Є одна команда, на яку необхідно планувати різні проекти. Коли я кажу «різні», це означає різної складності, тривалості, контексту і клієнтів.

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

Приклад. Частина людей, з якими я перетинався, думали, що працюють по Scrum, хоча насправді це був Kanban. Така ілюзія була обумовлена тим, що вони створювали тип проекту Scrum Jira, поміщали в активний спринт Story, Task, Sub-Task і ніколи не закривали цей спринт.

Коли я прийшов в компанію, то всі мої знання про Scrum і Waterfall не вкладалися в реальність, з якою я зіткнувся. Мені терміново потрібно було прийняти рішення, як я буду робити delivery проектів, бо стан справ було приблизно таке ж, як у нас в державі з медициною.

Проаналізувавши структуру моїх проектів, склад команди і необхідність бути гнучким, я чітко усвідомив, що мені потрібно йти по шляху Kanban замість Scrum.

Кілька тижнів все працювало так, як до мого приходу. Я намагався вникнути в те, що відбувається, і проаналізувати ситуацію. Я нічого не чіпав, щоб не зламати :) Сидів увечері на роботі і думав над тим, як би вирішити цю задачу, вивести всі в зрозумілий і прозорий процес, де кожен розуміє свою роль і те, що відбувається навколо. Я згадав, що зовсім недавно читав цю статтю , де хлопці поділилися своїм підходом до організації процесу розробки. Мені сподобалася ідея з крос-продуктовими командами, де є загальні сервіси (Design/Dev/QA). Мене ця ідея більш ніж влаштовувала, оскільки кількість ресурсів було невеликим, а продуктами для мене були проекти. Я теж вирішив прив'язатися до релізами і запустити роботу по Kanban. В той момент я практично нічого не знав про Kanban, крім загальних принципів, які звучать наступним чином: To Do => In Progress => Done.

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

Нова організаційна структура

Head of Department — формування бюджету. Формування delivery процесів в департаменті. Розвиток існуючих клієнтів (up-sell та cross-sell), відповідальність за прибутковість департаменту. Звітність безпосередньо власникам компанії.

PM — коригування процесів delivery. Відповідальність за дотримання термінів реалізації проектів. Планування ресурсів. Участь у вирішенні питань, які вимагають ескалації. Формування розуміння того, як будуть йти процеси взаємодії між клієнтом і компанією (change management, payments, product shipment тощо).

Product Manager — відповідальність за формування скоупа продукту. Виконання активностей в розрізі ініціатив Sales & Marketing (наприклад, розсилання листів учасникам презентацій продуктів, зустрічі з клієнтом при продажі). Щоденна робота з командою. Бачення та стратегія залишалися на власників.

Pre-Sales BA — формування комерційної пропозиції клієнту на основі скоупа та оцінки проекту. Комунікація з клієнтом до підписання контракту.

Account Manager — контроль над документообігом (оформлення контрактів, виставлення рахунків і закриття актів). Колаборація з проектним менеджером, щоб розуміти, коли і що буде здано, для виставлення рахунків і коректувань у плані оплат.

Corezoid BA — ведення декількох проектів з точки зору формування вимог і написання документації. Управління очікуваннями клієнта в розрізі функціональності, яку планується реалізувати. Імплементація автоматизації бізнес-логіки з допомогою спеціальної платформи Corezoid. Демонстрація виконаної функціональності клієнту.

BE Developer — каст заклинань і магія. Поповнення мани з кавоварки.

FE Developer — каст заклинань і магія. Поповнення мани з кавоварки.

QA — окремий сервіс по тестуванню без прив'язки до конкретного проекту.

Чому я не обрав Scrum?

Відповідь для мене видався очевидним через різномаїття проектів, їх дедлайнів і невизначеності. Основна невизначеність була в тому, що я міг підписати проект тривалістю 3 тижні, який треба починати робити вже сьогодні, тому що клієнт прив'язаний під публічна подія (наприклад, фестиваль або рекламу на ТБ/YouTube). Такого роду завдання передбачають гнучкість в плануванні і реалізації.

Scrum передбачає чітку ітеративності і фіксовану функціональність ітерації. На жаль, я не міг і поки не можу так робити — як мінімум з-за невеликої тривалості проектів (1-3 місяці) і, звичайно ж, із-за відсутності можливості виділити окрему команду під кожен проект.

Запровадження

Завдання: оцифрувати все, що відбувається в департаменті, і пояснити команді правила гри.

Оскільки усі проекти були пов'язані з чат-ботами, а їх тривалість була невелика, я прийняв рішення не вести окремий проект в Jira під кожен з них, а створити один проект під назвою Chat Bots, в якому будуть всі проекти.

Мені необхідно було мати стандартизований процес виконання робіт командою і загальноприйняті правила в розробці програмного забезпечення. Першим ділом я вирішив створювати мінімальний процес і налаштувати інтерфейси для роботи команди. У глибині душі я розумів, що хлопці з команди Atlassian вже вирішили майже всі мої болі, залишилося тільки знайти це рішення і зібрати все разом, не потрібно винаходити велосипед. Першим ділом я пішов на офіційні ресурси Atlassian і почитав user guides за Jira і Tempo.

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

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

Нижче наведено приклади того, як виглядала інформація спочатку і на проміжному етапі.

Ось так виглядала інформація для прийняття операційних рішень спочатку:

Проект Відсоток виконання Коментар
XXX 50% Блокер-клієнт
YYY 70% Чекаємо інтеграцію

Ця таблиця не зазнавала ніякого сенсу, крім агрегування всіх проектів в одному місці. Відсоток виконання проставляється виключно на калькуляціях і формули в голові PM. Це дуже суб'єктивно і неправильно.

До речі, багато проектні менеджери, яких я проводив співбесіду, вважають такі таблички нормальної реальністю.

А так виглядала інформація до впровадження Jira і після таблиці в Excel

Ця дошка була проміжним етапом між Excel і Jira і прожила близько 3 тижнів. Через 2 тижні після її створення я попросив команду перенести все в Jira і дав на це тиждень. Через тиждень інформація була стерта з дошки, і ті, хто не встиг перенести, заповнювали прогалини зі своєї голови. І так настала ера цифровізації.

Структура сутностей в JIRA

Entities relationship in Jira

Ця структура показує залежність між сутностями Jira всередині одного проекту. За фактом у мене було 3 проекту.

Також хочу зазначити, що всі аналітики ведуть свій backlog. Незважаючи на те що всі User Story знаходяться в одному проекті, функціональність Jira дозволяє досить легко візуально розділяти дані між людьми. Це можливо завдяки фільтрам.

Давайте перейдемо до того, чому ж я все-таки вирішив будувати окрему структуру залежностей і чому мені не вистачило стандартної схеми. Вся структура була створена, щоб коректно будувати звітність і розуміти, куди витрачено час у конкретному розрізі часу. Ті, хто будував WBS, зрозуміють мене ;)

Project Type — дозволяє розділити час (planned/fact) на рівні проекту:

Account
Ця сутність була створена, щоб позначати клієнтів, за якими ведеться робота. Тому що по одному клієнту можуть бути різні проекти. Наприклад, в одній компанії проекти можуть бути розбиті по брендам.

Component
Призначені, щоб описувати проект. У мене компонент — це назва проекту. Відповідно, у одного аккаунта можуть бути різні компоненти в один проміжок часу. Якщо б ви вели проекти по Scrum, це були окремі проекти в Jira. У мене це окремі компоненти всередині одного проекту.

Fix Version
Використовуються, щоб позначати релізи в окремих проектах (компонентах). В одному проекті може бути кілька версій. Відповідно, в одному проекті може бути кілька релізів. Вони можуть бути продані як однією, так і різними контрактами, але це все одно буде один і той самий проект.

Task
Служить для фіксації часу, опису документації аналітиками або виконання роботи дизайнером.

Story
Є агрегатом бізнес-функціональності. Більш докладно я розповідаю про це у своєму відео User Story canvas .

Sub-Task
Основне завдання — акумулювання часу — планованого і фактичного — на виконання сторі. Також сабтаски використовуються для виділення окремих типів робіт. Останнім часом я роблю досить просто: у мене в сторі створюється лише кілька сабтасков (BE/FE/CRZ/QA/BA). Вони акумулюють час, витрачений на реалізацію функціональності. Якщо ваша команда достатньо згуртована, можна розбивати сторі на більш детальні сабтаски — так вони будуть давати більш точні дані.

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

Результати

На мою думку, цей розділ буде самим цікавим в статті. Нижче наведені приклади реальних проектів і команди.

Я почну показувати приклади отриманого результату.

Tempo report — work time tracking

Цей звіт побудований за структурою, яку я описував вище в статті. Він дозволяє вивантажити цю структуру в Excel з декомпозицією до сабтаска, в яких зазначено 3 параметра часу (Planned Estimate/Original Estimate/Remaining Estimate). Інформація такого характеру дозволить вам розрахувати рентабельність вашого проекту майже в реальному часі, порівняти, скільки продали і за скільки зробили, ну і ще багато різних і корисних речей.

Capacity report — planned time

Цей звіт дозволяє побачити завантаження не тільки кожної людини окремо, але й команди цілком. Жовтим кольором виділені ті місця, де завантаження перевищує 100%.

Capacity report — resource availability

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

Tempo — resource planning view

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

Tempo — resource planning timeline

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

Tempo — resource planning view (by person)

Так виглядає планування однієї людини, все це засновано на реально створених сабтасках в Jira або ж на фейкових (планових) завдань для людини.

Планування і відстеження прогресу за релізам

Так виглядає зараз інформація про прогрес роботи над релізом всередині проекту.

А ось так виглядають ті ж релізи, якщо їх додати на дашборд через гаджет.

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

User Story card

Тут я вам хотів показати, як виглядають поля в самій Jira всередині User Story. Ці поля заповнюються бізнес-аналітиком при створенні, а пізніше створені сабтаски успадковують значення цих полів автоматично через автоматизацію Jira.

User Story flow

Sub-Task flow

Business Analyst view

Зеленим показані User Story, в яких прописана бізнес-функціональність. Синім кольором показані таски.

Developer view

Ось так виглядає view для розробника.

Підсумки

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

Нам ще багато чому варто навчитися і доведеться з багатьох зіткнутися. Через 5 місяців ми тільки почали дотримуватися принципів, які були впроваджені. А ще на нас чекають аналіз та оптимізація.

У Kanban є багато різних звітів і показників, на основі яких можна робити висновки і поліпшувати процес, але на це потрібен час.

Спасибі, що дочитали до кінця.


Читайте також:Чому варто спробувати Kanban & Monday для організації робочого процесу

Опубліковано: 26/07/19 @ 10:00
Розділ Різне

Рекомендуємо:

Як направити трафік з instagram на сайт
Ми хотіли найняти штат програмістів в продукт. Навіть з бюджетом це виявилося не так просто
Зарплати українських розробників — червень 2019
Front-end дайджест #35: Hermes, JS-in-CSS і VS Code на стероїдах
Чому AI переходить від Cloud до Fog-обчислень