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

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

Привіт, мене звати Артур і я працюю керівником відділу автоматизованого та мануального тестування у компанії Yalantis. Одразу попереджаю: у цій статті я ділюся своїми роздумами, і вона містить багато доволі холіварних думок, тому будьте готові до 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.

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

👍ПодобаєтьсяСподобалось32
До обраногоВ обраному10
LinkedIn

Найкращі коментарі пропустити

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

Як завжди у Аgile, якщо щось не працює — то причина не в методиках, а у людях!
І у першу чергу — у проджект менеджерах. Я знав чудових ПМів, які були програмістами і розуміють як складно оцінювати і планувати, особливо якщо завдання погано сформульоване. «Зробити логін» — це підходить для клієнта, який ніколи не замислювався як це працює.
Або для ПМа — погонича, який «говорить мовою кліента», але ніколи не був програмістом і теж не уявляє як працює «логін».
Насправді коли у команді програмісти хоча б середнього рівня — їм не треба розповідати як і що робити до дрібниць. Кожен сам обере як краще робити і зробить свою частину роботи. А от усе, що про взаємодію і комунікацію, про управління людьми — це вже робота ПМа.
Сформулювати одне, вірне, розуміння завдання, спланувати хто що буде робити, коли зробить, як це буде інтегруватися, що коли буде готово і т.і. Це як оркестр: у кожного свій інструмент, свої ноти, а диригент керує щоб усе це звучало разом. Поганий диригент — хаос звуків замість музики.
Вертаючись до сторі-поінтів: вони потрібні у першу чергу самому ПМу!
— Аби мати гнучкість у комунікації з клієнтом,
— аби не тиснути на девелоперів, а мати більш вільну оцінку
— аби застосовувати різні метрики (ту саму велоситі)
Я вважаю що ПМ має бути «овнером» сторі-поінтів, впроваджувати їх, допомогти домовитися що узяти за один поінт, пильнувати аби ніхто не «давив авторитетом» (і, звісно ж, не нав’язувати команді свої оцінки).
Як відрізнити хорошого ПМа від галерного «погонича»:
— ПМ є адвокатом команди, а «погонич» завжди прогинається під клієнта.
— Мета ПМа — результати роботи, мета «погонича» — робити клієнта щасливим.
— ПМ добре розуміє процес розробки і охоче виконує свою роль (формулює вимоги, розбиває на таски, задає питання клієнту); «погонич» не має досвіду у девелопменті, він дивиться тільки на вигадані KPI і усі питання намагається «делегувати» комусь з команди (нема вимог? — то напиши сам, я не встигаю).
— ПМ насправді «рулить» командою, бюджетом, проектом: він вирішує кого брати, кого замінити, кого нагородити. «Погонич» тільки поганяє команду, яку продали клієнту. Він не має важелів впливу ані на склад команди, а ні на бюджет, а ні на терміни чи скоп роботи.
Коли замість проєктної команди просто набрали «пучок за п’ятачок» джунів і поставили дівчину — перекладачку для комунікації з клієнтом та «поганяти» команду, а потім навчили їх «грати у Скрам» (бо клієнту це подобається) — то тут справді не потрібні сторі-поінти. Бо це не виробництво, не інженерія — а балаган, вистава для клієнта.

Тобто, помилка номер 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 і ось як ми це вирішили’ - було б цікавіше читати.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

і що, б"ють по морді за хрінову велосіті і невиправдані сторіпойнт-естімейти?

по лицю то ще в кращому випадку :D а там вже як повезе :D

тільки в зумі треба дотягнутися

Насправді сторі поінти працюють, але можу точно сказати, що їх використовування не має бути обов’язковим, все залежить від потреб команди і максимальної її продуктивності, якщо команді легше відштовхуватись від годин і вони можуть прорахувати ризики — нічого поганого в естимуванні в годинах чи в СП які прив’язані до годин не бачу, АЛЕ на моєму досвіді були команди які зрозуміли як працюють СП, як ними користуватися, а найголовніше вони дужче об’єднали команду, бо естимують задачу всі її члени включно з куа, тому взаєморозуміння покращилося, взаємоповага і відповідальність,але і без СП є інструменти які допомагають для імпруву;) В цілому не бачу сенсу відмовлятися від чогось, що можливо комусь може допомогти!)

Сторі пойнти з часом перетворюются на оцінку в годинах з наведених в статті причин:
Коли команда не вписалась в спринт, тобто по часу, вона не/свідомо починає враховувати в оцінках що проста робота може бути довгою, складна короткою.
І приходить до оцінки тіпа яку зустрічав в світі фрілансерів:
Час*коеф складності/ризику = естімейт

Час береться з досвіду схожої задачі, або плана робіт.

Перетворення сп у години бачив такє
— Яка ж складність...
— ну за півдня можна зробити?
— здається да
— ну то це 4 сп
День — 8 сп. Два — 16. Більше — розбиваємо на окремі роботи

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

День — 8 сп. Два — 16. Більше — розбиваємо на окремі роботи

це якась реальна потогонка

ЗЫ: из «ажайного» бачив «мы складнисть выраховуемо зи складности а якшо там роботы просто дох. але просто роботы то то нэ есть складнисть 1 сторипоинт»

Чому потогонка?
Кінцева мета — вийти на:
То що ми можемо показати в кінці спринта, тобто на дату Х.

Тому й піема ті сторі пойнти в відриві від часу — теж не цікавлять.

А якщо плануємо — оце в сп, а оце просто робота, в годинах, то виникає ще швидше :
То переведуть оті сп в години щоб мати суму в одних одиницях.

З того що бачу від сп тому масово відмовляються що навіть стаття здивувала — а ще хтось пробує гратися в забавку сторі пойнтів?

від сп тому масово відмовляються

Пруф?

пруф на свій досвід, і досвід піемів — в різних командах і компаніях з якими спілкувався = до яких маю довіру?

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

...мій перший яскравий досвід був ще десь в році 2012ому
коли піеми запропонували, і команди (3 штукі) підтримали — «а давайте й правда спробуємо»
чи то після 3го, чи то після 4го спрінта — всі, від піемів до лідив прийшли до висновку — що фігня якась виходить (читайте у топіку і моїх коментах) і після спец мітингу — прибрали.
...йшли роки, я бував у різних проектах, і цю картину бачив всюди.
зараз, з місяця три тому, у нової команді — піем на старті проекту зразу всім пояснив:
у джирі sp не заповнюємо. бо фігня. просто керування джири замовника не в нас, — вимкнемо взагалі, потім

в принципі скрум це допускає точніше агілє фактична задача сторіпойнітів визначати velocity з якого можна далі проектувати шось більше за спрінти «цей проект має 1 мілліон сторіпойнтів з нашим velocity 8 сторіпойнтів за годину потребує 60 років на реалізацію»

хоча звісно разом з оцим починається кумедія бо менеджери ще люблять burndown chart який вже заповнюється у реальному часі тобто у реальних годинах а при цьому ще й означає не реальний статус виконання задачі але лише витрачений час воно в принципі може й корисне але загалом виходить кумедно «скіко тут сторіпойнтів? а скіко часу?» як результат дублювання «метрик» що фактично фактична відсутність як таких

пруф на свій досвід

Ясно. Это больше говорит о Вашем опыте, а не о предмете разговора.
Но вообще такая статистика была бы интересна.

И опыту, то есть осмысленному фактажу я доверяю больше чем статистике.
Особенно основанной на опросах, а в данном случае по другому её не собрать.

Поэтому я пруфы не только не спрашиваю, а часто глянув первые пару абзацев приводимых ссылок — прекращаю дискуссию с догматиком, который и сам не понял о чем он привёл пруф.

Ну и конечно моё кредо:
В теории нет разницы между теорией и практикой. А на практике она есть.

Скрам давно стал видом религии, догматы которой уверенно объявляются верными, и даже «у нас скрам» а на практике используются пару вещей в очень вольной трактовке.

Но статистика, по опросам, покажет тотальную победу скрама :)

Чому потогонка?

=>

День — 8 сп. Два — 16. Більше — розбиваємо на окремі роботи

мінімальне значення сторіпойнітів 1 відповідно то є мати бути мінімальне часу реалізоване мінімальний реалізований відрізок часу 4 години 1/2 дня якщо записати «день 8 сторіпоінтів» відповідно у день можна вкласти 8 окремих тасок по 1 сторіпоінту відповідно це день сидіти без відривно тіко на те щоби організувати бюрократію по таскам

до девелоперських тасок це точно не відноситься девелопери не працюють як система масового обслуговавання інакше ваші процеси поставлені не правильно

Так у тому ж і проблема сп — що вони виміряють невідомо що. А те що відомо і корисно виміряти це — час.

А другу проблему що ви назвали я формулюю так:
Скрам то спроба застосувати методи керування виробництва однотипних матеріальних речей.

інакше ваші процеси поставлені не правильно

Нам смішно з середньовічних рецептур ліків з сушених жабей. Але ж людство вижило? То ті процеси були лікування були правильними чи ні?

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

Так у тому ж і проблема сп — що вони виміряють невідомо що. А те що відомо і корисно виміряти це — час.

ага це класична нє пєрєводімая ігра слов у слові estimate ))

... по суті сторіпойнти тут є передбачення на кшталт передбачення погоди ну от ми знаємо що теоретично на мінєсоту насувається −60 по фаренгейту а як воно буде саме цього разу бо 3 роки тому вже було щось таке але яке саме цього разу і чи готуватися техасу ну х.з. ))

Скрам то спроба застосувати методи керування виробництва однотипних матеріальних речей.

абсолютно! тому я одразу і зауважив що «по годинні сторіпойнти» можуть відноситися виключно до системи масового обслуговування

... доречі маю досвід )) і навіть магічні цифри на кшталт 65% от скажімо маємо готель на 100 номерів яка його теоретична повна capacity при чому у річному визначенні? а от ні правильно вираховувати його як 100 * 65% а отже це усього 65 номерів на 365 днів бо суто технічно і то навіть практично повню 100% capacity можна не «підтримувати» але «реалізувати» точніше «підготувати» на якийсь короткий термін на кшталт піку сезону або якогось бізнес події тоді можна протриматися тиждень чи навіть два на повній саме «теоретичній» потужності але це буде даватися значними зусиллями (тобто на справді там вже буде більше 100% ресурсів просто вони будуть приховані) і все одно на протязі досить короткого часу система почне давати збої і якість сервісу різко впаде і можливі навіть катастрофічні випадки

... тому навіть у системі масового обслуговування ви не можете зробити 8 годин робочий день 8 задач рівно по 1 годині бо на справді там усе одно тіх самих 0.65 тобто реально зробити 8 задач по 1 годині але «теоретичній годині» яка на справді 0.65 = 39 хвилин що цілком нормально моделюється і вимірюється «на середній робочій одиниці» з тим щоби мати цілком нормальні середні оцінки але то вже верховне таємне знання гуру а «середній менеджер насяльніка» справді подумає що там просто 8×1 і так і зробить ))

... я перевіряв вже навіть декілька разів стикався менеджер ставив «мітінги підряд отсюда і до обіду» ну а що capacity же ж дозволяє і у календарі план сходиться правда швидко виявилося що вже за годину треба робити coffee and pee break а потім ще траплялися кумедні випадки коли менеджер не врахував розташування та відповідно логістику вільник «кабінетів» і виявилося що «між мітінгами» на справді хвилин 5 чесної такої доброї мандрівки офісом і то якщо заздалегідь знати маршрут бо знову ж такі дійшли тіко тіх самих умовних 65% а інші просто загубилися і знайшлися не одразу а отже «година слот» виявивлся «зіпсованим» з відповідним зміщенням подальшого «розкладу»

ЗЫ: на визнання усіх тих менеджерів визнаю що одного разу вистачило і більше жоден такого не повторював щоправда на узагальнення у них все одно не вистачало і вони повторювали але вже «єто другоє» ))

Нам смішно з середньовічних рецептур ліків з сушених жабей. Але ж людство вижило? То ті процеси були лікування були правильними чи ні?

ні не правильні ну і доречі то же ж є класичний приклад «помилки ... того хто вижив» (а ну да українською же ж не має ... гм а ні дієприкметник є ну всьо дно не працює взагалі))

ЗЫ: а ні це же ж не дієприкметрик це дієіменник ))

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

так і купи говно коду пробачте пріннньом пріннньом ))

ну так, марафон 40 км команда не пробігає як 400 спринтів по 100 метрів. це просто жах

Питання до експертів. Чи добре прорефайнена таска оцінюється в сторіпоінтах краще (буде точніше спрогнозована)? І чи не є гарний рефайнмент ключем до вирішення питання?

Правильно задане питання завжди містить частину відповіді. З рефайнментом так само.

Если в этом тексте заменить все словосочетания «Стори поинты» на «часы», то смысл статьи абсолютно не поменяется. Главные «проблемы» оценивания в статье: шторминг, разное понимание задачи, авторитетное мнение и давление при выставлении оценки актуальны и для времени в часах. Хотя автор пытается донести мысль что проблема именно со стори поинтами.
Автор не разобрался с собственноручно приведенным определением Стори поинтов. В нем говорится о сложности усилий (еffort) команды, а не сложности алгоритма/кода/мыслей джаваскриптера. Т.е. пример с простой задачей, в которой неделю нужно тривиальные действия производить нерелевантный. Тут effort(усилия) большие, а значит и сторипоинтов нужно лепить много. В алгоритме на 20 строчек который должен работать быстрее со сложностью nlogn вместо n*n тоже effort будет большой, т.к. большинству вчерашних пиценосцев понадобится большое количество усилий (effort), чтобы найти на stack overflow что-то, что можно взять за основу этого алгоритма

ви прочитали статтю і не зрозуміли її. тут описується те, які проблеми можуть піти із того шо люди НЕ РОЗУМІЮТЬ як впроваджувати сторі поінти. і от одна з проблем, це те що люди часто починають естімейтити в них кожен для себе в ЗУСИЛЛЯХ СВОЇХ а не командних при чому все члени команди являються нерівнозамінними. це описано у другому пункті ВИСНОВКІВ. буд-ласка, будьте уважні коли читаєте, читайте те що написано ане те що хочете побачити та не займайтеся софістикою :)

основна проблема сторі поінтів в тому що їх впроваджують ДЛЯ ВСІХ а підходять вони тільки для ДЕЯКИХ команд. де всі рівнозамінні, де є адекватний скрам-майстер шоб слідкувати за процесом(шоб не починалися торги, тиск та всі повїязані проблеми)

так, деякі антипатерни будуть притаманні і для людино-годин але людино-години інтуітивно більш зрозуміліші для людей. ось і все.

і от одна з проблем, це те що люди часто починають естімейтити в них кожен для себе в ЗУСИЛЛЯХ СВОЇХ а не командних при чому все члени команди
являються нерівнозамінними.

Ну и при чем тут сторипоинты? Если в этой цитате в «зуссыллях своих» заменить на «часы требуемые конкретному члену команды» для вас меняется суть проблемы?

звісно. тоді планування буде стосовно часу. Вася бек оцінює в 3 години, Петро в 6 годин фронт і Михайло в 3 години тестування. отже у нас 12 годин на завершення сторі. тут одразу і залежність видно шо коли можна буде робити і таймлайн повністью прогнозован.
а оцінювання у сторіпоінтах у «своїх» зусиллях — то є антипатерн. адже ці зусилля повинні бути для всіх однакові. бо в скрамі поняття девелопер — це ВСІ РІВНОЗНАЧНІ ЧЛЕНИ КОМАНДИ. тобто нема як такових тестувальників, розробників, девопсів і тд. і задача в 1 сторі поінт вона однакова для всіх. саме тоді можна планувати адекватно спринт.

Ну так тоже самое можно делать и со сторипоинтами: тестировщику нужно 1 сторипоинт, Беку 3, фронту 2. В сумме 6, округляем до ближайшего значения 5. И я скажу более, я даже работал в команде практиковавшей этот дебилизм. Но когда каждый член команды может оценить только свою часть работы у команды ещё большие проблемы чем стори поинты. Это команда в которой на грумминге все молчат, если к qа во время обсуждения обратиться, то ответом будет: «could you repeat a question?» (так как свои часы на тестирование он посчитал, дальше можно не вовлекаться)

на правильно проістімечену таску тратися працівником проісчемейчений час повністю, а неправильно недоістемейячений таск часу не вистачає

Стаття із розряду «Аби була, згодится при подачі на О1».

це дійсно цінний комент для мене і для спільноти. дякую вам за ваше старання та труд. найулюбленіший та найкорисніший вид коментів саме такі :D

Надо быть полным кретином чтобы допускать мысль о их релевантности на 99% проектах. Они могут работать в очень специфичных проектах/командах.

Но они все равно пишут что это единственный вариант... мозгов нема считай калека.

а потім ще й дивуються «а чого нічо не працює» :D

ІМХО тут приблизно як з демократією — «є найгіршою формою правління, але нічого кращого людство поки що не придумало»

Перестаньте повторювати цю дурість. Меритократія давно придумана.

И кто будет определять «достойных»?
А что будут делать те, кто не попадет в список «достойных»?
Намекну — Индийская кастовая система, очень похожа на меритократию, только «достойные» отбираются по правилу «рождения».

Чому не варто писати булшіт статі?

1. Тому що вони не добавлять карми
2. Тому що вони забирають час на написання
2.1 тому що вони забирають час на коментування
3. Тому що вони НЕ ДОПОМОГАЮТЬ комьюніті стати кращі ( критикуєш?! запропонуй краще)
4. Тому що вони поширюють токсичність у комьюніті

Усі весомі доводи Артура можна звести до скріншотів Ron Jeffries & Jim Highsmith.

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

Чому не варто критикувати статті?

Тому що вони НЕ ДОПОМОГАЮТЬ комьюніті стати кращі ( критикуєш?! запропонуй краще)

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

І випереджаюче можливе запитання: так ти ж критикував, що ти запранував? Мій комент не підпадає під поняття критики. 8)

Правильно критикує. Воно не працює в такому контексті. Допомагає людям граблями не ходити.

А от Ви критикуєте автора, натомість не пропонуючи нічого взагалі.

Перечитайте мій комент ще раз будь ласка. )

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

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

ось посиланнячко
dou.ua/forums/topic/40516

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

Це ви вважаєте що клієнт нічого не пропонує коли критикує. Для БА або Продукт Менеджера, скарги клієнтів- це можливості, но це вже не ваша робота.

так ціль статті, ще раз — це ЯКІ ПОТЕНЦІЙНІ ПОМИЛКИ команда та менеджер можуть допустити при впровадженні сторі поінтів :) там же так і написано «давайте поміркуємо які помилки можемо допустити» )))
ну і для того шоб люди розуміли шо сторіпоінти НЕ ДЛЯ ВСІХ і шо якшо не йде то треба вертатися на години якшо шо :)

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

А про потенційних ризики та їх митигацаю можна зробити окрему статтю з більш повним переліком можливих ризиків.

Story Points не працюють

Перечитав весь текст — не побачив ніякого підтвердження тези із загловку. Типовий клікбейт.

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

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

яку проблему ми хочемо цим вирішити та як нам це допоможе?

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

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

Для чого ж насправді потрібні ці всі велосіті? Банально для того, щоб, плануючи наступний спрінт, можна було прикинути, скільки сторі пойнтів «влізе», орієнтуючись на те, скільки «влізло» в попередній (з урахуванням відпусток, вихідних і оце все).

Все.

перечитайте ще раз статтю уважно та без емоцій :)
там про те ЯКІ ПОМИЛКИ можуть допустити менеджери та команда.
ціль — показати типовіші помилки і САМЕ ТОДІ ВОНИ НЕ БУДУТЬ ПРАЦЮВАТИ.

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

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

Для чого ж насправді потрібні ці всі велосіті? Банально для того, щоб, плануючи наступний спрінт, можна було прикинути, скільки сторі пойнтів «влізе», орієнтуючись на те, скільки «влізло» в попередній (з урахуванням відпусток, вихідних і оце все).

так це будь-яка естмація для цього треба. тут по-барабану сторі поінти, години чи крокодили. це ВСЕ про планування.

САМЕ ТОДІ ВОНИ НЕ БУДУТЬ ПРАЦЮВАТИ

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

Не «ЧОМУ Story Points не працюють», не «КОЛИ Story Points не працюють» — просто «Story Points не працюють».

ну тут згоден)) заголовок трішки кричащий :D

Вся суть сторипоинтов в том чтобы используя умные слова ( методология , велосити, капасити и т.д. ) иметь оправдание перед заказчиком почему вы нихера не делаете вовремя, и никогда не даете точных сроков.
Ну и как дополнительный бонус — узнав о оценке в сторипоинтах в компании — можно заблаговременно её даже не рассматривать.

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

холіварна тільки назва статті )) бо сама вона — перелік помилок використання/розуміння методології

все вірно :) заголовок для привернення уваги ))

Якась апокаліптична стаття, що, напевно, відповідає апокаліптичному настрою автора :))) Толку нуль, вейст оф тайм...

сказала людина, 8 із 9 статтей котрої на доу — це просто копіпаста з публічних ресурсів)))

У скільки сторіпоінтів автор оцінив свою статтю?

в два крокодили і одного алігатора :)

Когда увидел заголовок, подумал что тут будут альтернативы Story points.) Интересно было бы увидеть опыт тех кто от них отказался или вообще живет в модели No estimates.

Канбан же.
Или Cowboy Coding.

Думаю, скрам погано натягається на цей проект.

Для чого скрам потрібен? Щоб виконавець прикрив свій зад. Задля цього зі сторони замовника залучають Product Owner, роблять йому кожні 2 тижні презентації, і кожного дня він має бути в курсі усього, що відбувається. Якщо замовник скаже, що команда якусь непотрібну фігню робила — то винуватий в цьому Product Owner — котрого поставив замовник — а команда зробили, що їй сказали, тому гроші маєте заплатити за роботу в повному обсязі. Це — дуже тупа розумна ідея.

Зверху на базову ідею навернули складність. Але та складність може працювати лише коли виконуються умови фреймворку. Для сторі пойнтів умови наступні:
* Усі спеціалісти в команді є взаємозамінними. Себто, ви не можете мати окремо тестувальників, окремо — фронтендерів, окремо-бекендерів, окремо — девопсів. Бо тестувальник не оцінить задачу для бекендера. А от коли в усіх однаковий досвід — тоді й середня оцінка буде схожою на правду, і задачу можна віддати тому, хто перший звільнився.
* В один спринт не можна брати взаємозалежні задачі. Бо задачі йдуть в роботу у випадковому порядку, тому кожна задача має право піти в роботу в кінці спринта.
* Фічі мають бути розбиті на елементарні задачі, кожну з яких робить одна людина. Якщо у вас одна задача проходить бекендера, фронтендера та тестувальника — то її взагалі неможливо оцінити, бо там реально сума 3 різних задач, в кожної з котрих реально дуже різні оцінки.

Синопсис: нєфіг натягати срам на глобус. Він працює там, де працює, і не працює за інших умов.

Насправді легко оцінюється робота в пойнтах коли в ділі конвеїр будь який, для цього власне і треба еталонна історія і таблиця еталонних історій, а також планінг покер (хоча деякі тіми використовують сабтаски). Ви командою прикидуєте складність поставки, тобто повного циклу DoD відповідно до схожих сторій чи до найпростішої еталонної, яка займає найменше. Як виходе занадто велика історія, яку неможливо взяти в спринт — її бьють на простіші. Краще за усе по функціональності, тобто якісь акксептанси окремо, та можна і по іньшому — скажімо бекенд та авто тести API окремо, фронтенд і інтеграція з бекендом окремо. Не принципово насправді. От коли scrum як процесс справді не діє — підтримка, тобто треба закривати баги. Нема жодного сенсу планувати якісь спрінти, вимірювати сторі пойнти тощо — якщо завдання швидко реагувати на проблеми в системі і закривати їх відповідно до тяжкості. Для цього є канбан. Вже було багато статей тут як народ перестав використовувати Scrum та перейшов на канбан та нормалізував свою роботу таким чином.

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

АХАХАХА! Я ще десять років тому говорив що сторі поінти, скарм, аджаіл це все херня для того щоб не писати ТЗ. А мені казали дєд ти нє шаріш...

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

Так звичайно не шарю. Всі хто шарять зараз фасілітують, фасілітують та не вифасілітують.

Story Points не працюють

«ясен пень» що не працюють. Навіщо далі читати — не знаю.

Тобто, помилка номер 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 і ось як ми це вирішили’ - було б цікавіше читати.

дякую за розгорнутий комент :) погоджуюся з кожним словом :)
щодо заголовку — треба було придумати щось клікбейтне що зверне увагу та спровокує до дискусій :D

Story Points же не прив’язані до часу

Прив’язані напряму не тільки по потребах (в іншому коменті писав) а і по суті:
Ми маємо одиницю часу — спрінт. І коли ми кажемо що ця команда має/може зробити X сп за спрінт, то ми декларуємо пряме відображення сп на робочі години.

Якщо ж сп це розмір невизначеності — складна задача: а то хз скільки ми будемо її робити.
То тоді ми маємо одиницю складність за одиницю часу?
А чи буде однаково: 1 задача у 20 сп і 20 задач по 1 сп? Тобто впевнено беремо у роботу на спрінт 20 задач тому що в попередньому спринту ми брали 20 сп?

Багато хто виділяє 3 аспекти у Story Points: складність, обсяг роботи та ризики

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

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

Звісно, є менеджери/замовники, що сприймають velocity як ключовий показник ефективності

Ефективність чи продуктивність? Це різні речі.

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

Як завжди у Аgile, якщо щось не працює — то причина не в методиках, а у людях!
І у першу чергу — у проджект менеджерах. Я знав чудових ПМів, які були програмістами і розуміють як складно оцінювати і планувати, особливо якщо завдання погано сформульоване. «Зробити логін» — це підходить для клієнта, який ніколи не замислювався як це працює.
Або для ПМа — погонича, який «говорить мовою кліента», але ніколи не був програмістом і теж не уявляє як працює «логін».
Насправді коли у команді програмісти хоча б середнього рівня — їм не треба розповідати як і що робити до дрібниць. Кожен сам обере як краще робити і зробить свою частину роботи. А от усе, що про взаємодію і комунікацію, про управління людьми — це вже робота ПМа.
Сформулювати одне, вірне, розуміння завдання, спланувати хто що буде робити, коли зробить, як це буде інтегруватися, що коли буде готово і т.і. Це як оркестр: у кожного свій інструмент, свої ноти, а диригент керує щоб усе це звучало разом. Поганий диригент — хаос звуків замість музики.
Вертаючись до сторі-поінтів: вони потрібні у першу чергу самому ПМу!
— Аби мати гнучкість у комунікації з клієнтом,
— аби не тиснути на девелоперів, а мати більш вільну оцінку
— аби застосовувати різні метрики (ту саму велоситі)
Я вважаю що ПМ має бути «овнером» сторі-поінтів, впроваджувати їх, допомогти домовитися що узяти за один поінт, пильнувати аби ніхто не «давив авторитетом» (і, звісно ж, не нав’язувати команді свої оцінки).
Як відрізнити хорошого ПМа від галерного «погонича»:
— ПМ є адвокатом команди, а «погонич» завжди прогинається під клієнта.
— Мета ПМа — результати роботи, мета «погонича» — робити клієнта щасливим.
— ПМ добре розуміє процес розробки і охоче виконує свою роль (формулює вимоги, розбиває на таски, задає питання клієнту); «погонич» не має досвіду у девелопменті, він дивиться тільки на вигадані KPI і усі питання намагається «делегувати» комусь з команди (нема вимог? — то напиши сам, я не встигаю).
— ПМ насправді «рулить» командою, бюджетом, проектом: він вирішує кого брати, кого замінити, кого нагородити. «Погонич» тільки поганяє команду, яку продали клієнту. Він не має важелів впливу ані на склад команди, а ні на бюджет, а ні на терміни чи скоп роботи.
Коли замість проєктної команди просто набрали «пучок за п’ятачок» джунів і поставили дівчину — перекладачку для комунікації з клієнтом та «поганяти» команду, а потім навчили їх «грати у Скрам» (бо клієнту це подобається) — то тут справді не потрібні сторі-поінти. Бо це не виробництво, не інженерія — а балаган, вистава для клієнта.

Так, це дійсно правда. і тут головне питання — що робити коли твій менеджер «погонич» :D міняти компанію, менеджера чи майндсет менеджера?)))

Міняти проект!
Бо саме існування таких менеджерів стало можливим завдяки «бодішоп» моделі, яку продають клієнтам «галери». Тобто якщо клієнт платить за команду, за відпрацьований час — але не за результат, то він і отримує «шоу» замість продукту.
Я впевнений що на fixed price проєкт ніколи не поставлять «погонича». Або якщо поставлять — то виженуть після першого дедлайна. Тому що нема сенсу налягати на весла в овертайм, якщо ніхто не вміє прокладати курс. «Погонич» просто виснажить команду у безтолковій метушні — бо не вміє поставити задачу. Там, де ПМ збере мітінг на пів-години аби показати план і кому що робити, «погонич» буде кожного дня по декілька годин мітінгувати з командою аби розібратися «чому не встигаємо і що далі робити?».
Або ж знайти аутстаф проєкт, де у клієнта вже є толкові ПМи, і налагоджений процес розробки — а ви тільки «вливаєтеся у команду клієнта».

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

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

Для пмів які беруться за такі дедлайни за фіксед прайс, окремий казан у пеклі є, бо хейт спускається стандартно на нещасних інженерів

Працював якось на такому, цікавий досвід, щоб більше туди не потрапляти.

у вас є умовно один місяць і продукт до цієї дати має бути готовим. І нікого не цікавить як — видумуйте самі.

Так — для ПМа такий проект це челенж, але з іншого боку у нього є свобода маневру («видумуйте самі»)! Розумний ПМ, який зможе погодити з клієнтом той результат, який його влаштує за місяць. Бо клієнт те ж зацікавлений отримати результат, а не просто сказати «не встигли — не дам грошей» і залишитися без продукту. Зіграна команда, яка вже притерлася і вміє сама організовуватись. Якщо вміло застосувати Скрам, і, особливо, навчити замовника його перевагам — то за місяць команда зможе зробити максимум корисного функціоналу. Особливо, якщо сама команда буде обирати технології. Зараз є дуже багато готового — якщо не писати усе з нуля, а брати бутстрапи, сервіси, фреймвоки — то навіть за місяць можна багато чого зробити.

Звісно видумали овертайми.
постійний стрес він створюється навмисно і дуже великий на протязі усієї розробки

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

В обох випадках була абсолютно з нуля набрана команда :))) В одному проекті на виході було 80 багів 60 з котрих — критичні,тех.лід постійно не спав та репортив на стендапах: «да ладно там я ночку посижу — сделаю!», потім паровозом за цим вже і я «ночку посижу» та іньщі, «тестлід дзвонить і каже — чому я професійна тестувальниця приймаю участь в цьому соромі?». Я їй відповідаю — «Не знаю я намагався з клієнтом побалакати, що те що вони хочуть в цей місяць нереально і треба буде або від чогось відмовитись чи розширити час, та мене прибрали з усіх комунікацій» . Потім на демо вже з’являється сам віце-президент голова нашого юніту (хоча сам же і давав усі апруви, я розумію, що то така бізнес стратегія не перший раз він на таке йде). Ну і як це скінчилось усе і якимось чином клієнт пішов на «фазу 2», уся команда дружно сказала : «дякую але без мене, я вже на іньшому проекті». Цікаво, що взагалі вдалось якось іньших людей набрати на це. До кінця другого такого «проекту» я не дійшов, захворів та мене зняли, скоріше за усе і сам би пішов. Це процесс під назвою ляп-ляп і в продакшн, жодного відношення до гнучких методологій це не має. Коротше кажучи не в фіксет-прайсі справа, в T&M я такого лайна не бачів ніколи. Там усе просто — є робота, робим її. Про продуктову розробку в стартапів я вже теж розписував, теж не цукор особливо по зарплатні.

міняти компанію, менеджера

От ви й самі уже пишете правильні варіанти :) тільки замість заміни менеджера, думаю точніше це назвати заміною проекту (з іншим менеджером). Ще один варіант — змиритись і страждати, ну і давати естимейти з деяким запасом, щоб страждання було поменше.

Зробіть для цього чувака окремий розді на сайті

а потім навчили їх «грати у Скрам»

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

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

що не переводяться в час

Елементарно переводяться. Є велосіті команди, скажімо в середьному робимо 20 пойнтів в два тижні. В якісь два зробили 15 в якісь аж 32. Оцінюєм епіки по product road map ділим на довжину спрінта, (зазвичай на два тижні) і отримуєм орієнтовну дату поставки продукту — ставим soft deadline на цю дату. Далі оцінюєм ризики, додаєм ще час на «стабілізацію» відповідно до ризиків ставимо hard dadline тобто дату прийняття програмного продукту в експлуатацію. Одна не задача, треба підняти зад і прочитати якусь розумну книжку де це написано. Тільки не так, що після того як вона прочитана не можеш відповісти на запитання — «Хто такий містер Томпкінс ?». Коли це аутстаф особливо не скажеш про це клієнту. І там як пощастить, може бути або не ІТ менеджер яка раніше керувала скажімо продажами, а може і така собі ніндзя наскілована, що можна займатись написанням коду, архітектурою тощо.

Головне в цій красивій конструкції факап повісити на містера Томпкінса, який чи
то звільнився посеред проекта чи то автобус його збив, і тепер треба ще рік — вчора заестімейтили нові капасіті й велосіті

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

Нема тут астрології, це просто інший підхід робити те саме, що і раніше але з урахуванням фактору того що ми більше не знаємо чим знаємо і вимоги міняються. А також принципів японського стилю менеджмент 改善 Кайдзен. Якщо у вас не вдалось і не працює, то це зовсім не означає, що такий підхід це взагалі не працює. А розробляти в принцпі можна і за підходом ляп-ляп і в продашн www.youtube.com/watch?v=oyVksFviJVE (в 2007-2008 був якраз в такому епізоді мало не один в один, коли ми з колегами робили одні і ті самі речі). Проблема тільки в тому, що не буде відтворюваності результату, колись все буде добре — а колись все завалиться. І буде чітка тенденція — чим складніший проект і чим більше людей задіяно, тим більше вірогідність, що усе завалиться з великим тріском.

ну якби воно працювало то ми б уже жили у світі без овертаймів і просрочених недороблайнів

з точки зору інструмента для отримання числа, замість плюнути на палець і оцінювати по вітру — ок, я бачу в цьому сенс, але на мою хамбл непопулярну думку нічим не краще за оцінювання в людиногодинах.

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

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

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

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

Загалом — як методика, одна з багатьох в інструментарії, — корисно, але робити з цього якусь священну корову просто тупо

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

Цікаві висновки, у якості прикладів якраз видаєте приклади чому власне почали використовувати сам сторі пойнти і естімейшн покер бо саме з цим процесом і пов’язані оцінки на сам перед. Момент перший — не давати оцінку «зі стелі», якщо не розумієш задачу — задай питання. Дати оцінку в годинах на якесь нове задання дуже складно, але оцінити її відповідно до якоїсь простої еталонної задачі набагато простіше. Момент другий, сторі пойнти завжди прив’язані до команди яка власне виконуватиме роботу, бо саме вона надає естімейт — а не один техлід чи взагалі треті люди які робили пресейл на вдавались в подробиці. Момент третій дедлайн і бюджет — ці фактори є і будуть завжди, але бізнесу треба теж бути реалістичними — можливо якусь не дуже корисну функціональність можна нема сенсу робити, бо вона занадто дорога і навпаки якусь просту але не дорогу навпаки треба робити. Далі вже є методи пріорітизації наприклад модель Кано, метод MoSCoW (www.hotpmo.com/...​s/moscow-kano-prioritize) тощо — де вже бізнес скаже, що йому справді треба — а що ні. Коротше кажучи це ціла методика виробництва ПЗ, і з певним рівнем кваліфікації вона дуже дієва. Якщо братись за це не розуміючи як це, без відповідних знань і вмінь — результат швидше за усе буде справді провальним, до того ж закономірно провальним. Так в принципі із будь чим складним діє, гнучкі процеси доволі складні і їх важко імплементувати це їх великий недолік.

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

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

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

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

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

Дайте я вас обійму.

Один раз в житті працював на проекті із повним SAFe, де застосовувались всі практики Agile по-справжньому і, головне, PO та Scrum master теж були справжніми і знали, для чого вони є.

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

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

японській тип менеджменту

Мабуть у цьому i проблема)

зазвичай воно добре працює коли процесс ставлять треті професійні організації

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

Добре що по картам таро не естімейтять

як у Сімпсонах — голову курки відрубали — куда впала там за стіки і зробимо )))

Маю кубики для настолок, гм. Від 4-гранних до 20. І можна навіть 100-гранний емулювати.

Хайпова тема, але типова. Оцінка у функціональних одиницях — за Томом Демарко, тобто story points не працює в тому випадку в одному випадку — це випадок Fragile savaged.files.wordpress.com/...​1/fragile-life-cycle1.png Тобто у вас процес який насправді керується не ітеративною розробкою і XP, а планами які спускає вище керівництво разом з дизайном і усім іньшим. Заради моди цей waterflow процес назвали agile, щоб від індустрії не вирізнятись та на ринку праці не казали — «не ходіть туди, там старючі процеси і не IT менеджмент керуе», та роблять вигляд ніби так і є. Далі команда може скільки завгодно робити еталонну сторю, таблиці еталонних сторів, робити цілі на спрінти тощо, та вище керівництво це жодним чином не цікавить. От в таких випадках не тільки user story та і взагалі жодна оцінка трудовитрат від команди не діє. Усе розумні дядьки менеджери та архітекти порахували за вас — ваша задача як виконавців, виконувати і вкладатись в строки від бізнесу і експертів. В справжніх agile процесах story point як підхід до оцінки трудовитрат діють чудово.

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

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

Та чогось переважно ніхто і не рахує,самі ж просять порахувати і зробити. Чи реально зробити X до дати Y. Якщо не реально, то давайте щось викинемо аби таки зробити до дати Y. Це типу так виходить, «ви скажіть, коли воно буде готове, а потім вже собі грайтесь у Аджайли»))

Дякую за матеріал.

Що ви пропонуєте з вашого боку замість story points ? Як ви вирішуєте описані у статті обмеження?

Дякую за фідбек.
Основна ціль статті була показати найтиповіші приклади коли можно лажанути у впровадженні сторіпонітів (точніше де вони можуть статися і як) ну і відповідно до цього — старатися не допускати їх. Ну і основне — не всім командам та типам компаній підходять сторі поінти. І інколи краще знову вернутися до людино-годин з плануванням спринта за допомогою діаграми Ганта по задачам на кожну людину згідно її оцінкам.

Я так розумію йдеться про класичну діаграму Ганта, як альтернативу (хоча інструмент в принципі теж дієвий, як проект зрозумілий і вимоги не міняються протягом самої розробки).

Цікава стаття, дякую!

Дуже холіварна тема! Тому й я вставлю свої 5 копійок. :)
(Я маю намір докапуватися, але робитиму це з повагою до автора)

По перше, Story Points (за Д. Сазерлендом) — це майндсет, котрий повинен посилювати співпрацю всередині команди. Постає перше питання — а у якому середовищі? Правильно, у скрамі! :)

які помилки може допустити менеджер та команда

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

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

По-друге — те, як ми оцінюємо задачі.

За моїм досвідом, найбільший біль — це створення таблиці «еффорт-поінт». Особливо, коли команда full-stack. І це обов’язок команди вирішити що для них є 1,2,3 і т.д. Щодо «фулл-стек сторей»- у першу чергу, це будуь обмеження софта, де ви керуєте проектом. Бо «натягнути сову на глобус» може бути складно.

наприклад, фронтенд-розробнику для виконання задачі треба дуже багато часу, а для всіх інших — це задача на «один-зубок»

Дуже популярна помилка серед команд та менеджменту багатьох компаній. Рон Джефріс (якого автор згадав) неодноразово зазначав, що поінти — це командна метрика, котра потрібна команді, щоб вимірювати скільки команда може створити функціоналу за одну ітерацію. І все! Як я спочатку зазначив — це майндсет, котрий повинен посилювати команду.

(Зараз я напишу дуже болючу штуку) — Коли поінти (командна метрика) доходить до керівництва, то постає перше питання — чому дорівнює поінт? «Ну неможливо, щоб він не дорівнював якійсь мірі часу!»
Коли керівництво отримає відповідь на питання (І це помилка у розумінні менеджмента АБО помилка у виборі методологіі) то поінти стають прокляттям — спочатку це буде елементом вимірювання особистої ефективності кожного члена команди (усе одно як ви це вимірюватимете, бо у скрамі це не повинно вимірюватися — прим. автора: я кажу про «канонічний» скрам).

А потім — поінти стануть «стратегічною ціллю». Будьте готові «пояснювати за кожен поінт у різниці з минулими спринтами». С цим пов’язано дуже багато ризиків, можна окрему статтю написати. (Не кажучи вже про інфляцію або дефляцію поінтів у команді)

В цілому, погоджуюсь з висновком автора. Згадуючи про Рона Джефріс, дуже рекомендую подивитись відео з ним щодо поінтів: youtu.be/UEDvKAqOuZU (Приблизно те саме, що написано у статті, котру згадували)

Чому у нас успішне адаптування поінтів настільки рідко трапляється, що його скоріше вважають за статистичну помилку? (Збій у матриці)
Основна — це те, що більшість компаній на українському айті ринку — аутсорс/аутстаф, де клієнтам потрібні конкретні цифри, дати, години та інше. Поінти банально не про це. Є й винятки. Працював на проекті, де ми були частиною середовища продуктової розробки клієнта і їх повністю влаштовували поінти, бо вони самі не до кінця знали де вони опиняться за 1-2 роки, бо дуже швидко єволюціонував ринок.

Згоден з вами. Дякую за розвернутий комент та лінку на відос :)

Основна — це те, що більшість компаній на українському айті ринку — аутсорс/аутстаф, де клієнтам потрібні конкретні цифри, дати, години та інше

Це усім потрібно. Строки та бюджети мають значення для будь кого. Уявіть що ви робите ремонт в квартирі платите бригаді по годинно, а вони не можуть сказати закінчать вони скажімо до грудня чи це буде йти аж до серпня. Ви за цей час ні можете ані жити в квартирі, те ще і сплачувати по рахунках за комірне, податки та платити бригаді. А ви можете наприклад брати під цей ремонт кредит, плануючи пустити квартирантів і отримувати прибуток принаймні з червня. А agile теж можна прорахувати дати soft deadline, hard deadline тощо. Головна відмінність — вимоги можуть змінюватись безпосередньо під час роботи, якісь бути прибраними якісь навпаки доданими. Можна проводити репланінги, змінювати софт під потреби бізнесу прямо по ходу роботи. Тому власне гнучкі методології і набули такої популярності, бізнес здебільшого не може дати чітких вимог до ПЗ — він їх і сам не знає. Щось із початкового плану виявиться не потрібним, щось навпаки з’ясується — потрібно будь що додати тощо.

Мова у статті йшлася про оцінювання завдач у командах. Те, що описуєте ви — вірно. Але це більше про team-company alignment.

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

Якщо вони не знатимуть вимог що робити — так і буде. Ремонт це у більшості випадків waterfall. Поінти (чи скрам тут) — це неправильно обрана методологія.

А agile теж можна прорахувати дати soft deadline, hard deadline тощо

Можна, але зі зміною вимог усі дедлайни та коммітменти стають марною працею.

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

Але накладати поінти на час (канонічні поінти) — погано, це факт. Бо це суперечить їхній первинній цілі.

Смотря как. Если 1 s.p. = X ч. тогда да.
Если 1 s.p. = X ч. ± дисперсия, при том что Х на дистанции будет себя вести как математическое ожидание, т.е. если взять все таски в 1 s.p. взять их фактическое выполнение в часах и посчитать среднее. В таком случае можно примерно перевести.
Причем дельта, чем более зрелая команда тем будет меньше.

Дивіться час вам всеодно треба вимірювати, час та гроші не можна не вимірювати. Справа в тому як ви це робите, оцінюєте окремі задачі і опрерації, вважаючи їх типовими, чи оцінюєте кількість роботи яку виконує команда за певний строк на вдаючись у подробиці, команда сама вам каже яка складність. Перший підхід з конвеєрного виробництва Генрі Форд-а, в принципі він зав’язаний на тому що сам робочий не має достатньої кваліфікації щоб сказати скільки займає та чи іньша операція, тому це має із секундомером заміряти якийсь спеціальний менеджер, вирахувати середня значення — і потім як хтось не вписується в середні строки зробити відповідні дисциплінарні висновки. З часом цей підхід в high-tech себе не виправдав, бо не так вже і багато типових завдань існує. Почали вимірювати і експериментувати ще в 60 в IBM тощо. Через що і написаний світовий безцеллер Фредеріка Брукса — «Міфічний людино-місяць», цій книжці багато років але вона актуальна по сьогодні. Другий японський підхід навпаки набув великого використання в ІТ, виявився дієвим. Єдина величезна проблема гнучких методологій — вони надзвичайно важко впроваджуються, обов’язково потрібні тренінги для усього персоналу і взагалі це завдання усієї організації щодо створення і підтримання процесу, це справді важко, потрібна відповідна кваліфікація. Тому постійно маємо такі холівари про оцінку завдань тощо. Це вже багато років йде, однак треба сказати, що всеж ситуація дуже покращується із роками і гнучкі методологіє зараз є переважними, хоча через це і дуже багато псевдо-аджайлу.

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

Чогось не зовсім зрозумів. Ви кажете що у вас сторі-пойнти не працюють як елемент оцінювання тому, що ви самі кажете що не витримали технологію за якою ці самі сторі пойнти визначаються. Щоб скрам із сторіпойнтами працював потрібна явана або неявна позиція скрам-майстра котрий буде слідкувати за тим, щоб регламент витримувався, бо Agile — це МЕТОДОЛОГІЯ як наслідок нам потрібен методолог що буде слідкувати за впровадженням і чистотою метода.

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

абсолютно вірно! треба ретельний контроль ззовні, і коли його немає, то як раз така помилка і може статися — як психологічний тиск авторитетних членів команди, як в принципі і інші потенціальні помилки шо описані в статті :)

тут думка до того — шо впровадження сторіпоінтів це не просто — тепер ми крокодилами міряємо наші ефорти — це доволі складний та не до всіх підходящий процес :)

Ну тобто це методологія а не просто церемонія. Навіть у оцінок у людино*часах є методології.

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

Сторри поинты — это наихудшая форма оценивания, за исключением всех остальных, которые были испробованы время от времени.

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

Все вірно, велосіти — це швидкість, скільки ви зробили за певний час, як у мене і написано.Так, це факт роботи, який команда зробила. АЛЕ! ви рахуєте наступний спринт орієнтуючись на ЦЕ ЧИСЛО. яке на РІЗНИХ етапах може ЗМІНЮВАТИСЯ згідно Такмана ;)

альтернативи — зрозумілі всім години :)

Тю, так перестаньте це робити, не орієнтуйтесь на це число, хто вас примушує? Я ось не орієнтуюсь і вам не раджу.

Години — альтернатива, яка ніфіга не краще, нажаль, жодна з проблем зі статті не вирішується з годинами. Велосіті у вас, теперь, 40 в тиждень, константа, нічого не змінюється, все стало передбачуваним, теперь Такман радіє, бо командна динаміка тепер якась інша, і через години її можна точно спрогнощувати і компенсувати? Ні. Різні розуміння складності в команді кудись поділись? Ні, просто теперь спори не за кількість сторі поінтів, а за кількість годин. Торги і психологічний тиск команди не мають ніякого відношення до одиниці виміру. Я уж мовчу шо залежності також не мають до засоба оцінювання ніякого відношення.

Так, отці визнають неідеальнісь сторі поінта, але шось я не бачу шоб хтось з них додавав шо «людиногодини краще».

Стосовно годин — чому це краще, на мою думаку. Тому шо кожний вже несе відповідальність сам за свою оцінку , а не загально-командне-безвідповідальне. Джуніор скаже свою оцінку за скильки він цю задачу зробе, сіньор свою. І ми вже не міряємо «середню температуру в палаті» коли у одного 36 а у іншого 40 і значить десь 38 , а ми тепер плануємо спринт орієнтуючись на оцінки конкретних людей шо будуть робити ці задачі. Ну, і тут вже ми можемо з легкістью вже взяти та накидати діаграму Ганта і спланувати в деталях наш спринт який буде з більшою вірогідністю вдалим

Взагалі, краще оцінювання — без оцінювання :D але то сильно гарним світ з розовими поні буде :D

У цьому випадку, кожен буде підганяти свою роботу під ще, щоб досягти цілі та його не вигнали. Не кажучи про те, що з 40 годин на тиждень, реальна кількість годин, коли людина може бути ефективна — не більше 30 (6 на день). (Писав у своєму коменті про майндсет)

На мою думку, оцінка у годинах (середніх та великих проектів) має величезну похибку. Неможливо точно оцінити проект у 1000 годин без похибки у 20-30%. І це будуть тільки закладені менеджером ризики. Ще можуть бути непередбачуванні. У проект у 1000 годин стане проектом у 1300 годин. Це ж дофіга!

Сазерленд колись розповідав як вони оцінювали 9-місячний проект у поінтах. Виглядає стрьомно (я так не сильно часто робив), але якщо йому вірити, то через поінти в них був головний фокус на тому «що важливого ми можемо вставити у ці 9 місяців» замість «як нам за 700 годин зробити проект на 1300». Де-факто, це приблизно одне й те саме. Але різниця у тому який фокус ви даєте команді.

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

а чому отразу «чморити за перфоманс»? Я так не казав :) Це приклад із вашого досвіду?

Так, колективний інтелект штука класна і працює, але часто люди роблять помилку коли беруть середнє значення всіх оцінок. От наприклад джуніор робить задачу за 8 годин, сіньор за 2. в середньому це буде 5 годин. тобто тут або синьор 3 години байдики бити буде, або джуніор віддасть задачу не готову до кінця :) усереднили не дуже вдало таким чином :) якшоб спланували по задачам кожного — то всі б виконали точно вчасно свої задачі. Але це знову ж таки — доволі гіперболізований приклад, як і більшість тут

Так а шо ж ще можно отримати з індивідуальної оцінки? Я ж питаю, але відповіді нема. Точно не точнісь.

Люди взагалі роблять помилки, і коли беруть середнє (доречі, хто вас заставляє брати середнє? яка такая методологія так вам каже?), і коли просто дають свою індивідуальну оцінку. При чому, в останньому випадку точнісь гірша, чому є достатньо доказів.

якшоб спланували по задачам кожного — то всі б виконали точно вчасно свої задачі.

Це така Наївність шо я навіть не знаю, звідки почати...

Підписатись на коментарі