Имея 34 года программирования за спиной, мне все еще приносят удовольствие люди, которые думают, что существует магия, в которой оценка ПО работает. На протяжении всей моей карьеры, я слышал много раз, что оценка плохо работает, и у них есть способ сделать ее лучше.
На деле - нет. Правильно оценить, сколько займет что-то запрограммировать вряд ли возможно. Я никогда не мог, и каждый раз, когда я вижу кого-то, кто пробует - всегда ошибается.
На самом деле, даже сложно узнать, насколько плохая ваша оценка. В конце концов, вы пытаетесь угадать, как много времени может занять то, что определено не идеально и будут делать неидеальные люди, в обстоятельствах, которые все время изменяются. Если это займет больше времени, нежели вы оценили, то это потому, что оценка была неверная или потому что у вас не было достаточно информации в начале или оценка времени изменила сам процесс разработки. Процесс разработки вещь итеративная: каждый шаг влияет на следующие. Внешние влияния - это, например, требования дирекции, изменения рынка, личные перемены и внешние изменения, например, в инструментах или обновления фреймворка; все они влияют на то, как быстро вы закончите запланированное.
Честно говоря, оценка ПО неотличима от игры в рулетку. Оценка любого временного промежутка зависит от того, насколько вы идеально понимаете все факторы, которые влияют на этот временной промежуток. Программирование не просто линейное уравнение, а очень сложная и часто хаотическая деятельность.
Я прочитал множество статей, типа "Почему оценка разработки ПО не работает и альтернативы", авторы которых думают, что собирая статистику, со временем оценка будет становиться точнее.
Она не будет. Все оцененные куски роботы очень отдаленно связаны с другими, и ваше неидеальное знание каждого из них редко сильно с всеми ими коррелирует. Если бы я писал то же самое приложение много раз, то получил бы более точную оценку, но это только потому, что я делал одно и то же. Одна веб страница может быть едва связная с другой, даже если они похожи, потому что они соединены с другими страницами самим приложением, другими системами или вообще были созданы другими людьми. К примеру, создать страницу поиска отелей и страницу поиска для авиабилетов: обе они страницы поиска и в их основе лежат данные, вызовы API и многие детали, которые радикально отличаются. Даже тонкие отличия в дизайне имеют большое влияние на то, как много времени займет разработка, так как проработка деталей может потребовать иного подхода к программированию так же, как и исключения, которые могут быть не очень очевидны, пока не зайдете слишком далеко.
Сегодня некоторые люди думают, что Scrum, у которого в основном отведено две недели на спринт, каким-то образом сделает оценки более точными. В конце концов, вы же оцениваете маленькие куски. Но, даже здесь, есть усложняющие факторы. Насколько мелко задачи были разбиты, как были получены оценки (покер планирования или что вы там используете), так или иначе собираются метрики и оценки качества по завершении, и честность всех лиц может повлиять на точность конечной оценки спринта.
Я заметил, что в Scrum, чем больше вы отслеживаете, как люди оценивают и делают задачи (отчеты скорости и т.д.), тем больше оно влияет на общее количество времени, которое оценивается. Если вам не получается завершить задачи в спринте, вы и ваша команда выставляетесь в плохом свете, поэтому вы умышлено (или не очень) добавляете подушку в ваши следующие оценки. Если отдел качества так же дает свою оценку, то часто их работа, сбитая к концу спринта, выставляет всех в плохом свете, так как задачи завершены не полностью. Это приводит к тому, что в следующем спринте оценки растут вверх, вследствии чего задачи все больше разбиваются на подзадачи, к которым применяется аналогичный подход, и в результате все занимает больше времени. Конечно же, после этого отчеты выглядят намного лучше, но дата завершения смещается намного дальше. Оценка скорости, основанная на расчетах пользовательских историй или функциональных точек, так же может быть изменена и оценка будет выглядеть правильной. Вы заканчиваете тем, что ремонтируете рулеточный стол.
Создание неточной оценки на неясных догадках с "подушкой безопасности" приводит к тому, что, возможно, лучше будет бросить монетку. Конечно, люди чувствуют себя комфортно, когда знают, как сложно что-то сделать, когда оно будет готово и вообще возможно ли это сделать - поэтому требуют оценок. Потом оценка становиться сроками сдачи и бюджетом, людей просят работать больше часов для того, чтоб "вернуться в колею" или добавляют людей. В конце концов, все выглядят некомпетентными, когда оценка оказывается неверной. Что случается практически всегда.
Я давным давно пришел к заключению, что создание программ занимает столько, сколько занимает и это выглядит легкомысленным, но более реалистическим.
Когда ми строили Deltagraph в 1988-1993 годах, каждая версия начиналась с нескольких страниц идей от менеджера по продукции и команды разработки. Мы всегда хотели выпускать основную версию каждые 6-8 месяцев, так как они должны были взимать оплату за флоппи диски, коробку, инструкцию и доставку (в отличии от сегодня) - чтобы не обременять клиентов. Каждая деталь была создана итеративно с множеством проб и переделок. Как только мы продвигались по циклу, некоторые детали были отложены до следующих версий, а некоторые новые были добавлены, так как маркетинг это требовал. Ближе к концу цикла, мы "отрезали" функционал, который не был готов или достаточно завершен. После, мы завершали то, что имели, и это шло на основный диск. Не было оценок, кроме очень смутных: было проще частично реализовать функционал, чтоб определить сложность, которую оно имеет или как много сил она может требовать для завершения. Мы работали вместе с каждодневными обсуждениями о том, где мы находимся и куда нужно двигаться. Не было никаких итераций, как в Scrum, и мы создавали каждый день и так же получали обратную связь.
На работе за последние десятилетие был проект, который выглядел очень простым, как по мне, не больше, чем обычное CRUD приложение, и я предположил, что это может занять две недели для одного человека. Тем не менее, руководство настаивало на детализации каждого пункта. Мы встречались еженедельно на протяжении полгода и создали документ на 150 страницах для доказательства того, сколько оно занимает времени. За это время проект можно было сделать 10 раз. Иногда больше занимает сбор сведений для достоверной оценки, нежели просто взять число с потолка и реализовать, а потом итерациями доделать пока не получиться то, что надо. В моей статье The Most agile Project I Ever Did мы никогда не могли оценить, как много времени оно займет, так как практически ничего не знали о проекте до его начала, но все же сделали его в разумные сроки и все были счастливы.
Конечно, два мои примеры ничего не доказывают, но вы можете создать ПО без предоставления оценок и, работая итеративно, приняв то, что оно будет сделано, когда будет сделано и, возможно, с меньшими затратами.
Людям необходима оценка разных причин, включая определения необходимого времени, бюджета, заказчик требует фиксированную ставку, ограниченные временем сроки или внешние обстоятельства. Необходимость оценок, двигаемая страхом, и даже неправильные оценки могут уменьшить этот страх. Конечно же, фундаментально Scrum требует планирования спринта, иначе не имеет смысла называть его Scrum и, возможно, он хорошее изобретение (мне он не интересен). Но если качество вашей разработки полностью зависит от точности ваших оценок - очень вероятно, вы будете расстроены.
Оценить, что сколько на что-то требуется времени, всегда сложно и чем меньше у вас имеется информации, тем более плохой становиться оценка, что, собственно, описывает программирование в целом. Вы редко (если вообще) имеете все знания. Как по мне, это бесполезная трата времени, кончено же, не все примут это. В реальном мире, если кто-нибудь потребует оценить, сколько времени займет разработка, то, вероятно, вы умножите оценку в 3 раза для надежности, запрашивающий умножит на 3 для надежности, и высшее руководство или клиент, примет это как конечный срок. В конце концов, это случайное число, вероятно, даст вам достаточно времени, чтоб закончить разработку перед тем, как оно истечет.
Но лучше умножить на 10.
