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

Тішать успіхи колишніх тіммейтів. Наснаги і ще більше перемог у майбутньому!

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

Velocity у жодному разі не слід використовувати як мірило ефективності команди. Це, в першу чергу, індикатор обсягу роботи, що команда може виконати упродовж 1 ітерації. Якщо простіше — ваш output у фічерах. Звісно, є менеджери/замовники, що сприймають velocity як ключовий показник ефективності, але таких треба навчати.
Зробіть крок далі і запитайте який ефект мають для Ваших клієнтів ці фічери. Бо здатність створювати більше фічерів протягом ітерації не важить нічого, якщо цими речима ніхто не користується. У Microsoft Excel тисячі фічерів, які пилом припадають, а в додатку MonoBank чи Uklon таких фічерів, для прикладу, одиниці.

Також часто люди забувають, що коли стається будь-яка зміна команди (залучення або виключення члена команди), це може відкинути її на попередню стадію, або навіть на дві стадії назад.

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

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

Це вже питання розбудови атмосфери довіри у команді. Сама суть використання Story Points полягає у тому аби почути різні думки, вести діалог стосовно деталей імплементації та, використовуючи здоровий конфлікт, усією командою дійти до спільного знаменника. Є ряд фасилітаційних технік для досягнення консенсусу, які можна використати. Раджу поеспериментувати з www.liberatingstructures.com. Підшукайте те, що працює саме для Вашої команди.

І, знову ж таки, по-третє, доволі складно оцінити задачу у «складності» Story Points. Задача може бути не складною, але займати багато часу, бо треба просто банально зробити багато дій — редагувати тест-кейси, створювати тестові дані, змінювати багато рядківкоду тощо.

Story Points же не прив’язані до часу. Порівнюйте задачу з ’умовною одиницею’ або використайте Bucket Estimation. Багато хто виділяє 3 аспекти у Story Points: складність, обсяг роботи та ризики. Чим більше складність завдання/роботи треба зробити/є ризиків — тим вища оцінка.

Для команди розробників це задача мінімальна, адже треба змінити одну цифорку, умовно кажучи. А для тестувальника — це смерть, адже треба зробити, як мінімум, смоук-тест всієї апки.

Story Points не мають сенсу якщо у тестувальникыв своя оцінка, у front-end своя, а у back-end своя. Має бути єдина спільна оцінка.

any time we spend worrying about velocity or capacity is waste, not adding a whit of value

Є різниця між ’worrying about velocity is waste’ та ’velocity is waste’. То як здавати аналізи в лікарні і переживати за результати — нема жодному сенсу. От як будуть результати — тоді подивимось і поговоримо.
З іншого боку, є команди, для яких Story Points не запрацюють. Такі команди можуть використовувати підхід No Estimates або метрики потоку з Канбан методу. А є команди, для яких Story Points чудово працюють. Тут вже кожному треба знайти своє.

Дякую, що поділились досвідом. Ще якби стаття називалась — ’Для нас не спрацювали Story Points і ось як ми це вирішили’ - було б цікавіше читати.

Але ми хотіли прийти до такого широкого розуміння — в нас один продукт. Один на всіх. Ламаємо стіни.

І для цього ми використовували системне мислення.

Цього в статті не було, дякую за уточнення.

То вони виконують роль Area Product Owners? Чи радше Subject Matter Experts?

Де Ви побачили щось про роботу PO наодинціі? Те, що PO відповідає за беклог не означає, що він все робить самотужки. Будь-якому РО в масштабованому середовищі доведеться шукати допомоги і багато делегувати.

Вітольде,

Value Steam Mapping може не лише дати усвідомлення того, що усі Ваші компоненти насправді формують один єдиний продукт з точки зору клієнта, але й виявити що один чи декілька ваших компонентів можуть служити як окремий продукт, але для іншої цільової аудиторії.

Наприклад, Volkswagen продає машини пересічним людям, але окрім того продає запчастини іншим автовиробникам. Можливо, й Poster можуть запропонувати щось подібне.

Вітольде,

1. На зображенні ’Як ми працбємо зараз’ вказано ’5 крос-КОМПОНЕНТНИХ інженерних команд’, звідси й питання. Зараз ви пишете про крос-функційні крос-компонентні кастомер-фейсинг команди. Навіщо для команд, що вже й так крос-функційні, наголошувати на їх крос-компонентності? Перше визначення є ширшим.

2&3. За що відповідають у вашій моделі новопризначені продакт менеджери, враховуючи, що за єдиний наявний продакт беклог відповідає Product Owner = CEO?

Ми чітко слідували Scrum: у нас були команди до 10 спеціалістів. Кожна мала певний вузький фокус на конкретному компоненті системи. Наприклад, одні працювали з хмарною платформою, інші — з hardware-пристроями тощо.

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

Ця українська продуктова компанія розробляє систему обліку та автоматизації процесів для HoReCa (Hotels, Restaurants, Cafe, усього 13 000 клієнтів). Сам продукт дозволяє контролювати продажі, прибуток, склад, виробництво тощо, а ще є екосистема, яку ми побудували навколо ключового продукту, як-от мобільний додаток зі статистикою та інше.

З контексту складно зрозуміти чи компанія пропонує один out of the box продукт, чи портфоліо з декількох продуктів. Якщо Ви ще цього не робили, то щиро раджу виконати Value Stream Mapping і зрозуміти яку насправді кількість незалежних продуктів компанія пропонує клієнтам. На кожен окремий продукт буде потрібен окремий беклог і окремі команди/інженери. Інакше є ризик наступити на ті самі граблі.

Чому обрали LeSS замість LeSS Huge

Чому саме LeSS? Не знайшов у статті пояснення чому обрали саме цей фреймворк.
Чи розглядали Ви Nexus або ж Scrum@Scale?

Також ми вирішили, що будемо вчитися брати менше фіч, але доводити їх до більшої готовності.

Краще беріть ще менше фічерів, але закінчіть їх повністю. Спробуйте порахувати скільки часу йде на ’допилювання’ таких фічерів ’більшої готовності’, які ризики вони в собі несуть.
Definition of Done у Скрам і LeSS — річ бінарна: або щось готове, або не готове. За незавершені речі доведеться платити з відсотками за технічним боргом.

Після переходу на LeSS

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

125 людей, що працювали не по Скраму за декілька років і сотні мільйонів доларів не заделіверили жодного робочого продукту (окрім пари занадто сирих навіть для базового вжитку PoC), а потім 55 людей, працюючи по Скраму, заделіверили субоптимальний продукт на 5 місяців пізніше.

Є купа кейс стаді, що описують успішне застосування Скраму у великих корпораціях, компаніях поза ІТ, освітніх та урядових проектах. Звісно, для ІТ старптапу на 20 людей застосування Скраму буде простішим, але свого часу це вийшло і у ФБР.
digital.ai/...​crum-project-fbi-sentinel

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

Щорічний State of Agile report — найкраще дослідження з існуючих, на мою думку.
digital.ai/...​rts/state-of-agile-report

Є в скрам-методології якесь чітке визначення — для яких проектів/команд він підходить, а для яких — ні?

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

Єдиний нюанс:

Це інструмент (простий, як зазначено у самому посібнику), який наче має розвязувати проблему, а не створювати тисячу нових

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

Дуже прикро чути це від колеги Скрам майстра. Дещо насторожує формулювання:

в реальном мире

Якщо ’реальна’ імплементація Скраму різниться від тієї, що описана у Скрам Гайді, то це вже не Скрам. Цей антипатерн зветься ScrumBut.

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

Для прикладу наведу деякі механізми, вбудовані у Скрам, що допомогають тримати технічний борг під контролем:

1) Незавершений інкремент продукту (той, що не відповідає Definition of Done) випускати у світ/до клієнта не можна. За прийняття рішення відповідає уся Скрам команда. Це дає розробникам право вето релізу.

2) Увесь технічний борг, який є результатом розробки нашвидкоруч/ігнорування кращих інженерних практик, має бути прозорим і вноситися у Беклог Продукту.

3) З ростом технічного боргу на Рев’ю Спринту команда демонструватиме усе менші обсяги нового функціоналу. Це найкращий момент аби ’продакти’ стейкхолдерам необхідність усування технічного боргу.

P.S. Скрам не вирішує Ваших проблем, а робить їх видимими. А вже вирішувати ці проблеми чи ігнорувати — рішення за Вами.

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

Объясните а зачем вообще инвестировать столько времени в имплементацию этих изменений?

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

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

на какие KPI это все влияет

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

How Big Tech Runs Tech Projects and the Curious Absence of Scrum

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

Чи Ви розмірковували над тим аби звернутися до дієтолога чи фахівця зі здорового харчування?

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

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

P.S. Певно, можна у тому всьому розібратися самотужки, але мені особисто було простіше звернутися до фахівця.

Scaled Agile Framework — это фреймворк (набор шаблонов, правил, принципов и практик), который помогает грамотно выстраивать процессы на базе Scrum.

Це не зовсім коректне твердження. ’The Scaled Agile Framework^® (SAFe^®) is a system for implementing Agile, Lean, and DevOps practices at scale.’ Тому, радше, масштабований Аджайл.

Команди всередині ART можуть працювати як по скраму, так і по канбану. Деякі вендори всередині фреймворку можуть взагалі не мати ніц спільного з аджайлом.Звісно, деякі конкретні імплементації SAFe можуть базуватися лише на скрамі, проте, це буде лише частковий випадок.

Ви цитуєте версію Скрам Гайду від 2017:

«Ретроспектива Спринта — это возможность для Скрам‐команд исследовать себя и создать план улучшений для следующего Спринта, с рекомендованной длительностью не более 3-х часов, для месячных спринтов»,

А от у версії від 2020 року підхід був дещо зміненим. Основне — це те, що прибрали акцент на необхідності вносити покращення з ретроспективи одразу ж у беклог наступного спринта.

кроме команды разработки, владельца продукта и скрам-мастера

У версії Скрам Гайду від 2020 року поняття development team теж зникло.

Ретроспектива — митинг не для скрам-мастера, а для команды

У Скрамі немає зустрічей/мітингів, є події. Не скрізь у статті це коректно відображено.

Если ваш бэклог улучшений

Скрам передбачає наявність лише двох беклогів: продукту і спринта. І покращення процесу мали б опинитись в одному з них. Інакше Ви шкодите принципу прозорості.

Дуже дивний опис порад для Scrum Master’a. Бо коли Скрам Майстер вирішує, що в його обов’язки входить сварити людей, то відбувається наступне (причому цілком заслужено): www.youtube.com/watch?v=JbQ-om9Z4Rc

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

Тут мужчина з досвідом детальніше пояснює:
www.youtube.com/watch?v=oeqPrUmVz-o