Комментарии 25
Спасибо, возьму на заметку.
К сожалению у нас не принимают никаких оценок сроков, которые выше дедлайна. Но все равно спасибо.
К сожалению у нас не принимают никаких оценок сроков, которые выше дедлайна. Но все равно спасибо.
Вместо одной случайной величины берется три, к ним добавляют случайные веса и — вуаля, мы повысили точность. Пассаж про «увеличивает вероятность хороших рисков и уменьшает вероятность плохих» тоже неплох.
Ну, я бы не назвал оценку даже по одной точке совсем случайной. Зависит от многих факторов — да, но регулярно тренируясь можно достичь неплохих результатов. На счет «к ним добавляют случайные веса» тоже не согласен. Основное, на мой взгляд, в данном подходе то, что мы
- Заранее продумываем возможные риски, которые могут возникнуть в ходе работы над задачей.
- Привлекаем к оценке риска того, кто будет выполнять задачу, то есть более компетентен, чем менеджер.
Переводную статью надо бы в категорию «Переводы».
Оценка по трём точкам — это процесс в три шага
Кто источник этой методики? К ней есть несколько вопросов. Например, оценка BG считается как «среднее время при решении задачи 100 раз». Но часто задачу требуется решить ровно один раз. Как решить творческую задачу 100 раз? Каждый раз время будет разное. Как оценить время выполнения задачи, которую ты никогда не решал?
Кто источник этой методики?Автор описывает упрощенный подход PERT.
Как решить творческую задачу 100 раз?Тут не предлагается решить задачу 100 раз, тут предлагается прикинуть сколько займет времени решение задачи в среднем, если решить её 100 раз. Можно же написать одну и ту же картину сто раз? Вот и надо оценить сколько это займет времени.
Как оценить время выполнения задачи, которую ты никогда не решал?Никак. Но если работаете длительное время в одной и той же области, то накапливается опыт, который позволяет примерно оценить сколько займет та или иная задача.
Хорошо, попробуем на примере? Требуется оценить задачу «Сделать авторизацию на сайте через Вконтакте». Как оценить её BG? По методике, я должен представить, что я делаю задачу «Авторизация через ВК» сто раз. Я как честный интерпретатор вычисляю: первый раз я её буду делать хз сколько, примерно 20 часов. Причем 18 из них будет чтение документации, разбор OAuth, поиск подводных граблей и т.д. Второй раз я сделаю эту же задачу за 2 часа. Третий раз за 1.5 часа. Четвертый — за 1.5 часа. Сотый раз — за 1.5 часа. Среднее время выполнения задачи — 1.7 часа. Это и есть оптимальная оценка? На мой взгляд, это хрень какая-то. Где ошибка?
Здесь есть ещё один забавный нюанс: пока я не сделаю задачу в первый раз, я не смогу сказать, сколько времени займет решение этой задачи в пятый и десятый разы. А пятый и десятый не нужны, нужен только первый.
Здесь есть ещё один забавный нюанс: пока я не сделаю задачу в первый раз, я не смогу сказать, сколько времени займет решение этой задачи в пятый и десятый разы. А пятый и десятый не нужны, нужен только первый.
Кстати, это красивая иллюстрация того, насколько круче опытный разработчик. Он не только прошёл первый шаг в большом количестве задач (20 часов --> 2 часа), но также может делать аналогии незнакомых задач с ранее сделанными подобными задачами (Авторизация ВК ~~ Авторизация ФБ --> 2-4 часа). И сроки меньше, и оценки точнее.
Хм. Примерно 20 часов, 18 из них на чтение документации — остается 2. Судя по дальнейшим предположениям, на написание кода будет потрачено 1.5 часа. Таким образом, на «разбор OAuth, поиск подводных граблей и т.д.» + проверка работоспособности остается 0.5 часа. Точно всё правильно?
Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?
Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?
Прошу прощения — неправильно прочитал — первый пункт больше не актуален.
Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?Документация может совсем отсутствовать, авторизация может оказаться вовсе не OAuth, а выполняться с помощью микроконтроллера без дата-шитов, код приложения написан на самодельном языке программирования (естественно, без документации), а предыдущие разработчики вымерли чуть раньше мамонтов. Часов миллион, не меньше. Стёб, конечно, но идея ясна.
Тогда, вероятно, данный метод оценивания Вам не подходит.
А как Вы проводите оценку задач на своих проектах?
А как Вы проводите оценку задач на своих проектах?
Декомпозиция задач, оценка по аналогии, задачи вида «исследовать задачу», обсуждение с коллегами. Всё сводится к тому, чтобы снизить неопределённость в оценке. Конечно, остаются ещё внешние факторы, которые нельзя изучить заранее, в этом случае как раз подойдёт описанный выше метод. Но по моему опыту, таких факторов в разработке ПО довольно мало, и они скорее организационные, нежели технические.
Возможно тут будет работать такой подход:
Разбиваем задачу на две подзадачи — «Разобраться в новой схеме авторизации» и «Реализовать известную схему авторизации». Каждая оценивается отдельно, потом оценки складываются. 1,5 часа будет относиться только ко второй задаче и средняя оценка не исказится.
Разбиваем задачу на две подзадачи — «Разобраться в новой схеме авторизации» и «Реализовать известную схему авторизации». Каждая оценивается отдельно, потом оценки складываются. 1,5 часа будет относиться только ко второй задаче и средняя оценка не исказится.
В изложении метода (кстати, неплохо бы упомянуть, что он происходит из PERT) есть некоторые неточности.
Замечание по теории: Пессимистическая и оптимистическая оценка выставляются исходя не из 100% случаев, а из 99%. Это зафиксировано в формуле, где знаменатель 6 — это «три сигма» в обе стороны.
Замечание по практике менеджмента: практического смысла спрашивать у исполнителя все три точки нет никакого. Это связано с тем, что обычно исполнитель не понимает, к чему его, например, обязывает вынесение точной оптимистической оценки (и что он получит, если назовет малое число). Реальная практика обычно такая: либо спрашивается «одна» оценка (которая рассматривается, например, как 70% — где-то по середине между BG и P), либо спрашивается две (реалистичная и пессимистичная, которые используются как BG и P). Что же касается оптимистической оценки, то её (как и вообще все корректировки в оптимистичную сторону) может сделать только менеджер или тим-лид, т.е. человек, ответственный за проект в целом и за риски по срокам в частности. Либо её можно принять равной BG, т.е. вообще не учитывать «положительные» риски в планировании.
При этом, по совокупности, никто не мешает всю эту практику «спроси исполнителя» в итоге сводить в формат PERT (я так делал и у меня это работало), однако надо понимать суть трудовых отношений и не писать в таблицу всё, что вам сказали. Оценки, пришедшие снизу, крайне желательно дублировать другими данными (историческими, внешней оценкой и т.д.).
P.S. Всё вышенаписанное, конечно, относится к программным проектам (где, в отличии от например строительных, нет устоявшихся нормативов). Как я понял, мы говорим про программные проекты)
Замечание по теории: Пессимистическая и оптимистическая оценка выставляются исходя не из 100% случаев, а из 99%. Это зафиксировано в формуле, где знаменатель 6 — это «три сигма» в обе стороны.
Замечание по практике менеджмента: практического смысла спрашивать у исполнителя все три точки нет никакого. Это связано с тем, что обычно исполнитель не понимает, к чему его, например, обязывает вынесение точной оптимистической оценки (и что он получит, если назовет малое число). Реальная практика обычно такая: либо спрашивается «одна» оценка (которая рассматривается, например, как 70% — где-то по середине между BG и P), либо спрашивается две (реалистичная и пессимистичная, которые используются как BG и P). Что же касается оптимистической оценки, то её (как и вообще все корректировки в оптимистичную сторону) может сделать только менеджер или тим-лид, т.е. человек, ответственный за проект в целом и за риски по срокам в частности. Либо её можно принять равной BG, т.е. вообще не учитывать «положительные» риски в планировании.
При этом, по совокупности, никто не мешает всю эту практику «спроси исполнителя» в итоге сводить в формат PERT (я так делал и у меня это работало), однако надо понимать суть трудовых отношений и не писать в таблицу всё, что вам сказали. Оценки, пришедшие снизу, крайне желательно дублировать другими данными (историческими, внешней оценкой и т.д.).
P.S. Всё вышенаписанное, конечно, относится к программным проектам (где, в отличии от например строительных, нет устоявшихся нормативов). Как я понял, мы говорим про программные проекты)
Я чего-то не понимаю.
Мы, артель, в составе трех плотников и одного менеджера, ваяем лодки.
Лодка делается за неделю.
Если совсем хорошо — за четыре дня.
Приходит менеджер, говорит — предпроектный этап, надо посчитать трудозатраты. Вот, министерство обороны предлагает контракт на постройку. Требования — чтобы держалась на воде. и было оснащено флагштоками для гюйса и флага.
Я прикидываю. Если все складывается привычно — то трудозатраты — неделя. А вот ТЗ нет, его разработка входит в контракт. И по текущим условиям от нас могут требовать хоть авианосец.
Я прикидываю, что нам троим делать авианосец примерно сто лет, и выдал эту оценку вместе с неделей и четырьмя днями менеджеру.
Что дальше? И почему он скрипит зубами?
Мы, артель, в составе трех плотников и одного менеджера, ваяем лодки.
Лодка делается за неделю.
Если совсем хорошо — за четыре дня.
Приходит менеджер, говорит — предпроектный этап, надо посчитать трудозатраты. Вот, министерство обороны предлагает контракт на постройку. Требования — чтобы держалась на воде. и было оснащено флагштоками для гюйса и флага.
Я прикидываю. Если все складывается привычно — то трудозатраты — неделя. А вот ТЗ нет, его разработка входит в контракт. И по текущим условиям от нас могут требовать хоть авианосец.
Я прикидываю, что нам троим делать авианосец примерно сто лет, и выдал эту оценку вместе с неделей и четырьмя днями менеджеру.
Что дальше? И почему он скрипит зубами?
Есть такое понятие, как «предпроектные показатели». Например, договариваетесь о водоизмещении не более 1 м^3 — и у вас заведомо не получится авианосец :)
Договоритесь что из дерева и без мотора — и всё станет совсем хорошо) А дальше оценка на основе исторических данных / аналогий, по предпроектным показателям, вполне работает)
Обсуждаемая статья в общем-то не про это. Не про оценку проекта, а про cоставление плана проекта, когда цель более-менее ясна. Хотя бы цель текущей итерации.
Договоритесь что из дерева и без мотора — и всё станет совсем хорошо) А дальше оценка на основе исторических данных / аналогий, по предпроектным показателям, вполне работает)
Обсуждаемая статья в общем-то не про это. Не про оценку проекта, а про cоставление плана проекта, когда цель более-менее ясна. Хотя бы цель текущей итерации.
Подскажу (благо 'матмех finished'...)
Вот картинка «нормального распределения» (представьте, что по оси X — срок, за который будет выполнен план целиком, а по оси Y — вероятность такого исхода):
Естественно распределение вероятных сроков по одной конкретной задаче — не такое, однако в статистике есть теорема, согласно которой сумма множества случайных величин (одного порядка) стремится к нормальному распределению.
Вот на графике: точка, которая помечена «Mean» — это ваш BG (Best Guess), т.е. оценка которая выполнится (или не выполнится) с вероятностью 50%. Точка "-3 sd" — это O, а "+3 sd" — это P. Cам же sd — это среднеквадратичное отклонение от мат.ожидания (показан на графике полоской).
Формула (1O + 4BG + 1P)/6 призвана дать гипотезу о средне-арифметическом сроке выполнения одной задачи (это не то же самое, что оценка 50%). В методе PERT вы потом складываете Mean всех задач по критическому пути проекта, и прибавляете к ним корень из суммы квадратов SD по тому же пути, умноженный скажем на 3 — и получаете 99% дидлайн общего срока выполнения.
Понятно, что это всё теория, которая применима ограничено (например, если все риски по всем задачам выстрелят одновременно, вы улетите далеко за вычисленный по PERT план). Но сама практика учета рисков отдельно от «ожидаемых» сроков всё же улучшает планирование, так что можно и PERT считать :)
Вот картинка «нормального распределения» (представьте, что по оси X — срок, за который будет выполнен план целиком, а по оси Y — вероятность такого исхода):
Естественно распределение вероятных сроков по одной конкретной задаче — не такое, однако в статистике есть теорема, согласно которой сумма множества случайных величин (одного порядка) стремится к нормальному распределению.
Вот на графике: точка, которая помечена «Mean» — это ваш BG (Best Guess), т.е. оценка которая выполнится (или не выполнится) с вероятностью 50%. Точка "-3 sd" — это O, а "+3 sd" — это P. Cам же sd — это среднеквадратичное отклонение от мат.ожидания (показан на графике полоской).
Формула (1O + 4BG + 1P)/6 призвана дать гипотезу о средне-арифметическом сроке выполнения одной задачи (это не то же самое, что оценка 50%). В методе PERT вы потом складываете Mean всех задач по критическому пути проекта, и прибавляете к ним корень из суммы квадратов SD по тому же пути, умноженный скажем на 3 — и получаете 99% дидлайн общего срока выполнения.
Понятно, что это всё теория, которая применима ограничено (например, если все риски по всем задачам выстрелят одновременно, вы улетите далеко за вычисленный по PERT план). Но сама практика учета рисков отдельно от «ожидаемых» сроков всё же улучшает планирование, так что можно и PERT считать :)
Давайте я немного проясню, откуда именно, на мой взгляд, берутся коэффициенты 1, 4, 1, и что значит словосочетание «по трём точкам».
Будем считать, что вероятность не попасть в границы оптимистичной и пессимистичной оценок равна нулю, а так же, что с вероятностью 50% мы выполним оценку Best Guess. Тогда наша случайная величина (потраченное время) ограничена. Для такой случайной величины можно предложить следующий способ подсчёта математического ожидания: это интеграл от нуля до единицы квантили распределения.
Квантиль уровня альфа это значение случайной величины, которое ограничивает её с вероятностью ровно альфа.
Согласно нашим предположениям, мы знаем всего лишь три значения этой квантили, обозначу её за Q(x):
Q(0) = P
Q(1/2) = BG
Q(1) = O
Для подсчёта интеграла проведем интерполяционный многочлен через эти три точки (параболу) и проинтегрируем его. Получим формулу Симпсона, дающую указанные коэффициенты.
Отличие от комментария выше в том, что нормальность распределения не нужна, нужно только предположение о том, что BG это 50%, а оценки O и P действительно оптимистична и пессимистична.
Будем считать, что вероятность не попасть в границы оптимистичной и пессимистичной оценок равна нулю, а так же, что с вероятностью 50% мы выполним оценку Best Guess. Тогда наша случайная величина (потраченное время) ограничена. Для такой случайной величины можно предложить следующий способ подсчёта математического ожидания: это интеграл от нуля до единицы квантили распределения.
Квантиль уровня альфа это значение случайной величины, которое ограничивает её с вероятностью ровно альфа.
Согласно нашим предположениям, мы знаем всего лишь три значения этой квантили, обозначу её за Q(x):
Q(0) = P
Q(1/2) = BG
Q(1) = O
Для подсчёта интеграла проведем интерполяционный многочлен через эти три точки (параболу) и проинтегрируем его. Получим формулу Симпсона, дающую указанные коэффициенты.
Отличие от комментария выше в том, что нормальность распределения не нужна, нужно только предположение о том, что BG это 50%, а оценки O и P действительно оптимистична и пессимистична.
Эта методика хорошо описана здесь: Управление проектами в СССР (ВУЗФИЛЬМ 1976), раздел: Сетевое планирование,
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выполнять оценку по трём точкам?