Scrum: Як працювати над однією історією одночасно

В новій сформованій команді scrum я був висунутий майстром scrum. Ми вже зробили кілька спринтів. На початку я намагався змусити свою команду працювати над однією історією. Але це не спрацювало. У моєї команди були складно розподілити завдання таким чином, щоб вони могли працювати одночасно над однією історією. Може, ми робимо щось не так?

Наприклад: у нас є історія для створення нового діалогу. Ми створюємо такі завдання:

• Створення класів моделей
• Зчитування даних моделі з бази даних
• З'єднайте класи моделей із поданням
• Реалізація діалогового вікна
• Збережіть дані на закритті
• Тестова документація
• Опис рішення

Чи можуть ці завдання виконувати одночасно більше однієї людини? Завдання - більш-менш - будуються один на одному. Або ми розробили завдання неправильно?

Чому весь колектив повинен працювати над однією історією?

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

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

Зазвичай ми робимо розбиття історій на підзадачі dev / infra / analyst.

1. Як правило, все, що працює більше днів, - це історія.

2. Після того, як завдання розбиті, один або максимум з двох розробників працюють над історією, залежно від кількості завдань, які є у вас. Зазвичай його.

3. Ми реєструємо витрачений час та оновлюємо решту оцінок в кінці дня перед тим, як виїхати або перед щоденним вставанням.

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

5. Історія, яка працює понад 2 тижні, вважається епопеєю.

6. Епопею можна скласти з багатьох історій

Те, що ви хочете, щоб ваша команда, називається ройовим , але не кожен предмет відставання може бути вирішений усією командою. Поширена думка, що для роїння потрібні деякі попередні умови:

• кросова функціональна команда
• нетривіальна історія
• визначення "зроблено", що передбачає залучення всієї команди

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

Але будьте обережні, використовуючи рой занадто часто або з занадто великою кількістю людей одночасно, так як ви можете зіткнутися з надмірною проблемою, коли між членами команди можуть виникнути певні конфлікти, оскільки вони надто багато працюють над одним і тим же предметом.

Можливо, ви захочете прочитати "Майка Конна", чи повинна команда одночасно приєднатися до одного предмета відставання? або цю статтю, яку я писав (вчора), яка конкретніше стосується помилок: роїти чи не рояти

Велика частина SCRUM полягає в тому, що команда повинна приймати такі рішення. У затримці має бути історія користувачів з надією достатньо інформації для створення завдань.

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

Біль, яку ви відчуваєте, намагаючись працювати над однією історією одночасно, повинна бути визнана командою, і в спринтних ретроспективних потенційних рішеннях потрібно виховувати. З’ясуйте, що ви робите правильно, і що потрібно покращити.

Використовуючи ваш приклад труднощів у розподілі завдань, над якими можна працювати одночасно, одне можливе рішення - взяти на себе кілька оповідань та передачу 3 або 4 предметів у спринті. Оскільки завдання для цієї історії користувачів будуються один на одного, розподілити роботу буде важко. Тож, а не боротися, що охоплює це.

Ваші завдання, як зазначено, здаються "невеликими", щоб бути розподіленими, але існує певна зв'язок між завданнями, такими як моделювання даних та їх отримання з бази даних.

Можливо, це розділити його на три основні речі, над якими люди можуть працювати одночасно, з деякими додатковими роботами / налаштуваннями:

• Бек-енд (база даних, модель тощо)
• Лицьовий (з використанням макетних даних)
• Тести (встановлення очікувань, сценарій тощо)

Завдання, які неможливо розділити, можна виконати парами. І звичайно, немає нічого по суті не в тому, що в одній точці ведеться більше однієї історії; до тих пір, поки кожен член команди знає, що роблять інші, і вони можуть допомогти, коли потрібно (як, наприклад, "спільне володіння кодом").

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

Крім того, наскільки ваша команда? Це також є фактором; досить складно, щоб десять людей працювали над однією історією, і якщо ви можете, ваша історія далеко, надто велика і її слід розділити (як і ваша команда).