Як оцінити сюжетні бали для вашого проекту?

| | 0 Comments| 5:27 AM
Categories:

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

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

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

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

Тепер для того, яке саме значення, це не має особливого значення. Правда, найпоширенішим представником сюжетних оцінок є Story Points. По суті, це числа Фібоначчі, починаючи з 0, 1, 2, 3, 5, 8, 13, 21 тощо. Наступне значення є сумою попередніх двох чисел. Це допоможе відрізнити загальну складність історії, оскільки кожне наступне більше число є значно вищим за попереднє.

Але вам не потрібно прив’язуватися до сюжетних моментів. Це можуть бути орієнтовні розміри футболки (XXS, XS, S, M, L, XL, XXL). Якщо ви хочете бути дійсно креативними, ви можете представити тварин ZOO та використовувати їх для оцінки розміру.

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

Компоненти оцінки сюжетних балів

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

Остаточна оцінка – це значення, яке представляє комбінацію всіх аспектів, сформованих в одне число. Ось що має включати така оцінка.

#1. Технічна складність

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

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

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

#2. Зовнішні залежності та ризики

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

  Кращі маршрутизатори DD-WRT у 2019 році для вимогливих досвідчених користувачів

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

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

#3. Фактор повторного використання

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

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

#4. Розуміння власної команди

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

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

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

Оцінка історії

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

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

Приклад процесу оцінки

  • Виберіть інструмент оцінки для команди, наприклад Planning Poker, дошку Miro тощо.
  • Розмістіть історію на дошці. Дозвольте команді обговорити останні думки або запитання щодо історії. Переконайтеся, що вся команда повністю обізнана з історією та готова оцінити.
  • Почніть оцінку. Кожному члену команди пропонується вибрати число зі шкали Фібоначчі.
  • Коли всі оцінені, подивіться на результати разом. Почніть обговорення. Зазвичай команда розділяє від двох до трьох номерів. Нехай люди з нижнього рівня обґрунтують, чому оцінка має бути такою низькою. Тоді нехай люди з іншого кінця пояснять, чому остаточна оцінка має бути такою високою. Мета полягає в тому, щоб викласти всі аргументи, міркування та факти, щоб уся команда була на одній сторінці, щоб зрозуміти, що включає ця історія.
  • Після завершення обговорення нехай команда знову оцінить. У більшості випадків команда тепер перетворюватиметься на одне або два окремих числа. Повторіть обговорення ще раз. Залежно від конкретного випадку, або команда узгодить остаточне число з двох альтернатив, або ви виберете інший раунд оцінки.
  • Оцінка закінчується лише в тому випадку, якщо всі члени команди абсолютно влаштовують остаточну оцінку. Це має бути згода всієї команди, а не кількох осіб. Потенційно кожну історію можна пізніше призначити будь-кому з команди. Ось чому важливо, щоб усі погодилися з тим, наскільки складною є історія.
  •   Як активувати свою кредитну картку Chase онлайн

    Зобов’язання щодо плану спринту

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

    Настає сесія планування, під час якої команда вибере кілька історій для наступного спринту. Рішення про те, які історії вибрати, має ґрунтуватися на наступному:

    ✅ Історії з найвищими пріоритетами команда розглядає в першу чергу.

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

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

    Фактор швидкості

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

    Щоб мати можливість точно спланувати вміст для спринту, ми об’єднуємо обидва аспекти:

  • Швидкість команди – вимірюється в днях. Один член команди доступний протягом одного повного дня, що дорівнює одиниці за швидкістю команди. Наприклад, команда з 10 осіб, повністю готова для спринту тривалістю 2 тижні, дорівнює місткості команди 100.
  • Звичайна кількість сюжетних балів, завершених протягом спринту – вимірюється в сюжетних балах. Це число випливає з попереднього досвіду та тісно пов’язане зі швидкістю команди.
  • Потрібен час і практика, щоб знайти найкраще місце.

    Переваги та поширені помилки

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

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

      Як встановити AutoGPT за лічені хвилини

    У будь-якому випадку, ось що станеться, коли команда «зрозуміє»:

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

    І ось що зазвичай відбувається, якщо команда все ще не може зрозуміти процес або спосіб роботи:

    • Вони чомусь досі дотримуються старомодних оцінок людино-днів. Вони конвертують усе в дні або залучених людей. Сюжетні точки або числа Фібоначчі означають кількість днів, прямо чи опосередковано, через різні перетворення.
    • Керівництво порівнює команди на основі кількості сюжетних очок, отриманих за кожен спринт. Це настільки неправильно, наскільки це можливо. Істотний факт тоді не розуміється: кожна команда оцінює моменти історії по-різному. Немає жодних причин намагатися синхронізувати дві команди, щоб оцінити їхні історії «однаково».
      • У той час як сюжет однієї команди означає малювання кола, для іншої команди це може означати малювання будинку з плоским дахом, чотирма вікнами та двома дверима. І це цілком нормально.
    • Іноді команди схильні оцінювати майже все від двох до чотирьох різних чисел. Можливо, тому, що вони бояться, що історія має число 123, хтось подумає, що це якось пов’язано з кількістю днів. Але справа в тому, що шкала Фібоначчі має нескінченну кількість чисел. Нам не потрібно обмежуватися лише оцінками 3, 5 або 8. Ми, звичайно, можемо (і, можливо, ми створюємо історії вже з цією метою, щоб вони були такими складними, у такому випадку це добре), але ми точно не потрібно.
    • Оцінка здійснюється старшими людьми, які визначають очікування всієї групи. Ми ніколи не повинні дозволяти впливати на оцінку одного члена команди. Кожен має рівне право висловлювати свою думку та бути почутим.

    Заключні слова

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

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

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