Когда гибкое повторение считают завершенным? [закрытый]

Я бы взял вариант 1. Если функция B может быть разбита на то, что завершено, а что нет, то это должно привести к пересмотренному набору задач для завершения ее к следующему спринту. То, что закончено, доставляется, и хотя доставка не совершенна, идея должна заключаться в том, чтобы попытаться сделать все возможное, а затем поработать над тем, что будет дальше, в соответствии с приоритетом.

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

Неудача спринта вводит слишком много перфекционизма в вещи. Неужели то, что сделано на 99%, ничего не стоит? Я бы так не думал, но есть люди, которые имеют действительно высокие стандарты и могут быть довольно требовательными.

EDIT: Иногда функция изначально дается с расплывчатыми требованиями, которые проясняются по ходу спринта. Например, запрос функции "Как пользователь, я бы хотел разместить заказ" может быть разбит далее как часть планирования спринта или во время спринта. В любом случае, если некоторые истории, связанные с функцией, сделаны, то они могут и должны быть представлены на демо, если они сделаны. Смысл в том, чтобы иметь возможность сказать: "Вот где мы находимся". Насколько важен приоритет на финише", поскольку то, что могло бы быть срочным раньше, может быть не так в конце спринта.

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

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

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

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

Для Agile Project важно иметь «определение сделано». Это небольшая проверка списка вещей, которые необходимо сделать, чтобы упросить что-то, как завершено. Необычно иметь разные уровни проведенного:

• История пользователя - это может включать такие вещи, как все задачи, связанные с США, должны быть полными, все код проверяются и успешно создают пропускные тесты, тестирование приема. завершенный.

• Sprint - это может включать такие вещи, как все истории для Sprint, «сделаны» (см. Выше, ретроспектива состоится, владелец продукта видел демонстрацию функциональности и т. Д.

• Спринт Разработка предыдущей серии Sprints была успешно интегрирована, и регрессионные испытанные, функциональность была выпущена в живую среду.

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

Не подвешивать это. Просто учитесь у него, адаптироваться и двигаться дальше.

Во-первых, правило: Итерации - это время с фиксированной длиной, и они завершены в конце во времени. Таким образом, это устраняет вариант 2 и вариант 3. Что касается параметра 4, а ненормальное завершение итерации может происходить в очень конкретных обстоятельствах (уверенность в том, что цель не может быть достигнута, внешнее событие недействительна цель, ...) Но это должно оставаться исключительным событием. И прежде чем прервать, есть вообще другие варианты: 1. Сделайте что-то еще / инновации 2. Получите помощь / аутсорсинг 3. Уменьшите объем. И это оставляет вас вариантом 1, очевидным выбором.

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

, если это правда, то либо B важнее, чем A, D и F, и вы не работали на самых важных предметах, которые первыми Неправильно, этого не должно происходить или ... a, d и f на самом деле очень ценны, в этом случае ваше предположение на самом деле не правда, и отложить B, таким образом, не является большой проблемой. Итак, просто сделайте это, как только вы поймете, что это не будет сделано, и не посмотрим, сможете ли вы заменить его с меньшим предметом.

Могу ли я ответить на "это зависит"? Плюс, я бы хотел бросить в «Определить полную».

У нас была эта ситуация пару раз и разобралась с ней по-разному в зависимости от обстоятельств.

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

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

Итак, это была вариант 4, либо вариант 2 для нас, когда он был вызван.

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

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

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

Многие люди здесь утверждали, что вариант 2 идет против основных правил Agile (или Scrum), но я бы не согласен. Scrum явно говорит, что вы можете расширить Sprint, если вы хотите, так же, как вы можете сократить истории или добавлять ресурсы. Вы не должны делать это до абсолютно необходимого, но насколько я знаю, это не строго против книги. В базе, когда мы это сделали, это было лучшее решение для всех, потому что мы все еще получили спринт, только три дня спустя, и все были очень довольны результатами. Если бы мы говорили неделю или более вариант 2, не было бы уместно.

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

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

Итак, есть несколько вещей.

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