День 1366. #TypesAndLanguages
Пару Слов об Оценках и Стори-Пойнтах. Начало
Стори-Пойнты (Story Points - SP) представляют собой сложность, риск, трудоёмкость и объём пользовательской истории. Истории оцениваются в баллах, чтобы получить относительный размер каждой из них, чтобы затем планировать будущее. Однако при планировании спринта нужно разбить историю на задачи.
Допустим, вы делите истории на задачи, которые длятся не более одного дня. Однако в этом случае вы фактически уберёте трудоёмкость из SP, поскольку каждая задача основана на ровно одном трудодне.
У вас может быть простая история, но она займёт много времени, например, написание документации. В этом случае история должна иметь немного стори-пойнтов, но всё же может занять больше времени, чем история на разработку трудного функционала. Аналогично, написание 3х документов не должно иметь в 3 раза больше SP, чем написание одного. Трудоёмкость выше, а остальные измерения остались прежними, поэтому SP не должны возрастать линейно.
Как разделить истории на задачи? Если вы можете распараллелить какую-то работу, то её следует разделить на несколько задач. Если нет, и в задаче нет логического «чекпойнта», то это должна быть одиночная задача. Технически задача (и история) должна быть выполнена за спринт, это единственное требование. Однако, если ожидается, что задача займёт больше половины спринта, то стоит попытаться её поделить.
Мы разбили истории на задачи. Какие истории включить в предстоящий спринт? Можно рассчитать производительность команды, особенно если команда стабильна. Это может дать представление о том, сколько времени займёт работа, исходя из предыдущих спринтов. Однако, использовать производительность команды в стори-пойнтах для планирования спринта значит не понимать их смысл.
Допустим, в команде 5 человек, команда стабильна, и в последнем спринте закончили 25 историй в 1 стори-пойнт каждая. В следующем спринте задачи в 3 SP каждая. Сколько задач взять? Если вы думаете, что 8, это означает, что вы используете SP как ещё одну единицу времени и что ваши оценки растут линейно. Это неверно. 3 задачи по 1 SP не равны 1 задаче в 3 SP (поскольку есть и другие факторы, учитываемые при оценке). Но есть ещё проблема: в предыдущем спринте каждый член команды работал над 5 задачами в 1 SP, т.е. производительность каждого 5 SP за спринт. Поэтому, если взять больше 5 задач в 3 SP, кому-то придётся взять на себя 2 задачи, а это уже 6 SP.
Можно решить только приступить к задаче и перенести её на следующий спринт, но это противоречит идее планирования и обязательности. Agile-подход направлен на устранение неопределённости и рисков, а не на избавление от планирования и обязательств. Программисты утверждают, что плохо предсказывают будущее, поэтому хотят планировать небольшие шаги. Тем не менее, всё равно необходимо завершать работу, за которую вы взялись в спринте. Если вы берёте задачу с мыслью «я не закончу её, но хотя бы начну», то делаете неправильно. Вы должны разделить задачу на части и взять одну часть, которую сможете выполнить в спринте. Agile-подход и стори-пойнты нужны для того, чтобы полностью избежать оценок по времени, а для того, чтобы сделать их более реалистичными и надёжными. Вам всё ещё нужно закончить работу за спринт, т.е временные рамки фиксированы размером спринта.
Вместо 8-ми задач по 3 SP стоит взять 5. Это большая разница: 15 SP против 25. И по этой причине команда может выполнять разное количество SP в каждом спринте. Если вы заранее знаете, сколько SP вы выделите при планировании спринта, то это полностью противоречит идее стори-пойнтов.
Можно рассчитывать производительность и скорость. Но не нужно использовать эти значения для планирования работы внутри спринта. SP — не единицы измерения времени.
Как же перейти от SP ко времени? Никак. Мы можем зафиксировать только работу, выполненную в текущем спринте. SP могут быть соотнесены с оценками времени, но не могут диктовать их, а оценки времени не могут быть выведены из SP.
Продолжение следует…
Источник https://blog.adamfurmanek.pl/2022/06/11/types-and-programming-languages-part-12/
>>Click here to continue<<