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

39

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

Брайан
источник
33
Я обнаружил поистине изумительное доказательство того, что невозможно точно оценить все сложные задачи разработки, или точно спланировать эти задачи, или вообще любой график, основанный на оценках. Это поле для комментариев слишком маленькое, чтобы его содержать.
Дэн МакГрат
2
@Dan McGrath: Почему бы вам не опубликовать ссылку, содержащую доказательство? Подождите, вы пытаетесь быть похожим на Ферма и его последнее доказательство теоремы, которое так и не было найдено: |
Шамим Хафиз
9
По той же причине, по которой трудно спланировать поездку, когда навигатор не уверен в пункте назначения, водитель не знает дорог, а все пассажиры хотят мороженого.
Стивен А. Лоу
1
Что-то, что может вас заинтересовать, - планирование на основе доказательств.
Крейг,
2
Их нетрудно определить. Просто невозможно придерживаться.
Тони Хопкинсон

Ответы:

57

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

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

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

Роб Вейр
источник
20
Отличные баллы. Это все равно что спросить, сколько времени тебе понадобится, чтобы поехать туда, где ты никогда не был Вы можете дать оценку, основанную на расстоянии, но вы не можете определить количество трафика в час пик.
JeffO
2
@Джефф Это очень хорошее сравнение. Я должен буду помнить тот
Дейв Макклелланд
1
@Джефф ... но ты можешь знать, что сейчас час пик и добавить этот факт к своим оценкам ... ты можешь все еще быть, но не так сильно
Пемдас
2
@Pemdas: На самом деле, вы не можете знать достаточно, чтобы добавить все факты к вашим оценкам. Вы не можете знать, отвечает ли пожарная служба на звонок. Вы не можете знать, упал ли электрический провод и блокирует ли дорогу. Есть бесконечное множество вещей, которые вы не можете знать о будущем. Это будущее. Трудно предсказать - по определению.
С.Лотт
1
@Pemdas - чем сложнее задача, тем больше вмешиваются боги хаоса. Конечно, это, вероятно, подходит вам больше, чем некоторые комментарии - со знакомыми заданиями вы знаете, насколько интересны эти противные боги.
Steve314
35

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Арсений Мурзенко
источник
1
@ Джефф O: я не знаю. Для меня дата доставки означает крайний срок. А крайний срок означает, что проект не может быть сдан после него. Кроме того, в психологическом плане клиенты могут быть менее рассержены, когда вы сказали, что доставите что-то через месяц, а вы доставите это на четыре дня позже, чем если бы, 8 января 2011 г., вы сказали, что доставите это 8 февраля 2011 г., и вы доставь его 12 февраля.
Арсений Мурзенко
10
@Pemdas: это не вопрос лени. Вы можете просто впадать в депрессию или испытывать временные трудности с концентрацией внимания, или иметь личные / семейные проблемы, или быть слишком напряженным другими клиентами или кем-то еще.
Арсений Мурзенко
2
В дополнение к баллам MainMa, если вы работаете в команде, есть ситуации, когда кто-то должен быть в отпуске, для радости или болезни.
Шамим Хафиз
5
@Pemdas Они в какой-то степени случаются с каждым программистом. Просто это проявляется способами, которые не всегда очевидны. Одна неделя на проработку данной проблемы может занять 3 часа, потому что вы очень резкие и «в зоне», а на следующей неделе это займет 3 дня.
Мэтью Фредерик
7
@ 0A0D Если вы разбили проект на наиболее детальные подзадачи и выяснили, как именно они будут функционировать, то проработайте все, чтобы убедиться в том, что вы понимаете последствия объединения этих частей, и тщательно изучите все новые или не свежие Вовлеченные в процесс технологии и устраняющие каждое неизвестное, тогда вы абсолютно точно сможете получить чертовски точную оценку. Конечно, вы также выполнили почти все программирование, оставив только часть кода, и вы не можете заранее знать, сколько времени займет эта оценка. ;)
Мэтью Фредерик
15

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

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

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

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

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

Джим Г.
источник
11

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

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

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

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

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

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

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

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

источник
Поэтому, если кто-то попросит указать дату поставки от 01.02.2011 для какой-либо функции, лучше всего сказать: «Как только я над ней поработаю, я сообщу вам, сколько времени это займет»? Я уверен, что все прошло бы хорошо, как свинцовый воздушный шар;)
Брайан
0A0D: это зависит от ситуации. С командой, которая не знает друг друга, я бы не стал ставить на ЛЮБОЙ крайний срок. Однако если вы знаете свою среднюю скорость, используете коллективные оценки и практикуете итеративную разработку, вы можете установить крайний срок с гораздо большей уверенностью.
@ 0A0D, в Европе 01.02.2011 означает 2 января. По крайней мере, это облегчает ответ, когда его спрашивают 8 января: D
6

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

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

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

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

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

С. Лотт
источник
3

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

Pemdas
источник
Согласились на обзор, но мне действительно любопытно: @Pemdas, вы склонны работать над одними и теми же проблемами для каждого проекта, с небольшими изменениями? Вы имеете в виду достаточно простые вещи, может быть, еще один сервис RESTful, который просто возвращает строки таблицы базы данных или что-то в этом роде? Поработав со многими десятками программистов и наняв десятки, я еще не нашел человека, который мог бы дать точные оценки для проблем, полных неизвестных.
Мэтью Фредерик
Я работаю над тем же продуктом, но наборы проблем меняются с каждым выпуском. Я признаю, что мне никогда не приходилось оценивать что-то, что заняло более 6-8 месяцев.
Пемдас
Perndas, просто для удовольствия: сколько времени потребуется, чтобы переписать ваш продукт на C # или Java? Для запуска в облаке Google? Для визуализации данных жить в OpenGL? Чтобы клиент конечного пользователя работал на Wii?
Возможно, наше определение оценок неверно. Определенно, требуется определенный период исследования, прежде чем вы сможете дать разумную оценку, которую я обычно не включаю в свои оценки времени доставки. Я не могу разумно ответить ни на один из этих вопросов, не проведя сначала какое-либо исследование. Я бы никогда не предположил, что смогу дать оценку без понимания технологий.
Пемдас
2

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

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

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

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

JeffO
источник
Я даже не думал о дополнительных выпусках. Это отличный инструмент, чтобы дать клиенту ощутимый прогресс. Хотя я не работаю с «внешними» клиентами, так как практикую это на практике, это отличный способ для конвейерного тестирования с разработкой.
Пемдас
2

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

Брайан Карлтон
источник
2

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

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

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

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

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

Петр Перак
источник
1

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

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

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

Кен Хендерсон
источник
1

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

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

HLGEM
источник
Я бы не назвал написанием юнит-тестов задачу не-разработки;) И наши боссы считают нас по 6 часов в день. Если я скажу 60 часов, они скажут 10 дней.
Петр Перак
@Peri, Конечно, я бы тоже не стал, но многие люди забывают добавить время для написания тестов и думают только об основной проблеме под рукой. Хорошо для ваших боссов, меня удивляет, сколько не делают.
HLGEM
1

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

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

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

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

scriptin
источник
1

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

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

    • Никто не хочет пропустить крайний срок и стать заголовком!
  2. Требования меняются (часто рационально), и программист не может наложить на них вето.

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

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