Як ми надаємо дійсні оцінки часу під час планування спринту, не роблячи «занадто багато» дизайну?

Моя команда набирає швидкість із Scrum, але більшість із нас більше знайомі з не спритними або "псевдо-" спритними методологіями. Частина, яка є найбільшою перешкодою для нас, - це проведення ефективної зустрічі з планування спринту, на якій ми розбиваємо наші пункти відставання на завдання та оцінюємо години. (Я використовую термінологію з VS2010 Scrum Template; вибачте, якщо я десь вживаю неправильне слово.)

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

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

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

Редагувати:

Просто для уточнення, оскільки деякі зауваження / відповіді дуже справедливі, але я думаю, що вирішувати неправильне питання.

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

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

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

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

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

3. Плануючи, майстер scrum повинен продовжувати планування, закликаючи зупинити будь-які дискусії, які занадто далеко переходять у "вирішення". У цей момент члени команди зобов’язані швидко домовитися про кошторис, зазвичай, даючи верхню межу / найгірший випадок. Набагато простіше підібрати більше роботи, якщо завдання закінчуються легше, ніж ви плануєте, ніж боротися з розкладом графіків через те, що завдання займають більше часу, ніж планувалося, і історії перекидаються на кілька спринтів.

4. Поговоріть про те, як оцінювання випадали в ретроспективі в кінці спринту. Особливо, якщо були якісь, що були надзвичайно далеко. Чи дізналася команда щось із того, як пішла історія проти того, як вони очікували, що вона піде? Майстер scrum повинен зосередити увагу на змін, які можна змінити, які можуть бути внесені до вашого дизайну / оцінки.

Я думаю, що проблема полягає в тому, що ви намагаєтеся оцінити час. Не варто.

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

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

Я настійно рекомендую застосовувати історії користувачів Майка Конна .

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

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

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

Автоматичні критерії приймання

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

Наприклад, "Коли користувач натискає" відтворити "на iPad під керуванням iOS 6+, відео починається." Це може бути важко насправді автоматизувати цей тест, але це критерії прийняття (AC) історії та сприяє одному балу.

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

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

Попередній догляд

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

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

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

Обмеження незавершеного виробництва

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

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

Як тільки історія переходить із запущеної роботи в незавершений процес, ми характеризуємо її як одну з кількох держав:

• На затриманні - робота в команді не може відбутися, тому що ми чекаємо на деяку позакомандну діяльність
• У розвитку - робота над досягненням критеріїв прийняття
• Тест потреб - ми вважаємо, що ми зустріли АС, чекаючи, коли хтось інший перевірить
• У тесті - історія оцінюється проти змінного струму, вирішуються помилки
• Готовий до розгортання - при наступній доступній можливості він розпочнеться наживо

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

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

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

Тут ви можете зробити дві речі.

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

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

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

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

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

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

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