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

Моя общая оценка guess * 2.5 + 1 week.

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

1) Буфер для Закона Murphy's. Что-то всегда собирается идти не так, как надо где-нибудь, что Вы не можете объяснить.

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

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

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

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

Как много сказано, это - хрупкое равновесие между опытом и риском.

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

2. , Когда Вы не знаете, как сделать что-то (как то, когда это - первый раз), риск повышается

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

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

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

6. , Подводят итог всего для получения промежуточного итога...

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

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

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

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

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

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

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

Затем умножают все это на 3,14.

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

Шаги к неповреждению:

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

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

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

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

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

И да, много этого материала покрыто под (по-разному) XP, "гибким", ТОЛПА, и т.д., но это не действительно, это усложнило. Вам не нужны книга или консультант, чтобы сделать это. Вам просто нужно корпоративное желание.

Правило Scotty:

• высказывают Ваше лучшее предположение
• , окружают к ближайшему целому числу
• <забастовка> дважды, что четыре раза это (благодарит Adam!)
• увеличение к следующей более высокой единице измерения

Пример:

• Вы думаете, что потребуется 3,5 часа
• раунд это к 4 часам
• четырехкратный это к 16 часам
• сдвиг это до 16 дней

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

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

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

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

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

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

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

, Если Вы преобразовываете это 40 часов в реальное время:

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

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

Этот Ваш 40-часовой идеал займет 80 часов для окончания.

Kirk: г-н Scott, Вы всегда умножали свои оценки восстановления на фактор четыре?

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

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

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

вздох .

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

области Risk включают:

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

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

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

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

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

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

На основе чего Ваши оценки?

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

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

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

Я беру свой худший вариант развития событий, дважды это, и это все еще не достаточно.

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

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

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

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

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

Это не называют, "расширяясь" — это называют, "делая их удаленно реалистичными".

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

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

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

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

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

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

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

Поскольку Вы находите, что новые задачи необходимы, добавьте их к своему списку.

Таким образом, у Вас будет реалистическая оценка.

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

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

HTH

удачи

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

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

Снижение обещаний, сверх -deliver.