Comments 8
В Scrum для этих целей обычно применяется список ранее оцененных и завершенных user stories, который используют сами разработчики в качестве «референсного» для быстрой оценки новых историй. Если взять наиболее примечательные, уже закрытые, истории, разбить их по категориям или по оценке; регулярно поддерживать актуальность списка, пополняя его более «свежими» исторями, можно с достаточной точностью оценивать новые задачи без участия разработчиков.
А почему у вас девять женщин выносят ребёнка на 1 месяц?
Ещё Перельман в Занимательной физике писал, что 7 лошадей в упряжке — это максимальная доступная мощность конной тяги. Добавление 8-й добавляет мизер, 9-й практически не влияет на силу буксировки. Потому, что накапливается рассогласованность усилий.
У людей по Паркинсону максимально эффективная численность группы ≈ 3.14, далее опять резко растут потери на согласование.
Ещё Перельман в Занимательной физике писал, что 7 лошадей в упряжке — это максимальная доступная мощность конной тяги. Добавление 8-й добавляет мизер, 9-й практически не влияет на силу буксировки. Потому, что накапливается рассогласованность усилий.
У людей по Паркинсону максимально эффективная численность группы ≈ 3.14, далее опять резко растут потери на согласование.
Ну так и я пишу, что у меня 7 лошадей в упряжке разработчиков в команде :) На самом деле, не обязательно вся команда проекта работает над одной фичей. Команда проекта может разбиваться на более мелкие команды для работы над разными функциональностями.
Но возможна ситуация, когда все пилят одну фичу, тогда команда разбивается на группы, выполняющие какие-то относительно независимые части одной фичи. Например, фронтэнд, бэкэнд и какие-нибудь полезные сервисы. И тогда необходимо организовать взаимодействие не всех со всеми, а только между группами и внутри групп.
Но возможна ситуация, когда все пилят одну фичу, тогда команда разбивается на группы, выполняющие какие-то относительно независимые части одной фичи. Например, фронтэнд, бэкэнд и какие-нибудь полезные сервисы. И тогда необходимо организовать взаимодействие не всех со всеми, а только между группами и внутри групп.
> T = N * A * k / D
> если один менеджер предпочитает создавать задачи не более чем на 8 часов
> Если одному человеку постоянно достаются задачи длительностью 1 час, а второму — 8 часов
Вы обещали рассказать, как оценивать задачи. Рассказали же, как на основе готовых достаточно надежных оценок посчитать итоговые трудозатраты. Это же простая арифметика * фактор риска, специфичный для команды/человека/окружения, о чем тут вообще можно рассуждать?
> если один менеджер предпочитает создавать задачи не более чем на 8 часов
> Если одному человеку постоянно достаются задачи длительностью 1 час, а второму — 8 часов
Вы обещали рассказать, как оценивать задачи. Рассказали же, как на основе готовых достаточно надежных оценок посчитать итоговые трудозатраты. Это же простая арифметика * фактор риска, специфичный для команды/человека/окружения, о чем тут вообще можно рассуждать?
> на основе готовых достаточно надежных оценок
Я нигде ничего не говорил про оценки. Требуется просто более менее одинаково подходить к разбиению фичи на задачи. Например, если этим занимается только один человек, то этого достаточно (и не важно как он это делает). У меня, скажем, итоговое время выполнения задач варьируется от 0,5 часов до 20 часов.
> Это же простая арифметика
Я действительно рад, если для Вас всё это очевидно. Мне же потребовалось некоторое время, чтобы осознать и сформулировать описанный подход. Поэтому я и решил написать статью — может кому-то поможет.
> о чем тут вообще можно рассуждать?
Долгое время я склонялся к тому, что адекватно задачи может оценивать только разработчик, который будет их делать. Однако оказалось, что с не меньшей точностью и гораздо быстрее я могу давать оценку сам на основе накопленной статистики. На всякий случай: разработчики у меня по-прежнему оценивают задачи.
Я нигде ничего не говорил про оценки. Требуется просто более менее одинаково подходить к разбиению фичи на задачи. Например, если этим занимается только один человек, то этого достаточно (и не важно как он это делает). У меня, скажем, итоговое время выполнения задач варьируется от 0,5 часов до 20 часов.
> Это же простая арифметика
Я действительно рад, если для Вас всё это очевидно. Мне же потребовалось некоторое время, чтобы осознать и сформулировать описанный подход. Поэтому я и решил написать статью — может кому-то поможет.
> о чем тут вообще можно рассуждать?
Долгое время я склонялся к тому, что адекватно задачи может оценивать только разработчик, который будет их делать. Однако оказалось, что с не меньшей точностью и гораздо быстрее я могу давать оценку сам на основе накопленной статистики. На всякий случай: разработчики у меня по-прежнему оценивают задачи.
Как по мне то «оценивать задачи без помощи разработчиков» у вас не получилось, зато получилось примерно посчитать время выполнения определённого количества уже оценённых задач.
1. Я оцениваю время на выполнение набора задач без привлечения к этому процессу разработчиков (то есть, по сути, оцениваю задачи без помощи разработчиков). Сколько при этом будет занимать каждая отдельная задача мне мало интересно.
2. Подскажите, где в тексте Вы нашли уже оценённые задачи? Мне правда интересно.
2. Подскажите, где в тексте Вы нашли уже оценённые задачи? Мне правда интересно.
где в тексте Вы нашли уже оценённые задачи
Везде, где Вы говорите про то, что задачи должны быть одного размера и тому подобное.
Неужели Вы не видите, что оперируете готовыми оценками, а статья повествует о том, как правильно суммировать трудозатраты? Это, безусловно, дело нужное и важное. Просто заголовок обещает совсем другое.
Sign up to leave a comment.
Как оценивать задачи без помощи разработчиков?