Що робити після ретроспективи: приклади конкретних дій

Дія після ретроспективи — це конкретна зміна, про яку домовилася команда: що спробуємо, хто допоможе довести це до результату й коли перевіримо, чи стало краще. Такі домовленості часто називають action items.

Наприклад, команда знову записала: «Треба краще описувати задачі». Минулого спринту розробник зробив обов’язковим поле, яке власник продукту вважав необов’язковим, а QA з’ясувала це вже під час перевірки. Саме побажання нічого не змінює в підготовці наступної задачі.

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

Нижче — вигадані навчальні ситуації, а не історії клієнтів Agilo. Кількість задач, строки та критерії перевірки потрібно підбирати під вашу роботу.

У статті

• Що саме варто записати
• Приклади для команди розробки
• Розбір домовленості про уточнення вимог
• Заготовка для наступної дії
• Як повернутися до результату
• Як зберегти контекст в Agilo

Що саме варто записати

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

1. Спостереження. Що сталося і як це завадило роботі? «Повернули дві задачі через різне розуміння обов’язкових полів» точніше за «в нас погані вимоги».
2. Зміну. Яку конкретну практику спробуємо і на якому обсязі роботи?
3. Відповідального. Хто погодився організувати наступний крок, залучити колег і повернутися з результатом?
4. Момент перевірки. Дата або подія: наприклад, наступне ретро чи завершення трьох погоджених задач.
5. Ознаки результату. Як зрозуміємо, що дію виконали, і за чим перевіримо, чи вона допомогла?

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

Почати з однієї-двох посильних змін — практичний варіант, а не обов’язкова норма Scrum. Scrum Guide пов’язує ретроспективу з підвищенням якості та ефективності й радить якнайшвидше братися за найважливіші покращення. Наведений тут спосіб запису — наша рекомендація для роботи з домовленостями.

Приклади для команди розробки

1. Уточнення з’являються вже після реалізації

Було: «Краще готувати задачі».

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

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

2. Запити підтримки губляться в особистих повідомленнях

Було: «Навести лад у підтримці».

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

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

3. Після передачі задачі колега відновлює контекст із чату

Було: «Нормально передавати задачі».

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

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

4. Спільне тестове середовище змінюється посеред перевірки

Було: «Зробити стабільний стенд».

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

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

5. Під час відпустки колеги команда не може оновити довідник

Було: «Прибрати залежність від однієї людини».

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

Що перевірити: наприкінці навчання перевірте, чи може Денис сам пояснити послідовність дій і виконати саме цю операцію за інструкцією. Один розібраний випадок не підтверджує, що команда вже опанувала всі сценарії.

Якщо спостереження ще не зібрані, шаблон What Went Well допоможе почати з того, що працює і що заважає. Формулювати наступну дію варто після обговорення конкретної ситуації.

Розбір домовленості про уточнення вимог

Повернімося до форми замовлення. Команда хоче раніше помічати розбіжності в очікуваннях. Для проби вона бере три наступні зміни форми й зберігає біля кожної приклади очікуваної поведінки та пізні уточнення.

Уявімо такий результат:

Олена підготувала приклади, колеги їх розглянули — дію виконано. Команда раніше узгодила частину умов, але все одно пропустила питання про права редагування. За трьома задачами не варто заявляти про доведене зниження кількості помилок.

На ретро можна вирішити: залишаємо спільний розбір прикладів, а для змін поведінки додаємо запитання «Хто й у якому стані замовлення може це зробити?». Наступного разу перевіряємо, чи воно допомогло. Це рішення спирається на конкретну прогалину; переписувати весь процес підготовки задач поки немає потреби.

Окремо запитайте колег, чи був розбір корисним і скільки часу забирав. Зміна має допомагати роботі, а її витрати теж потрібно бачити.

Заготовка для наступної дії

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

Що сталося і де збережено спостереження:
Яку зміну пробуємо:
На яких задачах або протягом якого часу:
Хто погодився відповідати за наступний крок:
Чия допомога, час або рішення потрібні:
Коли повертаємося до результату:
Що підтвердить виконання домовленості:
За чим побачимо користь і можливі незручності:
Після перевірки: залишаємо / змінюємо / припиняємо / збираємо ще дані

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

Як повернутися до результату

Домовтеся про перевірку ще на ретро. Якщо перешкода виникла раніше, обговоріть її під час роботи — немає потреби чекати наступної зустрічі, щоб попросити доступ або переглянути обсяг.

Під час перевірки корисно розділити три питання:

• Що зробили? Поверніться до початкової домовленості й наявних фактів.
• Що змінилося? Подивіться на користь, невирішену частину проблеми й додаткові витрати.
• Що вирішуємо далі? Залишити практику, змінити її, припинити чи поспостерігати ще.

Якщо дія залишилася невиконаною, з’ясуйте причину. Команда не виділила часу? Не отримала доступу? Відповідальний не міг вплинути на рішення? Після цього погодьте новий крок і умови його виконання. Просте перенесення на наступний спринт залишає ту саму перешкоду.

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

Повний порядок зустрічі — від підготовки до обговорення пріоритетів — є в гайді з проведення ретроспективи.

Поширені запитання

Що робити, якщо відповідальним записали всю команду?

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

А якщо рішення залежить від керівника чи іншої команди?

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

Чи можна зберігати такі дії у звичайному трекері задач?

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

Чи обов’язково доводити результат числом?

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

Як зберегти контекст в Agilo

В Agilo для ретроспектив наступна дія має назву й опис. Їй можна призначити відповідального, пріоритет і статус, а також пов’язати дію з початковою карткою. Момент перевірки й очікувані ознаки результату запишіть в описі, а висновок після спроби — у коментарі.

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

Створіть ретроспективу в Agilo і завершіть її однією конкретною домовленістю, на яку команда готова виділити час.