Спасибо за видео!) Актуальная тема на все времена) От себя хотел добавить. Оценка трудозатрат считается сложной задачей. Сложность в том, что тяжело оценить вещи, которые раньше не делал. Есть способ оценки в Functional Points (метод COCOMO, например). Но все, опять же, сводится к тому, что оцениваются проекты (похожие) которые делал много раз. Оценка же того, что раньше не делал, всегда приблизительная и лучше закладывать этот риск при оценке.
Очень важный момент на самом деле, совместная с менеджером оценка. Да хоть в условных часах, хоть в синих жабах. Важно, что менеджер сам будет иметь разумнодетальное понимание о задаче, принять адекватное решение, браться ли за эту работу, а так-же сможет его более ли менее внятно донести до клиента. В общем, базово важный этап, на нём не стоит экономить время, иначе потом может в десятки раз больше впустую время/деньги сожрать.
Ещё б добавил, что декомпозицию лучше выполнять иерархически. По функциональностям (где-то - по компонентам). Результат будет заметно полезнее. Например, тот же менеджер (14:30) не побежит обратно к разработке, а просто вычеркнет всю фичу , включающую эту затратную строку.
Ох. Мы сейчас начинаем проект на полгода. И пытаемся оценить предварительно первую пачку задач. И сразу в часах. Посмотрим, что получится (скорее всего ад и бестолковщина конечно)
Придется записать видео что делать, когда менеджер требует оценить в часах. :) На пол года оценить точно никогда не получится, слишком много неизвестных. Можно попробовать PERT оценку. Суть такова: вы оцениваете задачу 3мя оценкам: - минимальная - когда все идет как по маслу - наиболее вероятная - максимальная (пессимистичная) - когда все риски по этой задачи выстрелили. И PERT высчитывает наиболее вероятную оценку по формуле (мин + 4*вероятных + макс)/6 = Искомая наиболее вероятная оценка.
ох, оценка в часах -- она вообще очень опасна. Разработчики всегда оценивают в идеальных часах. Когда CI зеленый, по таску все понятно, никто не отвлекает. А в реальности сами знаете как. То на стендап сходи, то QA помоги. То по задаче непонятно что делать.
@@stringconcat Ну метод "спроси программиста и умножь на N" более менее работает. N обычно от 2 до 3, в зависимости от способности договариваться с начальством :)
![Как стать топовым backend-разработчиком? Пошаговый план [Roadmap]](http://i.ytimg.com/vi/8QWvYkjJZhs/mqdefault.jpg)
Очень классно описан процесс! Спасибо)
Спасибо за видео!) Актуальная тема на все времена)
От себя хотел добавить. Оценка трудозатрат считается сложной задачей. Сложность в том, что тяжело оценить вещи, которые раньше не делал.
Есть способ оценки в Functional Points (метод COCOMO, например). Но все, опять же, сводится к тому, что оцениваются проекты (похожие) которые делал много раз.
Оценка же того, что раньше не делал, всегда приблизительная и лучше закладывать этот риск при оценке.
На новом месте работы на меня как на дурака смотрят, когда я говорю, что надо оценивать хотя-бы в Point'ах, но никак не в часах
Лучший!
Очень важный момент на самом деле, совместная с менеджером оценка. Да хоть в условных часах, хоть в синих жабах. Важно, что менеджер сам будет иметь разумнодетальное понимание о задаче, принять адекватное решение, браться ли за эту работу, а так-же сможет его более ли менее внятно донести до клиента. В общем, базово важный этап, на нём не стоит экономить время, иначе потом может в десятки раз больше впустую время/деньги сожрать.
Это правда! Взаимодействие в команде - одна из главных составляющих успеха команды
Ещё б добавил, что декомпозицию лучше выполнять иерархически. По функциональностям (где-то - по компонентам). Результат будет заметно полезнее.
Например, тот же менеджер (14:30) не побежит обратно к разработке, а просто вычеркнет всю фичу , включающую эту затратную строку.
Да, отличное дополнение!
хороший способ.
Как-то видео начали за здравие, а кончили за упокой...)
Ну хоть лайк пусть будет)
Ох. Мы сейчас начинаем проект на полгода. И пытаемся оценить предварительно первую пачку задач. И сразу в часах. Посмотрим, что получится (скорее всего ад и бестолковщина конечно)
Придется записать видео что делать, когда менеджер требует оценить в часах. :)
На пол года оценить точно никогда не получится, слишком много неизвестных. Можно попробовать PERT оценку. Суть такова: вы оцениваете задачу 3мя оценкам:
- минимальная - когда все идет как по маслу
- наиболее вероятная
- максимальная (пессимистичная) - когда все риски по этой задачи выстрелили.
И PERT высчитывает наиболее вероятную оценку по формуле
(мин + 4*вероятных + макс)/6 = Искомая наиболее вероятная оценка.
Топ
Отличный метод. А мы тут сразу пытаемся время проговаривать и получается ад.
ох, оценка в часах -- она вообще очень опасна. Разработчики всегда оценивают в идеальных часах. Когда CI зеленый, по таску все понятно, никто не отвлекает.
А в реальности сами знаете как. То на стендап сходи, то QA помоги. То по задаче непонятно что делать.
@@stringconcat Ну метод "спроси программиста и умножь на N" более менее работает. N обычно от 2 до 3, в зависимости от способности договариваться с начальством :)