Почему расписания программ так сложно определить?

По моему опыту, заставить нас, инженеров, точно оценивать и определять задачи, которые нужно выполнить, - все равно что тянуть зубы. Вместо того, чтобы просто давать оценочную оценку в 2-3 недели или 3-6 месяцев ... какой самый простой способ определить графики программного обеспечения, чтобы их было не так больно определять? Например, клиент А хочет функцию до 01.02.2011. Как вы планируете время для реализации этой функции, зная, что на этом пути могут потребоваться другие исправления ошибок и что потребуется дополнительное время на разработку?

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

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

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

Согласно моему личному опыту, это совершенно противоположно тому, что сказал Пемдас : с практикой я только что понял, что совершенно невозможно оценить, сколько времени потребуется для выполнения задачи. В начале своей карьеры в разработке программного обеспечения я часто давал оценки, такие как «45 дней», «пять недель» и т. Д., Затем очень старался закончить вовремя. Через несколько лет я начал давать менее точные оценки, такие как «приблизительно один месяц», «пять-семь недель» и т. Д. На самом деле, я стараюсь либо не давать никаких оценок, либо просить клиента дать свою собственную оценку. или крайний срок, или я даю приблизительную оценку.

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

1. Нелегко узнать, что именно нужно сделать для продукта, и особенно, как это сделать . Очень часто я запускал некоторые части приложения, а после нескольких дней работы понимал, что мой первый подход был неправильным и что есть лучший и более умный способ сделать что-то.

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

3. Требования часто недостаточно ясны , но, прочитав их в начале, вы думаете, что они есть. Иногда вы можете понять, что означает «A», и, начав их реализовывать, вы заметите, что они могут означать «B».

4. Клиентам нравится менять свои требования именно тогда, когда вы только что закончили соответствующую часть , и они действительно не понимают, почему вы просите еще две недели и 2000 долларов, чтобы сделать крошечное изменение, потому что они не видят, что это крошечное изменение требует изменить другие вещи, которые требуют изменить другие и т. д.

5. Вы не можете оценить свою мотивацию . Бывают дни, когда вы можете работать часами и преуспевать. Бывают недели, когда после написания десяти строк кода вы переключаетесь на StackExchange для программистов и часами читаете ответы на вопросы.

6. Все становится действительно плохо, когда ваша оценка зависит от других людей . Например, в одном двухмесячном проекте мне пришлось ждать, пока дизайнер выполнит свою работу, чтобы закончить свою собственную. Этому дизайнеру потребовалось 3 месяца, прежде чем доставить кусочек непригодного дерьма. Конечно проект опоздал.

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

Что ты можешь сделать?

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

2. Будь чист . Если вы полагаетесь на дизайнера, другого разработчика и т. Д., Скажите это. Вместо того чтобы сказать «Я доставлю продукт через три месяца», скажите «Я доставлю продукт через два месяца после того, как дизайнер предоставит мне PSD-файлы».

3. Объясните: если требования меняются каждый день, проект вряд ли будет выполнен вовремя.

4. Нарежьте свое расписание . Своевременная доставка частей большого проекта.

5. Никогда не оценивайте, когда вы используете продукт, который вы не знаете хорошо, или, особенно, когда вы будете работать над исходным кодом кого-то другого: вы никогда не сможете предсказать, насколько дрянным может быть исходный код и сколько времени вы потратите понимание и копирование его в The Daily WTF.

Очень похожий вопрос: «Сколько времени потребуется, чтобы разгадать этот кроссворд?»

Вы не можете ответить на этот вопрос, пока не посмотрите на него, чтобы увидеть множество вещей, таких как:

• Это на знакомом языке? (Испанский против английского против китайского)
• Это один из типов, которые мы решили раньше? (Один в серии работает в журнале, например)
• Требуются ли какие-либо из выводов дополнительные знания, прежде чем мы сможем их понять?
• Есть ли где-нибудь в загадке вещи, которые, насколько вам известно, потребуют дополнительной работы?

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

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

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

Конечно, вы можете оценить, сколько времени займет + -2 минуты от вашего дома до работы. Вы знаете, как водить машину, можете оценить движение транспорта и некоторые другие внешние факторы.

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

В программном обеспечении это хуже:

1. Оценки часто становятся обязательством , поэтому наше суждение изменяется.
2. Там могут быть огромные различия между оценкой Боба и Карла для одной и той же задачи.
3. Неопределенности очень распространены, сколько из нас застряло на глупой ошибке или сбое жесткого диска, разрушающем любую очевидную хорошую оценку.
4. Мы обычно забываем обо всех других задачах кроме программирования, включая встречи, телефонные звонки, помощь нашей коллеге и т. Д.
5. Человеческий мозг ограничен . Он не предназначен для оценки долгосрочных задач.

Вот почему невозможно сказать своему клиенту, что вы сможете отправить с 02/01/2011 с хорошей точностью, и забыть о 03/01/2011.

Чтобы решить все эти проблемы, я рекомендую вам продвинутые методы оценки, такие как Planning Poker (отказ от ответственности: это один из моих веб-сайтов) и итеративное развитие с вычислением скорости .

• Первые два вопроса решаются с помощью Planning Poker. Оценки являются коллективными, и команда принадлежит им, а не отдельным лицам.
• Последние третьи проблемы решаются с помощью Velocity и Iterative Development. Зная вашу скорость (фактор, который применяется к вашим оценкам на основе истории), вы можете планировать выпуски с большей уверенностью. Итеративная разработка, когда она хорошо сделана, приносит самые важные функции на вершину и помогает вам повысить ценность ваших пользователей на ранних этапах.

Разработка программного обеспечения - по определению - акт открытия и изобретения. Это всегда должно включать что-то неизвестное.

Единственный раз, когда все, что связано с разработкой программного обеспечения, известно, это когда программное обеспечение завершено.

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

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

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

Честно говоря, я думаю, что это просто требует практики. Если вы пишете достаточно кода, в конечном итоге вы должны быть «довольно» точными. Мой первый босс полагал, что этот навык был достаточно важен, и попросил, чтобы я неофициально практиковал это в каждой функции / проекте, которые я реализовал. После каждого проекта мы проверяли оценки и пытались выяснить, где я ошибся. В конце концов, вы поняли это.

Это никогда не легко. Вы просто пытаетесь стать лучше в этом.

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

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

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

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

Я многому научился из этой книги:

Оценка программного обеспечения: демистификация черного искусства

Короче говоря, чтобы получить лучшие результаты оценки, мы делаем это:

1. все, кроме тривиальных задач, оцениваются более чем одним человеком (два в нашем случае)
2. мы делим задачу на меньшую задачу. Чем больше у вас задач, тем больше вероятность, что ваша оценка будет хорошей - закон больших чисел, если я правильно помню из бу
3. мы оцениваем худший, лучший и наиболее вероятный сценарий. Иногда каждый из нас оценивает эти древовидные сценарии совершенно по-разному. Это означает, что мы должны поговорить, и обычно получается, что один из нас не понимал задачу. Если бы один человек оценил задачу в одиночку, это было бы неправильно.
4. мы помещаем 3 числа сверху точки в уравнение и получаем оценку (отлично) k

После того, как задание выполнено и наша оценка ошибочна, мы пытаемся найти причины. И мы включаем эти знания в следующий процесс оценки. Пока что это лучший процесс, который я использовал для оценки больших задач. Когда я говорю «задача», я имею в виду работу, которая занимает от 50 до 500 часов.

Примечание. Это действительно относится только к проектам, где вы выставляете счет по часам в сравнении с фиксированной / фиксированной ставкой.

Я обычно стараюсь планировать свое расписание так, чтобы оно состояло по существу из нескольких спринтов SCRUM (независимо от того, используется SCRUM или нет). При составлении графика я заранее определяю, какой длины будет каждый спринт и какие функции будут у проекта. Как правило, есть некоторые функции, которые необходимо выполнить в первую очередь, поэтому я стараюсь дать наилучшую оценку (не путать с оптимизмом) для тех, и любые функции, которые будут в конце проекта, будут иметь обобщенные оценки. После сопоставления элементов со спринтами я пытаюсь добавить от 1 до 2 спринтов в хвостовой части проекта, чтобы учесть функции, которые сдвигаются вправо, и функции, которые были упущены при сборе исходных требований.

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

В дополнение ко всем названным вещам, я вижу эти две вещи как некоторые из самых больших проблем. Сначала вы оцениваете окончательную дату, основываясь на доступности каждого разработчика в течение полных 8 часов в день 5 дней в неделю. Это неверно и практически на 100% гарантирует, что дата завершения пропущена в любом нетривиальном проекте. Люди берут выходной, посещают корпоративные (или не связанные с проектами) встречи, борются с персоналом по поводу требований по медицинскому страхованию, делают перерывы и т. Д. Никогда не предполагайте, что на одного разработчика приходится более 6 часов в день.

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

Когда дело доходит до оценки времени для задач, которые могут занять больше, чем несколько часов, я стараюсь изо всех сил использовать эти правила:

1. Не когда - либо пытаться предсказать , когда другие люди закончат свою работу , если вам случится, зависит от него. Говори только за себя.
2. Сначала проанализируйте задачу, затем оцените. Под анализом я подразумеваю, по крайней мере, записывать (и не пытаться держать все в голове!) Список подзадач с оценкой для каждого из них.
3. Если задача достаточно сложная, оцените время самого анализа. Пусть оценка будет отдельным процессом. Вы также можете убедиться, что ваш начальник знает об этом.
4. Не оценивайте под давлением. Дайте понять, что для разумной оценки требуется время, и просто скажите им что-то вроде: «Я назову дату завтра к 11:00, когда закончу анализировать задачу». Я знаю, что некоторые клиенты / менеджеры могут давить сильно, но они не пройдут. Положи свое занятое лицо и требуй своего времени!
5. Попросите немного больше времени, чем вы думаете , потому что вы, вероятно, забыли добавить время перерыва на кофе (и другие помехи) в вашу оценку.
6. Для больших задач спросите еще больше - вероятно, будет больше, чем один кофе-брейк.
7. Если вы действительно не можете оценить (задача слишком сложная / незнакомая) или действительно не уверены - попросите кого-нибудь, способного помочь с вашим анализом.

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

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

Есть «известные неизвестные» и «неизвестные неизвестные». :-)

1. Оценки часто становятся крайними сроками.

   • Никто не хочет пропустить крайний срок и стать заголовком!

2. Требования меняются (часто рационально), и программист не может наложить на них вето.

3. Программист может / не может контролировать такие факторы, как

   • Наличие кода, от которого она зависит
   • Качество кода, от которого она зависит
   • Общая архитектура и дизайн системы
   • API для доступа к другим частям системы