Пропускаются ли сроки выполнения заданий по программированию? [закрыто]

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

У меня такой вопрос: это большая проблема, или пропущенные сроки часто встречаются среди программистов, поэтому я не должен слишком беспокоиться об этом?

Да. Пропущенные сроки являются общими в разработке программного обеспечения.

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

Перефразируя Фридриха Брукса « Мифический человеко-месяц» :

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

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

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

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

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

• Большинство программных продуктов - не что иное, как программные проекты, которые были сокращены из-за подобных проблем.

В заключение:

Плохие оценки и недооценка сложности из-за ремесленного характера процесса разработки программного обеспечения означают, что он остается незрелой дисциплиной.

Пропущенные сроки не должны стать обычной практикой, если вы хотите продолжать получать работу.

С учетом вышесказанного вы обычно хотите оставить себе дополнительное пространство для маневра в ваших оценках на случай, если что-то случится (и так всегда бывает). Вам не нужно раскрывать, что вы добавили в дополнительное время, просто не делайте это необоснованным. Может быть, от 5 до 10% общего времени? Единственный способ узнать это - сделать это несколько раз.

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

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

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

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

Удивительная вещь в скорости заключается в том, что она включает в себя все нематериальные вещи, такие как прерывания и неожиданные сложности, которые разработчики с трудом учитывают в своих оценках. Все вероятности усредняются с течением времени. В среднем за 10 недель наши оценки скорости были точными в пределах 5%. Тем не менее, когда мы оцениваем одни и те же задачи в часах, одна и та же команда постоянно недооценивает на 30-50%.

Моя теория (бездоказательная) состоит в том, что люди эволюционировали, чтобы недооценивать сложные работы в два-три к одному. Каждый раз, когда Конгресс спрашивает у НАСА что-то вроде: сколько будет стоить построить шаттл или отправиться на Луну, они вернутся через неделю с номером. После того, как они исчерпают все ожидаемые затраты, они обнаружат, что это будет стоить в три раза дороже.

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

Если кто-то переделал кухню, они обычно думают: «Ну, я сделаю это через две недели». Они заканчивают это около шести недель спустя.