Как я могу учитывать измененные или забытые задачи в оценке?

Для обработки оценок на уровне задач и составления отчетов о времени я использовал (примерно) технику, описанную Стивом Макконнеллом в главе 10 « Оценка программного обеспечения»., В частности, когда мне приходит время создавать оценки на уровне задач (непосредственно перед началом кодирования в проекте), я определяю задачи на достаточно детальном уровне, чтобы, по возможности, у меня не было задач с одной точкой, 50 % достоверности оценки больше четырех часов. Таким образом, процесс оценки задач помогает в создании программного обеспечения, помогая мне не забывать задачи во время оценки. Я придумываю диапазон часов, возможных для каждой задачи, и, используя статистические расчеты, которые описывает Макконнелл, наряду с моими историческими данными о точности, я могу при желании получать оценки на других уровнях достоверности. Я чувствую, что этот метод работал довольно хорошо для меня. Мы обязаны помещать задачи и их оценки в TFS для отслеживания, поэтому я использую оценки в процентах уверенности, которые мне сказали использовать.

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

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

В книге « Вальсируя с медведями: управление рисками в программных проектах» (авторы книги «Люди» из DeMarco и Lister) к этому потрясающе подходит. Вот моя реинтерпретация:

Сделайте оценку «все идет отлично». Конечно, все редко идет идеально, поэтому вероятность того, что это произойдет, составляет, скажем, 0,1 процента, мала. Другими словами, только один проект из тысячи будет идеально спланирован. Это то, что большинство людей используют в качестве своей «оценки», которая явно безумна.

Вместо этого мы должны думать об оценках как о распределении вероятностей. Эта оценка «идеального мира» является самой левой точкой в ​​распределении вероятности оценки.

Затем сделайте оценку «если все пойдет так же, как и в подобных проектах». Эта оценка помогает вам принять «внешний вид» ( http://wiki.lesswrong.com/wiki/Outside_view ), избегая ошибки планирования ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).

Затем сделайте оценку «Я уверен на 90%, что мы закончим к X». Будьте очень, очень уверены, что вы имеете в виду 90% уверен. Другими словами, вы ожидаете, что это займет больше времени, чем эта оценка, только один раз для каждых десяти проектов, которые вы делаете.

Теперь мы можем использовать вашу первую оценку в качестве оценки вероятности 0,1%, а вторую - оценку вероятности 50% (сезон по вкусу), а третью - оценку 90%, что даст вам хорошую кривую.

Скажем, ваши оценки 0%, 50% и 90% были 1 мая, 1 июня и 1 августа, тогда ваша оценочная кривая будет выглядеть примерно так:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Обратите внимание, как вероятность увеличивается со временем. Если кто-то попросит вас оценить 99,9% в этом сценарии, это может быть 1 января следующего года.

Одним словом - непредвиденные обстоятельства.

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

Во всяком случае, вообще говоря, есть три вида непредвиденных обстоятельств, на которые я бы порекомендовал посмотреть:

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

Эта последняя часть имеет решающее значение - это не просто «вещи занимают немного больше времени, чем я думал», это «сторонний модуль планирования, который, как нам сказали, мы должны использовать, так как это стандарт компании, может не соответствовать задаче». То, как вы рассчитываете, какое непредвиденное обстоятельство для риска добавить, представляет собой процентную вероятность того, что риск может пройти, выраженный в виде десятичной дроби (таким образом, 50% = 0,5), умноженной на воздействие этого риска (поэтому в примере, например, вам нужно написать CRON вручную заданий вместо использования планировщика, и это займет 10 дней, это число равно 10 дням).

Таким образом, если существует 50% -ная вероятность того, что ваш риск сбудется, и для его обхода потребуется 10 дней, добавьте 5 дней. Сложите все значения для всех выявленных рисков в проекте и добавьте его к итогу.

2) Дерьмо случается непредвиденно - лучшее описание, которое я когда-либо слышал, даже если это не элегантно. Это ИТ-проект, случается дерьмо. Это никогда не идет так, как ты думаешь, вещи занимают больше времени, упускаются из виду и так далее. Как правило, непредвиденные обстоятельства SH составляют от 10% (абсолютный минимум) до 25% (хотя могут быть и выше), причем 15% являются типичными, точный уровень зависит от уровня неопределенности и общего риска (перемещение должностей, неопределенные требования и т. Д.). ).

Если ваш премьер-министр не принимает непредвиденные обстоятельства SH (и, возможно, он не имеет опыта работы с ИТ-проектами или может быть слепым оптимистом), просто добавьте его ко всем отдельным суммам. Если он знает, что делает, у него будет собственный журнал рисков, и он будет любить вас за размышления об этом. Конечно, если у него есть какая-либо квалификация PM (например, PRINCE2), он узнает об этом.

3) Непредвиденные обстоятельства - это когда вы совершенно уверены, что клиент внесет изменения, но не хотите, чтобы это стало предметом спора. Добавьте либо X дней, либо X%, и это входит в банк за изменения, которые поднимает клиент. Есть два способа справиться с этим: либо вы говорите им об этом, и это их расходы, либо вы не говорите им об этом.

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

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

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

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

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

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