День 1367. #TypesAndLanguages Пару Слов об Оценках и Стори-Пойнтах. Продолжение Начало Нам нужны оценки по времени Нужно ведь планировать работу наперёд. Да. Поэтому оценивать задачи в стори-пойнтах — плохо. Программисты разные: у них разный опыт, разные навыки, им нравятся разные части разработки ПО. Нельзя просто придумать коэффициент для перевода SP в часы, так как каждый спринт индивидуален и каждый программист индивидуален, поэтому придётся знать эти коэффициенты для каждого человека и уметь предсказывать будущее (поскольку они меняются с каждым спринтом). Из-за этого программисту очень просто объяснить, почему он работал над задачей «слишком долго»: потому, что SP не передают никакой оценки времени (кроме того, что должны укладываться в один спринт). Но заинтересованные стороны должны знать, сколько времени это займёт. Во-первых, потому что они хотят планировать бюджет. Во-вторых, потому что необходимо координировать множество других вещей (маркетинг, реклама, продажи и т. д.). В-третьих, потому что если какие-то проекты будут длиться слишком долго, то их проще отменить. Поскольку программистов редко заботят нетехнические вещи, они хотят избавиться от ответственности. И именно поэтому им нравится оценивать задачи в стори-пойнтах. Не нужно думать о часах, и у них есть очень хорошее объяснение, что дела будут сделаны «когда они будут сделаны». Очевидно, что это мало полезно всем остальным, и хорошие инженеры это понимают. Если вы считаете, что нормально оценивать задачи в SP, то представьте, что сантехник говорит вам, что починка вашей раковины «займет 8 SP». Очевидно, вас это не устроит, вместо этого вы ожидаете оценки по времени. Как ни странно, программисты часто утверждают, что разработка ПО отличается от «реальной жизни», и поэтому они не могут оценивать по времени надолго. Это неправда. Как это должно выглядеть? Как только вы разбиваете истории на задачи, вы оцениваете каждую задачу в часах (или днях, или любой другой единице времени). Затем просто выполняете расчёты, чтобы проверить, какие задачи вы можете включить в спринт. И на основе этого определяете, какие пользовательские истории вы обработаете. Производительность и инкременты Прежде чем перейти к фактическим единицам времени, мы рассмотрим производительность. Вы не можете использовать производительность для планирования спринта: если вы заранее знаете, сколько SP вам нужно сделать за спринт, то вы делаете это неправильно. Спринты предназначены для фиксации того, какие пользовательские истории будут выполнены полностью, и фактическое количество SP будет отличаться от спринта к спринту. Однако, когда команда стабильна, вы можете рассчитать производительность и использовать её, чтобы оценить, достаточно ли у вас запланировано работы на какой-то период времени (до следующего релиза). Стратегический анализ бизнеса стоит дорого, да и планы со временем меняются. Нет смысла планировать что-то на 3 года вперед, потому что, скорее всего, планы устареют. В то же время хорошо бы иметь некоторое представление о том, сколько работы вам предстоит и над чем вы будете работать в течение следующих 6 месяцев. Если вы подсчитаете, что в среднем команда набирает X стори-пойнтов за спринт, то вы можете посмотреть сколько работы вам предстоит сделать, сколько из неё оценено в SP, и достаточно ли вам работы до следующего релиза. Просто умножаете производительность на количество спринтов до релиза. Дело не в том, чтобы быть суперточным, а в том, чтобы понимать, сколько времени это займёт. Если вы видите, что у вас достаточно стори-поинтов, чтобы заполнить работой следующий год, то нет необходимости делать бизнес-анализ с вашим клиентом сейчас, это может подождать до следующего месяца. Может быть и наоборот. Вы думаете, что вам хватит работы на ближайшие 6 месяцев, а по оценке получается только на 5. Делайте выводы. Окончание следует… Источники: - https://blog.adamfurmanek.pl/2022/06/11/types-and-programming-languages-part-12/ - https://blog.adamfurmanek.pl/2022/06/18/types-and-programming-languages-part-13/