Рус Укр
Ретроспектива спринту в Scrum

Ретроспектива спринту в Scrum

  • 14 грудня, 2020
  • читати 15 хв
Павло Морозов
Павло Морозов Scrum мастер в Hyperion Tech

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

Не подумайте, що дана стаття буде про винахід лампочки. Йтиметься про Scrum, а точніше про один з подій Scrum — ретроспективу спринту.

Я хотів підкреслити, наскільки важливо в будь-якій справі вдосконалюватися, розвиватися і застосовувати нові підходи. В цьому і полягає суть ретроспективи спринту, так як дана подія, згідно Scrum Guide, переслідує дві мети:

  1. провести інспекцію минулого спринту стосовно людей, відносин, процесів і інструментів
  2. створити план по впровадженню цих поліпшень в процес роботи команди

Під час ретроспективи команді необхідно виявити і обговорити:

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

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

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

У ретро бере участь вся Scrum команда — команда розробки, Product Owner і Scrum майстер.

  • Команда розробки займається створенням продукту, і тільки їй належить беклог спринту — перелік задач, які команда бере в спринт
  • Product Owner відповідає за досягнення максимальної цінності продукту і це — єдина людина, яка несе відповідальність за беклог продукту — перелік завдань з вимогами до продукту
  • Scrum майстер несе відповідальність за просування і підтримку Scrum відповідно до керівництва по системі

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

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

Спільними є:

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

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

  3. І модератор, і фасилітатор не повинні впливати на кінцевий продукт обговорення і нав'язувати свою думку

На перший погляд ці поняття ідентичні, але все-таки між ними існують невеликі відмінності.
Модератор стримує групу в рамках і не дає дискусії втратити суть, а фасилітатор дає більше свободи дій команді, сприяючи її груповій роботі. Модератор системно і структуровано веде групу до бажаного результату. Фасилітатор допомагає групі прийти до результату, спираючись на власний досвід учасників, підбиваючи учасників дискусії до важливих, але неочевидних рішеннях. Для Scrum майстра при проведенні ретро важливо знайти золоту середину — сприяти групою роботі команді і не дати команді вийти за рамки дискусії.
Щоб ретроспективи були корисні і цікаві, Scrum майстру необхідно до них ретельно готуватися. Для підготовки до проведення ретро Scrum майстру необхідно мати свій чек лист, який допоможе не забути і не упустити важливі моменти. Нижче представлений приклад такого чек листа:

Check list

  1. Яка тривалість ретроспективи? Scrum майстер стежить за лімітом часу, щоб ретро було не надто затягнутим.
  2. Де можна знайти результати минулого ретроспективи? Вони повинні десь фіксуватися, щоб Scrum майстер міг перевірити їх разом з командою.
  3. Чи врахований зворотний зв'язок щодо поліпшення ретроспектив? Важливо отримувати фідбек від команди про те, як пройшла ретроспектива.
  4. Які завдання Scrum майстер повинен був виконати за результатами минулого ретро? Якщо майстер обіцяв щось зробити, то необхідно розповісти про статус цих завдань.
  5. Які істотні події були протягом спринту? Якщо були якісь дуже важливі події, то важливо сфокусуватися на них в першу чергу.
  6. Чи існує важлива тема, яку варто було б приділити достатньо часу протягом ретро? Можливо, команда планує використовувати нові технології для свого продукту, в такому випадку необхідно врахувати всі ризики і продумати подальші кроки.
  7. Яку інформацію необхідно підготувати для проведення ретро? Наприклад, якщо Scrum майстер буде застосовувати нові техніки, то важливо продумати, що він буде візуалізувати і показувати.
  8. Які канцтовари необхідно взяти на ретроспективу? Необхідно врахувати, які канцтовари можуть знадобитися під час ретро (стікери, ручки, маркери, папір, скотч, фотки і т.д.)

Рекомендуємо курс по темі

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

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

Етапи ретроспективи

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

Отже, про етапи. Спринт ретроспективу подумки можна розбити на 5 етапів:

  1. Підготовка. На цьому етапі потрібно розворушити команду і підготувати її для подальшої дискусії

  2. Збір даних. Команда збирає інформацію про те, що пройшло добре в спринті, а де є проблеми

  3. Генерація ідей. Учасники накидають свої ідеї про те, як можна усунути проблеми і поліпшити командні дії

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

  5. Завершення. В кінці зустрічі підводяться підсумки

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

Будемо йти по порядку і розпочнемо з етапу «Підготовка», її можна провести наступним чином:

  1. Location. Для проведення даної вправи знадобиться якийсь предмет, наприклад стілець. Scrum майстер ставить стілець в центрі кімнати і попросить команду уявити, що цей стілець — це мета спринту. Після цього він кожен учасник розташовується по відношенні до стільця на близькій відстані, якщо людина вважає, що мета виконана, і на далекому, якщо вона не виконана. Після цього можна попросити кожного прокоментувати своє розташування. Варто зазначити, що питання команді можуть бути найрізноманітніші.
  2. Гра в асоціації. Scrum Майстер просить команду описати минулий спринт одним словом. Можна запропонувати порівняти його з погодою або машиною. За емоціям учасників зустрічі і по їх асоціаціям буде зрозуміло, наскільки спринт був вдалим. Наприклад, хтось скаже, що спринт нагадує стару дев'ятку, у якій двері відвалилася в середині спринту, але потім вдалося її прикрутити. Потім ця інформація буде детально розглянута учасниками на наступних етапах, а саме, чому це сталося і що зробити, щоб такого не було в майбутньому.
  3. Mad, Sad, Glad. Ці три слова необхідно написати на фліпчарті або борді, і команда по колу ділиться своїми почуттями, які відповідають цим словам. Краще не використовувати цю вправу часто, так як можна виплеснути багато негативних емоцій.

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

  1. Proud, thank you, learned. Дуже хороша вправа, яку слід проводити частіше. Необхідно розділити дошку на 3 частини і написати: Proud, thank you, learned. Після чого Scrum майстер просить команду написати на стікерах відповіді на такі питання: «Чим кожен член команди пишається?», «Кого хоче подякувати?», «Чому навчився за минулий спринт?», учасники клеять наклейку на одну з 3-х частин, якій відповідає стікер, і коментують написане.
  2. Timeline. Ця діяльність допоможе відновити в пам'яті події спринту. Необхідно намалювати тимчасову лінію на борді, кожен учасник відновлює в пам'яті всі важливі події, записує подію на стікері і клеїть його на лінію, коротко розповідаючи про неї. Коли команда відтворить всю картину спринту, то у неї з'явиться хороший набір даних перед наступним етапом — «Генерація ідей».
  3. Перевірка ДЗ. Назва цієї техніки говорить сама за себе. Всі пункти, які команда узгодила до виконання минулої ретроспективи, необхідно перевірити. Які з пунктів виконані або застосовуються? А які ще належить застосувати в майбутньому? Для фіксації результатів ретроспективи підійде будь-який зручний для вас інструмент.

Після того, як всі дані зібрані, можна перейти до етапу «Генерація ідей».

На цьому етапі можна застосовувати такі техніки:

  1. Continue, Start, Stop. Необхідно розділити борд на 3 частини. У кожній частині пишемо одне з 3-х слів — Продовжувати, Почати, Припинити. Учасники пишуть, що команді варто продовжувати робити, що варто почати робити, а що взагалі варто перестати робити. Одна ідея — один стікер. Кожен учасник клеїть свій стікер на відповідну частину дошки і коментує свої ідеї. Можна об'єднати схожі ідеї в кластери. Коли у команди буде кілька ідей, учасники зустрічі можуть проголосувати, які з них найбільш важливі і вимагають негайного виконання. Дану техніку Scrum майстер може видозмінювати, помінявши три слова. Наприклад він може написати — «Більше, Менше, Перестати» або «Перестати, Почати, Спробувати».
  2. Brainstorm. Для цієї активності знадобиться звичайний аркуш паперу і ручки для всіх членів команди. Кожен по черзі пише одну свою ідею щодо поліпшення роботи команди і передає лист сусідові по колу. Лист передається до тих пір, поки у команди не вичерпаються ідеї або вийде встановлений час. Після того, як всі ідеї записані, їх озвучують всій команді.
  3. Sailboat. Scrum майстер малює човен і просить уявити учасників зустрічі, що це їх команда. Потім він малює якоря і пояснює команді, що це те, що тягне її вниз. Потім він зображує вітрила — то, що штовхає команду вперед. Також можна намалювати скелі і рифи (ризики) або горизонт (наші надії). Кожен член команди заповнює малюнок стікерами, після чого команда обговорює всі викладені думки і фіксує свої ідеї про поліпшення робочого процесу. Дану техніку можна трохи змінити і провести в іншому вигляді. Замість парусника можна використовувати повітряну кулю або гоночний болід з перешкодами. Варто зазначити, що цю активність можна вже застосовувати на попередньому етапі, тому що ця вправа включає частину дій зі збору даних командою.

Отже, команда озвучила всі свої думки і ідеї. Тепер прийшов час для етапу «Планування рішень». Давайте розглянемо техніки, які нам можуть допомогти в цьому:

  1. Dot voting. Якщо команда озвучила багато ідей, то необхідно вибрати найбільш актуальні і важливі з них, так як неможливо вирішити всі проблеми відразу. Для цього Scrum майстер просить уявити, що у кожного члена команди є 3 уявні точки, ними необхідно проголосувати за три найбільш важливі ідеї. Ідеї, які зберуть найбільшу кількість голосів будуть переведені в статус «Action Points» і повинні бути виконані в майбутньому.

  2. Дебати. Після проставлення пріоритетів можна розбити команду на частини і обговорити ідеї в невеликих групах. Це варто робити тільки тоді, коли у вас досить багато учасників дискусії, або частина команди знаходиться в іншому офісі, і проводяться кілька ретроспектив. Після обговорення учасники зустрічі діляться своїми думками. Також можна попросити команду влаштувати дебати між групами, в результаті яких повинні бути узгоджені спільні спільні рішення.

  3. Top list. Дану вправа також варто використовувати після визначення пріоритетності ідей команди. Потрібно взяти найбільш актуальні теми і обговорити кожну ідею послідовно.

На останньому завершальному етапі ретроспективи спринту важливо підвести підсумки даної події. Повинні бути сформовані Action Points — це ті пункти, які команда домовилася застосувати у своїй роботі для досягнення прогресу. Команда після ретро повинна залишитися натхненною і мотивованою, щоб продовжувати впроваджувати поліпшення.

На завершальному етапі можна також провести так звану «Ретроспективу ретроспективи», тобто отримати зворотній зв'язок Scrum майстром від решти команди. Для цього можна попросити учасників зустрічі написати на стікерах їх відгуки про ретроспективу з їх пропозиціями. Scrum майстер буде враховувати цю інформацію при проведенні майбутніх ретроспектив. Замість відгуків на стікерах, Scrum майстер може також отримати фідбек від команди за допомогою анкетування.
Ретроспектива спринту — важлива подія Scrum, під час якого команда оцінює себе і свою роботу, а також складає план щодо поліпшення своєї діяльності. Але важливо не тільки скласти план, а й дотримуватися даного плану між ретроспективами. Тому приділяйте особливу увагу подальшій роботі з Action Points, застосовуйте нові підходи, практики, технології, усувайте перешкоди, покращуйте організацію роботи команди — адже від цього залежить ефективність команди, якість і успіх проекту.