Как мы можем сократить время простоя в конце итерации?

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

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

Какие методы мы можем использовать как команда, чтобы поддерживать импульс в течение последнего дня? Должны ли мы устранить недостатки? Получите раннее начало работы следующей итерации в любом случае? Что-то другое?

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

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

Примеры:

• Проведите день, изучая что-то
• Потратьте его на инновационный проект
• Потратьте это на то, чтобы привести в порядок этот надоедливый кусок кода, который вы никогда не найдете в рефакторинге
• Хорошей работы с приложением с точки зрения UX (который мы, кажется, никогда не находим время, чтобы сделать иначе)

Все, что мотивирует программиста, дает им стимул доставлять релиз вовремя.

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

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

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

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

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

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

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

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

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

Кен Швабер заявляет в своем блоге http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

«Боже, помоги нам. Люди нашли способы расслабиться в водопаде, отдохнуть и проявить креативность. С Лин и Канбаном эти укрытия убраны. Теперь у нас прогрессивный марш смерти без паузы».

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

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

Все разработчики в моей команде используют свободное время к концу спринта (при условии, что все задачи по спринту завершены) как «время Google».

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

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

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

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

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

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

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

Лично я считаю, что ретроспективы не стоит тратить время на это, обычно есть несколько общих повторяющихся тем (плохие пользовательские истории, плохая оценка и т. Д.), И вы просто принимаете их как проблемные области и идете дальше. Мы также пытаемся решать проблемы по мере их возникновения, а не ждать ретроспективы (что мы имели тенденцию делать на ранних этапах внедрения Scrum).

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

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

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

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