Сколько времени действительно нужно, чтобы что-то сделать?

Question

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

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

Ryan

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Я считаю, что это потому, что:

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

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