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

Проблема полягає в тому, як я повинен підходити до вигорання? Якщо я згуртував години разом, припустимо наступну оцінку:

10 годин - Dev час

4 години - QA

4 години - Огляд коду.

Оцінка завдань = 18 год

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

ОНОВЛЕННЯ

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

1. Хтось розробить завдання. (зробіть одиничні тести, тощо ...)
2. Спеціаліст із контролю якості для перегляду завдання (вони в першу чергу роблять інтеграційні та регресійні тести)
3. Технічний привід зробити перевірку коду.

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

Моє запитання до тих, хто працює таким чином, було б як спалити "завдання", коли вони налаштовані таким чином. Якщо у Завдання немає власних підзадач (яких JIRA не дозволяє) ... я не впевнений, що найкращий спосіб щодня відстежувати "те, що залишилося".

Це 3 завдання, а не одне.

Це може бути одна особливість / історія, але це три завдання. Одне завдання може виконати одна людина за обмежений час.

TL; DR

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

У Scrum вам слід вимірювати прогрес до досягнення цілі спринту, а не вимірювати таймфрейм спринту. Це дозволяє зосередити увагу на потенціалі команди та доставці функцій, а не на постійних налаштуваннях планування.

Завдання проти оповідань

Ви плутаєте завдання та історії. Історії містять усі завдання, необхідні для завершення розповіді, відповідно до "визначення вашої команди". Історія вважається 100% незавершеною, якщо всі її завдання не виконані. У Scrum історії завжди певним чином оцінюються; найчастіше вони оцінюються в балах історії.

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

Випалювати

У Scrum, ваша схема згоряння показує кількість роботи, що залишилася для спринту чи проекту. Справжні графіки вигорання часто мають плато; в деяких випадках графік може навіть піднятися. Наприклад, на тижневому спринті з двома історіями вартістю 3 та 5 балів ваші точки даних можуть виглядати приблизно так:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

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

Бокс-тайм

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

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

Чи можете ви визначити завдання розробника як "виконане" до того, як QA виконає свою роль? Чи можете ви визначити огляд коду як "зроблено" до того, як буде зроблено dev? Чи може QA бути "зроблено", якщо розробка розробників та коду не є?

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

Scrum НЕ каже, що будь-який предмет несе відповідальність за одного члена команди. Якраз навпаки - елементи спринтерського журналу - відповідальність КОМАНДИ. Якщо для виконання завдання потрібно три людини, то для цього потрібно.

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

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

Після первинної оцінки, наша неофіційна інформація стає більш відсотковою, ніж залишилося години. Якщо ми спочатку думали, що це займе два дні, але після одного дня, ми вважаємо, що це лише 25%, ми беремо 4 вихідних 16 годин. Це залишає 12 годин, де технічно ми оцінюємо 24, тому що, ймовірно, ми відрахуємо 4 години на три дні.

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

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

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

Це сказав:

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

Розділіть завдання на кілька завдань і введіть їх як завдання, де кожне обробляє інша людина.

Оригінальне завдання: щось виправити

Нові завдання: (дитина з батьків початкового завдання)

• Dev A - виправлення проблеми
• Dev B - допомога Dev A у вирішенні проблеми (тобто програмування пар, перегляд коду)
• Dev A - розробник тестує виправлення за допомогою набору даних X
• Dev B - dev тестує виправлення за допомогою набору даних Y