Одна з перешкод на шляху до готового — забагато змін під час спринту. Стефані Окерман згадувала про це у своєму попередньому матеріалі.

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

У маніфесті гнучкої розробки програмного забезпечення (Аджайл маніфесті) мовиться про те, що реагувати на зміни важливіше, ніж слідувати плану. Також там сказано, що найкращі архітектури, вимоги й дизайни з’являються в самоорганізованих командах.

То як нам водночас і реагувати на зміни, і допускати терміновість, і приносити робочу цінність?

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

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

Складно знайти баланс між терміновістю і поставками. Ідеальної формули не існує. Командам доводиться самим шукати робочі методи.

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

1. Коли в беклог спринту додається нова робота

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

Ось кілька ідей, як владнати термінові пріоритети, що не відповідають цілі спринту.

  • Скрам-майстер може допомогти захистити скрам-команду від відволікаючих факторів, навчаючи її правилам скраму, допомагаючи зрозуміти її відповідальність і право на прийняття рішень. Сюди входить також і навчання Продакт Оунерів пріоритезувати нові запити в беклозі продукту замість проштовхувати їх в дійсний спринт. Сюди входить і навчання стейкхолдерів скраму. Можна використовувати для цього менеджмент.
  • Буває складно сказати “ні” тим, хто тисне в спину, але члени команди можуть з цим справитися, пам’ятаючи про відповідальність одне перед одним. Якщо хтось закидає в беклог спринту щось іззовні, піддати сумніву цю задачу — це відповідальність і робота команди. Нагадуйте про це членам команди, підтримуйте їх у взятті на себе відповідальності. Адже кожному буває важко говорити “ні”. І підтримка команди, коли доводиться сказати “не зараз”, допомагає.
  • Про нову роботу, що виникає під час спринту, розробники і власник продукту мають домовлятися. Якщо щось влазить в спринт поза графіком, скоріш за все, щось інше потрібно з нього прибрати. Лише пам’ятайте, що наша ціль не має змінюватися під час спринту.

2. Погане уточнення беклогу спричиняє зростання кількості роботи під час спринту

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

  • Спробуйте залучити всю скрам-команду до участі в уточненні беклогу продукту. Участь усіх розробників може дати вам дві суттєві переваги: 1) Кожен стане частиною дискусії про те, що і чому ми будуємо, а це зменшить кількість пізніших непорозумінь. 2) Кожен зможе зробити свій внесок в декомпозицію і впорядкування елементів беклогу продукту, а отже, більше шансів мати елементи правильного розміру зі зменшеними взаємними залежностями.
  • Мета уточнення полягає в тому, щоб довести елементи продуктового беклогу до необхідного для роботи рівня деталізації. Ви можете формалізувати цей процес, додавши в нього визначення готового. Нам подобається визначення Романа Піхлера: він називає готове “зрозумілим, здійсненним і таким, що підлягає перевірці”. Деякі команди створюють візуальну дошку, що демонструє уточнення елементів беклогу продукту до стану готових.
  • Скрам-майстер коучить Продакт Оунерів виконувати свою роль і дотримуватися зобов’язань по відношенню до команди. Власник продукту відповідає за максимізацію цінності продукту і за роботу розробників. Уточнення необхідне, щоб цінність продукту стала зрозумілою і досяжною. Власник продукту не мусить виконувати всю роботу з уточнення беклогу самостійно. Та якщо ми помічаємо симптоми цієї проблеми, Продакт Оунера варто більше залучити до Product Backlog Refinement.

3. Коли “Як” не обговорюється на плануванні спринту

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

  • Скрам-майстер має підкреслювати цінність планування спринту. Команда легко втрачає бачення мети цієї події, часом усім нам потрібне нагадування. Можна попросити члена команди почати захід з оголошення його мети і очікуваних результатів. Періодично запитуйте, чи рухаємося ми в напрямку мети. Наприкінці події запитайте, чи всі згодні, що ми досягли мети. Також можете спитати, які перешкоди передбачають члени команди і з чим їм знадобиться допомога.
  • Скрам-майстер може допомогти команді ефективніше використовувати таймбокси. Якщо команда не встигає проговорити “як” у межах таймбоксу, розбийте його на два, щоб допомогти їм сфокусуватися на обох аспектах беклогу спринту. Метатися між “що” і “як” нормально, просто допоможіть команді збалансувати цей процес. Якщо команда закінчує планування спринту значно швидше, ніж збігає її час, але не обговорила “як” досить глибоко, використовуйте відкриті питання, щоб розвинути цю частину дискусії. На кшталт: “Це великий елемент. Як його розбити на дрібніші, які потім склеїмо в один?”, “Чи є у нас все потрібне, щоб вчасно зробити готовий інкремент і досягти мети спринту?”, “Які залежності визначатимуть, як ми робитимемо поставки до цілі спринту?”
  • Розділіть елементи беклогу продукту на задачі.  Часом команди обговорюють “як”, та не до кінця розуміють, про що говорять, аж до кінця планування спринту. Фасилітуючи подію, ви можете спробувати візуалізувати частину розмови на дошці. Спитайте: може, хтось може промальовувати те, що пояснює. Запропонуйте команді потім скористатися цими візуалами і розбити елементи беклогу продукту на задачі на скрам-дошці.

Усі ці навички роблять вас справді хорошим скрам-майстром. 

Навчитися цьому, як і багатьом цінним фасилітаціям, можна на поглибленому тренінгу PSM II

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

Джерело: scrum.org.