Дякую за Ваш відгук — радий, що Вам сподобалась стаття!

Я погоджуюсь із Вами, що канбан геть не простий у застосуванні як може здатися при першому погляді некваліфікованих фахівців перед застосуванням. І я погоджуюсь, що канбан метод починається із створення елементарної системи управління робочим потоком задач. Адже його головний принцип — «Start with what you do now» а перша практика — «Visualize the workflow». Далі — він поступово еволюціонує у виважену систему із відповідними принципами, практиками, заходами та ролям. Він адаптивний та гнучкий оскільки дозволяє організації змінювати та налаштовувати як завгодно щоб досягти виробничих/проектних цілей. Питання в тому, що не все організації/менеджери/консультанти/проекти готові до переваг використання метода.

Що дає по ітогу використання канбанів? Waterfall, звісно ж, як би ви не намагалися зробити вигляд, що його нема. Але паралелізований waterfall. І саме система вотерфолу дає найкраще передбачення і строків, і виділення ресурсів, і роздачу приоритетів потокам та квантів часу.

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

Недоліки канбанів: Дурням здається, що оскільки канбан простий ззовні, то він простий і зсередини. Тому не дуже кваліфікований менеджмент вимагатиме, наприклад, щоб знизили всі строки виконання на 15%, під угрозою зриву проекту. Тому, майте напоготові червоний канбан із надписом СТРАЙК, та тупо погрожуйте додати його в потік виконання.

У самому методі є вбудований механізм, який дозволяє системі постійно фокусуватись на саморегуляції потоку, ефективності використання ресурсів (фізичних та людських) а також на часі проходження всього циклу виробництва (lead time and cycle time) із меншою вартістю (delivery rate).
І він називається — ліміти роботи в прогресі (WIP limits). По-перше — вони дисциплінують учасників процесу завершувати почату роботу, зменшуючи ризики та витрати на розробку та поставку фічей. По-друге — практика дозволяє мінімізувати «втопленні витрати» (sunk costs). По-трете — вони дозволяють переміщувати системні обмеження забезпечуючи безперебійну роботу всієї системи, а не окремих елементів. По-четверте — ліміти зменшують ризики втрати контексту від постійних переключень.

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

Дякую за ваш коментар! SAFe не такий страшний як здається. Він розрахований на поставку програми (декілька зв’язаних між собою проектів) із кількістю учасників до 120 людей. Чим більша кількість залучених осіб — тим чіткіші та більш жорсткі мають бути процедури. Тому SAFe не такий гнучкий як Scrum, а тим паче ніж Kanban. Він має більше постулатів оскільки управління декількома «потягами» вимагає структурності. Common sense у такому випадку — привілей.

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

Що важливо розуміти: система з канбанами не має вбудованого механізму генерації KPI показників, цей фукнціонал (оцінку складності та ресурсоємності) треба впроваджувати як додаткову фічу.

Зазвичай — спонсору проекту/клієнту/керівництву організації цікаво коли і за скільки буде зроблений проект. Хоча б верхнерівнево. Там є купа цікавих метрик (Lead Time, Cycle Time, Response Time, Delivery Rate і т.д.) і є SLA — проте, все ж таки, застосовуючи Kanban складно прогнозувати поставку фічей. Це більше про управління робочим потоком.

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

Для цього потрібно щоб у системі були чітко визначенні класи сервісів, сформовані SLA (service level ageements) які відповідають SLE (service level expectations), SRM (Service Request Manager=PO) та SDM (Service Delivery Manager) мали чіткі домовленості по розподілу різних типів задач на пріоритезацію, активності Ustream (стадії до розробки) та Downstream (весь цикл розробки та тестування) були прозорими і зрозумілими для всіх учасників, а бізнес слідував чіткому правилу не міняти нічого у пріоритетах після того, як задачі пішли у стадію аналізу. Для цього потрібна «зрілість» усіх учасників та чіткі політки роботи (короткі письмові домовленості по процесу та результату).

Дякую за Ваш відгук!

Один из рабочих вариантов, который также рекомендуют, — закладывать ликвидацию части тех долга в нужные бизнесу фичи.

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

Например, в юзер стори, которая расширяет функциональность определённого модуля, можно добавить рефакторинг.

Я б радше радив одразу погодити та додати рефакторинг кожної одиниці беклогу (у межах розумного) як самобутній пункт у критеріях готовності продукту на початку розробки обов’язково проінформувати власника продукту або бізнесу про DoD команди ніж зіштовхуватись із ними в процесі роботи.

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

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

Дуже дякую за Ваш відгук, Романе — радий, що Вам сподобалась стаття!

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

Якось так.

SAFe — це фреймворк, як у будь-якого фреймворка у нього э ряд элементів та термінологія, яка залишаються незмінними. Для конфігурації Essential SAFe виділяють таких десять елементів.

Чи можна сказати, що ця специфічна вбудова в наш проект і є насправді SAFe — так, адже ці десять елементів повністю наявні на проекті. Щось краще, щось гірше. Чи коректно роботи із System Team ще і Feature Team у додаток — з моєї точки зору це некоректно і протирічіть логіці і суті операційних команд.

В будь-якмоу випадку — SAFe, як будь-який Agile фреймворк, базується на принципі емпіризму і на данний момент запущений єксперемент продовжується — питання відкрите. Будемо обговорювати із шановними SPCs через PI успішність експеременту, проте — і фактично і статистично рішення неефективне.

Компетенція та культура ДевОпс знаходиться на рівні програми — у нас на проекті System Team приєднали до командного рівеня, по рішенню одного SPC по аналогії із іншими проектами «Корпорації».

Оскільки ця System Team існує в рамках одного проекту і, згідно з їх точки зору (звичайно дуже суб’єктивної) потік задач для неї був недостатній (звичайно ж, тодішню воронку відмовились розглядадати) — вони вирішили сформувати із неї Канбан команду, яка паралельно із ДевОпс задачами, могла б доставляти малі фічі — тут вбачалась оптимізація навантаження.

Рішення було прияйнто в односторонньому порядку.

Розуміти так, як це визначено у фреймоврку згідно із правилами гри SAFe — власне с точки зору SAFe — Канбан команди та
Скрам команди живуть у єдиному операційонму ритмі (каденція) і мають загальні ART зустрічі (синхронізація) тому мають працювати у рамках 2-тижневих ітерацій.
Цей постулат був безапеляційно впроваджений у нас на проекті зі сторони SPCs не зважаючи нінащо. Але такий підхід дискусійний і не кожному до душі, що власне я і описував.

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

Стосовно другого зауваження — я згоден, що це можливо для організацій від 35-40 людей для побудови Agile управління програмно-портфельного рівня, які
почали свою трансформацію, проте це не було головним акцентом цієї статті.

Дякую Вам за коментарі!

Дякую :)

Дуже дякую — приємно чути! Я планую написати другу частину трохи згодом.

Дискусійне твердження — це дуже залежить, по-перше — від частоти та об’эму релізів й рівня розвитку CI/CD, а по друге — від поточнго процесу
управління релізом. Хто приймає ключове рішення по go/no go релізу та showstopers — ПО чи окрема ланка реліз менедмежнту? Дозвольте питання якщо не секрет — як часто у Вас на проекті відбувається реліз на прод і яка кількість команд приймають участі у ньому?

Рік — великий проміжок часу, колись напишу другу частину, де розповім що ми залишили і від чого відмовились.

Дякую за комментар — справа в тому, що теоретичний рогзляд SAFe вже був попередьно проведений у статтях — dou.ua/...​cles/safe-implementation й
dou.ua/...​les/essential-safe-guide. Моя ж мета — розповісти як він був впроваджений на моєму проекті конкретно під існуючі задачі. Я згоден, що текст не буде легко зрозумілим для аудиторії, яка не знайома із фреймворком — я вдячний Вам за відгук.