Agile в Беларуси

Некоторые думают, что планированию и оценке нет места в 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 в рамках одной задачи
• Заказчику почти всегда необходима оценка реальных затрат (а иногда еще и календарный график)

Продолжение следует

В следующей статье я планирую рассмотреть оценку на разных уровнях (проект, версия, спринт) и то, как именно проводить оценку. Если есть какие-либо пожелания/предложения по тому, какие вопросы стоит раскрыть, пишите!

В закладки: