Сколько времени на самом деле требуется, чтобы что-то сделать?[закрыто]

Question

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

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

Райан

Answer 1

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

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

Answer 2

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

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

Как только вы сделаете это, сложите сумму и удвоите ее.Если вам придется координировать свои действия с другими, утроьте их.

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

Answer 3

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

Я работаю в небольшой команде (5 разработчиков, 1 ведущий), многие из нас работают над несколькими проектами одновременно - какими-то большими, какими-то маленькими.В зависимости от приоритета проекта, прихотей руководства и наличия других команд (при необходимости) работа над одним проектом чередуется с другими.

Так что, да, работы за 3 месяца может и не хватить, но это может быть работа за 3 месяца в течение 6-месячного периода.

Answer 4

Я самостоятельно выполнял проекты на срок от 1 до 6 месяцев и всегда стараюсь удваивать или увеличивать вчетверо свои первоначальные оценки.

Answer 5

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

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

Я видел слишком много попыток разработать методологию оценки, и ни одна из них не сработала.Они могут иметь псевдонаучную привлекательность, но они просто не работают на практике.

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

Answer 6

Закон Хофштадтера:

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

Я верю, что это происходит потому, что:

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

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

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

Answer 7

Я занимаюсь проектами от 2 недель до 1 года.В целом мои оценки довольно хороши, апостериори.Однако в начале проекта я обычно получаю взбучку, потому что мои оценки считаются слишком большими.

Это потому, что я учитываю множество вещей, о которых люди забывают:

• Пришло время для исправления ошибок
• Время для развертывания
• Время для руководства/встреч/ взаимодействия
• Время, позволяющее владельцам требований изменить свое мнение
• и т.д.

Хитрость заключается в использовании планирования, основанного на фактических данных (см. Joel о программном обеспечении).

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

Answer 8

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

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