Спасибо за интересный и подробный рассказ о Вашем опыте. Хотелось бы попробовать внедрить что-то подобное и у себя в команде... Я пока не разбирался подробно в самой описанной технологии, но есть несколько вопросов после прочтения самой статьи. Насколько я понял метрики оценки, дизайн занял 3 дня (правда не понятно сколько человек участвовало на этом этапе и сколько фактически человеко-часов было потрачено) и потом 4 разработчика реализовали доработку за 18 дней (4 * 18 * 8 = 576 человеко-часов). По мне, так это далеко не маленьких проект...
В описании Вы делаете упор на то, что по факту трудозатраты на дополнительный этап дизайн-проекта почти не увеличивают общий скоуп проекта за счет "уменьшения" трудозатрат на последующих этапах разработки... Однако, мне кажется, что такой вывод можно сделать далеко не для всех проектов, а только для проектов больше определенного (мне пока не понятного) объема.
Объясню суть. В моей практике, неоднократно, были задачи с оценкой, например, 8 человеко-часов или около того. Да, это могут быть довольно "простые" и небольшие по объему задачи, но они имеют место быть! Наверняка у Вашего подхода к дизайн-проекту есть какое-то минимальное время на выполнения... По ощущениям, это никак не меньше нескольких часов и это при варианте если участвует всего один человек, иначе на кодирование времени вообще не останется...
Хотелось бы узнать Ваше мнение о таком варианте использования вашей методики, ведь небольшие задачи тоже нужно делать и это совсем не значит, что делать их нужно "некачественно"...
Полностью согласен с предыдущем комментарием. Мне по работе очень часто приходится оценивать задачи, причем как для себя, так и других сотрудников. Если рассматривать какую-то "типовую задачу" или любую доработку, для которой можно применить какую-то известную и проверенную метрику, то оценка почти всегда точная. Например, известно, что добавление одного "мета-описания поля к сущности" занимает в среднем 15 минут, но если этих полей более 10, то время можно уменьшить до 10 минут (эффект "копипаста"), то итоговая оценка получается весьма точной. Если же приносят задачу, решение которой весьма не очевидно, либо возможно придется проверить несколько (1, 2 или 5?) вариантов решения, то можно называть любую цифру! Единственная метрика тут, что "за неделю" (две, месяц) должен сделать (но не факт!)... А если заказчик просит за пару часов оценить новый проект, который будет длиться возможно год или два с точностью "хотя бы до месяца", то вообще можно сказать цифру в зависимости от того "чешется сейчас правая или левая нога".
Подводя итог, хочу сказать, что почитать про опыт в точной оценке было бы очень интересно, но для "исследовательских задач" или "больших объемов работ" точно сказать (и обосновать!) что-то конкретное практически нереально (IMHO)...
Спасибо за интересный и подробный рассказ о Вашем опыте. Хотелось бы попробовать внедрить что-то подобное и у себя в команде...
Я пока не разбирался подробно в самой описанной технологии, но есть несколько вопросов после прочтения самой статьи. Насколько я понял метрики оценки, дизайн занял 3 дня (правда не понятно сколько человек участвовало на этом этапе и сколько фактически человеко-часов было потрачено) и потом 4 разработчика реализовали доработку за 18 дней (4 * 18 * 8 = 576 человеко-часов). По мне, так это далеко не маленьких проект...
В описании Вы делаете упор на то, что по факту трудозатраты на дополнительный этап дизайн-проекта почти не увеличивают общий скоуп проекта за счет "уменьшения" трудозатрат на последующих этапах разработки... Однако, мне кажется, что такой вывод можно сделать далеко не для всех проектов, а только для проектов больше определенного (мне пока не понятного) объема.
Объясню суть. В моей практике, неоднократно, были задачи с оценкой, например, 8 человеко-часов или около того. Да, это могут быть довольно "простые" и небольшие по объему задачи, но они имеют место быть! Наверняка у Вашего подхода к дизайн-проекту есть какое-то минимальное время на выполнения... По ощущениям, это никак не меньше нескольких часов и это при варианте если участвует всего один человек, иначе на кодирование времени вообще не останется...
Хотелось бы узнать Ваше мнение о таком варианте использования вашей методики, ведь небольшие задачи тоже нужно делать и это совсем не значит, что делать их нужно "некачественно"...
Полностью согласен с предыдущем комментарием. Мне по работе очень часто приходится оценивать задачи, причем как для себя, так и других сотрудников. Если рассматривать какую-то "типовую задачу" или любую доработку, для которой можно применить какую-то известную и проверенную метрику, то оценка почти всегда точная. Например, известно, что добавление одного "мета-описания поля к сущности" занимает в среднем 15 минут, но если этих полей более 10, то время можно уменьшить до 10 минут (эффект "копипаста"), то итоговая оценка получается весьма точной. Если же приносят задачу, решение которой весьма не очевидно, либо возможно придется проверить несколько (1, 2 или 5?) вариантов решения, то можно называть любую цифру! Единственная метрика тут, что "за неделю" (две, месяц) должен сделать (но не факт!)... А если заказчик просит за пару часов оценить новый проект, который будет длиться возможно год или два с точностью "хотя бы до месяца", то вообще можно сказать цифру в зависимости от того "чешется сейчас правая или левая нога".
Подводя итог, хочу сказать, что почитать про опыт в точной оценке было бы очень интересно, но для "исследовательских задач" или "больших объемов работ" точно сказать (и обосновать!) что-то конкретное практически нереально (IMHO)...