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

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

В качестве примера: на моей предыдущей работе я был частью команды, в которой я был, несомненно, самым уверенным разработчиком Ruby. Мои товарищи по команде обычно оценивали истории, связанные с Ruby, гораздо больше, чем я, с аргументами вроде: «Ну, я не знаю, как X работает в Ruby, так что это займет у меня много времени».

Мой аргумент против этого исходит из того факта, что в спринтерском планировании задействованы возможности команды. Это правильный форум, чтобы сказать: «Наш потенциал в этом спринте будет немного ниже, чем обычно, потому что большинство задач основано на Ruby, а у нас только один сильный разработчик Ruby». Факторинг во время оценки удвоит этот аспект.

Я был бы признателен за любые авторитетные ссылки в ответах, но простые мнения тоже были бы хороши.

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

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

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

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

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

Тем не менее, это вызывает всевозможные проблемы на практике. Что произойдет, если вы в отпуске на этой неделе? Что происходит, когда приходит время пересмотра, и вы понимаете, что вы получаете 200% средних баллов за 110% средней зарплаты? Что происходит, когда бизнес начинает думать, что скорость команды, разделенная на людей, на самом деле является точным приближением? Что происходит, когда бизнес понимает, что вы производите гораздо больше ошибок, чем ваши коллеги (игнорируя, вы производите гораздо больше функциональности)? Что представляют собой истории размером с укус, когда у людей такие разнообразные укусы?

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

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

TL; DR
Мы всегда должны предполагать, что только компетентные разработчики будут назначены на конкретную историю.

Компетентность (или ее отсутствие) не является оскорблением. Это просто разумная мера навыков разработчика, который не отстает и не обладает исключительным опытом.

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

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

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

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

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

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

• Добавляем ли мы три дня к каждой истории? Если все три истории имеют одинаковую техническую направленность, это означает, что новичку на самом деле не понадобится дополнительное время для второй и третьей истории. Мы переоценили работу на шесть дней.
• Добавляем ли мы один день к каждой истории? Это тоже не правильно. Если мы в конечном итоге назначим новичка одной из трех историй, то мы сократили ему два необходимых дня на изучение; и мы дали два ненужных учебных дня другим разработчикам.
• Добавляем ли мы три дня к одной истории? Как мы можем гарантировать, что эта история будет обработана раньше двух других? Весь смысл создания отдельных пользовательских историй заключается в том, что они обычно могут решаться независимо друг от друга. Правильность нашей оценки теперь зависит как от предположения о том, что наш новичок выполнит эту работу, так и от порядка, в котором ему назначены эти задачи (если это имеет значение, например, если комбинированная рабочая нагрузка превышает один спринт).

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

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

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

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

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

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

Это сложная тема, и по этой теме часто идут дебаты. Мне не нравится понятие «канонического» мнения по этому поводу: существуют различные мнения, имеющие ценность. Но есть поддерживающие ценности, принципы и практики, которые должны направлять подход.

Нижеследующее основано на моем собственном мнении о работе с командами Scrum более 10 лет. Но это только МОЕ мнение.

1. Исторические точки как метод прогнозирования Первоначальная цель сюжетных точек состояла в том, чтобы найти быстрый метод оценки усилий с целью прогнозирования того, что команда может выполнить за определенный период времени. Некоторые из «корифеев» утверждают, что точки используются только для прогнозирования долгосрочного охвата (например, по выпуску), а не для определения пропускной способности на уровне спринта. Кроме того, концепция заключается в том, что команды применяют «относительный размер» на основе исторических значений (Усилие X аналогично Усилию B, которое составляло 3 балла). Это ускоряет процесс оценки, так что командам не нужно разбивать будущую работу на подробные рабочие пакеты и применять часы для всех задач. Высокопроизводительные команды стремятся превратить всех технических работников в очень компетентных членов с одинаковым уровнем квалификации. (Эта концепция будет более подробно рассмотрена в пункте № 4). Когда это будет достигнуто, то индивидуальный уровень квалификации действительно не будет переменной в определении размера. НО: для достижения этой цели обычно требуется достаточно много времени и согласованных усилий. ТАК ... что мы делаем, прежде чем попасть туда?

2. Часы заданий определяют пропускную способность спринта. Согласно тем же «светилам», которые утверждают, что точки используются для долгосрочного прогнозирования, они также предлагают использовать часы заданий для определения пропускной способности спринта, а не точек. На мой взгляд, это хорошо, но я скажу, что когда я помог тренерским командам добиться «высокой производительности», их выровненные навыки усреднялись там, где они могли точно определить, что они могли бы выполнить в спринте, используя только очки истории. , Опять же, это может быть целью, к которой мы стремимся, но новые команды не готовы к этому. Таким образом, вы можете найти в одном спринте историю с двумя точками, на которую уложено 12 часов работы, а другую - с 25 часами работы. Ну так что ты делаешь? Некоторые люди, которых я называю «гибкими пуристами», заявят, что размер истории (в пунктах) не зависит от продолжительности. Другие не согласны. Прочитайте логику пункта № 3 и посмотрите, что вы думаете.

3. Указание историй на основе консенсуса: применение объема, неизвестных, сложности, знаний

Таким образом, команды смотрят на часть работы и должны согласовать пункты, которые будут прокси для уровня усилий. Правильно? Если предположить, что все навыки равны, то консенсуса легко достичь. Но часто в командах есть парень, который является гуру Java, другой, который не так хорош в Java (возможно, он был на C # или .Net или Cobol и изучает Java). Итак, задача X для Боба очень проста. Для Джейн это сложнее.

Agile команды пытаются продвигать коллективное владение кодом и растут / расширяются знания. Поэтому мы обычно не назначаем истории людям на основе их опыта: мы предпочитаем, чтобы команды коллективно работали над историями и учились вместе. Это согласуется с концепцией «замедлиться, чтобы ускориться»: если мы потратим время, чтобы дать Джейн опыт работы с Java, хотя это может поначалу замедлить нас, позже у нас появятся более компетентные разработчики Java. Фактически, если у нас есть только ОДИН эксперт по Java, и каждый работает в своих областях, мы создаем ситуацию с несколькими потенциальными «точками отказа». Что происходит в спринте, когда 90% работы выполняется на Java, а Боб (наш эксперт по Java) болен или находится в отпуске? Расширяя навыки, мы устраняем потенциальные узкие места и снижаем риск. С этим в мыслях: Когда команда смотрит на историю, она должна иметь в виду несколько концепций при определении размера. Вы можете вспомнить акроним VUCK, чтобы запомнить это.

Объем: некоторые усилия довольно просты, но требуют большого объема повторяющихся задач. (У меня был парень, который должен был копировать и переформатировать более 50 таблиц, который сказал, что это 1 балл, потому что это было просто. Но поразмыслив, команда поняла, что хотя это было легко, это занимало много времени и было большое количество таблиц быть перемещены и оптимизированы. Таким образом, мы должны были скорректировать пункты из-за объема работы)

Неизвестные: иногда мы ДУМАЕМ, что знаем, что делать, но мы также идентифицируем некоторых неизвестных - они представляют РИСКИ . А это означает, что мы можем столкнуться с непредвиденными проблемами, которые нам необходимо решить, перепроектировать или попробовать другое решение.

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

Знание: ДЕЙСТВИТЕЛЬНО ли мы знаем, что решаем? Иногда клиенты не совсем понимают, какое решение они хотят, и мы немного экспериментируем. Или, возможно, никто никогда не реализовывал это решение (новая технология никогда не использовалась раньше), и поэтому мы не знаем, чего не знаем.

На мой взгляд, каждое из этих соображений на самом деле является прокси на длительный срок. Легкая история, много объема? Это займет больше времени, или нам нужно разделить историю. Unknowns? Добавлен риск, исследования, эксперименты, это может занять больше времени или нам нужно разделить историю. Сложный? Добавлен риск, необходимо исправить ошибки, изменить дизайн и т. Д., Так что это может занять больше времени. Не знаете, есть ли у нас необходимые знания? У нас есть дополнительный риск, возможно, придется экспериментировать и т. Д., Поэтому это может занять больше времени ...

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

4. Высокопроизводительные команды устраняют бункеры и узкие места: поскольку команды пытаются выровнять всех участников, у них иногда бывают менее опытные участники, которые берут на себя новые задачи, или они объединяют свои коды для обмена знаниями, чтобы улучшить свою команду. Как упоминалось ранее, это является обязательным условием, если команда когда-либо достигнет настоящих высоких показателей.

Так что, если Джейн добровольно возьмет на себя эти усилия в Java, и это сделает усилие в 2 или 3 раза больше того же усилия, если Боб сделает это, что вы будете делать? Со временем мои команды остановились на подборе историй, основанных на уровне усилий (LOE) / VUCK для людей, работающих над этой работой. Бобу, командному гуру, не имеет смысла говорить «это 1», когда для Джейн это будет непросто и займет неделю, плюс потребуется некоторое время Боба для парного кодирования и проверки кода. Поэтому мы увеличили эти точки, чтобы отразить реальный LOE. В следующий раз, когда появилась похожая история, то, что было 8 для Джейн, ранее стало 5. В конце концов, все согласились, что это было легко 3. В тот момент мы знали, что растем как команда.

TLDR

Нет, но, возможно, не по той причине, о которой вы думаете.

Длинная версия

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

Например (один из моих любимых), рассмотрим вашу задачу «Копать яму». Вы можете оценить это либо по количеству удаляемой земли, либо по времени, которое потребуется вам для удаления земли. Мой друг копает целое со скоростью 3 метра в час, у меня есть большой механический экскаватор, поэтому я могу управлять 100! Единственная константа - это количество земли, поэтому мы используем ее в качестве нашей единицы оценки.

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

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

В команде нет «я» и нет абсолютно никакого «я» в гибком планировании!