Должен ли разработчик принять оценку рабочей нагрузки, выполненную макросом Excel?

12

В новом проекте друг должен был написать тесты, где время, необходимое для их написания, рассчитывалось макросом Excel, написанным его менеджером, не являющимся разработчиком.

В таких случаях, должен ли разработчик взять на себя ответственность за написание и запуск тестов в рассчитанное время? Достоверны ли результаты этих испытаний?

Для информации, мой друг отказался отвечать за оценки, которые он не сделал, попросил преуспеть в работе над другим проектом, и его заменил неопытный внебрачный да-парень.

project-management productivity testing

— Nelstaar
источник

7

Что значит «принять» «оценку»? Если вы подсчитаете, что мне понадобится 30 дней, что произойдет, если я «приму» это? Какое мне дело до того, что, по твоим оценкам, мне понадобится что-то сделать? Вы можете оценить, что я сделаю это через минуту, и мне все равно, вы ошибаетесь, а не я.

— Дэвид Шварц

2

@ Дэвид Принятие оценки обычно означает пересмотр оценок и обеспечение консенсуса. Например, если используется инструмент параметрической оценки, инженеры проекта просматривают эти данные для обеспечения согласованности, возможно, используя вторую методологию, такую как Wideband Delphi.

— Томас Оуэнс

12

Похоже, что-то, что следует отправить Скотту Адамсу для мультфильма Дилберта.

— MetalMikester

1

Пока есть обзор. У меня этого конкретного примера не было ни одного.

— Nelstaar

5

Помните: оценка, обязательство, цель и план достижения цели - это четыре разные вещи. Убедитесь, что всем понятно, что это за вещи и какие из этих четырех вещей выводит Excel.

— Наллакер

14

Это зависит от того, насколько разумно они выглядят для разработчика и на каких данных / логике они основаны. (они могут основываться на статистических данных, собранных за несколько лет о том, сколько времени потребовалось - самому разработчику и / или другим - для решения аналогичных задач в прошлом ... или они могли быть полностью основаны на его менеджере - правильно или неправильно - предположения.)

В идеале, он должен обсудить со своим менеджером, что никто не может разумно взять на себя обязательство и взять на себя ответственность за задачу, оцененную кем-то другим.

Явный отказ от принятия оценок может действительно привести к его быстрой замене, поэтому лучше использовать более мягкий подход и избегать прямой конфронтации, если это возможно.

— Петер Тёрёк
источник

7

Предположительно, макрос работает с какими-то входными данными, это не просто генератор случайных чисел? Итак, чтобы ответить на ваш вопрос, нам нужно знать, что представляют собой входные данные и что делает макрос. Без этого любой ответ довольно бессмысленный.

Или, действительно, ваш вопрос о принятии оценок, сделанных менеджером, который не имеет соответствующего опыта? В этом случае ответ «нет», вы (или ваш друг) должны составить свои собственные оценки и представить их менеджеру. Если эти 2 цифры не совпадают, им нужно работать вместе, чтобы выяснить лучший путь вперед - возможно, согласиться написать меньше тестов или, возможно, потребуется больше времени, чтобы написать их все.

Отказ в упор никому не поможет, и работать в сроки, которые вы не можете встретить, тоже неинтересно, решение заключается в том, чтобы принять профессиональный подход и прийти к компромиссу, который позволит продолжить работу.

— Стив
источник

Тесты разбиты на подразделы (почти атомарные), и каждый получает небольшую оценку.

— Nelstaar

Я думаю, что при использовании этого метода финальный тестер не видит / не тестирует общую картину.

— Nelstaar

1

«Предположительно, макрос работает с какими-то входными данными, это не просто генератор случайных чисел». Он также может быть случайным, потому что это не способ захватить КАЖДУЮ переменную, которая сделает такой алгоритм точным.

— maple_shaft

1

@maple_shaft: Вот почему они называют это оценкой - она не должна (или не должна) быть точной. Оцените ли вы, используя некоторые вычисления в Excel, или с карандашом и бумагой, не имеет никакого значения. Использование Excel для оценок имеет гораздо больше смысла, чем некоторые другие «методы», которые я видел при использовании ...

— Треб

Оценки @Treb должны быть настолько точными, насколько позволяют предоставленные данные и текущее состояние проекта, с учетом конуса неопределенности.

— Томас Оуэнс

5

Определенно НЕТ.

Маленькая программа, даже большая, сложная, не может оценить, сколько времени займет какое-либо задание на программирование. См. Математические ограничения для оценки программного обеспечения по причинам, почему. Более длинная рецензируемая статья « Большие пределы оценки программного обеспечения» также доступна.

Я бы также пересмотрел свое мнение о рассматриваемом менеджере: почему он или она считает, что макрос электронной таблицы не был опробован в прошлом, учитывая, что все остальное пытались оценить длительность программных задач в прошлом.

— Брюс Эдигер
источник

1

Я не читал эти статьи полностью (пока), но параметрические методы широко использовались для оценки программных проектов в пределах 15% в течение более 20 лет, предполагая, что входные данные являются действительными. Кроме того, совместные методы, такие как широкополосный Delphi, могут (и были использованы) подтвердить точность параметрических моделей. Посмотрите Экономику разработки программного обеспечения (Boehm) для обсуждения параметрических методов и применения Широкополосного Delphi к программным проектам (как с, так и без пареметрических моделей).

— Томас Оуэнс

Я согласен с Томасом. В то время как вы не можете точно предсказать каждую отдельную задачу для всего проекта, в ходе проекта и используя исторические данные для конкретной организации, вы можете попасть в стадион. Некоторые задачи займут больше времени, а некоторые - короче, но в итоге они усредняются. Особенно, если проект похож на те, что уже сделаны организацией. С учетом сказанного, оценки не могут объяснить действительно плохие неожиданные вещи, такие как аппаратное / программное обеспечение не работает так, как рекламируется, новые технологии намного сложнее, чем ожидалось, нехватка разработчиков, плохое руководство и управление.

— Данк

1

Вы, ребята, должны читать и понимать документ. Простой макрос электронной таблицы не имеет возможности правильно оценить. Программное обеспечение - математика, и математические системы иногда подвергаются небольшой проблеме, известной как неполнота. Я гарантирую вам, что рассматриваемый менеджер обманывает его или ее, и что результаты макроса не соответствуют действительности.

— Брюс Эдигер

1

@ Брюс: Используя формулы (включая электронные таблицы Excel) для успешной оценки проекта, я, безусловно, могу утверждать, что ни Томас, ни менеджер, ни я не обманываем себя. Как я уже говорил, каждая отдельная задача будет меняться, но в ходе проекта они имеют тенденцию выравниваться. Я обнаружил, что использование формул (разработанных и измененных с течением времени) было гораздо более точным, чем оценки отдельных разработчиков. Как правило, разработчики чрезмерно оптимистичны или чрезмерно пессимистичны. Конечно, формулы работают только при наличии разумных данных, навык, безусловно, является фактором.

— Данк

Я читал эти газеты прошлой ночью. Они идут вразрез с более чем 40-летним опытом управления проектами и более 30-летним опытом управления проектами программного обеспечения. См. Iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf и sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Томас Оуэнс

4

Тьфу!

Это гигантский «запах работы». Это невероятное микроуправление.

Если они не могут доверять своим сотрудникам, чтобы дать оценку, чем еще они не доверяют вам?

— Ozz
источник

1

99% разработчиков не могут даже придумать плохие оценки, основанные на чем-то объективном, не говоря уже о точных оценках. Поэтому я не вижу ничего, указывающего на «запах работы», потому что кто-то другой дал оценку. Особенно, если они использовали фактические данные, чтобы оправдать свои числа. Если люди несут ответственность за выполнение каждой задачи, то это проблема запаха работы. Однако, если инструмент сильно недооценил все задачи, тогда все разработчики пропустили бы оценки. OTOH, если все остальные, кажется, соответствуют большинству всех оценок, а другой разработчик никогда не делает, то это проблема запаха разработчика.

— Данк

@ Dunk - моя точка зрения такова, что микроуправление в разработке программного обеспечения - это «запах работы», и я бы не хотел там работать.

— Оз

1

то, что вы называете микроменеджментом, является единственным способом ведения бизнеса во многих отраслях. Если вы не можете придумать разумную стоимость и запланировать смету для крупных проектов, тогда у вашей компании будет очень сложная работа, чтобы получить контракты. Вопреки гибкому идеалу, клиенты во многих отраслях не собираются заключать контракты на десятки миллионов долларов, если не знают, что получат в итоге. Они не были бы довольны идеей, что их деньги ушли, у них есть рабочий продукт, но он делает только 50% того, что им нужно или нужно.

— Данк

@ Dunk - Если вы довольны тем, как руководство производит оценки для вас, продолжайте. Я бы предпочел, чтобы команда разработчиков производила оценки. Смехотворные оценки менеджмента (вместе с постоянно меняющимися требованиями, целым рядом других обсуждений) - вот почему многие программные проекты не выполняются вовремя и в рамках запланированного бюджета. Я бы предпочел доверять людям, которые делают работу.

— Оз

Дело не в том, чтобы руководство делало оценки или люди, выполняющие работу, которая придумывает оценки. Речь идет о том, чтобы вытащить оценки из своей задницы или попытаться основать свои оценки на некоторых объективных данных. По моему опыту, сравнивая оценки управления с оценками разработчиков, вы обнаружите, что оценки управления, как правило, приводят к более длительным срокам выполнения. Разработчики, как правило, настроены оптимистично .....

— Данк

3

Абсолютно нет.

Я обещаю вам, что менеджер не настолько заблуждается, чтобы думать, что его макрос Excel может точно предсказать оценки. Я даже не спорю о том, что должно быть хорошо известным фактом, что слишком много переменных задействовано, чтобы точно предсказать что-то подобное в алгоритме. Если он изобрел такой алгоритм, он должен запатентовать его и заработать, по моему мнению, миллионы.

Здесь действительно происходит то, что менеджер использует этот предполагаемый макрос Excel в качестве слегка завуалированной маскировки, чтобы скрыть тот факт, что он навязывает нереалистичные ожидания и чрезмерное давление на своих разработчиков.

Он знает, что это BS, и ему все равно, это предлог для того, чтобы перебронировать ресурсы и попытаться сделать вещи быстрее, заставляя всех его «никчемных» разработчиков постоянно «ПОЗЖЕ».

Этот менеджер звучит как эксплуататорский придурок.

— maple_shaft
источник

1

Эх, то, что менеджер генерирует оценки для разработчиков, не означает, что они неточны, и мы действительно не можем сделать такой вывод без дополнительной информации. Если менеджер компетентен, они должны признать реалистичные, а нереально достаточно легко скорректировать вещи соответственно.

— rjzii

1

@Rob, Вы забыли ключевой момент, который высказал ФП, что они придерживаются этих оценок (предположительно строго потому, что предыдущий разработчик в команде упомянул «не хотел, чтобы их оценивали» и был переназначен). В оценочных моделях нет ничего плохого, но они должны быть приблизительным ориентиром и не должны «помогать разработчикам», что, к сожалению, я видел, как менеджмент делал МНОЖЕСТВО людей.

— maple_shaft

2

Здесь проблема заключалась в том, что эти оценки были непосредственно внесены в счет клиента. Почему некоторые менеджеры продолжают называть это оценками?

— Нельстаар

@maple_shaft - Не зная, каковы оценки, трудно сказать, были ли они необоснованными и, следовательно, возражения против того, чтобы их удерживали, были обоснованными. Если бы они были справедливыми оценками (например, «Восемь часов, чтобы написать Hello World»), то не было бы проблем с тем, чтобы их придерживаться за пределами философии.

— rzzii

3

В новом проекте друг должен был написать тесты, где время, необходимое для их написания, рассчитывалось макросом Excel, написанным его менеджером, не являющимся разработчиком.

Существуют параметрические модели оценки для оценки времени завершения проектов, в том числе программных проектов. Обычно оценка для производственного кода, но я не понимаю, почему его нельзя экстраполировать, чтобы оценить, сколько времени потребуется для написания тестового кода. Эти оценки только так же хорошо, как данные, которые вводятся в них, хотя.

Предполагая, что используемый метод является допустимой моделью оценки, а данные точны и достоверны, нет никаких причин, по которым хорошая оценка не может быть получена из макроса Excel, написанного менеджером, не являющимся разработчиком.

В таких случаях, должен ли разработчик взять на себя ответственность за написание и запуск тестов в рассчитанное время?

Ни при каких обстоятельствах никакая оценка не должна приниматься вслепую. Ни одна оценка не является идеальной, независимо от того, как она получена. Инженер должен проверить любые оценки, выявить потенциальные проблемы, оценить их влияние, а также обсудить и уточнить оценку по мере необходимости.

Достоверны ли результаты этих испытаний?

Тесты хороши так же, как и усилия, затраченные на их разработку и внедрение. Если тестировщик производит тесты низкого качества, дефекты проскальзывают через тестирование и перейдут на более позднюю фазу проекта. Само собой разумеется, что сжатие графика приведет к некачественным испытаниям, поэтому, если времени недостаточно для разработки соответствующих контрольных примеров, а затем для реализации этих случаев, то испытания не будут такими полезными.

— Томас Оуэнс
источник

3

Похоже, вы задаете два разных вопроса:

Достоверны ли результаты этих испытаний?

Excel - это инструмент, подобный любому другому, с которым мы работаем, и то, в чем были написаны расчеты, не должно влиять на результаты самого алгоритма. Тот факт, что оценка исходит из макроса Excel, не имеет отношения к тому, действительны ли результаты расчета (т. Е. Достоверность оценки). Если у вас есть неверные предположения в базовой модели, не имеет значения, что вы используете для расчета, так как базовые предположения неверны.

В таких случаях, должен ли разработчик взять на себя ответственность за написание и запуск тестов в рассчитанное время?

Если требование о том, чтобы разработчик выполнил работу в указанное время, было в их контакте, то они мало что могут сделать, чтобы поспорить с ним, если оценки являются разумными. Что приводит к следующему пункту: если расчеты дают разумное количество времени и они похожи на оценки, которые разработчик дал бы себе, то нет никаких причин не возражать против данных сроков. Фактически, это может работать на пользу разработчиков, поскольку они могут влиять на предположения, используемые в модуле, а не на произвольные сроки.

Если сроки кажутся неосуществимыми для требуемого объема работы, то, очевидно, они должны поднять эту проблему и попытаться работать с менеджером, чтобы получить более реалистичные сроки, но если сроки будут выполнимы, то им будет трудно возразить против них.

С точки зрения управления проектом и оценки сроков, да, это может быть сделано, но это сильно зависит от характера выполняемой работы. Скорее всего, вы увидите более точные оценки за время, необходимое для написания кода модульного тестирования (при условии, что разработчик понимает структуру и написал их раньше), чем вы будете писать новый код в зависимости от случаев использования кода тестирования. за.

— rjzii
источник

Я согласен, что этот метод можно / можно использовать до тех пор, пока существует диалог между участниками проекта.

— Nelstaar

1

@Nelstaar - Практически все, что я когда-либо читал об управлении проектами и оценке, включает в себя текущий диалог и настройку со временем. Обычно наиболее надежные оценки имеют вероятность, связанную с ними в отношении вероятности попадания в указанную цель (т.е. 90% вероятности выполнения задачи в течение 8 часов).

— rjzii

2

Я не хочу преуменьшать результаты написания тестов, но в проекте, вероятно, раньше их писали несколько разработчиков. Если оценки основаны на этих данных, они могут быть более точными, чем предполагал ваш друг. Поскольку ваш друг покинул проект, не делал попыток создать противоположные оценки или посмотреть, могут ли они быть выполнены в соответствии с прогнозом, мы никогда не узнаем.

Все, что ему нужно было сделать, - это пройти один или два теста, чтобы увидеть, насколько точной была оценка, и вернуться к менеджеру с обоснованным аргументом. Могут быть и другие члены команды, которые могли бы предоставить отзыв о достоверности оценок или последствиях отставания. Иногда один менеджер должен дать «что-то» своему боссу, чтобы все были счастливы. Разработчики видят в этом ложное чувство безопасности. Возможно, если бы разработчики стали предлагать оценки и демонстрировать готовность к выполнению задач, у руководства может появиться больше доверия.

Я предполагаю, что если бы он смог завершить тесты за меньшее время, он ничего не сказал бы об этом. С другой стороны, исключение себя из практики, в которую он не верит, может указывать на высокий уровень честности.

— JeffO
источник

+1 за отзыв при работе над заданиями в отношении оценок.

— rjzii

1

Простой и краткий ответ:

Вам все равно, откуда исходит оценка.

Что вас действительно волнует, так это сама оценка. Согласитесь с этим или не согласитесь и объясните, почему и сколько вы бы оценили. Это самое главное.

— Клемент Эрреман
источник

1

Вы должны заботиться, откуда исходит оценка. Параметрическая модель с действительными и разумными входными данными, генератор случайных чисел, студент первого курса информатики, инженер-программист с 5-летним опытом работы в области менее 6 месяцев и инженер-программист, ставший руководителем проекта с 25-летним опытом работы в области все имеют различную способность произвести эффективную оценку. Это также восходит к комментарию, который я сделал в предыдущем ответе об этической / профессиональной ответственности инженера-программиста за представление, защиту и оспаривание оценок соответствующим образом.

— Томас Оуэнс

Точно: самое главное, чтобы обсудить оценку. Я бы с удовольствием одобрил использование макросов Excel, если бы оценки, которые он делал, были более правильными, чем 25-летний опытный инженер. Важна оценка и объяснения, которые к ней приводят (рабочая нагрузка, доступные ресурсы, сложность), а не кто или что было объявлено.

— Клемент Херреман

Вы согласны со мной, говоря, что ваш ответ неверен? Учитывая те же данные (такие как нагрузка, ресурсы, трудности и т. Д.), Кто так же важен, как и что и почему. Все сводится к фактору доверия. Я доверяю COCOMO (созданному и поддерживаемому некоторыми ведущими специалистами по оценке стоимости программного обеспечения) больше, чем макросу Excel (созданный кем-то с ограниченным опытом и знаниями в оценке стоимости, а тем более с областью применения). Все дело в общей картине, чтобы установить, насколько достоверна эта оценка.

— Томас Оуэнс

Нет-нет, наверное, я не достаточно понятен. Это действительно не важно, кто сделал оценку. Что важно, так это точность оценки. Всякий раз, когда я получаю оценку, я сравниваю ее с оценкой, а затем обсуждаю ее с моим руководителем проекта, если я согласен или нет. Если их аргумент достаточно хорош, то я согласен с ними и принимаю оценку. Видеть? Я никогда не говорил и не думал о том, кто оценил.

— Клемент Херреман,

Как вы определяете точность, если вы не знаете, кто оценил и какие методы они использовали? Я мог бы передать одни и те же данные двум людям: один студент-первокурсник, изучающий программирование, в настоящее время проходит свой первый курс по информатике, а другой - старший инженер-программист с 15-летним опытом работы и пятью специалистами в этой области. Оба используют одни и те же методы оценки (не забывайте - часто входные данные также являются оценочными). Студент может сказать, что это займет 6 месяцев с 95% уверенностью. Старший инженер может сказать, что это займет 15 месяцев с уверенностью 80%. Я бы больше доверял старшему инженеру.

— Томас Оуэнс

1

Теоретически, разработчик никогда не должен принимать оценку, сделанную любым другим человеком, независимо от того, как она была получена. Одна из причин заключается в том, что предоставление более длительной оценки, чем удобен для вашего менеджера, немедленно выявляет потенциальную проблему с расписанием или, возможно, неправильное понимание объема работ, которые необходимо выполнить.

Обычно люди находят оценку времени программирования еще сложнее, чем само программирование, поэтому, если ваш менеджер может написать макрос Excel, может решить эту проблему, он, вероятно, может создать макрос для написания кода (маловероятно).

Теперь, на практике , если вы понимаете работу и оценки выглядят разумными, имеет смысл просто выразить некоторую обеспокоенность по поводу методологии в процессе прохождения, но затем временно договориться о том, сможете ли вы их выполнить. Позже, если работа занимает у вас больше времени, чем сметы, вы должны как можно скорее довести это до сведения ваших менеджеров. Будьте готовы обсудить точные причины, основанные на вашем реальном опыте внедрения. Надеемся, что в этот момент ваш менеджер не станет необоснованным и продолжит настаивать на том, чтобы вы работали с механически сгенерированными оценками.

— PeterAllenWebb
источник

-1

Одна из самых новых методологий разработки программного обеспечения - гибкая , а одна из известных гибких сред - scrum . Но в этой методологии разработчики (команда разработчиков) отвечают за расчет времени, необходимого для выполнения задачи или реализации пользовательской истории.

Я определенно говорю НЕТ . Так как:

Менеджер, не являющийся разработчиком, не может оценить необходимое время для выполнения работы
Для оценки необходимого времени для выполнения любой работы необходим человеческий интеллект, которого нет в Excel
Принимая такие методы работы, менеджер постепенно привыкает заменять разработчиков при оценке времени. Это может привести к катастрофе. Рассмотрите этот сценарий, в котором ваш менеджер говорит:

Я хочу начать новый проект по продаже велосипедов в Интернете, и я знаю, что вам и Джону потребуется 3 недели, чтобы это сделать.

— Саид Нямати
источник

5

ОП не упоминает команду своего друга, которая использует гибкие методы. Я не думаю, что гибкие правила имеют какое-либо отношение к командам, использующим другие методы (или вообще никаких методов). Однако здравый смысл должен :-) Более того, очевидно, что решение об оценках принимал не Excel, а только некоторые вычисления, основанные на некоторых (неизвестных нам) предположениях и данных (каждое из которых может быть правильным или неправильным). , Если я ввожу оценки для данной задачи каждым из членов нашей команды, а затем задаю Excel для вычисления их среднего значения, выполняет ли Excel оценку?

— Петер Тёрёк

3

1 и 2 явно ложные. Модели параметрической оценки широко применяются в управлении программными проектами и используются уже более 20 лет, и любой, кто имеет подготовку по управлению проектами (инженер-программист или нет), может быть обучен использованию этих инструментов, если предположить, что они (или, предпочтительно, инженеры проекта) ) способны предоставить точные оценки входных данных.

— Томас Оуэнс

3

-1 - Это не отвечает на вопрос, имеет очевидные ошибки («... новейшие методологии разработки программного обеспечения гибки») и, по-видимому, не добавляет ничего значимого. Я не уверен, для чего были возражения или принятый ответ.

— Морган Херлокер

1

мы, конечно, не знаем из вопроса, является ли параметрическая оценка нормой в этой компании и / или основана ли она на хорошей истории их бизнеса; если это так, то, насколько я ненавижу это говорить, отказ выполнять свою работу в соответствии с принятыми в организации операционными процедурами (без соблюдения разумного пути допроса) является неосторожным.

— StevenV

2

@ Томас Я согласен, я просто думаю, что слишком много мы не знаем о ситуации, чтобы категорически ответить Да или Нет. В любом случае, категорический отказ без хорошего обсуждения, чтобы убедиться, что ситуация и аргументация понятны, редко хороший карьерный ход.

— StevenV