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

Декілька місяців тому був невеличкий мітап з нашим, на той момент, Віталіком Детленком, CTO нашої компанії. І він ділився там іншим контекстом, іншим доповіддю, але згадав про наш Kanban, що ми переїжджали і так далі. І неочікувано, для мене неочікувано, було багато питань щодо Kanban. Здивувався, зрозумів, що тема може бути актуальною, цікавою, тому сьогодні про неї тут. І перед тим, знову ж таки, як почнемо, хто працює зі Scrum зараз? Окей. SAFe, інші методології? О, цікаво, теж є, супер. Ну, Kanban ? Відмінно, супер. Хто може поділитися, розповісти, пояснити різницю? Lead time, cycle time, TTM? Супер, буде корисно, відмінно. Починаємо.

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

Давайте заглибимося трошки в контекст Uklon, куди ми це все впровадили і на чому це все працює. 12 продуктових команд, 220 + в IT-дивізіоні, 30 мікросервісів, 3 країни, більше 30 вже, здається, 30 міст. На все це ми розтягнули наші нові процеси, і вийшло доволі добре. Якщо подивитися на таймлайн наших процесів, я там не брав вже з самого початку у розвитку компанії, що у нас там було. Там більше був такий стартаповий підхід, не багато людей, і впровадження якихось методологій було скоріше витратою часу, ніж якоюсь користю. Тому взяв більше спочатку впровадження Scrum. Там десь був, звісно, період не так чітко. Це 2015 рік, але все ж таки. Протягом роботи з Scrum, бачите, що ми працювали з Scrum досить довго перед тим, як перейти на Kanban. І протягом всього цього часу ми експериментували, як пристосовувати його під нас, під наші процеси. І звісно, Scrum свій, у кожній компанії свій Scrum, розумієте, про що я. І приблизно в 2019 році, експериментували з SAFe. Був у нас консультант, який допомагав нам пристосовуватися. Він, за різними причинами, не заїхав. Але все ж таки, якщо узагальнити, то ми взяли дуже багато цікавого з нього. Як і з Scrum, в принципі, із SAFe взяли декілька речей. Одну з таких речей ми взяли саме під час цих експериментів. Ми розділили продуктові команди за контекстом. І розділили наші мікросервіси, розподіливши відповідальність між всіма командами. І так, був період трансформації. Kanban ми впроваджували ітеративно, експериментальним шляхом. Проводили декілька команд, потім масштабували на всі команди. Наразі Kanban є стандартом для всіх наших команд. Створення нової команди відразу розпочинається з практик Kanban. Тут може виникнути запитання щодо Scrum. Що сталося із Scrum? Чому ми відмовилися від Scrum? По різним причинам, я виділив кілька.

Основні причини - він заважав нам у постійних релізах. Збивав команди з потоку. Двотижневі спринти вимагали багато атрибутів саме в плануванні. Якісь процеси пов'язані з наповненням беклогу, потім з ретроспективою, потім треба було код фрізи. Треба було чекати кінця цієї ітерації, щоб видавати ці релізи і так далі. Потім ми якось адаптували, натягували. Десь заходило, десь не заходило. Але хотілося релізити часто, хотілося релізити коли буде зручно, відразу по результатам тестування і так далі. Зараз, там десятки. На масштабі всієї кампанії десятки релізів на день. Релізимо тоді, коли нам зручно. Релізи формуємо на льоту. І єдина там відсічка – це по метриках, по нашим таргетам.

Щодо міфів. Не можу не згадати насправді. Написав, читати не буду. Буде у вас на руках потім сама презентація. Хтось згадає, або читав, скоріш за все, про ці всі міфи десь в статтях і так далі. У кого, можливо, вони ще живуть. Але єдине, що пораджу – це почитати книжку «Kanban фор скепсис», також посилочка внизу. І друге, що скажу – це кампанії, які використовують Kanban зараз. Українські, гіганти. Теорія. На чому будується Kanban взагалі? Перше, що приходить в голову до нас, коли ми кажемо про Kanban – це Kanban Дошка, візуалізація, стовпчики і так далі. І так, дійсно, це важливий аспект саме Kanban. Коли ми відкриваємо борду якоїсь команди, у нас все перед глазами. Ми бачимо, над чим керують ця команда, де в неї батлнеки, де якісь прапорці виставляються і так далі. Розуміємо, який у нас флоу.

Наступне – це work in progress. Знову ж таки, на борді ми розуміємо, з чим працюємо. І саме ця візуалізація допомагає командам акцентуватися на work done. Тобто ми не затягуємо щось нове, поки не пропихнули з нашого процесу, з нашого флоу, все, що ми затягнули до цього. Звісно, цим флоу, який ми по пул-моделі затягуємо в систему нові айтеми, тасочки в роботі, то ми маємо менеджити їх ефективно для того, щоб у нас був sustainable потік, безперервний, з якимись сталими процесами і так далі. Це дозволяє покращувати цей флоу і, в принципі, зменшувати cycle time, lead time і так далі. І останнє, скажемо так. В моїй презентації, але не останнє взагалі, є багато ще додаткових якихось принципів. Виділив 4 як основних. Всі інші, вони само собою розуміються.

І, так, по імпрументам. В принципі, шлях Kanban — це постійні імпрументи. Так, я відійду, щоб вам не заважати. Глаза світять, я вам заважаю. Постійний імпрувмент. Тобто, коли ми стоїмо на шляху Kanban, кожен на своїй ділянці роботи, кожен колега, який працює, тестувальники, девелопер, менеджери, будь-хто в цілому борт компанії, має акцентувати саме увагу на постійних ітеративних покращеннях, які в результаті комбінуються і дають якийсь загальний значний результат на компанію. Тобто, це шлях постійних покращень. Дрібними кроками. Або не дрібними.

Що по порадам. Перше, що я вам пораджу, це при переході на Kanban залайнити всю компанію, особливо менеджерів, які будуть безпосередньо впроваджувати цю методологію вашої команди, залайнити команду всередині, донести, навіщо ми це робимо, донести, чому ми не використовуємо і не живемо далі, як ми жили до цього. Легше буде потім це все імплементувати. Знаємо всі менеджери більш-менш скрізь погано відносяться до зміни — це складно. І я ще дійду до цього. По старту. Ламати процеси і викошувати все, що у вас є, будувати з нуля — не зовсім ефективно. І не треба цього. Kanban регламентує старт імплементації. Можна почати прямо з сьогоднішнього дня. Та борда, яка у вас є, скрізь за все, в будь-якій методології, вона, в принципі, вже відповідає здебільшого. In Progress, Review, Ready for Review і так далі, і так далі. Тестування, Ready for Release — це все у вас, скрізь за все, є.

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

Змінення підходу до естімації. В Scrum у нас є... Все тут зрозуміло. Є ітерація, є сторі поінти, є беклог. Оцінили, кинули карточки.Погнали. Щось встигли, щось не встигли. Запакували, перекинули далі. В Kanban це трохи не так. Треба змінити парадигму мислення в плані естімації. І, по суті, Kanban каже, що естімації взагалі не потрібно. Ми беремо і робимо. Тому що цей оверхед на самій естімації може бути набагато більший, ніж ефект і час самої розробки. Це досить важливий вейст, в принципі.

А далі ще по естімаціям розкажу, як ми до цього підходимо. Що каже Kanban в цьому плані? Ми маємо дивитися на історичний розгляд. На різний розмір наших задач. Десь можливо адаптувати. Для чого? Для того, щоб наша варіативність в системі була якомога менша по процентам. Щоб у нас, наприклад, 80% задач, умовно, епіків, ми закриваємо в якихось таймфреймах. Від 15 до 20 днів, до 30 днів і так далі. Далі цей коридор звужувати. І таким чином і планування, і естімації, в сенсі, планування стає легшим. Естімації відходять на зовсім інший план і ставити не потрібно. Тому тут важливий момент зміни. Про варіативність вже сказав. Фокус на якості. Фокус на якості має бути завжди. Всі наші баги, інциденти і так далі, не кажучи вже про НПС наших юзерів, це впливає на наш потік. Наші баги, навіть в деві, це є нічим іншим, як вейсти. Переробляємо, заводимо тасочки, оверхед на оцій менеджмент і так далі, це вести. Тому фокус на якості загалом має бути.

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

Реліз менеджмент. Пов'язано з естімаціями дещо, але насправді також важливий момент. В тому плані, що нема в нас тепер реліз. Беклогу реліза. Ми не розуміємо там умовно, коли ми будемо юзати. Тому тут важливо експериментувати з кількістю задач в релізі. Розуміти, виставити якийсь сайкл тайм релізу. І дивитись, скільки нам комфортно в конкретній команді компанії видавати. Упс, в мене тут все пропало. Видавати постійно релізи. Тому від кількості задач. Якщо вони у вас більш-менш одного розміру, наповнюємо реліз. Ставимо сайкл тайм релізу в таргет. Дивимось, адаптуємо, попадаємо, не попадаємо. І ітеративно покращуємо. Але реліз менеджмент важливий момент. Додатково відмічу. Далі така знову ж таки continuous тема. Виявляємо батлнеки в системі. На першому етапі формування вони прямо будуть перед глазами всі. Їх буде легко дуже виявити. І знову ж таки легко з ними буде викорінювати їх. Чим далі, тим ці батлнеки будуть менш явними. Треба буде лазити, треба буде саме аналізувати, звідки вони беруться, ретроспективи аналізувати за допомогою тулзів, які ви виберете. І вибирати. І вивчати, що заважає нам нашій сустенебіліті. І нашому флоу.

Є плагіни і так далі. Але не завжди зручно. І не завжди дає функціонал повністю, який може нам розібрати оці батлнеки, які там приховані за якимись іншими процесами, для того щоб знайти корінь проблеми. І що? Треба налаштувати наші таргети. По-перше, визначити метрики і для них таргети. Про це й поговоримо далі. Що ми використовуємо в Uklon як метрики. Flow efficiency. Загалом, міряємо багато чого. Якщо не сказати все. Перше, це flow efficiency, cycle time, throughput, work in progress. Перед тим, як більш детально по кожній з них пройтись, розкажу, яку тулзу ми використовуємо. До речі, хто знайомий з нею ? О, супер. Супер, є люди, огонь. Як вам, нормально? Люди руки піднімали? Супер. Визначу, що тулза специфічна з точки зору UX, але це те, що по суті нам дає інструмент, це той інструмент, який нам дає розібрати на молекули загалом наш процес. Заточено саме під Kanban. Кожна задачка, кожний реліз, все у вас буде перед очима. Буде давати максимум можливостей. Це для того, щоб зануритися, подивитися, розкласти, і проаналізувати, визначити, якщо ви знаєте, що робити далі, щоб покращитися.

Flow efficiency, повертаючись до метрики. Flow efficiency – відношення активного часу розробки до всього циклу розробки в нашій системі. Це те, про що я говорив, треба налаштувати на початку самого Kanban. Ділимо всю нашу дошку на активний і пасивний, і очікувальний стан наших задачок. In progress, ready for review. Тобто, in progress – активний, ready for review – пасивний. Ну і все, що ready, все, що очікує – це пасивні статуси, які в результаті нам треба дивитися, аналізувати, щоб їхній час зменшувався для покращення нашого flow efficiency. В літературі пишуть, що все, що більше 40 – це добре, 50-60 – огонь. Але, знову ж таки, індивідуально, для кожної команди. У нас є випадки різного характеру. Тому тут це індивідуально. Але дивитися дуже корисно на цю тему. Це flow efficiency, але в розрізі самого Neyv. Бачимо стовпчики – це кількість задач з їхнім flow efficiency. Бачимо там графік. Можна подивитися на кожному статусі, скільки часу вони провели. Там точечки – це або окремі задачі, або в одній точці декілька. Коротше кажучи, це потужна тема.

Throughput. Чому throughput? Я б тут сказав, що ми його таргети, звісно, не ставимо по throughput,. Але дуже важливо дивитися в розрізі, скажімо, в комбінації. Flow efficiency і throughput, Чому? Тому що це банальна тема. Запускаємо на команду 15 чоловік дві задачі. Flow efficiency буде підніматися до 100%. Команда буде відпочивати. З однієї сторони добре для команди, для бізнесу – питання. Тому спостерігаємо за throughput, при налаштуванні flow efficiency, для того щоб у нас баланс нашої ефективності і закритих задач не змінювався. Lead time, cycle time, різні. Я буду говорити про cycle time, тому що це вимірюється в рамках в рамках самої системи, від початку задачі in progress до продукту. При цьому ми міряємо, який cycle time середньо для всіх задач в системі, так і cycle time релізів. Для того, щоб знову ж таки дивитися по балансах. Воно корелює одне з одним, але цікаво дивитися, якісь outcome можна виявити.

Work in progress. А саме управління лімітами work in progress. Тобто ми знову ж таки за методологією Kanban не вводимо нічого нового, поки не пропихнемо все, що у нас назбиралося на дошці. Дивимося за цим, слідкуємо. Досить багато кейсів спокуси затягнуть побільше в папарелі зробити багато. Ні до чого хорошого, як правило, не призводить. Хоча паралелізм можна запускати, він є в деяких випадках досить активний. Але загалом в системі повинна бути ця стабільність, яка регулюється в тому числі лімітами на work in progress. Що далі? Далі, як це все в принципі натягується на продуктове планування. Якщо ми знаємо наші цілі, наші метрики, і якщо ми їх витримуємо, якщо вони реалістичні, давайте, скажу, відмітку: всі картинки взяти з інтернету. Тут це джировська тулза Bigant. Знову ж таки, трохи навантажена функціоналом, але дає такий фишай, щоб зрозуміти, над чим зараз в конкретний момент працює компанія і що ми запланували надалі. Bigant. І повертаючись до метрики планування. Знаючи всі ці теми цикл-таймом нашим, цикл-таймом релізів, ми можемо плюс-мінус з якимось одним релізом максимум, якщо у нас цикл-тайм релізу два тижні, ми кажемо, на оцю ініціативу ми покладемо два-три тижні. Тому аплається шліфувати, в нашому випадку ми це ще шліфуємо, є точки для зон росту, але загалом працює непогано. Покажемо далі.

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

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

Чому? Тому що там буде дуже маленька вибірка, це все ж таки статистика, повинна мати повний набір даних. Щоб зрозуміти, де ми, в принципі, як наші експерименти впливали на покращення, чи на погіршення. І якщо подивитися на Work in Progress – тренд качає, але падає. Кількість item в In Progress знижується. Throughput залишається більш-менш незмінним. У листопаді я міряв не в кінці місяця, тому є зниження. Cycle time знижується. Тобто ми частіше видаємо релізи, завдання, і швидше доносимо якісь value результи нашим юзерам, клієнтам. Flow efficiency – тренд на зростання. Експерименти і те, що ми там впроваджували, працюють. Kanban завівся, працює, покращувати точно можна далі і треба.

Згадаємо про принципи Kanban. Ну, так. Там цифри я абсолютно не ставив. Але в результаті цикл релізів зменшився до 2,5 разу. Flow efficiency в деяких командах – у 2 рази. І там ще є заділ на зростання дуже потужний. Далі ми цю всю історію з Kanban будемо дивитися на скелінгу вже на більш стратегічний рівень, на планування кварталу. І саме головне на сьогодні – Рій помсти. Буду конкурувати з колом. Хай це буде саме наша потужна конкуренція. Донатимо. І закінчимо набагато раніше, на 3 хвилини раніше. Готовий відповісти на ваші запитання.