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

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

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

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

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

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

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

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

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

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

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

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

    Підтримав: Vic