Що найкраще пояснення того, що таке Story Points?

Тут ми починаємо використовувати пункти Story Points для нашого Agile розвитку, але мені важко пояснити, а також не можу знайти жодної остаточної відповіді на те, що вони є. Найкраще, що я можу зробити, - це вказати на інші сайти (наприклад, http://blog.mountaingoatsoftware.com/tag/story-points ) і дати деяке невиразне узагальнення того, що вони є. Я шукаю гарне пояснення з деякими прикладами використання, які можуть бути корисними для інших. Чи є хороші ресурси для пояснення сюжетних точок?

Це може допомогти в якості початківця: Майка Конна на сюжетні моменти . Але це набагато краще: Agile Development Teams: Scope and Scale з Майком Кон

Рішення Майка в оцінці програмного забезпечення просто і ефективно. Біологічні факти:

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

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

Якщо ваша довідкова історія становить 100 балів, а інша історія втричі більша, то це буде 300 балів.

Щоб перетворити сюжетні точки вчасно для вашого планування, ви повинні знати свою швидкість .

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

Це працює .

Я погоджуюся з усім @Pierre 303: сказано вище: (крім 100 опорних точок).

Єдине, що я хотів би додати (наголос) - це те, що ми не вміємо оцінювати завдання. Ми можемо оцінювати завдання щодо інших завдань, якщо вони приблизно однакового розміру. Чим більша різниця між завданнями, тим гірше ми отримуємо.

Таким чином, я не погоджуюся з використанням стартової точки 100.

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

Наша команда використовує Planing Poker : У цьому ми маємо опорне завдання на 2 очки. Потім ми використовуємо ряд Фібоначчі для оцінки завдань: 1,2,3,5,8,13,21, Величезний,? відносно опорного завдання (Замість того, щоб Фібоначчі я бачив, як інші команди використовують сили 2. 1,2,4,8,16,32, Величезний ,?) Я бачив, як інші команди використовують (малий (1), середній ( 2), великий (3), XLarge (4), коли вони обчислили швидкість, він все-таки спрацював.).

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

Тож якщо ваша довідкова задача - 2SP. Тоді скласти оцінку 1/2/3/5 порівняно просто, оскільки завдання мають однаковий розмір. Після того, як ви пройдете в 3 рази більше, ніж еталонне завдання (5SP), оцінка стає важче (чи має значення 8/9 / 10SP) Все, що ви можете сказати, є більшим за 5SP і менше 13SP, тоді 8SP відповідає рахунку.

Все, що має значення SP 13/21 / величезне, занадто велике для відставання у спринті. Це оцінки для речей, над якими ви ще не готові працювати (і, таким чином, не розбивались на більш дрібні завдання (не розбивайте їх, поки вам теж не потрібно)). Але вони дають вам оцінку розміру завдання у відставанні продукту (що дозволяє певне планування в майбутньому). До того моменту, коли ви будете працювати над ними, ви повинні мати достатньо знань, щоб розбити їх на більш дрібні завдання на відставання спринту та переоцінити їх окремо (Примітка. Поширене неправильне уявлення про те, що сума частини дорівнюють оригіналу).

• Все, що ви оціните як величезне, потрібно розбити на більш дрібні завдання.
• Що-небудь, що оцінюється як? значить, недостатньо чітко визначено, щоб оцінити.
  Вам потрібно додати завдання спеціально для визначення та визначення завдання
  (тобто написати деяку документацію чи презентацію).

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

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

Коли ви закінчите, оцінюючи всі вимоги, які ви до цього часу, то ви оцінюєте, скільки ви можете виконати у спринті. Протягом наступних кількох спринтів ви оцінюєте, скільки ви закінчили. Точки історії вимоги вважаються виконаними лише тоді, коли вимога виконана. У Scrum немає "80% завершеності". Це тому, що люди насправді погано оцінюють повноту. Після кількох спринтів у вас має бути уявлення про те, скільки сюжетних точок ви можете зробити за спринт.

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

Я б також рекомендував прочитати Agile Samurai . Це добре робить пояснення цих та інших спритних концепцій, на мою думку.

Ось посилання на докладніші теми.

Ось ще одне посилання.

Вони марно витрачають час.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Цікаво, що ця думка зараз походить від хлопця, який написав Scrum та XP з траншей і чиє ім’я компанії ( Crisp ) можна знайти на стільки колод планувальних покерних карт, якими користується стільки команд у всьому світі.

Останнє речення ОП: "Чи є хороші ресурси для пояснення сюжетних точок?" Так, ця книга - хороший ресурс. Їжа для роздумів.

Найпростіше пояснення, яке я можу придумати, - це використання об'єкта, який є відчутним і може надати конкретний приклад.

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

У цей момент розум програмістів запустить і поговорить про впорядкований підхід; це не забирає вдвічі довше, оскільки інфраструктура забирає найбільшу частину часу та інші подібні приклади. Це неминуче. Арфа на тому, що це оцінка в (бали, жаби, віджети), оскільки ми НІКОЛИ не можемо точно оцінити час і, таким чином, оцінюючи (точки, жаби, віджети), знімає віру, що ми можемо.

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

Не забувайте планувати покер, коли команда готова до участі.

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

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

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

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