Что такое «роение»?

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

Что именно это? Когда это должно быть применено? Как ты делаешь это хорошо?

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

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

Здесь есть некоторые трудности. Например, QA не всегда может тестировать вещи до того, как они построены (или даже спроектированы). В этом случае вы должны создать совместный проект на ранней стадии, и тогда QA сможет написать (изначально провальный) тесты на соответствие проекту, а не фактической реализации.

Рой просто означает тот факт, что несколько человек работают вместе, чтобы выполнить задачу или историю. По моему опыту, это не то, что вы делаете часто.

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

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

«Рой» - это не более, чем причудливый термин «эй, позвольте нам помочь вам с этим».

Рой на самом деле является центральной концепцией ловкости. Это не то, что делается «когда есть проблемы». Рой в своей простейшей форме означает, что команды работают совместно над предметами (историями) и доводят их до конца. Основная идея заключается в том, чтобы «прекратить старт и начать финиш». Другими словами, вместо того, чтобы каждый разработчик работал независимо над историей, команда сосредотачивается на более ограниченном наборе историй / задач вместе, и каждый элемент выполняется быстрее. Думайте об этом как о разнице между однопоточной и многопоточной системами. Если в пользовательской истории есть 10 задач, которые необходимо выполнить, и каждая из них занимает 8 часов, при условии отсутствия осложнений, один разработчик может выполнить каждую задачу последовательно и завершить историю за 80 часов или около двух недель (с учетом 10-дневного спринта). 8 часов в день). Что, если два разработчика разделили задачи и работали над ними одновременно? Те же 80 часов работы можно выполнить за одну неделю. Добавьте треть, и вы можете видеть, что это может быть сделано через 3-4 дня.

Рой можно сделать несколькими способами:

1. Парное программирование (два разработчика сидят бок о бок, работая над кодом, один - «водитель», пишущий код, другой - навигатор, помня о более долгосрочной перспективе и помогая одновременно анализировать код).
   2. Совместная работа: разработчик и тестировщик работают одновременно над одной и той же работой: одно кодирование и другое тестирование, автоматизация написания и т. Д.
   3. Рой, как я уже говорил выше, что очень распространено. Обычно члены команды роят историю, но у каждого есть свои задачи в этом методе.
   4. Программирование мобов: вся команда фокусируется на одной истории (или даже задаче) за раз.

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

Команды, которые роятся, имеют тенденцию иметь меньше WIP и заканчивают больше историй - и под выполненным, я имею в виду Разработано, Проверено, Одобрено, готовое к развертыванию. Таким образом, это практика, которая является основой для ловкости.

Следующая статья о InfoQ описывает один подход к роению:

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

Прочитайте статью для подробного объяснения.