У Scrum, як впоратися з суперечками / робочим навантаженням в кінці спринту

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

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

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

• Перший - тримати всіх зайнятих в кінці спринту.
• Другий (споріднений) - це суперечка щодо системи. Ми майже закінчуємо інтеграцію протягом останніх кількох днів спринту. У нас є лише одна система інтеграції, тому люди часто блокуються продовжувати працювати над своїм завданням, оскільки вони не можуть отримати доступ до системи. Оскільки це кінець спринту, то в відставанні спринту залишилося не багато роботи. Над чим ці люди повинні працювати? Забрані елементи з верхньої частини відставання продукту від власника продукту не надто добре отримані, оскільки поточні елементи не виконані. Робота над технічним боргом допоможе проекту в цілому, але не допоможе завершити спринт.

Чи є найкращі практики для будь-якої структури спринтів, щоб уникнути цих проблем? Поради щодо переговорів з власниками продукції?

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

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

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

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

Пам’ятаючи, що відповідальність за те, щоб Комісія доставила, а не окремих членів, сама по собі , чи можливо, щоб усі чотири-шість членів працювали над кожним завданням РАЗОМ - просуньте кожного з них через процес і перейдіть до наступного. Спочатку це може здатися неефективним, але якщо вузькі місця, які ви бачите, такі погані, це може бути правильним варіантом.

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

Ми вирішили це, прийнявши підхід Канбана.

У нашому програмному забезпеченні для відстеження (Джира) є черги з мінімумами та максимумами.

Ми підлітаємо "за потребою". Це може бути один раз на тиждень, може бути 3 рази, залежно від обмежень та роботи, яку потрібно виконати.

Це допоможе вам зосередитись на тому, щоб власник продукту зосередився на тому, щоб стежити за чергою, щоб зробити багато, і зменшити мікро-управління індивідуальними квитками. Просто пам’ятайте, що як завжди зміни потребують часу.

Ми все ще демонструємо кожні два тижні і випускаємо щотижня.

Нічого собі, якби ти не сказав роботів, я б припустив, що ти зараз був у моїй команді. У нас є точнітой самий набір проблем. Працюючи над численними спритними проектами з різною мірою вірності маніфесту та різною мірою успіху, мій аналіз полягає в тому, що наша проблема полягає в тому, що спринти занадто короткі. Ми робимо двотижневі спринти, що викликає кілька проблем. Одне полягає в тому, що ми виявляємось обережними в плануванні і часто закінчуємо мертві дні. По-друге, це величезна підслухана перевірка, ретроспектива та планування, що займає 1-2 дні кожні два тижні. Інша, як ви сказали, потребує інтеграції в останню хвилину та часто невдалої години до огляду. Мій перший та найуспішніший гнучкий проект мав чотири тижні спринти, котрий я збираю досить великий за галузевими стандартами, але він спрацював для нас чудово.

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

Друга проблема, ймовірно, є наслідком спроби виправити непроблему №1. Ви повинні змусити людей, які не зайняті, допомагати своїм ровесникам; замість того, щоб працювати над не спринтними завданнями, які викликають суперечки щодо обмеженої інтеграції.

Також інтегруватись слід не в кінці спринту, а постійно.

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

По-друге, власник вашого продукту повинен довіряти команді, щоб найкраще знати, як себе організувати та оптимізувати. Натомість команда довіряє PO, щоб найкраще знати, що потрібно замовнику.

Це дуже поширені проблеми з новими спритними командами. Чудово бачити, коли команда починає руйнувати власні силоси та рости.