Ошибка планирования особенно часто проявляется при оценке задач в разработке программного обеспечения. Однако гибкие методы оценки, такие как планирование покера и т. д., похоже, не предназначены для того, чтобы избежать этой проблемы.
Итак, что вы делаете, чтобы избежать ошибки планирования при оценке задач или билетов в ИТ-проектах? Существуют ли какие-либо методологии или лучшие практики управления продуктом, призванные избежать этой распространенной ошибки?
Покер планирования предназначен для использования (или, по крайней мере, может использоваться так, чтобы он включал) форму прогнозирования эталонного класса.
При оценке с помощью покера планирования вы можете выбрать своего рода «базовый» билет, который представляет примерно 1 балл работы, а затем оценить все остальные билеты как «примерно в два раза сложнее» для 2 пунктов истории или «вероятно, в 10 раз сложнее». " за 13 пунктов или "намного проще" за 1/2 пункта.
При оценке по базовому билету и планировании только на основе сравнения с ним все оценки становятся относительными. Это должно устранить довольно большую предвзятость; вы думаете не о времени , а о сравнительном размере , в чем люди гораздо лучше разбираются.
Затем, чтобы решить, как далеко вы можете продвинуться, вы смотрите на послужной список команды на предмет «очков истории за спринт» и набираете что-то сопоставимое. Если команда становится лучше, они продолжают оценивать прежним образом, но «очки истории за спринт» растут, поэтому объем работы, которую они берут на себя, также растет, без необходимости повторной калибровки.
Этот метод работает до тех пор, пока вы продолжаете напоминать людям, что очки истории — это не меры времени, а сложность в контрольной точке, и что им не разрешено выполнять преобразование между ними в любое время. Он перестанет работать в тот момент, когда вы решите, что сюжетный балл — это час, или день, или любая другая мера времени, поскольку вы сразу же попадете во все ловушки оценки, о которых вы (и статья) упомянули.
Вы не можете «избежать» предвзятости. Он всегда есть. Вы можете свести его к минимуму, только оценив задачу с помощью нескольких различных методов и сосредоточившись на вероятностных оценках, а не на детерминированных. И даже в этом случае вы будете знать, насколько хорошо вы справились с погрешностями, только когда сможете сравнить свои фактические значения с запланированными и у вас будет достаточно большое количество сравнительных наблюдений. Это предполагает, что у вас есть высоконадежный метод отслеживания и контроля ваших фактических значений, и это огромное предположение, которое, вероятно, не совсем верно.
Как и в случае со всеми человеческими предубеждениями, чем больше вы думаете, что держите их под контролем, тем более вы предвзяты.
Согласно статье Википедии об «ошибке планирования» :
Ошибка планирования — это явление, при котором прогнозы о том, сколько времени потребуется для выполнения будущей задачи, демонстрируют склонность к оптимизму и недооценивают необходимое время.
Различные agile-фреймворки используют разные метрики, но обычно используемые метрики скорости и кумулятивного потока являются типичными барьерами для смягчения систематической ошибки планирования. Конечно, есть и другие показатели, но я кратко расскажу о скорости, потому что я думаю, что она наиболее точно решает проблему.
Скорость — это метрика, которая рассматривает исторические темпы доставки и использует скользящее среднее или другие статистические функции для сглаживания возмущений. Метрика скорости является вероятностной, и хотя она часто лучше всего работает с базовым эталонным классом для привязки метрики, при прагматическом использовании она на самом деле менее чувствительна к этому, чем можно было бы подумать. Настоящим определяющим фактором того, насколько надежна скорость как прогностическая метрика, является согласованность процесса оценки.
Ключом к общепризнанному успеху скорости в гибком планировании является последовательный процесс оценки. На самом деле очень мало имеет значения, является ли процесс оценки оптимистичным, пессимистичным или вообще игнорирует эталонный класс, если процесс оценки применяется одинаково на всех итерациях. В течение достаточного промежутка времени последовательный процесс оценки будет стремиться к устойчивой скорости доставки.
Хотя последовательный процесс оценки необходим для надежного прогнозирования, это не означает, что процесс оценки вашего проекта нельзя изменить или улучшить. Заметным предостережением здесь является то, что итеративные или поэтапные улучшения процесса оценки будут создавать небольшие возмущения в скорости доставки, но, как правило, они будут достаточно малы, чтобы быть проглоченными функцией сглаживания.
В качестве соответствующего предостережения также можно внести радикальные изменения (надеюсь, улучшения!) в процесс оценки. Когда это происходит, вам нужно либо отбросить исторические данные, либо применить «фактор выдумки» для учета изменений в методологии. В краткосрочной перспективе это может привести к снижению надежности прогнозирования с помощью метрики, но часто может оказаться целесообразным, если приведет к более устойчивой надежности выполнения прогнозов.
Это не совместная оценка при планировании покера, которая так сильно помогает (хотя это может уменьшить индивидуальные предубеждения). Это часть отслеживания скорости, которая позволяет вам применять исторические данные, чтобы помочь с будущими оценками.
Например, если в предыдущем спринте мы пытались выполнить работу на 50 баллов, а закончили только 40, то наш показатель скорее ближе к 40, чем к 50.
Вот еще один пример использования исторических данных для повышения точности оценок (более сложный с точки зрения сбора данных, к тому же он использует распределения вероятностей).
Другие методы, которые я видел, работают:
Не забывайте об идее сходимости оценок (ранние оценки далеки от совершенства, и они будут улучшаться все больше и больше по мере продвижения работы).
Эрик
асмайер