Хорошее руководство по выбору шкалы баллов для использования с Agile / SCRUM?


10

Мы используем Pivotal Tracker для нашего проекта, который позволяет нам выбирать из трех шкал:

0,1,2,3
0,2,4,8
0,1,3,5,8

И я ищу ресурс, который поможет нам принять решение. (После использования 0,1,2,3 для двух итераций мы можем видеть, где один из других будет гораздо более полезным или значимым.)


Не могли бы вы объяснить больше, непонятно, о чем вы спрашиваете.
Амир Резаи

Конечно: мы ищем веб-сайт, статью, страницу или документ, которые обращаются к выбору шкалы баллов.
Dogweather

Google твой друг. Шутки в сторону. Это не сложно найти (попробуйте google.com/search?q=agile+ideal+days+points ). Что сложно , так это найти подход, который подходит вашей команде, и для этого нам нужна дополнительная информация от вас.
Мартин Уикман,

Ах, ха - спасибо. Моя "команда" микроразмера. Один программист на неполный рабочий день (я), один менеджер проектов на неполный рабочий день, который плохо знаком с разработчиком программного обеспечения, и другой программист на неполный рабочий день, который только начинает. Мы все хорошие друзья, и между игроками нет стресса.
Dogweather

1
@ Dogweather: если бы я был тобой (единственным программистом в «команде»), я бы вообще не использовал Scrum, кроме простых методов повышения производительности, таких как GTD. ИМХО, ты тратишь время на Scrum.

Ответы:


5

Очень популярна шкала историй «Фибоначчи» : 1, 2, 3, 5, 8 и т. Д. На ее основе лежат популярные колоды карт для планирования покера (от Mountain Goat Software и Crisp): знак вопроса, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, бесконечность.

Майк Кон в своей книге «Проворный анализ и планирование» отмечает, что использование 1-2-4-8 вместо 1-2-3-5-8 вполне допустимо.

Важно помнить, когда вы применяете сюжетные очки для «микроразмерных» команд: ограничивайте максимальный размер сюжета, не «смешивайте камешки с валунами» (подробнее см. В Agile для Solo Developer )


1

Я думаю, что вам нужно то, что предлагает достаточно различий с меньшими точками, а не так много вариантов для больших историй, основываясь на том факте, что все, что больше 20 или 40, должно быть разбито в любом случае. Это гарантирует, что вы поддерживаете более мелкие различия для историй небольшого и обычного размера и только грубые различия для историй большего размера.

Когда мы делали Scrum, у нас все было хорошо с точками, основанными на Фибоначчи, где 20 было самым большим числом, которое, как мы думали, реально вписалось бы в спринт. Если что-то было 40 или 100, то разработчики в основном говорили, что история слишком большая.

Кроме этого, я не думаю, что это имеет такое большое значение. Я бы предпочел последовательность на основе Фибоначчи, потому что я обнаружил, что она работает. Однако то, что работает для команды и продукта, который вы разрабатываете, прекрасно.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.