1. Я оцениваю время на выполнение набора задач без привлечения к этому процессу разработчиков (то есть, по сути, оцениваю задачи без помощи разработчиков). Сколько при этом будет занимать каждая отдельная задача мне мало интересно.
2. Подскажите, где в тексте Вы нашли уже оценённые задачи? Мне правда интересно.
> на основе готовых достаточно надежных оценок
Я нигде ничего не говорил про оценки. Требуется просто более менее одинаково подходить к разбиению фичи на задачи. Например, если этим занимается только один человек, то этого достаточно (и не важно как он это делает). У меня, скажем, итоговое время выполнения задач варьируется от 0,5 часов до 20 часов.
> Это же простая арифметика
Я действительно рад, если для Вас всё это очевидно. Мне же потребовалось некоторое время, чтобы осознать и сформулировать описанный подход. Поэтому я и решил написать статью — может кому-то поможет.
> о чем тут вообще можно рассуждать?
Долгое время я склонялся к тому, что адекватно задачи может оценивать только разработчик, который будет их делать. Однако оказалось, что с не меньшей точностью и гораздо быстрее я могу давать оценку сам на основе накопленной статистики. На всякий случай: разработчики у меня по-прежнему оценивают задачи.
Ну так и я пишу, что у меня 7 лошадей в упряжке разработчиков в команде :) На самом деле, не обязательно вся команда проекта работает над одной фичей. Команда проекта может разбиваться на более мелкие команды для работы над разными функциональностями.
Но возможна ситуация, когда все пилят одну фичу, тогда команда разбивается на группы, выполняющие какие-то относительно независимые части одной фичи. Например, фронтэнд, бэкэнд и какие-нибудь полезные сервисы. И тогда необходимо организовать взаимодействие не всех со всеми, а только между группами и внутри групп.
Хм. Примерно 20 часов, 18 из них на чтение документации — остается 2. Судя по дальнейшим предположениям, на написание кода будет потрачено 1.5 часа. Таким образом, на «разбор OAuth, поиск подводных граблей и т.д.» + проверка работоспособности остается 0.5 часа. Точно всё правильно?
Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?
Статья, по сути, — это адаптация PERT для начинающих (таких как я, например). Не подскажете, кстати: в оригинале написано «P-O/6 = the standard deviation», правильно ли я понял, что должно быть (P-O)/6 и каков вообще смысл этой величины?
Тут не предлагается решить задачу 100 раз, тут предлагается прикинуть сколько займет времени решение задачи в среднем, если решить её 100 раз. Можно же написать одну и ту же картину сто раз? Вот и надо оценить сколько это займет времени.
Как оценить время выполнения задачи, которую ты никогда не решал?
Никак. Но если работаете длительное время в одной и той же области, то накапливается опыт, который позволяет примерно оценить сколько займет та или иная задача.
Ну, я бы не назвал оценку даже по одной точке совсем случайной. Зависит от многих факторов — да, но регулярно тренируясь можно достичь неплохих результатов. На счет «к ним добавляют случайные веса» тоже не согласен. Основное, на мой взгляд, в данном подходе то, что мы
Заранее продумываем возможные риски, которые могут возникнуть в ходе работы над задачей.
Привлекаем к оценке риска того, кто будет выполнять задачу, то есть более компетентен, чем менеджер.
2. Подскажите, где в тексте Вы нашли уже оценённые задачи? Мне правда интересно.
Я нигде ничего не говорил про оценки. Требуется просто более менее одинаково подходить к разбиению фичи на задачи. Например, если этим занимается только один человек, то этого достаточно (и не важно как он это делает). У меня, скажем, итоговое время выполнения задач варьируется от 0,5 часов до 20 часов.
> Это же простая арифметика
Я действительно рад, если для Вас всё это очевидно. Мне же потребовалось некоторое время, чтобы осознать и сформулировать описанный подход. Поэтому я и решил написать статью — может кому-то поможет.
> о чем тут вообще можно рассуждать?
Долгое время я склонялся к тому, что адекватно задачи может оценивать только разработчик, который будет их делать. Однако оказалось, что с не меньшей точностью и гораздо быстрее я могу давать оценку сам на основе накопленной статистики. На всякий случай: разработчики у меня по-прежнему оценивают задачи.
лошадей в упряжкеразработчиков в команде :) На самом деле, не обязательно вся команда проекта работает над одной фичей. Команда проекта может разбиваться на более мелкие команды для работы над разными функциональностями.Но возможна ситуация, когда все пилят одну фичу, тогда команда разбивается на группы, выполняющие какие-то относительно независимые части одной фичи. Например, фронтэнд, бэкэнд и какие-нибудь полезные сервисы. И тогда необходимо организовать взаимодействие не всех со всеми, а только между группами и внутри групп.
А как Вы проводите оценку задач на своих проектах?
Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?
Тут не предлагается решить задачу 100 раз, тут предлагается прикинуть сколько займет времени решение задачи в среднем, если решить её 100 раз. Можно же написать одну и ту же картину сто раз? Вот и надо оценить сколько это займет времени.
Никак. Но если работаете длительное время в одной и той же области, то накапливается опыт, который позволяет примерно оценить сколько займет та или иная задача.