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

8

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

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

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

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

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

Винсент Хьюберт
источник
7
Фраза «Непрерывная интеграция» приходит на ум.
Роберт Харви
1
Непрерывная интеграция - это то, что система интеграции все делает своими единожды, интеграторы интегрировали каждое устройство в нее. К сожалению, с нашей настройкой, это не так просто, как проверка кода, нам нужна настройка физических соединений с двигателями и картами ввода / вывода, а что нет. Убедиться, что ваше новое устройство работает в среде CI, - это сама задача, и эта задача вызывает конфликт. Интересно, что взять все, что есть в системе CI и поместить его на реальную машину, - довольно тривиальный процесс - доказать, что CI того стоит.
Винсент Хьюберт
2
Зачем вам ждать реального устройства интеграции? У вас нет тренажеров (по крайней мере, функциональных, если не общих), которые вы могли бы использовать для выполнения хотя бы базового тестирования и интеграции программного обеспечения перед переходом на аппаратное обеспечение?
Томас Оуэнс

Ответы:

6

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

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

Боб Дворник
источник
2
Исправление ошибок было еще одной задачей, которая заставляла нас быть занятыми в конце спринта.
Sjoerd
5

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

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

Мартин Викман
источник
2
На самом деле, интеграция в систему может быть осуществлена ​​в любое время. Проблема в том, что нечего интегрировать до того, как задачи находятся на стадии интеграции, и большинство из них прибывают на эту стадию ближе к концу спринта, что приводит к разногласиям.
Винсент Хьюберт
1
Кажется, моя рекомендация по сокращению ваших заданий здесь поможет, нет?
Мартин Уикман,
4

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

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

Мэтью Флинн
источник
3

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

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

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

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

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

Майкл Даррант
источник
2

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

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

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

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

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

Бруно Гардиа
источник
0

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

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

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

Крис Ван Баел
источник