Story Points: когда SP лучше, чем часы и при чём тут Фибоначчи Заказчик, знай: когда пиэм даёт тебе оценку в часах для мало-мальски крупных задач или задач, относящихся к проекту, который команда разработки еще в глаза не видывала, он наверняка что-то недоговаривает. Высока вероятность, что товарисчи сильно перезакладываются. Это в лучшем случае. В худшем ты получаешь просто рандомные сроки. Да, в определенных случаях работу вполне можно оценивать в часах, этот вариант канает, если задачи небольшие, если задачи рутинные, если задачи типовые или функционально максимально предсказуемые, если состав вашей команды стабилен при этом, ну и если вы работаете не в рамках гибких методологий разработки, где в принципе SP не применимы. Для всего остального существуют Story Points. Хотя не, преувеличиваю. SP чаще ассоциируются именно со Скрамом, при этом в теории их можно заюзать и в Канбане, и в SAFe, и в других гибких методологиях. Story Points отражает не время, необходимое для реализации задачи, а сложность задачи и связанные с ней риски. Story Points - относительная единица. Чтобы оценить ту или иную задачу в SP, обычно опираются на т.н. эталонную задачу - некую простую задачу небольшого объема, сложность которой максимально предсказуема. Предположим, команда решает, что эталонная задача весит 1 SP. Задача, которая примерно вдвое сложнее эталонной - 2 SP. Втрое сложнее - 3 SP. А дальше? 4, 5, 6..? Нет. Было бы всё линейно - не было бы смысла искать альтернативу часам. Суть в том, что чем задача объемней/сложней, тем менее точной может быть оценка, связанная с этой задачей. Это факт. Поэтому для оценки задач в SP используется не стандартный набор натуральных чисел, а, например, ряд Фибоначчи (напомню, в последовательности чисел Фибоначчи каждое следующее число является суммой двух предыдущих): 1, 2, 3, 5, 8, 13, 21, 34... Сложную задачу трудно оценить относительно эталонной, поэтому команда может сказать, что, к примеру, 8 SP для нее является более вероятной оценкой, чем 5, поскольку разница между 8 и 5 более очевидна, чем между 6 и 5 (если бы это был стандартный ряд натуральных чисел). В чем преимущество SP относительно часов: SP - это универсальная оценка сложности, которая не зависит от квалификации разраба и/или тестера, SP учитывает все стадии работы с задачей, а не только непосредственно разработку: коммуникации, ревью, тестирование, деплой, кроме того, SP учитывает риски и позволяет сравнивать задачи. Ну а если заказчику неинтересны ваши покеры-шмокеры вместе со всеми досужими рассуждениями о сути гибких методологий разработки и преимуществах стори-пойнтов, есть 2 варианта удовлетворить его потребность в оценке в человеко-часах: 1) потратить время на максимальную декомпозицию: разбить проект/задачу на атомы, оценить в человеко-часах и просуммировать, учесть риски и/или накинуть сверху классические 30% в качестве страховки; 2) попытаться натянуть сову на глобус и на основании исторических данных конкретно вашей команды, опираясь на velocity и logged hours в тасках, сопоставить SP и часы, затраченные на задачи. К примеру, если задача сложностью 3 SP выполняется в среднем 6 часов, то 1 SP примерно равен двум часам. Но это не самая лучшая практика - попытка сравнивать мягкое с теплым.