Хотите дальше читать devby? 📝
Support us

Эстимейты: что, где и как?

Оценка — один из наиболее часто встречающихся тасков в IT индустрии: программисты оценивают продолжительность разработки, тестировщики оценивают время тестирования, менеджеры оценивают общее время разработки проекта.

Оставить комментарий
Эстимейты: что, где и как?

Оценка — один из наиболее часто встречающихся тасков в IT индустрии: программисты оценивают продолжительность разработки, тестировщики оценивают время тестирования, менеджеры оценивают общее время разработки проекта.

Люди, координирующие нас, просят точных оценок, но мы все понимаем, что эстимейты — это только предсказание которое лишь возможно истинно. Члены команды должны уметь оценивать задачи и определять вероятности, которые показывают, насколько их оценки могут быть верны. В этой статье рассказывается об основах оценивания, которые могут быть полезны новичкам.

1. Разделяй и властвуй

Разделяй и властвуй — этот старый принцип отлично подходит к нашей ситуации. Вы не можете оценить что-то, что вы не можете разбить на части. Вы не можете оценить проект «нам нужен вебсайт». Он должен быть прежде разбит на части, которые вы сможете осознать и оценить по отдельности. Есть две стороны декомпозиции проекта: доменная и техническая. Ни одна из них не является абсолютной и не может покрыть все возможные аспекты проекта сама. Я как-то совершил подобную ошибку на своем проекте — мы оценили проект лишь с технической стороны. Это был не самый приятный опыт :). Идеальное сочетание доменных и технических аспектов оценивания определяется для каждого проекта в отдельности, но всегда правдиво одно: вы никогда не должны забывать, что есть две стороны оценивания. Лично я предпочитаю разбивать проект на доменные бизнес-задачи, дополняемые техническими исследованиями и сложностями каждого отдельного проекта. Какой уровень декомпозиции достаточен? Тот, при котором вы наиболее вероятно дадите адекватные оценки каждой задаче. Я обычно останавливаюсь на уровне простой страницы/формы или простого блока на сложной странице/форме. Это задание должно включать в себя логически связанные действия и должно быть достаточно малым для снижения оценочных рисков.

2. Найдите ориентир

Предположим, что вы уже представили ваш проект в виде иерархии отдельных однородных задач. Теперь вам надо вспомнить что-то подобное, что вы уже делали раньше. Допустим, вы уже реализовывали подобную простую страницу за 4 часа — таким должен быть ваш базовый эстимейт для текущего задания. Подкорректируйте эстимейт в зависимости от различия сложностей предыдущего задания и текущего и вы получите адекватную оценку. Оценивайте задание за заданием и оцените таким образом сначала все крупные фичи, а потом и весь проект. Я предпочитаю задания, оцениваемые в не более чем 20 часов. Если оценка больше — лучше разбейте это задание на подзадания. Почему? Люди часто ошибаются, а шанс ошибки растет с размером оцениваемого задания.

Подписка на Coursera Plus — $399 в год. Неограниченный доступ к курсам,  специализациям и профессиональным сертификациям

3. Обработайте риски

Риски присутствуют на каждом этапе разработки программного продукта. Что-то может пойти не так — и обычно что-то идет не так. Этот момент разработки должен быть запланирован еще на стадии оценивания проекта. Управление рисками обычно включает в себя увеличение эстимейтов на некоторый процент, чаще всего 30%, но это, конечно же, зависит от специфики проекта. Какой процент использовать вам? Возьмите ~40% за основу (конкретное число зависит от проекта), и обновите его в соответствии с каждым из следующих пунктов:

  1. У вас есть опыт реализации подобных задач
  2. У вас есть опыт работы с данной платформой
  3. Платформа стабильна и не выявляет неожиданных проблем в процессе использования
  4. У вас есть опыт работы с данным доменом

Уменьшайте процент рисков на каждом пункте, где вы можете ответить утвердительно, и увеличивайте его на каждом пункте, где вы отвечаете отрицательно. Это разумно: как кто-нибудь может верить вашим эстимейтам, если вы никогда не работали с данным доменом на данной платформе. Однако, вы не должны снижать процент риссков ниже 25% — за исключением редких случаев, когда вы заново реализуете нечто, что вы уже реализовывали в прошлом, и вы абсолютно уверены, что знаете точное время разработки (вы, кстати, ошибаетесь :)). Еще одной хорошей практикой является обновление ваших эстимейтов в зависимости от выполнения вашых прошлых эстимейтов. Если в прошлом вы давали эстимейты, в среднем на 10-20% недооценивающие проект, то:

  1. Вы чертовски точны!
  2. Не надейтесь, что «ну теперь-то совсем другие условия» — просто увеличьте вашу оценку

4. Выводы

В этой статье описан самый простой процесс эстимирования. Есть и другие техники, другие методологии с другими подходами к оценке, но данный процесс прост в использовании и хорош для начала. Как и с другими повторяющимися операциями, вы становитесь лучше с каждой новой оценкой. Так что глобально ошибиться с вашей первой оценкой — это нормально, просто проанализируйте, где вы были неправы и попробуйте избежать этих ошибок в будущем.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.

Читайте также
Как разработчики манипулируют рейтингами в App Store
Как разработчики манипулируют рейтингами в App Store
Как разработчики манипулируют рейтингами в App Store
Financial Times рассказывает, как разработчикам iOS-приложений удаётся получать более высокие рейтинги с помощью психологических уловок. Публикуем перевод.
«За две недели хороший программист сделает из экскрементов мамонта и палок более-менее годный проект». Как разработчики оценивают сроки (+Рекомендации)
«За две недели хороший программист сделает из экскрементов мамонта и палок более-менее годный проект». Как разработчики оценивают сроки (+Рекомендации)
«За две недели хороший программист сделает из экскрементов мамонта и палок более-менее годный проект». Как разработчики оценивают сроки (+Рекомендации)
Как просить повышения зарплаты в полном праве, Или индивидуальные планы развития как двигатель прогресса
Как просить повышения зарплаты в полном праве, Или индивидуальные планы развития как двигатель прогресса
Как просить повышения зарплаты в полном праве, Или индивидуальные планы развития как двигатель прогресса

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.