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

Я понимаю, что оценки - сложная проблема при разработке программного обеспечения на заказ, и я, конечно, не претендую на звание лучшего в получении точных оценок. Однако я выявил определенные аспекты оценок, которые, как я считаю, универсально (или почти) верны. В типичном для Интернета стиле приманки я назвал эти «законы» (программных) оценок («и вы не поверите, что будет дальше!»):

1-й закон оценок: оценки - пустая трата времени

Время, потраченное на оценки, - это время, которое не тратится на создание ценности. Это игра с нулевым результатом, когда дело доходит до того, сколько времени разработчики должны выполнить работу - хуже, если оценки запрашиваются срочно и прерывают разработчики, которые в противном случае были бы «в зоне ответственности», добиваясь своей цели. Если ваш средний разработчик тратит 2–4 часа в 40-часовую неделю на оценки, это потеря производительности на 5–10%, если в противном случае он мог бы работать продуктивно все время. Процент потерь еще больше, если соответствующий разработчик работает неполный рабочий день или может тратить только часть своей рабочей недели на написание программного обеспечения (как это часто бывает).

Несколько лет назад отдел Microsoft смог повысить продуктивность команды более чем на 150% без каких-либо новых ресурсов или изменений в том, как команда выполняла задачи разработки программного обеспечения (проектирование, кодирование, тестирование и т. Д.). Основное изменение заключалось в том, когда и как оценивались задачи. По иронии судьбы, большая часть этой оценки была сделана по запросу руководства, которое, стремясь к большей прозрачности и надеясь получить представление о том, как можно повысить производительность команды, ввело в действие политики, которые требовали частых и своевременных оценок (новые запросы нужно было оценивать в пределах 48 часы). Несмотря на то, что эти оценки были всего лишь ROM (грубые порядки величины), усилия, которые они требовали, и создаваемые ими перерывы разрушали общую продуктивность команды. Узнайте больше об этом проекте в Белой книге Microsoft или в книге Дэвида Андерсона Канбан (дополнительные сведения о канбане см. В моем курсе Pluralsight Основы канбана).

2-й закон оценок: оценки не подлежат передаче

Оценки программного обеспечения не взаимозаменяемы, в основном как следствие того факта, что члены команды не взаимозаменяемы. Это означает, что оценку одного человека нельзя использовать, чтобы предсказать, сколько времени может потребоваться другому человеку, чтобы выполнить задачу.

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

Переносимость оценок, очевидно, улучшается, когда оценщик и исполнитель имеют одинаковый уровень опыта, и тем более, когда они работают вместе в одной команде. Некоторые методы, такие как планирование покера, будут пытаться задействовать опыт всей команды при оценке задач, гарантируя, что оценки не упускают из виду ключевые соображения, известные только некоторым членам команды, или то, что они написаны так, как если бы был назначен самый быстрый кодировщик. каждая задача. Это может помочь произвести оценки или оценить диапазоны (неопределенность является частью оценки - см. 3-й закон ниже), которые с большей вероятностью будут точными, но это достигается путем умножения времени, затраченного на оценку по размеру всей команды. Это резко увеличивает стоимость подготовки оценок.

3-й закон оценок: оценки неверны

Оценки - это не обещания. Это предположения, и, как правило, чем больше масштаб и чем дальше в будущем будет оцениваемая деятельность, тем больше потенциальная ошибка. Это известно как конус неопределенности. Существует множество визуализаций конуса неопределенности - на приведенной ниже средней темно-зеленой линии представляет текущую оценку, которая обычно увеличивается с течением времени. Более светлые зеленые линии представляют собой вероятное отклонение, которое может иметь оценка, с большей частью на верхнем конце, поскольку в большинстве случаев оценки занижены из-за вещей, вы не знаете, что вы не знаете или просто не можете предсказать.

Никто не должен удивляться ошибочным оценкам; они должны быть удивлены, когда окажутся правы. Если бы оценки всегда были точными, их называли бы точными.

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

Оценки отдельных рабочих элементов и проектов, как правило, тем точнее, чем ближе работа к завершению, и достигают 100% точности после завершения работы. Самая точная оценка, как и самый точный прогноз погоды, говорит вам о том, что произошло вчера, а не о том, что произойдет в будущем. Хотя может показаться нецелесообразным знать, сколько времени занимает что-то только после того, как оно было выполнено, если задачи разбиты на небольшие, довольно однородные пакеты, вы можете предсказать, сколько времени потребуется для прохождения задачи через систему, в среднем , применяя Закон Литтла, без предварительных оценок.

4-й закон оценок: оценки временны

Оценки являются скоропортящимися. У них относительно короткий срок хранения. Разработчик может изначально оценить, что на разработку определенной функции уйдет неделя, прежде чем проект начнется. За три месяца работы над проектом многое было изучено и решено, и та же самая функция может теперь занять несколько часов или месяц, или она могла быть полностью исключена из проекта из-за изменения приоритетов или направления. В любом случае оценка имеет небольшую или, возможно, даже отрицательную ценность (если она неточна и решения принимаются на ее основе), поскольку с момента ее создания потенциально изменилось очень многое.

Чтобы решить эту проблему, некоторые команды и методологии разработки рекомендуют регулярно переоценивать все элементы в бэклоге продукта. Однако, хотя это и решает проблему скоропортящейся природы оценок, она имеет тенденцию усугублять расточительство, определенное 1-м Законом оценок. Вы бы предпочли, чтобы ваша команда оценивала один и тот же элемент невыполненной работы полдюжины раз, но никогда не начинала над ним работать, или вы бы предпочли, чтобы они предоставляли новую функцию каждую неделю? Опять же, см. Упомянутый выше официальный документ Microsoft, в котором представлены эмпирические данные о влиянии повторной оценки на общую продуктивность команды.

Из третьего закона оценок мы знаем, что оценки имеют тенденцию становиться более точными, чем позже они сделаны (и чем ближе они к фактически выполняемой работе). Таким образом, чем дольше оценка может быть задержана, тем более точной она будет, когда она будет сделана. Это тесно связано с принципом бережливой разработки программного обеспечения, заключающимся в откладывании принятия решений до последнего ответственного момента. Оценки также должны выполняться в последний ответственный момент, чтобы обеспечить максимальную точность и минимальную необходимость их повторения. Во многих случаях может быть достаточно оценки после завершения работы, когда она может быть на 100% точной (практически при нулевых затратах!).

5-й закон оценок: оценки необходимы

Несмотря на первые четыре закона оценок, оценки часто необходимы. Компании не могут принимать решения о создании программного обеспечения, не имея представления о затратах и ​​времени. Обслуживающие компании часто должны предоставить оценку как часть любого предложения, которое они делают для создания приложения или выигрыша проекта. То, что приведенные выше законы верны, не означает, что оценки могут исчезнуть волшебным образом (#NoEstimates). Тем не менее, можно лучше управлять ожиданиями и временем, затрачиваемым на оценку, понимают ли все участники, от заказчика до менеджера проекта до отдела продаж и разработчика, эти истины, когда дело доходит до пользовательских оценок программного обеспечения.

Стоит помнить Закон Гудхарта: Когда мера становится целью, она перестает быть хорошей мерой. Если требуются точные оценки, их не следует использовать в качестве обязательств или сроков. Если они будут использоваться в качестве целей, они будут изменены (примеры см. В комментариях ниже или на reddit).

Резюме

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

Как обычно, у Дилберта есть отличные комиксы на тему оценок:

И, наконец, если вы дочитали до этого места и заинтересованы в разработке программного обеспечения, в настоящее время я ищу команды, заинтересованные в улучшении своих методов разработки (особенно тех, которые используют веб-технологии Microsoft). Свяжитесь со мной на ardalis.com.

Если вы считаете, что эта статья была ценной, нажмите в сердце ниже и сообщите мне о своем собственном опыте в комментариях или через социальные сети. Спасибо!

Первоначально опубликовано на ardalis.com.