Story Points при оцінці роботи


Один з ефективних способів оцінки роботи в розробці програмного забезпечення є використання Story Points. Story Points засновані на розмірі та складності, а не тривалості. Вони також вимірюються не сталими величинами, такими наприклад як час – години або дні. Ще одина хороша якість Story Points, що вони трансформуються і налаштовуються, на відміну від часу. Крім того, їх дуже легко зрозуміти.

Цінність Story Points

Це завжди важливо, щоб використовувані оцінки мали сенс. Багато команд використовують такі одиниці:

– Розмір одягу: XS, S, M, L, XXL
– Послідовність Фібоначчі: 1, 2, 3, 5, 8, 13, 20, 40
– Сила двох (кожне наступне число в двічі більше за попереднє): 1, 2, 4, 8, 16, 32

З використанням цих одиниць, також повинна бути правильна стратегія процесу оцінки. Не зовсім правильним буде запитувати: “На скільки це завдання складне в вимірі від 1 до 10 сторі пойнтів?” У цьому випадку буде важко отримати хоть приблизно правильну оцінку завдання.
Оцінка повинна бути використана в історичній перспективі. Краще запитати щось на зразок цього: “Останнім разом робота на цим завданням у нас заняла 5 пойнтів. Це завдання більше чи менше? На скільки більше? Два рази, в три рази?”

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

Схожі статті

Waterfall vs. Scrum Що таке “Waterfall”? Waterfall являє собою планове управління проектами з розробки програмного забезпечення. Зазвичай ви працюєте з діаграми Ганта & Microsoft Project, у вас є початкові і кінцеві дати, а також фази проекту. У Waterfall, фази р...
Історії користувачів (User Stories) Історії користувачів в agile термін, що традиційній розробці називають "програмні вимоги". Вони є короткими заявами про намір або вимога до системи. Ось основна формула написання історії користувача: Як <роль> я хочу <функція> щоб <...
Розуміння ролі Продуктного менеджера в Скрам Відповідальність Повинен мати спільне бачення Розробляє Winning продукт Власник продукту управляє зусиллями по розробці програмного забезпечення в цілях створення якісного продукту Інші функції A) Створення бачення продукту B) Підтримка...
Definition of DONE в розробці програмного забезпечення Давайте уявимо, що в кінці кожної ітерації в SCRUM або будь-якому іншому способі Agile розробки програмного забезпечення, розробник приходить до вас і каже: "I'm done with this functionality! або функція зроблена" Але ви, звичайно, запитаєте: "Що т...