YouIT

О проблеме эстимейтов в разработке программных продуктов

427   0   1   0 | Добавлено 185 дней назад  

При разработке программного обеспечения постоянно возникает необходимость давать эстимейты или эстимации (estimates), то есть оценку времени работ. Оценку приблизительного времени работы выполняет непосредственно программист в простых человеко-часах или в относительных величинах Story Points. Полученные цифры используются, например, для планирования спринтов или подбора исполнителей на проект.

Эстимейты в разработке ПО обладают одним недостатком: они редко когда бывают точными и могут в разы расходиться с фактическим временем выполненной работы. Даже существует утверждение, смысл которого в том, что точный эстимейт для некоторой задачи можно дать тогда и только тогда, когда работа над этой самой задачей уже завершена.

Классификация работ

Ноутбук, Графики

Для того чтобы глубже понять проблему эстимейтов, сначала необходимо классифицировать работу программистов. Каждый вид работ имеет свою сложность при проставлении эстимейтов.

Вид №1 - Разработка нового функционала

Разработка нового функционала (конечно же при условии полных и непротиворечивых требований заказчика) является наверное самым благоприятным случаем для более-менее точного эстимейта. И здесь обычно чем опытнее программист, тем более точным будет его эстимейт. Если же программист серьезно просчитывается, то это обычно говорит о его неопытности и чрезмерном оптимизме, чем о проблеме самих эстимейтов.

Вид №2 - Разработка нового функционала и его интеграция с существующей системой

Тут для предоставления точного эстимейта программисту вначале требуется достаточное количество времени на изучение интерфейса той системы, с которой ему необходимо интегрироваться. Если программисту такого времени не предоставляют или оно ограничено – эстимейт будет далеким от истины, так как он не будет учитывать особенностей внешней системы.

Вид №3 - Расширение существующего функционала

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

Вид №4 – Исправление дефектов в собственном функционале

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

Вид №5 - Исправление дефектов в унаследованном коде

Дефекты в унаследованном или просто чужом коде не эстимируются вовсе до момента, пока не установлена их причина. Это как с поломкой машины. Если она заглохла, то пока вы как минимум не заглянете под капот, вы не скажете сколько вам потребуется времени на исправление поломки.

Программист должен давать эстимейты своим менеджерам или заказчикам на дефект в унаследованном коде только после его предварительного анализа. В противном случае эстимейт будет не эстимейтом, а ничем не подкрепленным предположением.

Помните о том, что вы всегда должны заглянуть под капот. Доносите это до всех тех людей, включая не техничных заказчиков и менеджеров, которые требуют от вас эстимейта здесь и сейчас.

P.S. Наверное, фундаментальна проблема эстимейтов заключается в самом названии. Если термин “эстимейт” (estimate - оценка) переименовать на более подходящий термин “прогноз” (forecast), то общее положение дел в разработке ПО возможно станет чуть лучше.


Похожие статьи

Комментарии (0)

Авторизируйтесь для участия в дискуссии

Google Facebook ВКонтакте
работа программиста качество кода IT-компания обучение программированию карьера собеседование C# сертификация джуниор алгоритмы ООП энтерпрайз .NET тестирование javascript программирование эстимейты roadmaps информатика фан быстродействие базы данных