Когда считается полной гидроматранной итерацией? [закрыто

Question

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

Один вопрос, с которым мы сталкиваемся, - это решать, когда должна завершить итерацию (спринт).

Допустим, мы определили наше отставание на основе функции и дали для них оценки историй, и мы решили, что первый 30-дневный спринт будет включать в себя функции A, B, D и F. Что вы должны делать, если у вас есть » Получите достижение конца спринта, и вы завершили A, D и F - но B завершено всего на 80%. Тебе следует:

1. Завершите спринт вовремя, но исключите функцию B (откладывая оставшуюся работу в будущем спринте)

2. Распространите спринт к тому времени, когда необходимо для завершения функции B, но не запустите следующий спринт.

3. Распространите спринт к тому времени, когда необходимо, чтобы завершить функцию B, и начните работать над следующим спринтом.

4. Выпустите весь спринт, и все работают, чтобы стать частью будущего релиза.

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

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

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

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

Answer 1

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

В Scrum вы Временная бокса. Анкет И вы предоставляете только функции, которые работают.

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

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

Answer 2

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

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

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

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

Answer 3

Могу ли я ответить "это зависит"? Кроме того, я хотел бы добавить «определить комплекс».

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

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

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

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

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

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

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

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

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

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

Итак, есть несколько вещей, которые нужно рассмотреть.

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

Answer 4

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

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

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

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

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

Важно не завешивать его. Просто учитесь на этом, адаптируйтесь и двигайтесь дальше.

Answer 5

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

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

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

РЕДАКТИРОВАТЬ: Иногда функция изначально дается с расплывчатыми требованиями, которые разъясняются в течение спринта. Например, запрос функции «Как пользователь, я хотел бы разместить заказ», можно либо разбить либо в рамках планирования спринта, либо во время спринта. В любом случае, если сделаны некоторые истории с участием функции, они могут и должны быть представлены на демонстрации, если это будет сделано. Дело в том, чтобы иметь возможность сказать: «Это то, где мы находимся. Насколько приоритет при этом закончить?» Как то, что могло бы быть срочным раньше, не могло быть таким в конце спринта.

Answer 6

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

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

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