Це переклад статті Ешлі-Христиан Харді. Оригінал статті Sprint Planning: Remember it’s a Sprint, not a Marathon ви можете знайти за цим посиланням.
Переклад статті російською можна прочитати за цим посиланнням.
Що таке планування спринту?
Планування спринту – це обмежена у часі зустріч на початку спринту, на якій Команда та Власник Продукту (ВП) обговорюють та приймають рішення про те, яка робота буде завершена у спринті.
Як правило, зустріч поділяється на дві частини: "Що?" і "Як?".
Що?
Власник продукту приносить із собою список пріоритетних історій користувачів на зустріч. В ідеальному випадку, продуктивність команди відома, тому ВП добре усвідомлює, скільки роботи увійде в cпринт. Йде командне обговорення та розбивка історій, а потім команда домовляється та визначає роботу, яка буде завершена у спринті.
Як?
Команда обговорює узгоджену роботу та план її завершення.
Історії користувачів розбиваються на задачі, уточнюються технічні деталі.
Якщо команда практикує регулярні зустрічі з уточнення беклога продукту, вона вже має уявлення, про що йдеться в історії.
Як це виглядає?
Поширені проблеми:
Власник продукту сам визначає та вирішує, яка робота буде завершена
Беклог продукту не актуальний, не пріоритезований чи не готовий до обговорення
Наприкінці планування все надто деталізовано, і вся робота вже розподілена серед виконавців (цю проблему важко подолати)
Ніхто не розуміє, що означає статус "Готово"
Зустріч надто довга
Зустріч не залучає учасників до процесу
Деяким людям складно показати себе
Невідповідне середовище команда не відчуває підтримки або безпеки
Немає довіри чи поваги з обох сторін
Команда не розуміє, навіщо потрібна ця зустріч
Перед плануванням спринту
Чек-лист для підготовки до успішного планування:
Мотивована команда.
Хороший контакт та довіра між ВП та командою.
Якщо ВП не довіряє висновкам команди, на зустрічі учасники швидко почнуть уникати обговорення, а не знаходити шляхи вирішення. Команді важливо бачити цінність зустрічі та переваги планування. Якщо є якісь сумніви – процес провалиться.
Зустріч відбувається у встановлений час.
Вона не повинна бути надто довгою та стомлюючою, бо тоді втрачається цінність.
Проведено підготовчу роботу, часто у форматі зустрічей з уточнення беклогу.
ВП гарантує, що існує здоровий, пріоритезований беклог, який наразі обговорюється який підтримується.
Історії у верхній частині беклогу, які повинні входити до наступного спринту, розбиті на невеликі частини, щоб команда могла їх обговорити та запланувати.
Скрам-майстер переконався, що усі члени команди беруть участь: Власник продукту, Скрам-майстер, розробники, тестувальники, адміністратор бази даних – кожен, хто є частиною команди розробників. Інші зацікавлені сторони можуть бути присутніми лише як спостерігачі, які не переривають процес.
Кожен учасник повинен відчувати свою цінність на зустрічі, мати можливість поділитись своїм баченням.
Рішення про роботу приймаються командно.
Якщо ВП приймає всі рішення щодо роботи та її виконання, команда відчуватиме, що це марна трата часу.
Консенсус щодо методу оцінки та розбивки роботи. Story Points або Planning Poker - команді потрібно домовитись про метод оцінки, щоб працювати узгоджено.
Тривалість
Тривалість зустрічі залежить від довжини спринту, чим довше спринт, тим більше часу потрібно його планування.
Для орієнтиру:
Однотижневий спринт - 2 години
Двотижневий спринт - 4 години
Спринт довжиною 1 місяць - 8 годин
Тривалість також дуже залежить від зрілості та ефективності команди та Власника продукту, від обсягу попередньої підготовки.
Цілі
Завдання зустрічі – сформулювати ціль спринту. Її можна уявити у формі беклога спринту. Беклог спринту – список пріоритезованих завдань, які команда зобов’язується завершити до кінця спринту. Тут важливо пам'ятати про командні критерії готовності (Definition of Done).
Якщо ви уявили собі кінцевий результат спринту – погодьте його з Власником продукту, і ваш шлях стане набагато простішим. Команду дуже мотивує візуалізація та уявлення подумки цього результату.
Один із ключових принципів гнучкості – здатність приймати зміни. Зрозуміло, що найменше інформації ми маємо на початку проєкту, під час роботи часто трапляються несподівані речі. Тому дозвольте беклогу змінюватись у процесі та будьте готові уточнювати його при необхідності.
Структура зустрічі
Структура зустрічі необхідна у вигляді попереднього високорівневого плану. Приклад: розповідь Власника продукту, команда обговорює задачі, сесія питань та відповідей із ВП, беклог спринту уточнено, ретроспектива та зустріч закриті. Ця структура має бути незмінною для кожної зустрічі, вона допоможе команді увійти в хороший режим та отримати від неї максимальну віддачу.
Продуктивність команди:
- Достатньо взяти середнє останніх 3 спринтів, як керівництво.
- Обговоріть години, коли команда готова працювати, відпустки, режим роботи членів команди.
- Пам'ятайте, що спринти не бувають однаковими!
- Не намагайтеся бути дуже детальними - це марна трата часу, адже кількість невідомих занадто велика.
- Команда все одно узгоджує обсяг роботи.
- Залишіть деякий час для вирішення поки невідомих питань та проблем.- Так команда отримає більше свободи дії.
- Простіше додати роботу в спринт, якщо у вас добре опрацьований беклог, ніж прибрати її.
Співпрацюйте, разом плануйте роботу над історіями користувача, не оцінюйте обсяг ресурсів, не намагайтеся занадто оптимізувати або мікроменеджити кожного. Продукти має робити команда, а не група людей, які працюють над своїми задачами.
Розбивка задач
Визначте критерії готовності (DoD). Це усуває конфлікти та дає прозорість процесу. "Готово" має означати потенційне постачання продукту.
Обговоріть всі задачі, щоб отримати уявлення про роботу та її виконання: створення скриптів, рефакторинг, інтеграція коду, тестування та автоматизація, виправлення багів, технічне обслуговування.
Надто не прив'язуйтеся до процесу оцінки, це лише припущення, а не зобов'язання.
Часта помилка на цьому етапі - ходити по колу.
Не притягуйте окремих членів команди до відповідальності за оцінку. Команда не має боятися оцінювати.
Не варто порівнювати відносні оцінки із фактично витраченим часом (якщо немає істотних відмінностей, але тоді це потрібно винести на командну ретроспективу).
Уся команда володіє беклогом спринту, тому не закріплюйте задачі за виконавцями. З досвіду, я знаю, що якщо це відбувається, тоді одні й ті ж люди постійно отримують одну й ту саму роботу. Це погано, тому що тоді ви розвиваєте «фахівців» у своїй команді, а обмін знаннями та розвиток стають обмеженими. Цілком нормально мати фахівців, поки вони обмінюються знаннями з командою, але немає нічого гіршого, ніж одна людина, яка несе знання та відповідальність за конкретну частину коду, а потім вона йде - і забирає ці знання із собою.
Цілі спринту досягає вся команда. Оскільки у вас є список пріоритетів, якщо одна задача виконана, член команди може запропонувати допомогу іншим, якщо потрібно; або перейти до наступної, за пріоритетом, задачі.
Використовуйте Story Points як спосіб відносної оцінки. Тут ви порівнюєте задачі за складністю, а не за часом. Розробнику простіше сказати "ця задача в 3 рази складніше, ніж та", а не "ця задача займе у мене близько 4 днів". Не плутайте Story Points з годинником, тоді люди просто намагаються конвертувати Story Points у час, а потім Story Points взагалі втрачають свою цінність.
Узгоджуйте розміри ваших задач. Хороші задачі, які займають трохи більше одного дня; їх переваги:
розробникам простіше планувати робочий день,
підвищується ефективність, якщо задачу можна розпочати й завершити того ж дня,
невеликі задачі дають повніше уявлення про обсяг роботи,
можна скоротити “вузькі місця” процесу,
атомарні задачі можна було виконувати паралельно. Задачі, що залежать одна від одної, - викликатимуть проблеми та провокуватимуть “вузькі місця” .
Створюйте ті задачі, які вимагають виконання; розробка, тестування, документація, демо тощо… Не закріплюйте до них роботу Власника продукту чи командні зустрічі.
Якщо ви не впевнені у завданні, створіть додаткову “дослідницьку” задачу. Вона необхідна для проведення дослідження та роз’яснення.
Не плануйте 8-годинний робочий день, навіть якщо команду наймають на цей час. Насправді команда не працює 8 годин поспіль. «Ефективність» гарної здорової команди – близько 70% робочого часу, тому я планував 6:00 на день, адже протягом дня відбувається багато всього: зустрічі, обідня перерва, з'ясування деталей з ВП, короткі перерви.
Робоче середовище
Середовище
Команді важливо почуватися в безпеці, розуміти, що нормально не знати всього зараз. Agile весь складається з адаптації, підлаштовування та навчання. Має бути відчуття співпраці, підтримки, зацікавленості та драйву. Команда не повинна боятися ставити запитання, висловлюватися. Команді важливо відчувати впевненість у тому, яких результатів вони справді можуть досягнути та які взяти на себе зобов'язання; і якщо вони мають якісь сумніви чи у них виникають ризики, поставтеся до них серйозно. Дуже важливо, що останнє слово стосовно цих результатів залишається за командою, а не за Власником продукту.
Автономія команди
Я великий прихильник самоорганізованих автономних команд. Не тому що я лінивий .... А тому що я бачив результати їхньої роботи. Автономні команди ефективні, тому що вони володіють продуктом від початку до кінця, вони незалежно ухвалюють рішення і це сприяє зростанню та мотивації всіх учасників.
Як Скрам-майстер, ви повинні дозволити команді ставити власні цілі, коучити та вчити команду, як взяти на себе відповідальність, допомогти їм привласнити план та беклог спринту. У жодному разі не стримуйте команду, допоможіть їм дивуватися та винаходити, щоб перевершити самих себе. Дозвольте їм думати та нехай у кімнаті іноді панує тиша.
Активне слухання
На початку зустрічі особливо важливо залучити команду до розповіді ВП, коли він пояснює та розповідає про пріоритети. Добре, якщо команда активно слухає та ставить запитання на цьому етапі.
Взаємоповага
Я говорив про важливість довіри, але повага не менш важлива. Я згадував, що Власник продукту повинен мати довіру в команді, і важливо, щоб вона була взаємною. Команда має поважати ВП та довіряти рішенням, які він приймає. Це та людина, яка пріоритезує їхню роботу, їм важливо знати, що їхня робота має цінність і добре продумана.ВП відповідає за «чому» і команда має дозволити йому зосередитися на цьому. ВП відповідає за управління зацікавленими сторонами та є представником голосу бізнесу.Команда відповідальна за «як», ВП слухає і, можливо, ділиться думкою, але аж ніяк не диктує команді, як виконувати задачі, це їхня робота і вони в цьому профі. З обох сторін потрібна взаємоповага та чітке визначення ролей для кожного.
Питання
Не заспокоюйтесь, якщо команда не ставить жодних питань. Якщо питань немає, то, здається, є повне розуміння, але таке буває вкрай рідко. Ви можете домовитися, що кожен має поставити хоча б одне запитання. Зазвичай, коли виникає одне питання, за ним з'являються й інші.
Процес
Якщо ви використовуєте фізичну Kanban дошку, запропонуйте команді самостійно виписати свої стікери, повісити їх на дошку та розставити пріоритети, знову ж таки, це хороший спосіб розвивати самоорганізацію. Використовуйте час зустрічі для оновлення свого інструменту, будь то фізична Kanban дошка, Jira або TFS. По-перше, кожен зможе побачити план, погодитися на нього та розпочати роботу. По-друге, добре, коли кожен розуміє процес. Тоді, якщо Скрам-майстер захворів, то члену команди легко підмінити його.
Завершення зустрічі
Планування спринту обмежене у часі, закінчуйте його вчасно. Навіть якщо фактично планування ще не закінчено, важливо розпочати роботу, продовження зустрічі не допоможе завершити історії користувачів. Цілком нормально не знати всіх деталей, це розвиває гнучкість!
Іноді команді необхідна сміливість сказати «Ок, цього достатньо, ми не знаємо всіх деталей, але вивчатимемо решту і підлаштуємося під час роботи». Бути гнучким - значить експериментувати, винаходити та старт роботи дає команді шанс зробити це!
Наприкінці зустрічі знайдіть кілька хвилин, щоб знову подумати про те, що вийшло добре, чого не було в попередньому спринті й переконайтеся, що й надалі будете використовувати дієві підходи, із собою, а неефективні більше не будете використовувати. Це дозволяє останній раз кинути оком на заплановану роботу та розпочати свою подорож.
Comments