Чому швидкість Scrum-команд не збільшується протягом часу

Всіх вітаю, шановна спільното!

Спочатку трохи про себе. Мене звати Висоцький Владлен, колись давно закінчив НТУУ «КПІ», отримав диплом магістра (з відзнакою) за спеціальністю вимірювальна техніка та метрологія, до 2018 року працював в різноманітних Конструкторських Бюро державного та напів-державного типу, отже все своє життя до цього року був інженером, займався embedded системами, мікроконтролерами, сенсорами та іншими цікавими речами. Вісім років тому набрався сміливості та перейшов працювати у велику міжнародну ІТ-компанію, приєднався як розробник по С/С++, але вже через півроку перейшов на Scrum Master трек і ось вже понад сім років працюю в цій ролі. Мені подобається ця роль, і подобається настільки, що вирішив почати ділитися власним досвідом та результатами своїх досліджень з усіма, кому це буде цікаво. Тим більше, що інженерну справу я не покинув, просто переніс її на інший рівень — рівень процесів. Мій досвід і тут допомагає мені.

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

Повністю підтверджую, що ця стаття написана особисто, окрім зображень. Вони — це справа «рук» ШІ, з якою він досить непогано впорався. Але сюжет зображень та їх стилістика — це також повністю моя ідея, люблю я мову аналогій та метафор. Текст даної статті може містити орфографічні помилки, вибачаюсь за це, але просто не хотів редагувати її через ШІ, не знаю, як і що може вплинути на рішення команди DOU стосовно її публікації.

У чому справа

Гадаю, вам доводилося колись чути такі запитання від менеджменту проєкту, як «Чому велосіті наших команд за останній рік не збільшилася?» або «Давайте побрейнштормимо, як можна збільшити показник швидкості наших команд» тощо. Я чув їх і не раз, особливо на достатньо «молодих» проєктах. Питання можуть бути різними, але їхня суть одна й та сама — як ми цифрами можемо показати, що кількість роботи, яку виконують команди, збільшилась за певний проміжок часу.

Тут хочеться відзначити, що мова йде саме про оцінку швидкості в Story Points. Сподіваюсь, що всі про них чули і, впевнений, що всі або принаймні майже всі з вас, шановні читачі, використовували чи й досі використовуєте їх в своїх командах при оцінках задач. Я так само зустрічався з цією одиницею виміру обсягу робіт майже на всіх проектах, де я був залучений, переважно, як Скрам Майстер. Декілька років тому я і сам запитував себе — чому команда починає робити більше роботи за спринт або квартал (це той факт, який я спостерігаю), але її швидкість (velocity) не збільшується. Швидкість команди роками залишається плюс-мінус однаковою, а зміни спостерігаються тільки зі змінами в складі (capacity) команди, а саме: більше розробників — більша швидкість, менше розробників — менша швидкість. Тому я почав досліджувати цей феномен більш детально і виявив дуже цікаві речі, якими і хочу поділитися з вами, шановні читачі.

Давайте розбиратися

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

Уявіть собі юнака, який тільки-но почав ходити до спортзалу підкачати свої м’язи. І, як всі початківці, він починає з невеликої ваги — хай це буде 10 кілограмів —, а за тиждень вже здатний піднімати 20 та 30 кілограмів. І цей юнак в кінці тренування може вам розповісти щось на кшталт такого:

• 10 кг для мене це легко, можу підняти 3 рази за десять секунд, навіть однією рукою;
• 20 кг це вже не так легко, але і не зовсім-то і важко, можу підняти 3 рази за три хвилини, але вже двома руками, мушу після кожного підйому перепочити кілька секунд;
• 30 кг — це ще поки важко для мене, ледь-ледь її можу підняти один раз, а щоб підняти три рази, то треба майже півгодини, відпочиваючи по десять хвилин після кожного разу, дуже важко.

Ну, про час, гадаю, тут все зрозуміло: чим важче, тим більше часу потрібно, щоб підняти штангу декілька разів. Або про зусилля, які витрачаються на це, так само, гадаю, все зрозуміло: чим важче, тим більше зусиль потрібно витратити. Якщо б ми ознайомили його з технікою оцінювання в Story Points (а в більшості випадків розробникам розповідають про зусилля, які потрібно витратити на вирішення задачі) та попросили його оцінити цю роботу по підйому штанги різної ваги, то вийшло би щось таке: 10 кг — це 1 SP, 20 кг — це 2 SP, 30 кг — це 3 SP (можна і більше, але не суть). Теж виглядає все логічно, вірно? Тоді йдемо далі.

Отже, наш юнак продовжує ходити в спортзал, не пропускаючи жодного заняття, і вже через декілька місяців його м’язи збільшуються, і він може вже піднімати більшу вагу, аніж на перших тренуваннях. Йому не цікава вага 10 та 20 кг, для нього це дуже легко, і зараз він використовує штангу вагою від 30 кг.

І цей юнак, як і в перший місяць свого тренування, може поділитися з нами своїми враженнями:

• 30 кг для мене зараз — це легко, можу підняти 3 рази за тридцять секунд, навіть однією рукою. Гадаю, скоро і від цієї ваги відмовлюся, бо стає нецікаво;
• 50 кг це вже цікавіше, є з чим працювати, можу підняти 3 рази за три хвилини, але двома руками, мушу після кожного підйому перепочити;
• 80 кг — о, це поки важко для мене, ледь-ледь її можу підняти один раз, а щоб підняти три рази, то треба майже півгодини, відпочиваючи по десять хвилин після кожного разу.

Приблизно така сама історія, як і на початку. А от тут виникає питання: якщо би ми знову попросили би його оцінити роботу в Story Points, то які б цифри він поставив?

І тут я впевнений, що вийшло б щось таке: 30 кг — це 1 SP, 50 кг — це 2 SP, 80 кг — це 3 SP. Чому я такий впевнений? Тому що спостерігав таку картину багато разів в своїх командах, на різних проєктах.

Як же так? — запитаєте ви. — Вага же збільшилась, і тут однозначно потрібно оцінювати по-іншому, що 30 кг — це 3 SP, як і було в попередній раз, 50 кг — це вже 5 SP, а 80 кг — це точно 8 SP (або навіть і більше, але не суть). І я з вами абсолютно погоджуюся, саме так і має бути. Але ж оцінюємо не ми, а він, і він оцінює з точки зору зусиль, які він витрачає, а порівняти одне зусилля з іншим він може тільки через час: ця задача робиться швидше, зусиль потрібно менше, а ця робиться повільніше, зусиль потрібно більше, а отже, перша задача менша, а друга — більша. І «менша» або «більша» — це не з точки зору ваги, а з точки зору зусиль, які потрібно витратити, а зусилля всі сприймають по-різному, тому що це персональна оцінка. Ось тут і знаходиться та сама причина, чому ми не бачимо зростання velocity команди протягом певного періоду. Гадаю, ви вже здогадалися, що це за причина? Якщо хочете, не гортайте далі сторінку, а розмірковуйте над тією історією, яку ви щойно почули.

В чому криється причина

Ця причина криється в тому, що ми продовжуємо оцінювати задачі через час, потрібний на її виконання, через персональні скіли, персональні зусилля, забуваючи про те, що Story Points були придумані саме для того, щоб виключити ці персональні складові при оцінюванні задачі. Вони були придумані для того, щоб оцінювати саме РОЗМІР задач, тобто вагу штанги, а не витрачений ЧАС на виконанні вправи з нею. Як тільки ми починаємо дивитися саме на вагу штанги, то все стає на свої місця: з часом розробники, набираючи більше впевненості в своїх знаннях, діях, знаннях продукту (тобто збільшуючи свої «м’язи»), починають робити більше роботи (тобто починають піднімати «штангу» більшої ваги). І якби все так і було, і вони оцінювали б саме вагу, то результат був би таким: 10 кг = 1 SP, 20 кг = 2 SP, 30 кг = 3 SP, 50 кг = 5 SP, 80 кг = 8 SP. І графік нашої швидкості показав би нам, що від нашої першої появи в спортзалі до моменту, коли ми вже здатні піднімати 80 кілограмів, що наша velocity зросла у 8 разів.

Але зазвичай такого не трапляється, і наш графік коливається біля якоїсь сталої (середньої) величини. Продовжуючи тягнути в оцінку час, розробники, як команда, так і залишаються з тими ж Story Points, що були у них на початку. Ну, майже з тими, але кардинального збільшення я ніколи не спостерігав. А як у вас, шановні читачі, чи спостерігаєте ви зростання velocity ваших команд у декілька разів? Поділіться, будь ласка, своїм досвідом в коментарях.

Отже, це те, до чого я прийшов, аналізуючи цю ситуацію, швидкість команди, тобто її velocity, не збільшується протягом існування проекту саме тому, що ми оцінюємо задачі в ЧАСі (хвилини, години, дні, тижні т.д.), а не в РОЗМІРі (Story Points).

Звісно, тут можна почути, що «команда досягла свого максимума і саме тому ми не бачимо збільшення velocity», і це теж буде коректно. Але нагадаю, що зазвичай мова йде про перші роки існування проєкту, особливо в аутсорсній компанії, де дуже прискіпливо дивляться, в тому числі, і на цей показник команди.

Завершення

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

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

З повагою до всіх читачів моєї статті,

Владлен