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

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

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

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

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

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

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

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

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

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

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

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

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

Тьфу!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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