Как часто команда Scrum должна выполнять свои обязательства по Sprint? [закрыто]

10

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

Я знаю, что в официальном Scrum Guide теперь используется слово «прогноз», а не обязательство, вероятно, для решения этих проблем.

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

Спасибо.

Евгений
источник
1
Вопрос, который я часто задавал, и два хороших ответа
Мэтт Фрейк
1
Если вы всегда выполняете свои обязательства, вы, вероятно, недостаточно агрессивны. Надеемся, что ваша точность со временем улучшится, так как часть цели Scrum - улучшить навыки каждого в оценке того, сколько времени займет задание в реальном мире.
Кешлам
1
@keshlam, это не обязательно полностью верно. В гибком движении есть целая школа мысли, которая активно пытается превзойти традиционные оценки, признавая ее потенциальную ядовитую природу.
Стефан Биллиет
1
Конечно, @StefanBilliet ... но Scrum намеревается одновременно снять стресс-оценки с точки зрения внешнего мира, улучшая при этом внутреннее чувство команды о том, сколько дополнительной работы они смогут выполнить, когда.
keshlam

Ответы:

21

Вопрос не в том, как часто команда должна «выполнять свои обещания».
Это больше вопрос расследования, почему у команды возникнут проблемы с выполнением своих обязательств.

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

Несоблюдение обязательств по спринту является симптомом; Вы должны быть заинтересованы в коренной причине.

Стефан Биллиет
источник
Так должны ли мы стремиться к выполнению обязательств в 99,99% случаев? Если это уровень необходимой гарантии того, что обязательство будет выполнено, мы возьмем на себя только половину средней работы, которую мы обычно можем выполнить. Так что я думаю, это не 99,99%. Так что же это? 50-70%? 80-90%?
Евгений
@ Евгений Зачем тебе номер, а кого нужно уверять? Я начинаю понимать, что в вашей организации есть кто-то, кто накажет вас, если вы не достигнете своих целей в спринте ...
Стефан Биллиет,
Не за что. На самом деле в моей организации никого не волнует, выполнено ли обязательство или нет. Я пытаюсь это изменить, потому что в настоящее время исправление ошибок и написание тестов не учитываются, потому что на них нет времени. Я хотел бы посоветовать командам взять на себя меньше обязательств, чтобы они могли выполнять свои обязательства на регулярной основе. Но насколько меньше? Если выполнение обязательства - это вопрос жизни или смерти, тогда вы определенно будете выполнять меньше, чем если бы это был просто прогноз, на который никто не полагается.
Евгений
2
Судя по всему, у вас есть более фундаментальные проблемы. Прежде чем вы сможете измерить производительность по количеству ставших «выполненных» историй, вы должны иметь общее понимание «выполнено»
Майкл Шоу,
13

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

Если спринты постоянно не доставляют, то Scrum выполнил свое обещание - сделать «проблемы» видимыми. Проблемы могут включать в себя отсутствие правильно определенных задач, недостаточный опыт работы в команде или культуру управления, из-за которой постоянно пытаются перевыполнить поставку - и поэтому постоянно терпят неудачу.

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

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

Майкл Шоу
источник
4

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

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

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

talboomerik
источник
2

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

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

Чтобы ответить на ваш конкретный вопрос, из трех организаций, где я использовал scrum, только одна отслеживала показатели "пропустить фиксацию" с течением времени. Для этой компании команды обычно достигают своего прогноза примерно в 85% случаев.

Брайан Оукли
источник
Согласен. Я был в одной команде, где в конце каждого планирования спринта менеджер требовал обязательство завершить все истории спринта. Я привык говорить «да» и просто продолжал быть проворным. Я полагал, что это, вероятно, заставило его чувствовать себя лучше таким образом.
Роб
1
@RobY: Я думаю, в зрелых командах есть место для обязательств. По моему опыту, большинство гибких команд не особенно зрелы, и любое ПО, требующее обязательств, не является хорошим ПО. Я был в одной команде, которая была довольно крепкой по своей скорости, и мы чувствовали себя вполне комфортно, когда принимали реальные обязательства, когда это было необходимо, но другие команды, в которых я принимал участие, не были настолько зрелыми.
Брайан Оукли
Я был маленьким лакомым кусочком. Я согласен, обычно есть основной набор историй, которые вы можете посвятить, но по мере приближения к скорости это становится менее определенным. Поскольку скорость является средней, то по определению иногда вы будете больше, а иногда и ниже. Кстати, тот же менеджер загружал нас в 2 или 3 раза быстрее, а затем требовал обязательств ... так ...;) (я в основном реагировал на ваш первый абзац, который, как мне кажется, действительно хорошо говорит)
Роб
2

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

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

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

санки
источник
Я действительно не согласен с этим ответом. Человеческая природа состоит в том, чтобы пытаться доставить, и вы можете поспорить, что ваш нижний доллар будет сокращен «тестированием», чтобы поставить, а не отбросить историю. Если вы всегда находитесь так близко к линии, вы не будете достаточно тщательно тестировать, и он снова начнет кусаться.
Майкл Шоу
@Ptolemy, где требуются дисциплина, профессиональная гордость и твердое « определение выполненного ». Это должно помешать вам отправлять дерьмо. Кроме того, вы не должны считать что-то сделанным, если вы срезали углы.
сани
Это гораздо понятнее с точки зрения разработчика, чем с точки зрения тестирования Scrum. У вас не может быть никаких известных дефектов, потому что тестер был сосредоточен на тестировании основных функциональных возможностей, и у него не было времени для «случайного события», которое могло выявить ошибку.
Майкл Шоу
2
@Ptolemy: команды не могут технически «сократить тестирование», так как тестирование является частью истории. Если они сокращают это, это ничем не отличается от сокращения части кодирования. Если вы пропустите часть закодированной функции, вы заканчиваете историю? Точно так же, если вы прекратите тестирование, вы не закончите историю.
Брайан Оукли
Я никогда не использовал scrum, но я взял на себя обязательства и решил, что все сделано. Было бы неплохо, если бы определение done было полностью объективным, то есть у группы не было места для толкования определения в свете того, нужно ли это делать для выполнения обязательства. Естественный язык, какой он есть, кажется нереальным. Если вы достаточно спокойны в отношении обязательств и достаточно близки к объективному определению, это не будет проблемой. Когда Птолемей говорит, что «человеческая природа - это попытка доставить», в моей схеме это означает, что «люди недостаточно расслаблены в отношении обязательств».
Стив Джессоп