Перехід продуктових команд зі Scrum на Kanban: реалізація, метрики, висновки

Всім привіт! Мене звати Каріна Гуліда, я project manager. Не кожному на цій посаді доводиться організовувати перехід 12 продуктових команд зі Scrum на Kanban в межах однієї компанії. Але саме такі труднощі та успіхи всього процесу випали на мою професійну долю в Uklon.

В цій статті я розкажу, як понад 100 спеціалістів відмовились від спринтів на користь підходу «витягання карток з черги». Стаття буде цікава всім, хто планує або задумувався про переведення команди зі Scrum на Kanban.

Які проблеми хотіли вирішити міграцією на Kanban

В першу чергу, ми хотіли зменшити time to market — кількість часу від початку роботи над новою ініціативою до доставки її в прод. Певну частку (інколи досить вагому) займав час на очікування через появу вузьких місць у робочих процесах. Перехід на Kanban дозволив візуалізувати ці bottlenecks і надалі сфокусуватись на їх усуненні або хоча б скороченні періоду очікування.

До переходу на Kanban ми використовували методологію Scrum. Певні артефакти і обов’язкові ритуали були для нас неефективними. Далі спробую пояснити, чому.

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

➡️ З одного боку, ми маємо продуктовий roadmap, що зображує, які стратегічні задачі стоять перед кожною командою.

➡️ З іншого боку, ми повинні досить швидко реагувати на зміни ринку, укріплювати конкурентоздатність продуктів, що призводить до того, що пріоритети ініціатив/ епіків/ задач можуть не один раз змінюватись.

Ритуали формування і досягнення цілей на спринт здавались нав’язаними та надлишковими, адже сформовані цілі вже були зафіксовані в продуктовому плані. «Декомпозиція» цілей на спринти не додавала прозорості процесу, а тільки забирала цінний час команди на оцінку задач в story points, проведення регулярних мітингів, які часто були формальним слідування підходів і правил Scrum.

Етапи переходу, оптимізація процесів, переваги Kanban на власному досвіді

Важлива складова переходу на Kanban — перебудова робочого процесу. У нас з’явились активні стани роботи команди (active states) та стани черги (queue states). Впровадження станів черги в наші процеси дало змогу ефективніше керувати роботою команд і підсвітило можливості для вдосконалення, яких раніше видно не було.

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

Візуалізувати всі ці проблеми допомогли статуси черги в робочому процесі: Ready for Development, Ready for Review, Ready for QA, і т.д. Окрім підсвічування вузьких місць, новий підхід знімав навантаження з команд. Задачі витягувались зі стовпців черги поступово, кожний учасник команди залишався зосередженим на поточній тасці.

Вимикалась багатозадачність. Помітила, що коли таски безперервно почали переходити з однієї фази процесу в іншу, це підвищило ефективність взаємодії команди. Значно зменшилась кількість питань в чатах, на зустрічах. Kanban дошка команди стала єдиним джерелом правди і актуального статусу тасків.

До плюсів Kanban також віднесу обмеження кількості задач, що знаходяться в роботі — WIP ліміт (work in progress limit). Оптимальний WIP-ліміт для команди залежить від кількох факторів. Різноманітні рекомендації зводяться до того, що потрібно встановити обмеження на рівні, коли кожний учасник команди тримає в роботі 1-2 задачі.

Розділення всього процесу розробки на активні та пасивні фази дає можливість вимірювати додаткові Kanban метрики. Адже неможливо покращити те, що неможливо виміряти.

Ефективність потоку (Flow Efficiency) — один із ключових показників, який допомагає знайти можливості скорочення часу очікування. По суті це співвідношення між активним часом роботи команди і загальним. Що вища ефективність потоку, то швидше й легше виконуються завдання.

Джерело: getnave.com

Від оцінювання задач до прогнозу термінів виконання

Ще одним ключовим показником у Kanban є Cycle time. Ця метрика показує, скільки часу задача перебувала в розробці від моменту, коли над нею почали працювати, до моменту, коли вона пройшла фазу доставки.

Враховуючи середній Cycle time, кількість задач, пропускну спроможність кожної команди, ми почали будувати більш точні прогнози, які спирались на унікальний досвід певної продуктової команди. У результаті, відмовились від оцінки задач в годинах або story points. Адже оцінки за визначенням не є точними і на них впливають численні фактори ризику. Kanban пропонує прогнози майбутнього на основі даних, заснованих на ймовірності, використовуючи лише минулий досвід.

З чим виникали складнощі

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

Помилка, яку припустили на самому початку: недостатньо замотивували команди на зміни. Не було достатнього і чіткого пояснення цінності переходу на Kanban. Як наслідок, учасники команд недостатньо слідували правилам, які передбачала система. В деяких командах був відсутній контроль за метриками, тобто всі сигнали про проблеми просто не помічались і позитивних змін в робочих процесах не було помітно.

За допомогою командних ретроспектив ми почали виявляти недоліки і поступово виправляти їх. Сьогодні налагоджувати роботу в командах допомагають Engineering managers (вони як раз займаються контролем робочого процесу в командах). Це новий юніт, фактично, нова роль, поява якої в Uklon плюс-мінус збіглась в часі з переходом на Kanban.

Kanban Analytics

Існує кілька специфічних для Kanban діаграм, які допоможуть керувати процесом роботи команди. Оскільки активно ними користуюсь, коротко опишу їх користь:

  1. Cumulative Flow Diagram — один з найкорисніших аналітичних інструментів для управління робочим процесом. Він забезпечує стислу візуалізацію найважливіших показників вашого робочого процесу. Головна мета діаграми — продемонструвати, наскільки стабільний потік, і показати, де зосередитися, щоб зробити процес гладкішим та ефективнішим.
  2. Cycle Time Scatterplot — показує, скільки часу потрібно для виконання окремих робочих елементів на дошці Kanban. Діаграма візуалізує час виконання завершених задач, допомагає знайти вузькі місця, відстежити тенденцію, як змінюється Cycle Time команди.
  3. Cycle Time Histogram — показує загальний розподіл часу виконаних завдань, тобто скільки задач з різним Cycle Time було виконано командою. Налагоджені процеси і злагоджена робота команди будуть давати в результаті більшість задач з плюс-мінус однаковим Cycle Time. Стабільний темп роботи команди допомагає будувати надійні прогнози.

Висновок

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

Перехід на Kanban зробив наші процеси більш гнучкими, а команди — готовими реагувати на зовнішні і внутрішні зміни. В тому числі завдяки Kanban після початку повномасштабної війни в Україні, ми змогли швидко змінити пріоритети у наших продуктових планах, викреслити не актуальні на той момент цілі, і в досить стислі терміни випустити нові проєкти «Волонтер» і «Евакуація» на базі наших продуктів.

Відмова від спринтів, перехід на Kanban і впровадження підходу «витягування карток з черги» дозволив бізнесу, насамперед Product owners, змінювати пріоритети роботи до моменту її початку. Це ефективний спосіб залишатися готовими до змін ринку, оскільки команда завжди працює саме над тим, що найважливіше та найпріоритетніше на даний момент.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почитайте про SAFe, для такої кількості команд це якраз те що треба.
+ квартальні планування як частина процесу.

У результаті, відмовились від оцінки задач в годинах або story points.

Це велика помилка, пофіг скрам у вас чи канбан. Це дасться взнаки через 1-2 квартали.
Як ви можете скласти план що виконається на квартал без оцінки в годинах/SP? Відповідь — однозначно ніяк.
При плануванні на квартал ліди/архітекти поверхнево оцінюють роботу, часто без залучення команди (яка і буде цю роботу робити).

сформовані цілі вже були зафіксовані в продуктовому плані. «Декомпозиція» цілей на спринти не додавала прозорості процесу, а тільки забирала цінний час команди на оцінку задач в story points,

Коли команда оцінює щось то це не тільки скрам покер, вони вникають в те що треба зробити, обговорють вимоги, задають питання, обговорють технічний дизайн. Це все одно треба буде зробити, тільки тепер це буде робитись під час роботи над тікетом (що сильно знизить ефективність).
+ при відсутності естімейту і спрінт дедлайну втрачається мотивація команді напрягтись і закінчити те що пообіцяли на ці два тижні спрінта.
Тепер у вас залишилось тільки напрягтись і закінчити що пообіцяли на 3 місяці, ну а в останній тиждень роботи за місяць не зробиш(

А ви пробували SAFE в роботі? Якого успіху вдалось досягти? З якими складнощами зіткнулись та чи побороли їх?
Якщо не секрет, то яким чином?

А ви пробували SAFE в роботі

Так, працював більше 3-ох років на позиції ліда команди.

Якого успіху вдалось досягти? З якими складнощами зіткнулись та чи побороли їх?

Найбільша проблема при великій кількості команд — це вирішення залежностей. Тобто команді А треба щоб було готове шось від команди Б, команді Б треба людино-тиждень девопса, і так дальше.
SAFe це ± вирішує. Результатом квартального планування будуть сторі/таски для кожної з команд уже розкидані по спрінтах. Щось типу цього www.scaledagileframework.com/...​4/07/F3-Program-Board.png

І якщо команда Б не змогла в першому спрінті віддати те на що залежна команда А, то вже ясно що пішло не по плану => включаються менеджери щось робити (викинути якусь іншу фічу, повідомити клієнтам, заплатити за овертайми, ...).
Чим раніше відомо що щось йде не по плану тим більша ймовірність це виправити чи зменшити шкоду.
Ще один плюс це само по собі створення кількох рівнів деталізації роботи.
Для команди борда з її тасками/цілями, для менеджерів вже назви фіч і залежності (лінка що я вище скидав).
Для бізнесу — список фіч, ціна в SP, ризики і дати коли буде готове.

В мене ніколи не було щоб початковий квартальний план приймався до роботи. Після першого дня планування все завжди мінялось бо бізнес бачив що для фічі А треба 2 місяці а менш корисна фіча займає 2 тижні то краще перше зробити її.

З мінусів — важче впихнути чисто технічну роботу, фокус на бізнесі.
Квартальне планування займає кілька днів + 1-3 тижні перед плануванням для лідів/сіньорів розбиратись з фічами і естімейтити їх.

ІМХО, методології для менеджменту це як патерни для девелоперів. Самі по собі вони проблем не вирішують але дуже допомагають при розробці бо це рішення типових проблем у ефективний/загально прийнятний спосіб.

П.С. я не агітую тратити тисячі $ на SAFe консультантів, почитати книжки/відео і відправити активіста/активістку на курси буде достатньо)

Дякую за розгорнуту відповідь. Не дуже часто я зустрічав людей в чийому досвіді SAFE спрацював. З недоліками згоден на всі 100%.
З мого власного досвіду (не Уклон) SAFE програва важкістю планувать, що при зміні настроїв в бізнесі часто зводили на нуль все планування.
Можливо питання в якості проробки рішень заздалегідь та ступеню невизнченості в плані яким чином віирішити задачу.
Останнє питання — якого розміру PI? та розміри спринтів, що практикувались?

якого розміру PI? та розміри спринтів,
що практикувались?

PI — 3 місяці
Спринт — 2 тижні

з’являється такий собі ватерфол довжиною 2-3 місяці. Саппорт менеджери в шоці, впихнути реквест від кастомера на покращення чогось стало набагато складніше.

ну і дрібниці типу не беріть відпустки на час планування

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

Берутся з запасом) у нас залежностей вiд iнших майже нема, тому все трошки легше, нiж у iнших команд.

Є така чудова книжка Zombie Scrum називається, дуже схожа на вашу ситуацію з описаного вище і з коментарів, звісно можу помилятись бо всю картину в короткій статті не побачиш, але рекомендую почитати.

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

Як до речі реагують розробники на безкінечний процес розробки в якого немає ні початку ні кінця? Чи ви фокусуєтесь на релізах? Чим задовільняєте спрагу до відчуття accomplishment? Я розумію що це залежить від людей і для кожної з методології потрібні люди з відповідним mindset’ом.

Коли працюеш в українській компаній розробляючи додаток яким користуються мільйони співвітчизників, то відчуття accomplishment буає навіть частіше за релізи.
Knaban прискорює і реалізацю замовлень і розв’язок залежностей між командами і вирішення проблем в проді. До речі SCRUM це не покриває, так само як приоретизацію помилок.
Доречі дякую за назву книги, подивлюсь.
Зі свого боку, застерігаю не покладатись цілком на книжки. Життя має високий ступень різноманітности. Притягнути можно за вуха що завгодно. Особливо в ретроспективному сягненні, до якого людський мозок дуже пристосований. Але ж вирішенню завдань сьогодення ретроспективний аналіз не дуже сприяє, але допомагає в контрольованому процесі.
Більше про те, як працює наш мозок можно дізнатися з книги «Мислиння швидке та повільне» Д. Канемана.

Оце була постановка задачі

В першу чергу, ми хотіли зменшити time to market

А це висновок:

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

Перехід на Kanban зробив наші процеси більш гнучкими, а команди — готовими реагувати на зовнішні і внутрішні зміни. В тому числі завдяки Kanban після початку повномасштабної війни в Україні, ми змогли швидко змінити пріоритети у наших продуктових планах, викреслити не актуальні на той момент цілі, і в досить стислі терміни випустити нові проєкти «Волонтер» і «Евакуація» на базі наших продуктів.

Відмова від спринтів, перехід на Kanban і впровадження підходу «витягування карток з черги» дозволив бізнесу, насамперед Product owners, змінювати пріоритети роботи до моменту її початку. Це ефективний спосіб залишатися готовими до змін ринку, оскільки команда завжди працює саме над тим, що найважливіше та найпріоритетніше на даний момент.

Пані Project Manager, Ви нічого не забули? :)

Добрий день, Pavel!
Так, дійсно про вимірювані показники в висновках я не згадала. Якщо казати про time to market, то його значення покращилось, в різних командах, від 2 до 15%

від 2%? А яке у вас середньо квадратичне відхилення для цієї метрики між спрінтами було?

В чому питання: якщо ви побудували процесс, в котрому результати від ітерації до ітерації настільки стабільні, що можна відстежити покращення у 2% — то ви для мене Бог :)

Десь два, а десь цілих 15% , але не мінус. 350% це коли проект чи програма знаходиться в глибокій дупі і ttm був десь на рівні безкінечності. Тут С левел заводять грамотного менеджера, таку собі «маркізу» (зазвичай затягує із собою архітектчиню з якою давно працює), організовує процесс, дає прочухана кому треба як в середені так і у замовника і воно починає працювати. От правда за це грамотних менеджерів ненавидять. Якщо С левел їх не захищають то дуже швидко з проекта чи програми їх нікчеми виживуть.

Не дуже зрозумів, що пан хотів сказати.
Але нарахунок «нікчем» — з мого досвіду проблеми рівня «всі процеси в дупі» йдуть не з джунів та не з прибиральниць. Й насам перед треба прибрати з команди вплив того самого С-левелу що й створювало проблеми. А далі — додаємо прозорості, лагідно обертаємо усіх метриками чи залучаємо сторонніх специалістів до рєвью результатів — та вичіщаємо команду (якщо буде потреба). Найскладніше, якщо в команді є дуже токсична але дуже фахова людина("так, сволота, але на ньому все тримається«).

P.S. Якось я за одну ітерацію підняв перформанс команди у два рази: ми просто стали оцінювати усе в х2 SP. Й усі були задоволені :)
Так що без додовання методик вимірювання, похибки, контролю впливу інших факторів — усі ці «від 2 до 15» — то лише для тосту на корпоративі

Дивіться, те що я тут читаю це була чистої води спіраль water-scrum-fall www.plutora.com/blog/water-scrum-fall. Тобто відвертий мікс з підходами до розробки програмного забезпечення. Чому так ? Бо усе контролює, включно с бюджетами і строками такий собі документ під назвою product road map, за яким майже завжди мається на увазі діаграма Ганта. Певно, що підхід не спрацював, власне як завжди images.app.goo.gl/3friK6FzJq1tozkt5 З оцінки задач в годинах або story points мені вже навіть і не смішно, занадто багато разів я це бачів на власні очі. Думаю про вимірювання Velocity, DoR, DoD та estimation poker не варто і питати, усе зрозуміло і так. Так само і про back log grooming та пріорітезацію за Moscow чи Kano. А чи став другий підхід справді за принципом бережливого виробництва Lean ? Чи присутні принципи Кайдзен ? Скажімо скільки задач було створено за претендентами на продакшені, чи end-to-end тестування? Чи були задачі зроблені за ініціативою розробників, чи існує система на ретроспективах де подаються пропозиції з покращення виробничих процесів чи вирішення проблем? Хто може подавати таки пропозиції — а чия справа писати код чи тестувати вчасно ? Чи розбирає менеджмент і команда ці пропозиції і чи перетворюється вони на задачі? Міністерство оборони США зробило такий собі список аудиту для само перевірки thenewstack.io/...​n-how-to-detect-agile-bs

Відповідь буде неочікувано короткою. Якщо не робити на ретро те що написали Ви, то це нібито і не ретроспектива зовсім. Підхід поскардитись на несмачну каву на холодні булочи не про нас.

Цікавенько так все.
1900 роки. Генрі Форд впроваджує фундаментальне. З нуля. Ще ніхто не знає як все має бути.
Генрі Гант розробляє свою діаграму і тп. Календарно-сіткове планування. Всім вистачає.
Будуються фабрики-заводи-параходи. Всілякі теоретики-економісти ще десь курять бамбук.
Вже потім, по реальних впроваджених фундаментальних речах, вони висунуть свої теорії.
Проходить деякий час. Старе фундаментальне посипається пудрою, мішурою і блискітками.
На світ появляються Agile-Scrum-Kanban.
Дивно, як же до того все робилось без них ;)
Ви мене дивуєте. Вам реально-практично не вистачає для продуктивної роботи в ІТ саме цих штучок і тому потрібно роздути персонал та навантажити ще чимось колектив ? ;)

Лірика: Великий промисловий об’єкт. Ми переходимо на ISO 9001(удосконалюємо систему менеджменту якості). Приїхали люди. Будуть нам допомагати.
Декілька тижнів об’єкт лихоманить від паперового шквалу, в т.ч. і відділ ІТ.
Ми масово друкуємо різні папери, пакуємо це в папочки і ліпимо красивенькі кольорові ярлички на папочки. Результат: ми отримали красивенькі папочки в шафці, об’єкт працює як і працював. Зате продукція вже має знак ISO 9001.

Ви мене дивуєте. Вам реально-практично не вистачає для продуктивної роботи в ІТ саме цих штучок і тому потрібно роздути персонал та навантажити ще чимось колектив ? ;)

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

Співчуваю. Пройти через цей біль сертифікації ISO.
А без Agile та SCRUM робироль, барато. Була навіть маленька епоха waterfall.
Проте питання від тих, хто платить гроші — як отримати не автомобіль. Бо з ним все більш-менш зрозуміло.
Питання — як отримати те, що начебто є продуктом інжинерії але з додаванням хаосу творчості.
Якщо для вас це не має складності — вітаю. Все ще попереду.

То спогади давно минулих днів. Маю надію, що зараз вже все стало інакше.
Ідеально-мрійливо хотілось би почути після впровадження новітнього:
— програмери стали якісніше кодити, менеджери стали краще продавати продукт;
— код став значно якіснішим і розробники перестали брати з клієнта кошти за виправлення своїх же помилок;
— Генеральний періодично запитує — ну, що ми додатково заробили після впровадження новизни? Коли вже можемо розганяти тестерів ? Ми ж тепер даємо якісний і безпомилковий код, то нащо вони нам ?

Цікаво)
Мав нагоду спостерігати за рухом досить великої інжинірингової організації як раз в інший бік — від Kanban підходу та No estimation до іттеративного Scrum-like процессу з оцінюванням. Для чого? Мати більш керованний і прогнозованний процес делівері. Правда у них не було такого фактору як війна.
Дійсно, в часи коли реальний горизонт планування — максимум неділя-дві і не знаєш коли і куди завтра калібр прилетить — Kanban більш кращий спосіб організувати процес.

У мене є два питання:

1. У вас є якись формальний ліміт скільки одна задача може бути в In progress? Умовно кажучи чи може задача «Зміни колір кнопки» бути в In progress декілька днів 🙂 ?

2. Як ви вірішуєте проблему коли один дев наприклад систематично витягує прості карточки із ToDo а іншим залишаються більш складніші?

1. Насправді ми не викорисовуємо Канбан як підхід «взяв задачку і роби її, поки не буде зроблено». Ми дивимось на Cycle Time. І це не можливо без естімейту.
Тому задачі декомпонуються на меньші таким чином, щоб кодування рішення не займало більше 1-2 днів. Додатково до цього кожна команда планує релізи.
Оцінювання така сама практика як і ретроспективи. Вона не є винятковим атрибутом SCRUM, а більше невід’ємною частиною будь якого планування.
2. SCRUM чи Kanban відрізняє тільки підхід до взяття в роботу тікетів членом команди.
І як на мій досвід, саме SCRUM не обмежує брати те що до вподоби з ToDO тому що саме там і є скоуп спрінту. Єдине чим користуються члени команди це ціль спринта. В протилежність цьому Kanban жостко лімітує брати першу найвищу.
Тому описана ситуація є порушенням базового принципу Канбан top-right, при якому саме місце картки на дошці визначає її приоритет. І найприоритетніші залачі повинні братися в роботу коли «звільняються руки».
Як на мій смак, Kanban більш гнучкий в реакції на фідбек, бо дозволяє змінити рішення тут і зараз, ане чекати кінця спрінта, чи взагалі відміняти спринт. При цьому повністю захищаючи каденцію релізів.

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

Якщо поділити зони відповідальності на проекті (module ownership), то швидкість розробки збільшиться в рази.

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

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

Тому, щоб проблеми не було потім — ви її робите одразу!

За умови, що над архітектурою — тобто розділенням функціональності на чіткі логічні одиниці (модулі, мікро-сервіси тощо) та описом взаємодії між ними ніхто не працював. В Барселоні з 1882 будують храм Саграда Фамілія, історія його будівництва це по суті ода більшості програмних проектів. Перше — не було чіткого бюджету і строків здачі, друге було змінено зодчого по ходу будівництва, трете проект принципово перероблявся декілька разів, а найголовніше — взагалі не робились проектні креслення, тільки ескізи. Після смерті Гауді, будівництво було дуже на довго заморожено, бо він тримав в голові кінцевий результат і не делегував. Результат — будівництво, що йде 140 років, хочь і дуже красивої будівлі, що є однією з найвідоміших визначною пам’яткою Барселони. В програмних продуктах ми майже завжди має саме таку ситуацію. Сініори не проектують софт, тримають усе у голові, а тех лід не питає з них дизайну за здалегіть, часто робляться принципові переробки тощо.

Я чого спитав стосовно In Progress) Тому що в статті сказано що команди відмовились від естімації:

У результаті, відмовились від оцінки задач в годинах або story points. Адже оцінки за визначенням не є точними і на них впливають численні фактори ризику. Kanban пропонує прогнози майбутнього на основі даних, заснованих на ймовірності, використовуючи лише минулий досвід.

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

Ця «історична» складова є тим, що я ніяким чином не міг як розробник ПО зрозуміти. Як допоможе швідкість імплементації нового алгоритму сорутвання опомогти в розв’язанні задачі по баласуванню графа. Тим не менше SCRUM євангеліє на цьому базується.
Для мене книгою, яка поставила крапочки над і стала «Чистий Agile» Роба Мартіна.
Єдине де «історичні данні» допомагають є виконання проекту, який побито на етапи. І данні іллюструють наскільки успішним є прогрес в проекті. Не більше.
Все інше «від лукавого». Вся динаміка ламається в той час, в який команда стикається з невідомим. І ніякий Agile не дає відповіді, скільки часу може зайняти розв’язання задачі.

Як завжди питань в нас більше ніж відповідей. Тут можна робити аргумент — стикнулись із невідомим, робіть досліди і дослідно-конструкторскі роботи тобто spike. Таким чином можна буде прояснити справжній масштаб робіт. Тобто деякі відповіді на деякі питання Agile все-таки має.

А ось стосовно spike, з власного досвіду, у Канбан швідкість прийняття рішення та процесс виглядає набагато кращим ніж в SCRUM. В більшості випадків spike за годину не виконаєш. А в спринті вже весь час зайнято і для планування невідоме не готове.
Що каже SCRUM — беремо spike. І? Ну звичайно ж тільки його беруть у спрінт. Бо відповіді ж не має. І зазвичай його вирішують швидше за інші завдання. Почитали, погуглили, зробили прототип швиденько. І вже в настйпний спрінт беремо задачку.
Нібито все чудово, але коли клієнт побчить нову фічу? В кращому випадку через місяць, бо зайняло 2 спринти.
Що робить Канбан. Він робить spike та слідом задачку по результатам spike (research). В загалом займє від 4- х днів до тиждня. Тобто в рази швидше.
Так, з точки зору навантаження на product owner Канбан вимагає майже щоденної роботи над приоритезацією. Але ж це й дає гнучкість бізнесу в вирішенні «хотєлок» одну за одній.

Дякую, за запитання і дискусію!
Коли писала про переваги відмови від оцінки в story points, в тому числі мала на увазі, що з часом, коли це вже 100+ спрінт — око замилюється і оцінки стають чимось формальним і усередненим.
Зараз використовуючи метрику Cycle Time Histogram, ми маємо не просто середнє значення скільки часу витратимо на задачу, а ймовірнісний прогноз, з різними рівнями/відсотками «довіри» що цей прогноз реалізується. І ці показники побудовані на історичних даних певної команди/продукту. Команді залишається декомпозовувати задачі до співставного розміру.
Ну і звісно це починає коректно працювати, коли команда використовує Kanban 3+ місяців і накопичила достатньо історичних даних.

Там по іншому зайшли. Планувпння, що робить команда — це інструмент за допомогою якого команда : по перше — починає детально розбирати завдання, не береться за те, що не розуміє і не з’ясовує усі моменти по ходу спринта. Уточнення всеодно неминучі, задача поступово прийти до більш точних оцінок. По друге у Scrum робиться така річь як ціль на — ітерацію (спрінт). У бізнеса існує три типи задач — нагайні, дуже нагайні, і " що і скільки потрібно щоб це було зроблено щонайшвидше«. До чого призводить розмиття цілей постійним викидом нових задачь, коли робиться розробка нового програмного продукту, або нової функціональності? Її поставка постійно відкладається на потім. Скажімо термінові фікси багів на продакшені попередьноьї версії продукту. Тому і виділяється проміжок часу, ітерація відома як — спрінт, та на нього накладається конкретна мета, рекомендується дати назву такому спринту. Дуже поганим показником є ситуація коли команда чи менеджмент, не може дати явну назву, яка відповідає цілям цього спритна. Добрі назви скажімо — Product Detail Page, Landings, Dashboard тощо. Погані — Sprint 5, Bard Simpson, Astalavista Babe (назви справжні з бойових срамів) тощо. На виході спрінта очікується демонстрація результатів бізнесу чи користувачу і потім корекція і уточнення з врахуванням їх вимог, якщо щось не влаштовує. Таким чином команда концентрується саме на головній меті, вчиться не брати на себе більше роботи ніж вони можуть зробити в рамках однієї ітерації, а також виконувати цілі на спрінт. Зазвичай перші спринти провалюються, тобто за результатами ціль не було виконано. Це неминуче породжує первинний конфлікт. Тому команда обмозговує на ретроспективі наступні питання. Що було добре і потрібно продовжувати? Що було погано і потрібно змінити? Які є ризики, яким чином їх невілювати ? Хто візьме на себе відповідальність за конкретний ризик і прийме відповідні міри (action item) щоб його невілювати. Тобто команда і менеджмент — не дають бізнесу постійно вкидувати нові завдання які не стосуються головних цілей і таким чином не виконувати цілі ітерації і проекта загалом.
На етапі підтримки ПЗ, пріоритетом для бізнесу є на сам перед робота існуючої системи, яка обслуговує існуючих клієнтів і приносить гроші, а вже потім розробка функціональності та покращення. Підхід з ітераціями в такому випадку зазвичай підходить погано, саме тому команди з підтримки обирають саме Kanban. Це простий процесс з цілями на основі претендентів. Базис у пріорітетах, скажімо blocker-ри (відмова бази данних на продакшені, перехід на резервні сервіси чи термінові зміни у бізнесі) робимо в першу чергу, critical (закриття секьюріті вразливостей, перформанс ботлнеки, втечу ресурсів чи данних тощо) — робимо в другу чергу, minor (звичайні баги) в третю, та low — (різні improvement-и та автоматизації) в четверту. Процес дуже простий, робимо доску (kanban bord) в якій усі задачі скирдуєм в беклог з лівої сторони, обираємо задачі і найвищім пріорітетом та перемішуємо їх по конвеїру — скажімо : «в розробці, робить Василь», «в тестуванні, робить Ганна», «в розгортанні, робить Петро», «покривається автоматичний тестом, робить Наталка». Далі вже менеджер збирає статистику, щоб відповісти на наступні питання. В якому стані проект, скільки є наявних задач і з яким вони пріорітетом? Який критичний шлях — від початку прицендента до його усунення ? Чи вистачає ресурсів та людей, що можна зробити щоб задачі виконувались швидше, чи є занадто загружені роботою люди? Чи є люди які навпаки в простої ? Чи може використовуватись ця борода в скрамі в середені спрінта? Так і це дуже зручно, особливо коли справа йде про не кросс-функціональні команди, тобто усі не можуть робити усе, хоча ми вже йдемо на територію SAFe з PI та Scrum of Srums.

Радий що з’являються статті не тільки переходу на SCRUM :D — бо в нього дійсно дуже невелике вікно застосування)
Також круто що були EM які змогли підхопити процесс.

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

Наприклад:
В беку свій великий беклог фіч, і з’являється пріоритетна фіча у мобілках, але їм потрібен час беку для реалізації.
Хто і як буде розрулювати/рухати пріорітети беку, та за якими показниками?

Так. Гарне питання до речі. Чи може в них фіча тімс?

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

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

Наприклад в цій проблемі, як найменше, задіяні проджект(и) (контроль та розподілення ресурсів), продакт овнер(и) (пріоретизація по продукту), ліди команд (естімейтінг, поточне навантаження). І вся ця кодла повинна домовитися як вони будуть опрацьовувати такі ситуації, та ситуації «необхідності змін процесу» )

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

Процеси розміщення фіч на роадмапі, плюс-мінус у всіх однакові. Але я розумію, про яку біль в своєму прикладі ви говорите) І спробую максимально просто описати наш варіант її вирішення:

У кожної фічі («ініціативи» на нашій термінології) є свій цифровий, унікальний пріорітет «score». Ініціатива отримує свій score перед початком планування квартала. Право задавати score мають CTO, Architect і CPO (+ частково VP of Product) по затвержденому алгоритму. Тому коли настає ситуація із вашого прикладу — команди дивляться на score сторі чи таски, чий score вище — той перший і йде в роботу.
Звісно score протягом кварталу може змінюватись, як і будь-які пріоритети — але це вже інша історія))

Дякую, приблизно те що і очікував почути :)
Єдине підпитання, якщо не секрет, що використовується для скорінгу? окрім потенційного прибутку)

Ми щороку формуємо річні OKRs. Objectives, як стратегічні цілі, включають вимірювані показники — key results (і дійсно це не тільки прибуток, але і наприклад, стабільність комплексу (avg uptime) умовно, технічна ініціатива яка додасть надійності при великих навантаження — з високою вірогідністю отримає високий score, тому що коли комплекс лежить, прибуток не те що не зростає — він нульовий).
Всі фактори, які впливають на досягнення key results враховуються в скорінгу

Дякую що поділились трішки досвідом. Теж впевнений що канбан є більш адаптивний в реальних задачах для більшості бізнесів.
Чи могли б розкрити деякі моменти:
1) які саме артефакти не зайшли в скрамі? Адже наприклад теж ретро ви зберегли. Може сам скрам не був ефективно реалізований? Є скрам майстер (нормальний)?

2) у вас повністю крос функц команди? Як ви слідуєте принципу канбан, що кожен член команди може замінити іншого, нехай хоч і не на 100%?
В іншому разі це не зовсім про канбан

3) Скільки часу зайняв перехід на канбан?

4) Залишились квартальні роадмапи?))

Спробую допомогти Каріні, сформулювавши власний погляд на SCRUM та реалії розробки ПО в сьогоденні.
1. З власного досвіду, SCRUM не дуже пристосований до змін. Він добре працює на великому проєкті, де є великий ступень незалежності від інших команд і більшість змін йде до продукту що розробляється.
У разі змін приоритетів в розробці(не вимог до функціоналу, а безпосередньо змін) він перестає працювати. Закритість спрінтів вимагає багато узгоджень та лишає бізнес можливості швидкої реакції на навколишній світ.
Помилки знайдені після релізу взагалі більшостю SCRUM адептів віддаються на шось абстракте і не мають ніякої регламентації в фреймворку (начебто їх не існує). Не можливо чекати наступний спрінт, якщо в вас «лежить» прод або нова фіча вимагає швидких змін.
Ось чому, якщо ви розробляєете ВЛАСНИЙ продукт з різноманіттям функціоналу, то SCRUM більше заважає.
І цілі спринта разом з естімейтами на різноманіття доробок більше виглядають як карго культ і не сприяють бойовому духу команди.
Стосовно ретроспективи. Цей інструмент є корисним в будь якому фреймворці. Так само як і Канбан дошка, без якої SCRUM не працює, але ж вона все ж таки Канбан а не SCRUM. Тому я б рекомендував її всім хто спрямований на покращання процессів на регулярній основі.
2. Стосовно кросфункціональності. Все залежить від ступеню гранулярності завдань. Якщо доходити до рівня «додати кнопочку на цю формочку», тоді треба мати anykey-щика розробника. Але якщо залишатись на рівні story з ухилом до досвіду користувача, то задача в залежності від наявних ресурсів може виконуватись поступово через розширення тієї частини функціоналу де є вільні руки в канбан. Є фронтенд — доробляємо частину фротенду. Є бек — робимо необхідні зміни до беку. Якщо грамотно пикористовувати принцип архітектури «відкритий до розширення, закритий до змін» то конфліктів з Канбан не виникає. Узгодження контрактів та версіність інтерфейсу є одним з інструментів в досягненні успіху.
3. Скільки часу зацняло? В середньому на адаптацію треба від місяця до трьох. Це для того, щоб прилаштувати процеси. Дуже важливо слідкувати за розумінням процесу та принципів Канбан усіма учасниками. А все інше вже в руках команд та ретроспектив.
4. Чи лишились квартальні роадмапи? Звісно так. Без планування не існує майбутнього.
Буду радий фідбеку на фідповіді.

Дякую за розгорнуту відповідь.
1) післярелиз то вже як компанія сама налаштує процеси. Є варіанти. Фреймворк це не методологія і він про створення більше, про загальні принципи.
Чекати спринти для швидких змін — так це саме не про скрам.
2) не зовсім зрозумів, але думаю через коменти таке не дуже ефективно дискутувати ). То ціла справа як налаштувати канбан
3) дуже швидко. Гадаю ви про сам перехід на нові правила, а не про повне сприйняття філософії канбану і не про стабілізацію роботи разом з можливістю прогнозувати.

В будь якому разі ваша компанія тільки виграла!
Вітаю 🙂

Дякую Максим, що підключився до дискусії!) Ось на практиці наша командна робота і взаємодопомога)))

Підписатись на коментарі