А в чем вы видите смысл оценки задач? Для какой цели вы используете?
Предсказание (с какой-то ошибкой) ресурсов требуемых на реализацию задачи;
Возможность относительного сравнения задач между собой (часто для определения их приоритетов);
Я не спорю с Вами в плане необходимости оценки, sp, их ценности и надежности, а только в доказательном аппарате: мне кажется "не честным" использование Lead Time, когда мы пытаемся определить надежность самой оценки. Т.к., в моем понимании (и уверен 99% работников), при оценке в sp мы рассматриваем задачу как "коня в вакууме" (конечно, это не правильно) и не знаем когда конкретно и кем она будет выполняться, но мы оцениваем именно ее (In-progress - ... - Done) сложность/ресурсы и не учитываем Reaction Time.
Простите, не уверен что понял, что находится по осям последнего графика. X - количество единиц времени, затраченных на "In-Progress/Review/Testing"; Y - количество таких задач? Если да, то лучше все таки изобразить их на разных графиках по оценках как в статье. Но, если лепестки распределения достаточно точно Вами отмечены, то я скорее склонен увидеть довольно хорошую точность/качество оценки.
А какой смысл смотреть на «Lead Time», который раскрывает проблему ожидания клиентом своей задачи считать без «Reaction Time»? Ведь именно от «Lead Time» он будет расчитывать все свои планы и договоренности с вами. ------------------------- Не обязательно. Это все должно явно решаться и проговариваться, все остальное только допущения. Конкретно я вижу лишь ошибочность использования Lead Time как показателя качества оценки задач, так как при таком подходе становятся бессмысленными понятия продуктивности/пропускной способности отдельного человека/команды: стори-поинты теряют свои аддитивные свойства, т.к. при наличии нескольких задач в ToDo и их последовательном выполнении Lead Time предпоследней = Reaction Time последней.
Возник вопрос по поводу расчета Lead Time и использование его как показателя качества оценки задач. Разве при оценке задач мы учитываем промежуток времени с момента как задача перешла в ToDo до момента как она перешла в Developing? В моем понимании, когда мы ставим оценку, мы сознательно отбрасываем этот промежуток и он определяется в основном важностью/приоритетом задачи, а не ее сложностью.
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
Интересно было бы посмотреть на Ваши графики после вычитания (ToDo - Developing)-периода из Lead Time.
Из моего скромного опыта подавляющему большинству как раз и нужна оценка Lead Time без учета Reaction Time.
Предсказание (с какой-то ошибкой) ресурсов требуемых на реализацию задачи;
Возможность относительного сравнения задач между собой (часто для определения их приоритетов);
Я не спорю с Вами в плане необходимости оценки, sp, их ценности и надежности, а только в доказательном аппарате: мне кажется "не честным" использование Lead Time, когда мы пытаемся определить надежность самой оценки. Т.к., в моем понимании (и уверен 99% работников), при оценке в sp мы рассматриваем задачу как "коня в вакууме" (конечно, это не правильно) и не знаем когда конкретно и кем она будет выполняться, но мы оцениваем именно ее (In-progress - ... - Done) сложность/ресурсы и не учитываем Reaction Time.
Простите, не уверен что понял, что находится по осям последнего графика.
X - количество единиц времени, затраченных на "In-Progress/Review/Testing"; Y - количество таких задач? Если да, то лучше все таки изобразить их на разных графиках по оценках как в статье. Но, если лепестки распределения достаточно точно Вами отмечены, то я скорее склонен увидеть довольно хорошую точность/качество оценки.
А какой смысл смотреть на «Lead Time», который раскрывает проблему ожидания клиентом своей задачи считать без «Reaction Time»? Ведь именно от «Lead Time» он будет расчитывать все свои планы и договоренности с вами.
-------------------------
Не обязательно. Это все должно явно решаться и проговариваться, все остальное только допущения.
Конкретно я вижу лишь ошибочность использования Lead Time как показателя качества оценки задач, так как при таком подходе становятся бессмысленными понятия продуктивности/пропускной способности отдельного человека/команды: стори-поинты теряют свои аддитивные свойства, т.к. при наличии нескольких задач в ToDo и их последовательном выполнении Lead Time предпоследней = Reaction Time последней.
Доброго времени суток.
Спасибо за материал.
Возник вопрос по поводу расчета Lead Time и использование его как показателя качества оценки задач.
Разве при оценке задач мы учитываем промежуток времени с момента как задача перешла в ToDo до момента как она перешла в Developing? В моем понимании, когда мы ставим оценку, мы сознательно отбрасываем этот промежуток и он определяется в основном важностью/приоритетом задачи, а не ее сложностью.
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
Интересно было бы посмотреть на Ваши графики после вычитания (ToDo - Developing)-периода из Lead Time.