В Scrum, как справиться с конфликтом / рабочей нагрузкой в ​​конце спринта

Моя команда начала использовать Scrum несколько спринтов назад. Наш проект включает создание программного обеспечения, взаимодействующего с физическими устройствами (например, роботами и датчиками), и наше типичное отставание от продукта обычно представляет собой добавление устройства управления ко всей системе.

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

Мы сталкиваемся с 2 проблемами в конце спринтов:

• Во-первых, чтобы все были заняты в конце спринта.
• Второй (связанный) - это конфликт в системе. Мы в значительной степени заканчиваем тем, что объединялись в течение прошлых нескольких дней спринта. У нас есть только одна система интеграции, поэтому людям часто не разрешают продолжать работать над своей задачей, потому что они не могут получить доступ к системе. Так как это конец спринта, осталось не так уж много работы в спринте. Над чем должны работать эти люди? Забрать предметы из верхней части списка невыполненных заказов от продукта не очень хорошо, так как текущие позиции не выполнены. Работа над техническим долгом поможет проекту в целом, но не поможет завершить спринт.

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

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

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

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

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

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

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

Мы решили эту проблему, приняв подход Канбана.

У нас есть очереди в нашей программе отслеживания (Jira) с минимумами и максимумами.

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

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

Мы по-прежнему демо каждые две недели, и мы выпускаем еженедельно.

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

РЕДАКТИРОВАТЬ: Вспомнил еще одну вещь из того первого проекта, который был благом. У нас всегда был полностью приоритетный бэклог продукта, и у разработчиков была свобода извлекать из него задачи, если их задачи по спринту были выполнены, а другие задачи по спринту не были доступны.

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

Кроме того, вы должны интегрироваться не в конце спринта, а постоянно.

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

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

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