Что делать с оценкой неполного рассказа?

Я являюсь частью команды разработчиков, которая относительно новичок Scrum, предположим, что в конце спринта несколько больших историй были in progressили не были acceptedв ПО.

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

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

РЕДАКТИРОВАТЬ: В моем конкретном случае истории не были завершены из-за препятствия, которое длилось несколько дней, а не из-за недооценки пользовательской истории. Для тех из вас, кто может помочь, мы используемVersionOne

agile scrum

— ediblecode
источник

Я работаю с процессом XP и

— задаюсь

Неспособность определить препятствие как возможный риск и определить подверженность риску RE (влияние * вероятность) указывает на проблему с оценкой. Пользовательская история с высоким RE должна иметь больший буфер затрат и времени, связанных с ней, для устранения этих рисков, если они перерастут в проблемы.

— Томас Оуэнс

удвоить его и добавить 32, как C => F

— Пол

Ответы:

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

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

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

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

Я бы не стал переоценивать, потому что в Scrum вы оцениваете историю, когда принимаете ее, начинаете работу, и у вас нет концепции частично завершенной . История либо на 100% завершена, проверена и принята (выполнена), либо еще не завершена. Если нет понятия частично завершенного, вы не сможете определить, сколько работы осталось в истории. Похоже, я тоже не одинок в этой мысли . Вы оценили работу, которую, по вашему мнению, вы можете сделать, поэтому оставьте эти данные в точке и обсудите, почему оценка была отклонена в вашем посмертном спринте, и постарайтесь избежать этой ошибки для будущих спринтов.

— Томас Оуэнс
источник

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

— съедобный код

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

— Томас Оуэнс

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

— Томас Оуэнс

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

— Дэвид Торнли

@DavidThornley Это вовсе не способ управления рисками, а отправная точка для плана управления рисками, который также включает стратегии обнаружения и смягчения последствий. Это метод, который используется для того, чтобы у вас было достаточно денег и времени в плане, если риски перерастут в проблемы. Это защищено Стивом Макконнеллом в Оценке программного обеспечения и Карлом Вигерсом в этой статье . Важно понимать, что это не буфер для каждой задачи, а буфер проекта (или итерации) на случай возникновения различных рисков.

— Томас Оуэнс

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

Во-вторых, поскольку ваша команда является новичком в Scrum, это все часть процесса обучения. Теперь вы поняли, что некоторые истории слишком велики, поэтому вашей команде понадобится больше времени, чтобы разбить истории. Как правило, ответственность за то, чтобы это произошло, лежит на мастере схватки. Скрам-мастер также должен будет проконсультироваться со спонсором проекта / владельцем продукта с неполными историями, чтобы попытаться разбить их дальше или получить окончательное решение о том, как полностью их удалить.

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

— Пустынная планета
источник

Nitpick: Решение, что делать с неполной историей, является вопросом расстановки приоритетов. Таким образом, я считаю, что это должен решать владелец продукта, а не Scrum master.

— Слеське

@Sleske - Согласен. Я должен был прояснить это в своем ответе. Первоначально я сказал, что мастер схватки проконсультируется с командой, но я должен был включить спонсора / владельца проекта, который я исправил. Спасибо за голову, хотя.

— Пустынная планета

Если неполные истории все еще не завершены в конце спринта, вы не сможете разложить их на этом этапе, потому что это может полностью подорвать определение «Готово» - «То есть вы говорите, что часть истории выполнена? Но это еще не было проверено! " Вот почему эпопеи как одиночные истории ужасны и никогда не должны быть допущены в спринты.

— Робин Грин,

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

— Пустынная планета