Совет молодому программисту по созданию программных смет

Джоэл Спольски в своем блоге не рекомендует ни одну задачу продолжительностью более 16 часов . Если там больше деталей, разбейте их на подзадачи. Я предпочитаю 1 день или 1/2 дня. И ИТ-специалисты, и разработчики обычно настроены оптимистично (предполагают, что все будет работать с первого раза, минимальная отладка и т. д.). Отслеживайте свои оценки по сравнению с фактическими и используйте это, чтобы смягчить свои собственные оценки.

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

Хорошим уровнем детализации, к которому нужно стремиться, является наличие задач объемом около 1 дня усилий.

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

1. Уровень уверенности/ неуверенности в том, что нужно сделать.
2. Технология , с которой вы работаете — сколько у вас накладных расходов от кодирования до итерации тестирования? Сколько времени занимает сборка? Насколько сложно тестировать и проверять свой код небольшими итерациями?
3. Сколько взаимодействия вам нужно с другими разработчиками для выполнения ваших задач?
4. Насколько стабильна ваша среда и настройки? У вас ежедневно происходит много поломок или простоев, которые могут помешать вам добиться прогресса?

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

Следующим этапом будет пересмотр ваших оценок с вашими опытными коллегами . Не просто пересматривайте цифры. Просмотрите обоснование выбора чисел в качестве оценок.

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

Практика делает совершенным (хотя нет идеальных оценок усилий...).

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

• Имейте первую добычу для ваших собственных целей. Давайте назовем это

Икс

• Если x > вашего допуска PM (у меня 40 часов), то разбейте на более простые логические задачи. Давайте назовем это

х1, х2, х3

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

x1-наихудший случай

• Я возьму x1 и x1 в худшем случае и усредню их. как это:

(x1+x1-наихудший случай)/2

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

Надеюсь это поможет. гео

• Разбейте его помельче. Никогда не более 2 недель; желательно <2 дней.
• Запишите, как вы это делаете, чтобы вы могли видеть, как вы обычно работаете в 2 или 10 раз. Используйте отслеживание ошибок/задач с этой функцией, например, FogBugz или redmine.

Получите себе копию «Оценки программного обеспечения» Стива МакКоннелла . Это очень поможет .

Одно ВЕЛИКОЛЕПНОЕ правило оценки касается управления клиентами. Если вы скажете своей жене, что будете дома в 5 и вернетесь в 6, она рассердится, НО если вы скажете ей, что вернетесь домой в 7 вечера, а затем вернетесь домой в 6, в конце концов, она счастлива. странно, но факт... базовая психология. Оооооооооооооооооооооооочень важная часть оценки — это убедиться, что она будет выше, чем та, которую вы предоставите, и если менеджер проекта недоволен оценкой, все равно подождите и доставьте ее быстрее!!!!!! в конце концов, он будет рад, что вы доставили его раньше (и, скорее всего, скажет: начните лучше оценивать). В любом случае, с точки зрения бизнеса, лучше прийти вовремя, чем опоздать, поскольку они договорились о датах с большим количеством внешних сторон и хотят выполнить эти даты.