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

9

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

  1. Кто должен участвовать в оценке времени? Разработчик, руководитель группы, Scrum Master и т. Д.?
  2. Чей голос должен быть учтен больше всего?
Амир Резаи
источник
2
Если вы делаете Scrum : (а) нет лидера команды. (б) команда должна оценить все вместе, используя Planning Poker. (c) и парень, который, вероятно, сделает задачу, должен следовать. Команда Scrum является кросс-функциональной, и задачи не назначаются, но если парень, который владеет БД, скажет, что это займет 3 дня. Вероятно, это займет 3 дня.
1
Вы должны знать, что оценка - это не решение, а (часто трудный) прогноз. Там нет иерархии. Там нет голосов.
user281377
@ammoQ Проблема в том, что многие руководители проектов принимают это как решение!
Амир Резаи
2
Да, это распространенное психическое заблуждение. Конечно, вы можете принять решение о сроках, но тогда вам придется оценить (т.е. предсказать) архивируемое качество и полноту.
user281377 9.12.10
@ user281377 Мне нравится то, что у тебя получается: принцип неопределенности Гейзенберга для разработки программного обеспечения.
К.Стефф

Ответы:

8

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

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

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

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

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

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

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

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

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

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

Джон Хопкинс
источник
+1 за номер, который вы «хотите». Смотрите здесь .
Спенсер Рэтбун
1
Что-то более подробное о «числе, которое я хочу»: Оценка игр
K.Steff
2

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

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

Дин Хардинг
источник
1

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

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

кашка
источник
0

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

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

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

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

BoBaH
источник
1
«У проекта есть бизнес-требования + сроки, идущие сверху вниз. Это« данные оценки »для первой итерации». - К сожалению, правдиво и ответственно за такое давление, которое заставляет других давать неточные оценки, пытаясь придерживаться этих сроков, несмотря на то, что знает, сколько времени это действительно займет.
Джон Хопкинс
@ Джон Хопкинс - +1, честно, но я описал идеальный процесс, в действительности, как вы сказали, технические менеджеры иногда предпочитают совершать априорные нереалистичные графики и находить «оправдания» для задержек в ходе реализации проекта
бобах
Я не критикую ваш ответ - просто говорю, что к этому конкретному элементу следует с осторожностью относиться и что оценивающим следует, по возможности, в первую очередь не сообщать об этих крайних сроках из-за страха, что они окажут на них влияние.
Джон Хопкинс
1
«У проекта есть бизнес-требования и сроки, идущие сверху вниз». - Если люди на вершине не являются разработчиками сами с опытом «в окопах», это рецепт для бедствия.
вектор
Вы когда-нибудь замечали, что команды MLB всегда имеют бывшего игрока в качестве менеджера в блиндаже? Это потому, что только бывший игрок понимает, что нужно, чтобы выполнить работу, и уверен, что ребята выходят на поле.
вектор
-1

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

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

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

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

Гопи
источник
-2

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

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

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

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

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

Вектор
источник
2
Пожалуйста, улучшите этот ответ.
К.Стефф