Эстимейты: что, где и как?
Оценка — один из наиболее часто встречающихся тасков в IT индустрии: программисты оценивают продолжительность разработки, тестировщики оценивают время тестирования, менеджеры оценивают общее время разработки проекта.
Оценка — один из наиболее часто встречающихся тасков в IT индустрии: программисты оценивают продолжительность разработки, тестировщики оценивают время тестирования, менеджеры оценивают общее время разработки проекта.
Люди, координирующие нас, просят точных оценок, но мы все понимаем, что эстимейты — это только предсказание которое лишь возможно истинно. Члены команды должны уметь оценивать задачи и определять вероятности, которые показывают, насколько их оценки могут быть верны. В этой статье рассказывается об основах оценивания, которые могут быть полезны новичкам.
Разделяй и властвуй — этот старый принцип отлично подходит к нашей ситуации. Вы не можете оценить что-то, что вы не можете разбить на части. Вы не можете оценить проект «нам нужен вебсайт». Он должен быть прежде разбит на части, которые вы сможете осознать и оценить по отдельности. Есть две стороны декомпозиции проекта: доменная и техническая. Ни одна из них не является абсолютной и не может покрыть все возможные аспекты проекта сама. Я как-то совершил подобную ошибку на своем проекте — мы оценили проект лишь с технической стороны. Это был не самый приятный опыт :). Идеальное сочетание доменных и технических аспектов оценивания определяется для каждого проекта в отдельности, но всегда правдиво одно: вы никогда не должны забывать, что есть две стороны оценивания. Лично я предпочитаю разбивать проект на доменные бизнес-задачи, дополняемые техническими исследованиями и сложностями каждого отдельного проекта. Какой уровень декомпозиции достаточен? Тот, при котором вы наиболее вероятно дадите адекватные оценки каждой задаче. Я обычно останавливаюсь на уровне простой страницы/формы или простого блока на сложной странице/форме. Это задание должно включать в себя логически связанные действия и должно быть достаточно малым для снижения оценочных рисков.
Предположим, что вы уже представили ваш проект в виде иерархии отдельных однородных задач. Теперь вам надо вспомнить что-то подобное, что вы уже делали раньше. Допустим, вы уже реализовывали подобную простую страницу за 4 часа — таким должен быть ваш базовый эстимейт для текущего задания. Подкорректируйте эстимейт в зависимости от различия сложностей предыдущего задания и текущего и вы получите адекватную оценку. Оценивайте задание за заданием и оцените таким образом сначала все крупные фичи, а потом и весь проект. Я предпочитаю задания, оцениваемые в не более чем 20 часов. Если оценка больше — лучше разбейте это задание на подзадания. Почему? Люди часто ошибаются, а шанс ошибки растет с размером оцениваемого задания.
Риски присутствуют на каждом этапе разработки программного продукта. Что-то может пойти не так — и обычно что-то идет не так. Этот момент разработки должен быть запланирован еще на стадии оценивания проекта. Управление рисками обычно включает в себя увеличение эстимейтов на некоторый процент, чаще всего 30%, но это, конечно же, зависит от специфики проекта. Какой процент использовать вам? Возьмите ~40% за основу (конкретное число зависит от проекта), и обновите его в соответствии с каждым из следующих пунктов:
Уменьшайте процент рисков на каждом пункте, где вы можете ответить утвердительно, и увеличивайте его на каждом пункте, где вы отвечаете отрицательно. Это разумно: как кто-нибудь может верить вашим эстимейтам, если вы никогда не работали с данным доменом на данной платформе. Однако, вы не должны снижать процент риссков ниже 25% — за исключением редких случаев, когда вы заново реализуете нечто, что вы уже реализовывали в прошлом, и вы абсолютно уверены, что знаете точное время разработки (вы, кстати, ошибаетесь :)). Еще одной хорошей практикой является обновление ваших эстимейтов в зависимости от выполнения вашых прошлых эстимейтов. Если в прошлом вы давали эстимейты, в среднем на 10-20% недооценивающие проект, то:
В этой статье описан самый простой процесс эстимирования. Есть и другие техники, другие методологии с другими подходами к оценке, но данный процесс прост в использовании и хорош для начала. Как и с другими повторяющимися операциями, вы становитесь лучше с каждой новой оценкой. Так что глобально ошибиться с вашей первой оценкой — это нормально, просто проанализируйте, где вы были неправы и попробуйте избежать этих ошибок в будущем.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.