Вы завышаете свои расчетные даты завершения проекта?

Ответ 1

Закон Хофстадтера. Любой вычислительный проект займет вдвое больше времени, как вы думаете, это будет; даже если вы принимаете во внимание Закон Хофштадтера.

Ответ 2

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

Ответ 3

О да, я научился всегда умножать мою первоначальную оценку на два. Вот почему инструмент FogBUGZ Evidence-Based Scheduling настолько полезен.

Ответ 4

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

Шаги для разрыва:

• Нанять менеджеров технических программ. Разработчики могут удвоиться по мере необходимости.
• Поместите любой запрос функции, запрос на изменение или ошибку в базу данных сразу же, когда она появится. (Моя организация использует Trac, который не полностью сосать.)
• Ваши PM прервут эти запросы на шаги, каждый из которых займет неделю или меньше.
• На еженедельной встрече ваши лидеры выбирают, какие билеты они хотят сделать на этой неделе (возможно, с помощью маркетинга и т.д.). Они присваивают эти билеты разработчикам.
• Разработчики заканчивают как можно больше своих назначенных билетов. И/или они спорят с премьер-министрами о задачах, которые, по их мнению, длиннее недели продолжительностью. Билеты корректируются, разделяются, переназначаются и т.д., Если необходимо.
• Код записывается и проверяется каждую неделю. У QA всегда есть чем заняться. Сначала выполняются самые приоритетные изменения. Маркетинг точно знает, что происходит по трубе, и когда. И в конечном итоге:
• Ваша компания падает с правой стороны от 20% -ного успеха для программных проектов.

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

Недостатки этого подхода:

• Когда маркетинг спрашивает: "Сколько времени потребуется, чтобы получить [X]?", они не получают оценки. Но мы все знаем, и так делают, что оценки, которые они получили раньше, были чистой фантастикой. По крайней мере, теперь они могут видеть доказательства, каждую неделю, что [X] работает.
• У нас, как разработчиков, меньше вариантов того, что мы работаем каждую неделю. Это несомненно верно. Два момента: во-первых, хорошие команды привлекают разработчиков к решениям о том, какие билеты будут назначены. Во-вторых, ИМО, это делает мою жизнь лучше.

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

И да, многие из этих вещей покрыты (по-разному) XP, "agile", SCRUM и т.д., но это не так уж сложно. Для этого вам не нужна книга или консультант. Вам просто нужна корпоративная воля.

Ответ 5

Правило Скотти:

• сделайте все возможное.
• округлить до ближайшего целого числа
• удвоить значение в четыре раза (спасибо Адаму!)
• увеличить до следующей более высокой единицы измерения

Пример:

• Вы думаете, что это займет 3,5 часа.
• округлить до 4 часов
• в четыре раза до 16 часов
• сдвиньте его до 16 дней.

Ta-даа! Ты чудотворец, когда делаешь это менее чем за 8 дней.

Ответ 6

Обычно да, но у меня есть две стратегии:

• Всегда предоставлять оценки как диапазон (т.е. 1d-2d), а не один номер. Разница между числами говорит менеджеру проекта о вашей уверенности и позволяет им лучше планировать.
• Используйте что-то вроде FogBugz 'Evidence Based-Scheduling или личную таблицу, чтобы сравнить свои исторические оценки с тем временем, которое вы на самом деле взяли. Это даст вам лучшую идею, чем удвоение. Не в последнюю очередь потому, что удвоения может быть недостаточно!

Ответ 7

Я смогу ответить на это через 3-6 недель.

Ответ 8

Он не называется "раздуванием" - он называется "делает их удаленно реалистичными".

Ответ 9

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

Ответ 10

Не забывайте, что вы (инженер) фактически оцениваете в идеальные часы (срок схватки).

В то время как управление работает в реальном времени.

Разница заключается в том, что идеальные часы - это время без перерыва (с 30-минутным разогревом после каждого перерыва). Идеальные часы не включают время в собрания, время для обеда или обычного чата и т.д.

Учитывайте все это, и идеальные часы будут стремиться к реальным часам.

Пример:   Расчетное время 40 часов (идеальное)   Менеджмент предполагает, что это 1 неделя в режиме реального времени.

Если вы конвертируете это 40 часов в реальном времени:

• Предположим, что одна встреча в день (продолжительность 1 час)
• один перерыв на обед в день (1 час)
• плюс 20% накладных расходов для чит-чатов в ванной перерывах, получающих кофе и т.д.

8-часовой рабочий день - 5 часов рабочего времени (8 - встреча - обед - разминка).
Время 80% эффективности = 4 часа идеального времени в день.

Этот ваш 40-часовой идеал займет 80 часов в режиме реального времени.

Ответ 11

Kirk: Г-н Скотт, вы всегда умножали ваши оценки ремонта в четыре раза?

Скотти: Конечно, сэр. Как еще я могу сохранить свою репутацию чудотворца?

Ответ 12

Хорошее эмпирическое правило показывает, сколько времени потребуется, и добавьте 1/2 снова столько времени, чтобы покрыть следующие проблемы:

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

Ответ 13

<sneaky>
Вместо того, чтобы раздувать оценку проекта, раздуйте каждую задачу индивидуально. Труднее для ваших начальников бросить вызов вашим оценкам таким образом, потому что кто будет спорить с вами в течение нескольких минут.
</& подлый GT;

Но серьезно, используя EBS, я обнаружил, что люди обычно намного лучше оценивают небольшие задачи, чем крупные. Если вы оцениваете свой проект через 4 месяца, вполне может быть за 7 месяцев до его завершения; или нет. Если ваша оценка задачи составляет 35 минут, с другой стороны, это обычно примерно так.

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

Затем умножьте все на 3.14.

Ответ 14

Многое зависит от того, насколько детально вы хотите получить, но дополнительное время буфера должно основываться на оценке риска - на уровне задачи, где вы добавляете различные времена буферизации для: Высокий риск: от 50% до 100% Средний риск: от 25% до 50% Низкий риск: от 10% до 25% (все зависит от опыта предыдущих проектов).

Области риска включают:

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

Таким образом, для заданной задачи (или группы задач), которая охватывает компонент A, начальная оценка составляет 5 дней, и она считается высокой степенью риска на основе покрытия требований - вы можете добавить от 50% до 100%

Ответ 15

Шесть недель.

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

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

Ответ 16

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

Ответ 17

Вы можете рассчитать продолжительность проекта двумя способами: каждый из них должен решить все задачи и выяснить, сколько времени займет каждый, фактор задержек, встреч, проблем и т.д. Эта цифра всегда выглядит очень коротко, поэтому люди всегда говорите такие вещи, как "double it". После некоторого опыта в реализации проектов вы сможете рассказать очень быстро, просто взглянув кратко на спецификацию, сколько времени это займет, и, неизменно, она будет вдвое больше, чем первый метод...

Ответ 18

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

Во всяком случае, отметьте все ваши оценки и сравните их с фактическим временем завершения, чтобы понять, насколько вы склонны недооценивать и при каких условиях. Таким образом, вы можете более точно "раздуть".

Ответ 19

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

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

Когда вы найдете новые задачи, добавьте их в свой список.

Таким образом, вы получите реалистичную оценку.

Я склонен быть оптимистом в достижимости, и поэтому я склонен оценивать с низкой стороны. Но я знаю это о себе, поэтому я, как правило, добавляю дополнительные 15-20%.

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

НТН

веселит

Ответ 20

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

Ответ 21

Каковы ваши оценки на основе?

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

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

Ответ 22

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

Ответ 23

Я использую свой худший сценарий, удваиваю его, и этого все равно недостаточно.

Ответ 24

О да, общее правило из долгого опыта - дать проекту наилучшую оценку времени, удвоить его и то, как долго это будет на самом деле!

Ответ 25

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

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

вздоха.

Ответ 26

Как много сказано, это тонкий баланс между опытом и риском.

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

• Когда вы не знаете, как что-то делать (например, когда это происходит в первый раз), риск увеличивается

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

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

• Конечно, когда вы приобретаете опыт по определенной задаче (например, подключение ваших моделей к базе данных), риск снижается

• Суммируйте все, чтобы получить ваш итоговый итог...

• Затем, во всем проекте, всегда добавляйте еще 20-30% (этот номер будет меняться в зависимости от вашей компании) для всех ответов/документов/вопросов, которые вы будете ждать, встреч, которые мы всегда забываем, изменения идеи во время проекта и т.д.... то, что мы называем человеческим/политическим фактором

• И снова добавьте еще 30-40%, что объясняет тесты и исправления, которые выходят из тестов, которые вы обычно делаете сами... например, когда вы сначала покажете это своему боссу или клиенту

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

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

Ответ 27

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

Ответ 28

Я всегда удваиваю свои оценки по следующим причинам:

1) Буфер для закона Мерфи. Что-то всегда будет ошибочным, если вы не можете объяснить.

2) Недооценка. Программисты всегда думают, что все легко сделать. "О да, это займет всего несколько дней".

3) Сторговое пространство. Высшее руководство всегда считает, что графики могут быть сокращены. "Просто заставьте разработчиков работать усерднее!" Это позволяет вам дать им то, что они хотят. Конечно, чрезмерное использование этого (более одного раза) будет обучать их предполагать, что вы всегда переоцениваете.

Примечание. Всегда лучше поместить буфер в конце графика проекта, а не для каждой задачи. И никогда не сообщайте разработчикам, что буфер существует, иначе Parkinson Law (Work расширяется, чтобы заполнить время, доступное для его завершения) вступит в силу вместо этого. Иногда я говорю Upper Management, что буфер существует, но, очевидно, я не даю им основания № 3 как оправдание. Это, конечно, зависит от того, насколько ваш босс доверяет вам быть правдивым.

Ответ 29

Недоукомплектовать, перегружать.

Ответ 30

Многие люди говорят, что делают оценку и удваивают ее (а иногда и удваивают). Другие говорят, что используют планирование на основе фактических данных (al la Joel).

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

• Мое лучшее предположение о том, как долго это займет.
• Неопределенность (риск) - похоже, возможно, что-то (известное/неизвестное неизвестное) не в спецификации, которое удваивает время.
• Исправления ошибок
• Время ожидания

Для # 1 я использую наиболее реалистичную оценку, которую я могу.
Для # 2 я решаю, вероятно, риск, а затем умножьте # 1 на то, чтобы получить скорректированную оценку,
Для # 3 и # 4 умножьте скорректированную оценку на 20% и станьте значением каждого.

Таким образом, для любой задачи итоговая сумма составляет 140% или более исходной оценки.

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

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