Які реальні альтернативи Story Points ви використовуєте на проєктах?
Нещодавно прочитав статтю, де обговорювали недоцільність використання Story Points. І там прозвучала думка про те, що як би ви не називали свої оцінки — поінтами, майками, числами Фібоначчі чи навіть крокодилами (найкращий варіант, до речі) — бізнесу все одно потрібні дати. У результаті команди просто таємно конвертують «1 SP = 1 день» за спиною у скрам-майстра.
Окрім цього, завжди є проблема різних трудовитрат, коли розробнику для задачі треба 10 хвилин, а QA після цього робить два дні регресу. Спроби звести це в один абстрактний Story Point часто перетворюються на бюрократію, через що навіть творці Agile вже кажуть, що міряти velocity — це марна трата часу.
Тому цікаво дізнатися, хто у своїх командах вже відійшов від класичних SP. На що ви їх замінили та чи оцінюєте одразу в годинах, практикуєте #NoEstimates чи маєте власні метрики для синхронізації розробки та тестування?
31 коментар
Додати коментар Підписатись на коментаріВідписатись від коментаріврозміри футболок S,M,L,XL, XXL
немає прив’язки до «міфічної людино-години»
має відношення тільки відносто інших задач
це по суті ті самі Story Points, лише замість цифер літери
сторі пойнти працюють тільки в командах які вже спрацювались за2-3 роки
в командах свіжозібраних сторі пойнти це абсолютне марнування часу, бо у кожного з команди своя метрика
Таа для цього естімейшн покер і робиться щоб усі зійшлись з рештою до одного показника. Припустимо скрам майстер каже, максимум що влізає в один спринт — 8 sp (13, 21 не важливо). Якщо отримуєм більше — таку user story треба розбити на менші фрагменти.
Використовував замість сторі-поінтів дві метрики:
— обʼєм змін (кода, інфраструктури, бази і тп), який потрібен для реалізації: в абстрактих одиницях, наприклад, t-shirt sizes
— рівень визначенності — наскільки зрозуміло, що саме робити. Одиниці виміру — шкала від repeat до research. Показує, наскільки таска схожа на щось, що ми вже робили, наскільки ми розуміємо усі деталі.
Але це все не вирішує все-одно святий грааль менеджменту — давати точні дати, коли таска буде зроблена.
Якщо би можна було дати точні дати, ми би вийшли на рішуче інший рівень виробничосиі праці в ІТ. Для цього і порібні оцінки саме в умовних функціональних одиицях і при чому які ростуть якраз не ленійно, чим складніша задача тим вона займатиме усе більше часу.
Чому так — бо використовується науково доказовий метод в розробці ПО — більше вам відомий як відлатка і тестування. А як мр знаємо ще від Сократа, на початку будь яких дослідів — нам не відоме, більше за ніж нам відоме.
з естімейтами є 2 проблеми які +\ неможливо вирішити просто так
1. бізнес очікує і комітиться на результат ще до того як відома проблема
2. естімейт не може бути точним, це естімейт.
визначення слова Estimate: to guess or calculate the cost, size, value, etc. of something.
тому ми всі робимо ці SP бо звикли, бо бізнес хоче, бо нам не*уй робити. Вихлопу від цього коли мова йде про нові рішення, про складні рішення — мало.
я бачив альтернативний підхід (олдовий аджайл коуч розповідав на відео), просто планувати сторі без естімейтів. Питаєте дев команду скільки з цих сторей вони можуть взяти в спринт, плануєте і працюєте. Якщо у вас нормальна команда у якій все ок з комунікацією, ви за3-4 спринта і так вийдете на своє «велосіті» по сторям. Але ви не будете використовувати 100500 церемоній і танців з бубнами.
в моїй команді ми юзаємо СП бо так роблять всі інші команди. Але просто зводимо це все до мінімуму щоб не витрачати тонни часу. Зробили більше — клас. Зробили менше — тут вирішує пріорітизація, головне зробити важливі речі спочатку.
акиуальну тему ви підняли, враховуючи нові вводні — ші агенти. девам важко оцвнити сторіки, адже немає впевненості що агент справиться. цікаво які з’являться нові фреймворки чи зміняться існуючі
ничего не изменилось вообще, кроме велосити, но его считать не надо
Цікаво, чи взагалі є якісь естімейти байдуже в якій системі вимірів, які хоч раз справдилися.
Типова розмова:
— Начальство: намалюйте естімейт.
— Деви: На!
— Начальство: Задохєра! Вріж вдвічі, а краще втричі.
— Деви: ну ок, х з вами
Минає час.
Начальство: якого х ще не зроблено?! Ми ж такі класні естімейти намалювали!
естімейт стає реалістичним, якщо його помножити на «3.14»
— Начальство (своєму начальству): показує перший естімейт, який дав дев, помноженний на два (а краще на три)
— Начальство начальства: Задохєра! ...
Сторі пойнти це супер.
Контрольованою інфляцією естімейтів можна малювати дуже гарні річні графіки
Не плутайте оцінку з забов`язаннями на виконання роботи в зазначені строки, оцінка потрібна для того якараз щоби прийняти рішення і не потрапляти в ситуації коли взяли на себе забов’язання більші ніж реально здатні виконати. По технології Scum Mater та Produсt Owner з кожною новою ітерацією питають у команди робити усе більше за їх власною оцінкою. Як вже зазначалось кінцевому замовнику абсолютно усеодно скільки ви витратили сторіпоінтів або людиногидин, папуг чи написали операторів створили файлів і т.д. Їм цікавий функціонал із домовленим рівнем якості в строки та бюджет. А зайняло це 3 сторі поінта чи 100 не має значення.
Альтернатива — міфічні людиногодини.
Story points самі по собі, йдуть із такою штукою як Sprint Goal. Тобто за два тижні вам треба показати бізнесу якийсь вімірюванний і конкретний функціонал, на який ви закомітились — а пойнти оцінки порібні щоби дізнатись — а це в принципі реалістично або ні.
Те що чомусь сюрприз для ІТ бізнесу — швидкість розробки не ленійна, а експансійна. На початку розробки в началі проекта може бути в 10 і більше разів повільніше ніж в кінці, поки команди спрацьовуються прояснюються вимоги тощо. Це можна і на калькуляторі прорахувати коли Fixed Price, розбити на ітерації по два тижні із цілями на них, закласти час під ризики і вийти на дати.
зі Скрам-покером — це, нмд, маніпулятивна фішка, щоб примусити швидко дати непрорахований естімейт з подальшим тиском по таймінгу і красноглазінгу.
В сеннсі маніпулятивна ? Навпаки спливає постійно, що люди не розуміють повнюстю складності і те що в задачі не тільки їх частина, а наприалад : UI/UX, Security Audit, Dev Ops та QA робота і т.д. і т.п.
Дісно буває емітація процессу — коли назва Agile, реально в кращому випадку Waterfall model, чи улюблений усією індустрією — хаос (ляп-ляп і в прдакшн, дивись досліди університету Кернегі Мелон на замовлення Пентагона uk.wikipedia.org/...Capability_Maturity_Model і стандарт ISO/IEC 15504 SPICE який створено на його базі, 80% організацій мають хаотичний процесс розробки).
Перший симптом коли усі естімейти на планінгу проставили вже хтось з гори тільки не команда яка виконуватиме роботу і ій озвучують строки в які вони мають вкластись, бо вже домовлено по контракту там і т.д. Це підход до ІТ як до копання каналів землекопами. Другий симптом — жодного притомного опису задачі, тобто аби шо написано в якості вимог, а то і взагалі нічого не написано. В таких умовах будь який естімейт в будь яких одиницях вимірювання — профананція. Лікується тільки зовнішнім аудитом і принудиловкою до слідування процессам. Хто з середкни спробує міняти такий процесс — вилитить з колективу як корк з бутилки шампанского.
бо планнінг робиться БІГОМ після того, як ПМ + BI + овнер1-2 рядками тексту. А команда в цей час намагається встигнути зробити поточні таски. І починається оцінка погано-документованих і мало-зрозумілих хотєлок.10-20 тасок.
створили перелік тасок, описаних
Якщо десь і дають ознайомитись з тасками заздалегідь, то все одно, мало в кого з девелоперів є час на аналіз
DoR — зміною сторі поінтів на години, ніяк не з’явится, і не в сторі пойнтах проблема. Це як кричати, що в усьому винуваті квадратні колеса в бричці що не їде та яку купили за багато грошей, а на повірку це не бричка — а сучасний снігоход і його треба заправляти бензином і мастилом, а не запрягати ще більшою кілкістю волів і стігати іх пліттю дужче.
это просто относительно дешевый метод оценивания с хорошо прогнозируемой погрешностью. для того чтобы погонщик давил на красноглазинг оценивание не нужно, нужно желание погонщика
Ну, по-хорошому, планнінг покер має зменшити вплив персонального біаса (коли хтось в команді систематично завищує естімейти, хтось систематично занижує тощо), але це занадто примітивний підхід, який не враховує купу всього.
То це дві різних задачі в одній юзер сторі. І сторі має мірятися сумою усіх задач, від котрих вона залежить.
Якщо говорити про SP, то зазвичай це одна оцінка, а не дві різні.
Якщо в годинах, то так, ваша теза має сенс
От і проблема, що ви намагаєтеся змусити людей, котрі робитимуть дві різні задачі (кодінг та тестування) надати одну оцінку!
та немає проблеми. бо я нікого нічого намагаюсь змусити. Я просто ділюсь тим як воно працює.
Якщо ви даєте оцінку в SP і вона різна від різних учасників процесу, то для чого вам воно потрібно? :)
Мають бути дві задачі з незалежними оцінками. Одну оцінюють деви, іншу — тестувальники.
В даному випадку Duplication is far cheaper than the wrong abstraction
sandimetz.com/.../20/the-wrong-abstraction
Тоді це не про User Story і тоді вже це не про Velocity.
Взагалі поки не зрозумілий для мене предмет спору 😅😅
не за спиною, а прямо зі скрайм-майстром конвертують.
SP в якомусь сенсі являється рудиментом, але все ще глибоко живе в багатьох компаніях і командах.
У нас оцінка годинах. На моїй пам’яті я ще не зустрічав компаній в українському простору з підходом #NoEstimates :)
я лет 6 так работал за все время, 2 из которых сам это устроил в качестве хед оф девелопмент и 4 года в роли архитектора. Что характерно обе компании отказались от эффективных менеджеров, которые30-50% времени на эти эстимейты у команд и забирают вечными митингами не о чем
Повезло там де ви працювали цей час :)
просто багато речей з часом перетворюються у бізнес, а для бізнесу треба всяку х***у щоб можна було продавати
аджайл почався з базових речей — давайте клієнту\користувачу якісний код, більше спілкуйтесь між собою, менше зайвих процесів. Як всі ці речі перетворились на 100500 мітингів і церемоній? Бо хтось захотів продавати курси і книги. Треба було заповнити це все ендлесс контентом.