Комментарии 4
Я предпочитаю использовать в качестве ответа меру неопределённости. Энтропия, число возможных состояний/исходов - фундаментальная, хорошая оценка.
Оценка, выдаваемая каждым конкретным разработчиком, зависит от конкретно этого разработчика, т.е. "потёмок его души" (знаний, опыта, настроения, возраста, здоровья и т.п.). Разработчик сегодня - это совсем другой разработчик, нежели тот же человек завтра, но уже прочитавший документацию, например. Надо научить разработчика понимать себя и понимать природу своих собственных оценок. Джоэл давным давно описал вполне действенный метод оценки, но он, как и многие другие реально действенные методы, итеративный и завязан на применяющего это метод разработчика, т.е. является вариацией на тему "проб и ошибок", а не четкой моделью (хотя метод не без модели).
Мне больше всего нравится, как разработчику, вероятностный метод. С помощью него, хотя бы можно примерно вычислить насколько сильно человек переоценивает свои силы. И использовать эти коэффициенты для корректировки оценок каждого члена команды.
Больше всего ненавижу оценку задач в story point. Мне лично, очень сложно давать оценки в каких-то попугаях, ведь стоимость попугая непонятна.... Задача на 2 дня это 1 бал или 2 балла? А если мы в голове начинаем связывать баллы с каким-то реальными величинами типа времени, то зачем лишняя сущность, неясно. Кроме того, ряд Фибоначчи 1, 2, 3, 5, 8, 13, 21, 34, 55 ... довольно странное решение: сложность большинства задач не настолько сильно возрастает и нужны промежуточные значения, например, между 13 и 21 и т.д. Да, и внешний заказчик вряд ли будет готов принять оценку проекта в поинтах (проект будет сделан за 102 point?!), то есть придется все-равно конвертировать баллы в какую-ту реальную величину.
Спасибо за классную и интересную статью.
Методология ограничений прекрасно описана в книге "Цель". Там описывается система предприятия на жизненных примерах и проблемах. Вам понравится!
Лучше оценивай, пока сторипоинты не запретили