Кто должен участвовать в оценке времени?

В ИТ-проекте:

1. Кто должен участвовать в оценке времени? Разработчик, руководитель группы, Scrum Master и т. Д.?
2. Чей голос должен быть учтен больше всего?

Дело не столько в вовлеченных людях, сколько в навыках, которые должны присутствовать:

• Хорошее понимание проблемной области - это особенно важно, когда требования неоднозначны или имеют высокий уровень. Как программист, который никогда не работал в путешествиях, чтобы оценить работу, связанную с классами билетов в самолете, и он предположит, что их 3 или 4 (эконом, бизнес, первый и т. Д.), Но если вы работали в путешествиях, вы будете знать, что есть десятки. Это может означать участие бизнес-аналитика или опытного пользователя, хотя со временем разработчики сами накопят такие знания.

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

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

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

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

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

(а) Не используйте число, которое вы «хотите», оно просто напрашивается на неприятности, и то, что вы хотите, не оказывает существенного влияния на то, как быстро можно выполнить работу.

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

(В Agile, на мой взгляд, и, конечно, в XP, правило заключается в том, что разработчики контролируют оценки, и это окончательно. Если пользователи хотят снизить оценки, им нужно изменить требование на что-то более простое.)

Я не знаю, есть ли универсальный ответ на этот вопрос. Там, где я работаю, обычно есть два инженера из команды, которые будут реализовывать функцию / исправление, которые дают оценку. Таким образом, каждый из двух инженеров дает оценку «min», «max» и «ожидаемая». Мы обычно ожидаем, что обе оценки будут достаточно последовательными, поэтому, если они сильно отличаются, то может потребоваться дальнейшее обсуждение (возможно, один инженер сделал предположения, а другой нет, и т. Д.).

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

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

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

Проект имеет бизнес-требования и сроки, идущие сверху вниз. Это «данные оценки» для первой итерации.

Эти требования должны быть разделены на самые большие задачи, имеющие 100% известную стоимость (например, «включить ведение журнала» = 2 часа = «загрузить log4j / SLF4J и подключить»).

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

Исправленные оценки должны возвращаться обратно в виде «видимой для бизнеса функции» = «этого количества времени», пока они не достигнут владельца бизнеса на соответствующем уровне, способном отбросить / изменить требования или сократить сроки. Тогда отступи. До окончательного сближения. На практике люди склонны игнорировать этот этап или упрощать его, что, в свою очередь, может создавать риски, связанные с пропущенными сроками и возможностями.

Кто или чей должен участвовать в оценке времени? Разработчик, руководитель группы, Scrum Master и т. Д.?

Я предпочитаю, чтобы все были там в оценке времени, и мы делаем то же самое здесь

Кто или чей голос должен учитываться больше всего?

Разработчик, но все же снова все о командной работе

Разработчики заряжены от реализации проекта! НИКТО ДРУГОЙ!

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

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

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

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