Перегляньте історії

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

Ось як ми робимо:

Історія Оцінка: 24 години (8 годин на день - ми використовуємо "ідеальні дні" в якості міри)

• День N: розробник починає працювати над Story A зранку (8 годин роботи завершено до кінця дня)
• День N + 1: Переоцінка історії = 16 годин (один робочий день, знятий із Історії A, з дня N)
• День N + 2: Переоцінка історії = 8 годин (один робочий день, знятий із Історії A, з дня N + 1)
• День N + 3: Історія А має бути завершена вже зараз. Але це не так. Розробник вважає, що на завершення піде ще 3 години. Ми оновлюємо історію на дошці та відповідно записуємо .
• День N + 4: історія A закінчила весь день, а не лише 3 години! Зараз це зроблено. Різниця, 5 годин, зовсім не враховується в нашому плануванні.

Як ми повинні щодня переоцінювати свої історії?

Різниця, 5 год, зовсім не враховується в нашому плануванні.

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

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

Питання, яке вам слід задати, таке: чи варто переосмислювати наші історії?

Я заперечую, що ви повинні дозволити Agile "магії" врівноважувати ваші недооцінки і ітерації під час обчислення швидкості для наступного (що є єдиною причиною виправити значення). Докладніші відомості див. У " Гнучкому оцінці та плануванні" Майка Конна .

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

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

Що я вважаю найефективнішим:

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

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

Щоденні переоцінки того, що залишилося, як правило, є абсолютно неправдивим, як ви описали у своєму запитанні. Робота завершена / залишилася - це неправдиве число, розроблене так, щоб виглядати так, що ви працюєте "досить наполегливо". Набагато краще, щоб запитати: "Коли ти думаєш, що ти закінчишся", і уточнити, що якщо є проблема з історією, команда підійде, щоб допомогти.

Я думаю, це не проблема. Швидше, це може бути брак досвіду. Чим більше ви стежите за scrum, тим більше розробників звикають надавати точніші оцінки. Це наш досвід впровадження scrum через 5 місяців.

У плануванні покерних сесій, наші розробники пропонували найрізноманітніші оцінки для кожного PBI і кожного завдання в першому спринті. Однак зараз ми майже рівні за часом та оцінкою. Як довго ви використовуєте scrum? Якщо не так багато, приділіть трохи часу. Але якщо це давно, то, як запропонував @pdr, подумайте про додавання додаткової надбавки до завдань з більш високими ризиками . Наприклад, кожен раз, коли наша команда хоче зробити частину крос-браузера інтерфейсу користувача, ми передаємо нашу оцінку. Таким чином, ми завжди множимо оцінку завдань між браузерами на коефіцієнт, щоб переконатися, що ми можемо їх покрити.

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

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

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

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