Story Points не працюють, або Чому ви продовжуєте стріляти собі в ногу

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Вітаю, з вами Артур. Одразу попереджаю: у цій статті я ділюся своїми роздумами, і вона містить багато доволі холіварних думок, тому будьте готові до butthurt.

Що таке взагалі Story Point

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

Story Points — це відносні оцінки складності зусиль команди на виконання задачі. Відносні та абстрактні. Це не дні, години, хвилини. Це можуть бути розміри одягу, числа Фібоначчі — ви навіть можете вимірювати задачі крокодилами, якщо домовитися в їх класифікації.

Як відбувається процес естімації

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

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

Ну, здається, все зрозуміло і виглядає класно.

Але....

Що тут може піти не так

Тепер трішки поміркуймо, які помилки може допустити менеджер та команда в процесі впровадження Story Points.

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

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

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

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

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

Приклад: тестувальник оцінив задачу на XXL, а бекенд-тім лід, здоровий бородатий дядько з поглядом людини, яка вбʼє тебе тільки за те, що ти подумав щось зробити не так, оцінив цю задачу на S. І дивиться на цього тестувальника, у якого вже спітніли долоні й трясуться колінки, і каже: «Ну, може, все ж таки хоча б М?»

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

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

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

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

Проблеми з оцінкою складності в Story Point

Так, ми оцінюємо складність, але релізи то ми плануємо по часу. І саме тому я часто бачив ситуації, коли люди за спиною скрам-майстра чи проджект-менеджера домовлялися самі із собою, по типу, 1 Story Point — це щось типу написання метода нескладного, а 8, наприклад, — то щось по типу цілого тижня роботи.

Знову ж таки, як це відображається на роботі команді? Ну, нехай у вас велосіті команди це 2S та 1М. Ми оцінили задачі і взяли в роботу ті самі дві ески та одну емку. Але через те, що для кожного члена команди це може бути своє розуміння та свої ефорти на її виконання, то переводячи ці поінти на дні виконання задач у спринті, вже виявляється, що фронти виконали за 2 дні задачку, бек — за 6 днів, а тестувальнику треба повна регресія після цього всього і ще 14 днів. І все — спринт ціль завалилася.

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

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

Наведу приклад, щоб було зрозуміліше. Зібралися ми оцінити сторі. Капасіті нашої команди 2S та 1M. Ми беремо ці дві ески та одну емку. Але виявляється така ситуація, що поки бекенд не зробить свою задачу — фронт взагалі не може її починати. І у нас фіксується простій команди. Вона чекає, поки завершиться задача бекенда. Або навіть може виявитися так, що цілі сторі залежать одна від одної, і інша команда може чекати завершення імплементації сторі, тож ми ніяк не можемо перемістити місцями виконання цих сторей.

Які висновки з цього

Обговорімо ще раз, що може піти не так та які помилки ми можемо допустити:

1. оцінка велосіті вашої команди, коли її склад змінюється доволі часто;
2. різне розуміння складності задачі до її оцінки;
3. розділення команди на ролі — фронт, мобайл, бек, тестувальник;
4. торги та психологічний тиск членів команди;
5. не врахування залежностей задач.

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

І почнемо одразу з автора Story Points та співавтора аджайл-маніфесту — Ron Jeffries, котрий каже, що то була велика помилка:

Свіжіші його думки на цю тему можна почитати тут.

Ken Schwaber, один зі співавторів аджайл-маніфеста та скрама також пише, що розрахунки капасіті та велосіті команди — any time we spend worrying about velocity or capacity is waste, not adding a whit of value.

З ними погоджується і Jim Highsmith , співавтор того ж маніфеста аджайлу, про що пише тут, а ще в текстах на цьому ресурсі та ось тут.

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

А також, не бійтеся визнавати свої помилки та змінювати процеси та підходи. Не бійтеся використовувати чейндж-менеджмент, щоб з вами не трапилось описане в книзі «The McKinsey way»:

Sometimes change management means just that — changing management.

Дякую за увагу, гарного вам дня та мирної ночі!

P.S.

Якщо сподобалось підписуйтесь на мій телеграм-бложик t.me/from_a_to_qa де я пишу про менеджмент, розробку, та тестування або ютубчик youtube.com/@from_a_to_qa