Комментарии 9
Зачем все эти сторипоинты и майки, если потом всё равно всё через скорость пересчитывается в часы?
Привет, спасибо за вопрос — это тянет прямо на отдельную статью или, как минимум, на пост.
Сначала короткий ответ: если вы хотите получить расчётное = точное время выполнения ваших задач, то необходимо взять формулу простейшей математики и посчитать 
, а для формулы нам необходимы объем (S) и скорость (V). Без использования формулы, ваше время будет угадыванием, а не расчётом.
А теперь длинный ответ.
Давайте снова немного теории:
Сторипоинты/ майки и другие прекрасные «величны», которые я измеряю в условных единицах (у.е) — это нично иное, как попытка сравнить задачи между собой. Это не абсолютные значения, а скорее относительные.
Эти самые сторипоинты/ майки — это относительная мера объёма — S — Scope. И они нам нужны, чтобы мы оценили объем (или можно сказать, сложность задач), есть ответили на вопрос — как много всего нам надо сделать?
Часы/ дни/ недели — это, в общем случае, мера времени — T — Time. Время нам нужно, что мы сначала оценили, а потом и высчитали — как долго мы будем всё это делать.
— у.е/T — это мера скорости — V — Velocity. Скорость — это сколько условных единиц в день/час/неделю мы делаем — то есть как быстро мы всё сделаем.
Благодаря оценке хочется получить время — T, потому что информативно — выражается в потятных часах/днях/неделях. Но без знания скорости команды и объёма задач из бэклога, время не высчитывается, а просто угадывается.
Потому очень важный вывод звучит так: для получения именно расчётного, а не угаданное время
(в часах/ днях/ неделях), вам нужно:
Оценить объём
: зачем оценивать? Вкаждой новой итерации у вас разный объем задач — очевидно, а что не очевидно — с каждой итерацией вы все лучше управляетесь с расставлением условных един для своих задач, сравнивая из друг с другом. Взять скорость
вашей команды из предыдущей итерации. Именно для того, чтобы эту скорость откуда-то взять первые несколько итераций у нас проходит по эгидой — «прикидываем». Посчитать (а не угадывать) время выполнения ваших задач по формуле
.
Ответила на вопрос @gun_dose?
Это не абсолютные значения, а скорее относительные.
Вот тут проблема, если в один спринт попадут задачи в среднем значительно более сложные или более простые, чем в другой. Допустим в часах один спринт содержит задачи по 16, 16, 8, 8 часов. Второй 8, 8, 4 и 4. В вашей системе измерения это будет 2, 2, 1, 1 в обоих случаях.
Взять скорость (V) вашей команды из предыдущей итерации
В приведённом выше примере скорость команды будет различаться вдвое. И само по себе понятие "скорость команды" весьма сомнительное. Всё равно есть задачи под конкретных людей или под узкую группу людей. Например деплой на продакшн обычно может делать только 1 или 2 человека из команды. Ну или если джун возьмёт себе слишком сложную задачу, то его скорость сильно упадёт. Это приводит к тому, что один и тот же набор задач команда будет делать разное время в зависимости от распределения задач между участниками.
Посчитать (а не угадывать)
У вас в числителе стоит грубо прикинутая величина, то есть по сути угаданная. Дальше считайте как угодно, на выходе всё равно получите угаданную величину.
И вообще, вы зря используете уничижительный термин "угадывать". Любое планирование - это прогноз, а прогноз по сути и есть угадывание.
А теперь самое интересное, ваши условные единицы элементарно масштабируются в часы. В таком случае за двухнедельный спринт велосити команды будет 80*N, где N - это количество участников в команде. Единственное, что остаётся принять во внимание - это личный коэффициент производительности каждого сотрудника. Например, если я для себя оценил задачу в 8 часов, то Володя будет делать её 12, а Петя 16.
Главное отличие условных единиц от часов состоит в том, что в условных единицах вы предлагаете потратить несколько спринтов на определение велосити. Простыми словами, снимаете ответственность за выполнение спринта в первый месяц. Если снять эту ответственность при работе с часами, точно так же можно присмотреться к команде и научиться прогнозировать точнее. Ещё один момент, часто звучит сравнение сторипоинта с задачей на полдня. Ну так давайте считать в часах с квантом в 4 часа и получим на выходе ту же точность.
А теперь самое главное преимущество оценки в часах с фиксацией фактически затраченного времени: допустим сегодня мы стартанули спринт и какая-то задача оказалась слишком сложной. Человек закопался и залогировал уже 16 часов вместо 8 отведённых. ПМ видит на доске красную задачу и успевает принять меры, например, позвать кого-то на помощь или раздать часть задач этого человека другим людям. Это позволит прийти к концу спринта без каких-то особых напрягов. Если же вы используете какие-то условные единицы без учёта затраченного времени, вы только ближе к концу спринта сможете увидеть, что у вас куча задач ещё не приехала в Done. И начинается беготня "давайте быстрее, релиз послезавтра". А это и есть показатель плохого менеджмента: если ближе к концу спринта вам приходится кого-то подгонять, значит ваши оценки не работают
Вот тут проблема, если в один спринт попадут задачи в среднем значительно более сложные или более простые, чем в другой. Допустим в часах один спринт содержит задачи по 16, 16, 8, 8 часов. Второй 8, 8, 4 и 4. В вашей системе измерения это будет 2, 2, 1, 1 в обоих случаях.
Во-первых, это не часы — это условные единицы. Это крайне важно. В часах выражается время, а не объем.
Да, вы правы, что это относительная мера не внутри спринта, а всё же относительная мера внутри команды.
Тут стоит сделать мне важное замечание — спасибо, что указали на это.
Идеально, чтобы с течением времени оценка в условных единицах примерно одинаковых по сложности задач стремились к постоянной величине.
Поэтому я рекомендую оценивать максимально декомпозированную = понятную задачу.
В приведённом выше примере скорость команды будет различаться вдвое. И само по себе понятие "скорость команды" весьма сомнительное. Всё равно есть задачи под конкретных людей или под узкую группу людей. Например деплой на продакшн обычно может делать только 1 или 2 человека из команды. Ну или если джун возьмёт себе слишком сложную задачу, то его скорость сильно упадёт. Это приводит к тому, что один и тот же набор задач команда будет делать разное время в зависимости от распределения задач между участниками.
Надеюсь, что важное замечание из параграфа выше закрыло этот вопрос.
Или всё же нет?
У вас в числителе стоит грубо прикинутая величина, то есть по сути угаданная. Дальше считайте как угодно, на выходе всё равно получите угаданную величину.
Напомню формулу , о которой идёт речь.
Позволю себе не согласиться. Со временем величина S будет становиться всё точнее и точнее. Команда или лид начнут понимать сложность такого типа задач. Именно сложность. Не скорость выполнения, потому что она(скорость), как вы верно заметили, у всех разная.
Ещё раз напомню, что S — это не часы, не минуты и даже не недели. S — это не время. Это объем или сложность задач.
И вообще, вы зря используете уничижительный термин "угадывать". Любое планирование - это прогноз, а прогноз по сути и есть угадывание.
Я ни в коем случае не вкладывала в слово «угадывание» уничижительного смысла. Я сама угадывала и продолжаю угадывать там, где это уместно.
Всей этой статьёй я хотела рассказать, что важно найти тот способ оценки, который соответствует целям и возможностям команды в данный момент. Угадывание здесь используется только как противопоставление расчёту.
Я считаю, что угадывание — это процесс, основанный на субъективных данных говорящего, а расчёт — это то, что основано на данных и формулах, которыми эти данные связаны.
Поэтому я совершенно не могу согласиться с тезисом, что «планирование = прогноз = угадывание».
Докажем от обратного: в случае
итерации, когда уже существуют условные единицы для расчёта (например, объём работы S) и скорость (V), для расчёта времени (T) ничего, кроме голой математики, не требуется. Это противоречит понятию угадывания.
И подчеркну: я ничего против угадывания не имею. В своей бирюзовой компании я никогда не буду тратить время на справедливую оценку объёма и честный расчёт скорости.
А теперь самое интересное, ваши условные единицы элементарно масштабируются в часы. В таком случае за двухнедельный спринт велосити команды будет 80*N, где N - это количество участников в команде. Единственное, что остаётся принять во внимание - это личный коэффициент производительности каждого сотрудника. Например, если я для себя оценил задачу в 8 часов, то Володя будет делать её 12, а Петя 16.
Главное отличие условных единиц от часов состоит в том, что в условных единицах вы предлагаете потратить несколько спринтов на определение велосити. Простыми словами, снимаете ответственность за выполнение спринта в первый месяц. Если снять эту ответственность при работе с часами, точно так же можно присмотреться к команде и научиться прогнозировать точнее. Ещё один момент, часто звучит сравнение сторипоинта с задачей на полдня. Ну так давайте считать в часах с квантом в 4 часа и получим на выходе ту же точность.
Очень важно понимать, что ввод условных единиц, описанных в статье, имеет смысл, когда нужна очень точная оценка. (Например, с датой релиза никак нельзя ошибиться!) В случаях, когда происходит трансформаций чего угодно во что угодно — это прекрасный метод оценки и прогноза, только он не имеет ничего общего с методом оценки Hard или Hard+.
Если мы занимаемся любым упрощениями, которые также описаны в статье, то ввод условных единиц не имеет никакого смысла и гораздо проще прикинуть, что «я для себя оценил задачу в 8 часов, то Володя будет делать её 12, а Петя 16».
А теперь самое главное преимущество оценки в часах с фиксацией фактически затраченного времени: допустим сегодня мы стартанули спринт и какая-то задача оказалась слишком сложной. Человек закопался и залогировал уже 16 часов вместо 8 отведённых. ПМ видит на доске красную задачу и успевает принять меры, например, позвать кого-то на помощь или раздать часть задач этого человека другим людям. Это позволит прийти к концу спринта без каких-то особых напрягов. Если же вы используете какие-то условные единицы без учёта затраченного времени, вы только ближе к концу спринта сможете увидеть, что у вас куча задач ещё не приехала в Done. И начинается беготня "давайте быстрее, релиз послезавтра". А это и есть показатель плохого менеджмента: если ближе к концу спринта вам приходится кого-то подгонять, значит ваши оценки не работают
А здесь у нас смешались цели, которые не противоречат друг другу, а существуют в параллельных вселенных.
Цель статьи и подходов, описанных в ней, — показать, какие существуют методы оценки задач в зависимости от того, насколько точными они должны быть. То есть эти подходы описывают то, что происходит до очередной итерации разработки, и то, что нужно получить после неё. Подходы к оценке совершенно не зависят от того, как мы будем решать проблему с коллегой, который не уложился в оценку. Это тема другой большой статьи.
Способ оценки не связан с тем, в каких величинах команда будет логировать время. Мы всегда логируем время в часах, несмотря на то, что в какой-то момент было необходимо использовать Hard+ mode для оценки.
Какой бы подход к оценке вы ни выбрали, это не избавит от проблем плохого менеджмента внутри спринта.
Помогать коллеге, которому нужна поддержка, важно и необходимо при любом подходе к оценке, описанном в этой статье.
с течением времени
Со временем величина S будет становиться всё точнее и точнее
в случае i+1итерации
Вот так вы оцениваете объём ваших задач. Одна итерация обычно две недели, это значит, что на притирку легко могут уйти месяцы. Месяцы в течение которых оценка объёма будет неточной. И насколько бы ни была в итоге точна ваша формула, ваше рассчётное значение в итоге будет таким же неточным, как ваше S.
Оценка задач в IT: делать или не делать — вот в чем вопрос?