Некоторые думают, что планированию и оценке нет места в agile. Это не так.
Рассмотрим несколько случаев, когда оценка необходима/желательна:
- Оценка общего бюджета проекта – для заказчика часто это весьма важно
- Оценка того, что будет сделано в данном milestone’e
- Оценка того, что будет сделано в данном спринте
- Отслеживание статуса
В дальнейшем будет рассматриваться именно экспертная оценка. Под экспертной оценкой понимается оценка, сделанная непосредственно для данной задачи одним или несколькими людьми (это могут быть и люди, не слишком хорошо знающие предметную область, не обязательно эксперты в традиционном понимании). То есть не рассматриваются обобщенные оценки, как, например, оценка по функциональным точкам или по аналогии.
Воспринимаемая и реальная точность
Так как эти два понятия в разных источниках называются и понимаются по-разному, то поясню, что под ними понимаю я.
Воспринимаемая точность – то, с какой степенью детальности мы даем оценку. Например, оценка в днях кажется более точной, чем оценка в неделях, а оценка в часах с двумя знаками после запятой более точной, чем в часах с одним знаком после запятой.
Реальная точность (верность, правильность, далее будет использоваться просто слово точность) – насколько наша оценка совпадает с тем, сколько на самом деле «стоит» данная задача.
Попробую пояснить на примере. Есть задача A. Две разные команды дали ей оценки 60 часов и 1 неделя соответственно. Предположим, что на самом деле задача заняла 4 дня. Первая оценка воспринимается более точной (используются часы), но вторая более правильной – она ближе к реальным затратам, т.е. она объективно более точная.
Типы оценки
Условно разобьём типы оценок на 4 категории:
- Абсолютная оценка
- Сравнительная оценка (оценка объема)
- Оценка в виде диапазона
- Вероятностная оценка
Абсолютная оценка самая простая – просто оценивается, сколько единиц времени займет данная задача.
Сравнительная оценка – во сколько раз больше данная задача займет в сравнении с базовой задачей.
Оценка в виде диапазона – для задачи выдается диапазон времени, за который она будет сделана (естественно, с какой-то подразумеваемой вероятностью).
Вероятностная оценка – на основании нескольких оценок строится одна (на основании какого-то закона распределения). Например, мы можем для каждой задачи давать три оценка – в лучшем случае/наиболее вероятно/в худшем случае. И затем на основе того, с какой степенью риска мы готовы работать, получаем итоговую оценку.
Единицы измерения
Можно выделить некоторые наиболее часто используемые единицы измерения в agile:
- Реальные часы
- Идеальные часы
- Инженерные часы
- Story points
Ниже термин «задача» понимается как история или задача в рамках истории.
Реальные часы
Показывает, сколько реального времени займет данная задача.
Плюсы:
- Работа с реальными часами проще всего, особенно для начинающих команд
- Если область известна, то оценка может быть довольно точной
- Можно использовать эту же единицу для параметра to do (сколько времени еще надо для завершения задачи)
Минусы:
- Оценка сильно зависит от неявных допущений участников (учтут ли риски, перерывы на чай/кофе/покурить и т.д.)
- Сложно оценивать задачи в новой области/с использованием новой технологии
- Не учитывает изменения уровня команды (со временем команда начинает лучше понимать проект, и некоторые начальные оценки становятся очень завышенными)
Идеальные часы
Вообще, под идеальными часами разные люди понимают разное. Я постарался разбить это понятие на два – идеальные часы и инженерные часы.
Идея идеальных часов в том, что программист не может быть постоянно100% загруженным, нужны перерывы, иногда возможно какие-то отвлекающие события, например, срочный запрос информации. Поэтому считается, что в день можно выполнить n идеальных часов (например, в день мы можем выполнить 6 идеальных часов).
Плюсы:
- Можно не учитывать перерывы в оценке неявно
- Оценка to do для задачи легко определяется
Минусы:
- Сложно оценивать задачи в новой области/с использованием новой технологии
- Не учитывает изменения уровня команды (со временем команда начинает лучше понимать проект, и некоторые начальные оценки становятся очень завышенными)
- Возможны сложности с биллингом
Инженерные часы
Под оценкой в инженерных часах подразумевают то, сколько времени надо на реализацию данной задачи, предполагая, что известно, как ее решить, и мы можем работать непрерывно. Для перевода в реальные часы используется какой-то стандартный коэффициент, который учитывает время на исследование, перерывы т.д. (например, 3).
Плюсы:
- Допущения участников в целом одинаковы
- Нет необходимости постоянно учитывать стандартные активности (базовое исследование, тесты, исправление ошибок), они включаются в коэффициент
Минусы:
- Необходима практика, чтобы оценка стала более-менее правильной
- Если в проекте большая доля исследований, причем сильно отличающаяся для разных задач, то оценка часто будет неверной
- Возможны сложности с биллингом
- Иногда сложно использовать для вычисления того, сколько времени еще надо на завершение данной задачи
Story points
Story point – это абстрактная единица размера, имеющая смысл только для данного проекта. Для оценки в story points, как правило, используются не абсолютные, а относительные оценки.
Чтобы оценить задачи в story points, необходимо из всех задач выбрать ту, которая будет предпоследней по длительности (почти самой короткой). Считается, что эта задача займет 1 story point. Для всех остальных задач определяется, во сколько раз они больше, и ставится соответствующая оценка в story points.
Важно помнить, что это не оценка задачи по времени – это оценка размера. И не стоит неявно преобразовывать в единицы времени.
Для перевода оценок из story points в затраты времени используется оценка нескольких задач в единицах времени (например, днях или часах). Эту оценку может делать как каждый член команды индивидуально, так и эксперт(ы). Затем на основании этих оценок вычисляется, сколько примерно понадобится реального времени, чтобы сделать 1 story point.
Плюсы:
- Можно достаточно успешно оценивать задачи из незнакомой области/на незнакомой технологии
- Изменяя коэффициент преобразования story point в затраты времени, мы можем учесть разные уровни команды/уровень риска проекта
- Как показывает практика, программисты лучше учитывают объем задачи, чем время, необходимое на ее реализацию, так что оценка в story points при достаточной практике является одной из самых верных
Минусы:
- Желателен опыт оценки в story points
- Часто тяжело выбрать базовую задачу
- Для того, чтобы оценки были сравнимы, базовая задача должна быть одна и та же
- Сложно использовать для вычисления to do в рамках одной задачи
- Заказчику почти всегда необходима оценка реальных затрат (а иногда еще и календарный график)
Продолжение следует
В следующей статье я планирую рассмотреть оценку на разных уровнях (проект, версия, спринт) и то, как именно проводить оценку. Если есть какие-либо пожелания/предложения по тому, какие вопросы стоит раскрыть, пишите!
