Команда оцінює сюжетні моменти, бізнес хоче фактичного часу

Я впевнений, що це не рідкість. У нас є дві команди scrum, які виконують добру роботу з оцінки історій користувачів за допомогою сюжетних точок (нинішнім сузір'ям команди є лише близько 8 місяців, хоча члени команди мають декілька років досвіду роботи з scrum). Але діловій частині компанії важко пов’язати з історіями користувачів; вони хочуть фактичних одиниць часу (або "формулу для перетворення точок історії в години"), щоб вони могли скласти план, коли речі будуть готові ( "нам потрібно знати, коли ми можемо сказати клієнтам, що Feature X буде вироблятися " ).

Я, і мій попередник майстра scrum, звичайно, пояснили, що "немає певного зв'язку між пунктами історії та реальним часом" і що "сюжетні точки використовуються для визначення кількості команди може вміститися у спринті", і я Ви впевнені, що можете здогадатися, наскільки вони були задоволені цією відповіддю. Вони все ще хочуть знати, в календарний час, коли ми перейдемо до цієї 27-ої історії користувачів на відсталі.

У будь-якому випадку, я збираю певну статистику, і наші оцінки SP перетворюються на диво різні результати фактично витраченого часу (як це вимірюється нашим програмним забезпеченням на дошці scrum, що відстежує скільки часу витрачають квитки у колонці "працює над") ). Для оповідань користувачів 1-SP, звичайно, є сильний ухил до дуже коротких проміжків часу (з випадковим вибухом), але особливо для 2-SP-сюжетів вони є скрізь: є коефіцієнт 20 між "найшвидшими" та "найповільнішими" завершеннями. Для 3, 5 і 8-SP історій розкид також більше, ніж коефіцієнт 2.

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

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

Назвіть кілька хороших стратегій для залучення ділової сторони , щоб вони не надто сильно втручалися в роботу, як ми працюємо (наприклад, накладенням використання окремого відстеження часу, яке ІМХО було б німим, оскільки воно в будь-якому випадку буде менш точним, ніж поточне "автоматичне" відстеження), і в той же час дозволяють їм отримати певну міру конкретності для того, коли будуть зроблені історії?

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

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

Ви маєте рацію, не існує формули для перетворення точок історії на години. Ви можете отримати досить втратне перетворення метрів на ноги, і навпаки, але ви не можете сказати, що триточна історія займе X годин, тому 5-бальна історія займе Y годин (вирішити для Y).

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

Таким чином, бізнес приходить до вас з 170 очок варті історії та епопеї. Розділіть це за історичною швидкістю команди 50 балів (в середньому кожен спринт поки що) і ви отримаєте 3,4 спринту. Оскільки ми робимо оцінку, обігніть до 4 спринтів: 8 тижнів. Два місяці, в основному. Мені також подобається брати останні 3-4 спринти і брати ще одну оцінку. Скажімо, ваша команда в останніх 3 спринтах зробила відповідно 53, 67 та 55 очок. Це підходить до 58-бальних очок, що при цьому становить 2,9 спринту - так це, в основному, 3 спринти. Схоже, ваша часова шкала на ці 170 балів виглядає як 6 - 8 тижнів.

Розкажіть бізнесу 2 місяці. Не кажіть їм 6-8 тижнів, тому що вони просто почують "6 тижнів". Навіть не кажіть їм 8 тижнів, адже в більшості місяців у них близько 4,5 тижнів, і коли люди чують "4 тижні", вони миттєво думають "1 місяць". Як тільки оцінка досягне приблизно 4 тижнів, вона стає 1 місяць. Тоді просто працюйте місяцями. Якщо ви потрапили на рік або більше, тоді, чесно, просто не оцінюйте цю роботу. Це безглуздо. Занадто багато може змінитися за рік.

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

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

О, і не забувайте найважливішої частини:

Закруглюємо. Завжди.

Напевно, у вас вже є певна притаманна конверсія від сюжетних точок до оцінок часу - як ви вирішили, що вибрали достатньо роботи для свого спринту? Ви, напевно, сказали щось на кшталт "команда може опрацювати 20 (або 40 чи що завгодно) очок на тиждень". Після декількох спринтів, ви зможете переглянути це на основі завершення - тож тепер це 15 або 25 (або 35, або 50, або ...) балів спринт - це швидкість вашої команди .

Для оповідань користувачів 1-SP, звичайно, є сильний ухил до дуже коротких проміжків часу (з випадковим вибухом), але особливо для 2-SP-сюжетів вони є скрізь: є коефіцієнт 20 між "найшвидшими" та "найповільнішими" завершеннями. Для 3, 5 і 8-SP історій розкид також більше, ніж коефіцієнт 2.

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

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

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

Отже, подивіться на 2-покажчик, який зайняв найдовше у вашій ретроспективі. Чому щось, що, мабуть, повинно було б зробити ранок, перетворилося на 10-денний гасло? Чи можна було щось позначити того першого ранку, щоб сказати, "що це повинно стати епічним і розбитий на більш дрібні завдання"? Як тільки це станеться, звичайно, потрібні додаткові роботи повинні бути поміщені у відставання і не заважати решті спринту.

Крім того, спробуйте побачити, як команда недооцінила цей предмет - чи могли б ви краще зробити майбутні предмети, переглянувши його?

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

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

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

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

Я займаюся кількома речами, коли отримую подібні запитання.

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

По-друге, я хочу, щоб клієнт, який стикається з людьми, взяв на себе відповідальність за графік торгів та ризик. Я б сказав щось подібне Пам'ятайте, інженерна команда працює на основі оцінок 50/50. Якщо нічого не зміниться, існує 50/50 шансів, що функція 27 буде готова за 14 тижнів. Імовірно, ви не хочете повідомляти клієнту про щось із таким рівнем ризику. Ви хочете, щоб я розробив оцінку, яку ми маємо, скажімо, на 90%? Тоді вам слід переглянути свої історичні свідчення і сказати щось на кшталт: Є 90% шансів, що історія 27 буде здійснена через 25 тижнів .

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

У вас вже є (дуже жорстка) конверсія:
спринти Scrum (зазвичай) два тижні.
Ви знаєте, що зможете закінчити, скажімо, приблизно 20 історій, що варті функцій за ці два тижні (або як ще ви визначите, що і скільки функцій упаковується в один спринт?), І ваші попередні спринти підтверджують цю оцінку (скажімо ви закінчили 18, 21, 23, 19 та 20 сюжетних точок, варті особливостей у останніх п'яти спринтах).

Скажімо, особливість X (і всі її залежності) оцінюються як 47 сюжетних точок.
Таким чином, ви можете підрахувати, що якщо ви ставите реалізацію цього найвищого пріоритету, вам слід взяти близько 3 спринтів, тобто 6 тижнів (але переконайтесь, що ваші оцінки враховують, хто що може робити - якщо 35 з цих пунктів працюють у БД, а у вас є лише для хлопця БД вам потрібно переглянути передбачувану швидкість, щоб врахувати це).

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

"Коли буде виконано функцію Y ?"
"Якщо ми зосередимося на цьому наступні ... 12 тижнів"
" 12 тижнів ?! Ви сказали, що це займе 4."
"Так, але ви сказали нам , що ви маєте пріоритет на функцію X , за яку ми сказали, що ви зв’яжете всі наші ресурси та займе 8 тижнів".
"Не можете одночасно працювати над функцією X та функцією Y ?"
" стогін "

Спринт визначається часом, скажімо, 2 тижні. Ви не можете передбачити, що якась історія відбуватиметься далі, ніж 2 спринти, як у вашого поточного спринту та наступного спринту. Я припускаю, що ви підготували історії, які обговорювались з командою для наступного спринту та були пріоритетні для бізнесу. Тож найкраще можна точно сказати наступні 4 тижні роботи.

Все, що перевищує 4 тижні, може змінюватися, і бізнес може скласти дорожню карту, яка не встановлюється за години. Це слід планувати за спринтом, скажімо, якийсь epic1 (епічний, як у купі згрупованих сюжетів) та epic2 слід робити у спринтах 47 та 48, а epic3 слід робити у спринті 49. Епіки я оцінюю приблизно за години самостійно до подивіться, чи один або два помістяться у спринті, тимчасова шкала все одно пройде. Якщо функції не працюють, бізнес повинен скоротити сферу застосування або прийняти не ідеальні рішення, які згодом можна буде вдосконалити (це повинно бути спритним, сприймати реальність замість наступного плану).

Ви можете зробити гарну діаграму Ганта (саме такий бізнес подобається) з майбутніми спринтами та основними темами / епосами для них.

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

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

Щодо нових функцій майже неможливо оцінити необхідний час.

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

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

Оскільки оцінка часу майже неможлива, не існує формули, яка б перетворювала сюжетні моменти на часові оцінки. Швидкість може бути лише дуже сильною оцінкою, не більше.

У SCRUM власник продукту може змінювати пріоритети елементів відставання перед кожним спринтом. Тому майстер SCRUM не може дати жодних оцінок для більш ніж одного спринту. Він не знає, який предмет відставання може стати важливим у наступному спринті.

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

До початкової посади:

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

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

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