Scrum: Как работать над одной историей за раз

Я был назначен мастером схватки в новой команде. Мы уже сделали несколько спринтов. Сначала я пытался заставить свою команду работать над одной историей за раз. Но это не сработало. У моей команды были трудности с распределением задач таким образом, чтобы они могли одновременно работать над одной историей. Может мы что то не так делаем?

Например: у нас есть история для создания нового диалога. Мы создаем следующие задачи:

• Создать модель классов
• Чтение данных модели из базы данных
• Соедините модельные классы с представлением
• Реализовать обработку диалогов
• Сохранить данные при закрытии
• Тестовая документация
• Описание решения

Могут ли эти задания выполнять более одного человека одновременно? Задачи - более или менее - основываются друг на друге. Или мы проектируем задачи неправильно?

Почему вся команда должна работать над одной историей?

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

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

Обычно мы разбиваем истории на подзадачи dev / infra / analyst.

1. Как правило, все, что длится более суток, - это история.

2. Как только задачи разбиты, один или максимум два разработчика работают над историей, в зависимости от количества выполняемых задач. Обычно это один.

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

4. Подзадачи создаются для любых новых проблем, возникающих во время работы.

5. История, которая более 2 недель, считается эпической.

6. Эпос может быть составлен из многих историй

То, что вы хотите, чтобы ваша команда делала, называется роением , но не вся команда может быть обойдена всей командой. Считается, что роение требует некоторых предварительных условий:

• кросс-функциональная, совместная команда
• нетривиальная история
• определение «сделано», которое подразумевает участие всей команды

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

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

Возможно, вы захотите прочесть книгу Майка Кона « Должна ли команда набрасываться на один предмет за один раз?» или эту статью, которую я написал (вчера), которая более конкретно связана с ошибками: роиться или не роиться

Большая часть SCRUM заключается в том, что команда должна принимать такие решения. Журнал ожидания должен содержать пользовательские истории с достаточной информацией для выполнения задач.

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

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

Используя ваш пример сложности распределения задач, над которыми можно работать одновременно, одним из возможных решений является взятие нескольких историй и доставка 3 или 4 предметов в спринте. Поскольку задачи для этой пользовательской истории строятся друг на друге, будет трудно распределить работу. Так что вместо того, чтобы бороться, обнимите его.

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

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

• Back-end (база данных, модель и т. Д.)
• Front-end (используя фиктивные данные)
• Тесты (настройка ожиданий, сценария и т. Д.)

Задачи, которые не могут быть разделены, могут быть выполнены парами. И, конечно, нет ничего плохого в том, что в какой-то момент ведется более одной истории; так же, как каждый член команды знает, что делают другие, и они могут помочь в случае необходимости (например, «владение общим кодом»).

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

Кроме того, насколько велика ваша команда? Это тоже фактор; довольно сложно заставить десять человек работать над одной историей, и если вы можете, ваша история слишком большая, слишком большая и должна быть разделена (как и ваша команда).