Синтез sprint retrospective

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

Що робить агент

1. Отримує джерело даних: транскрипт ретро, експорт з Miro або Mural, нотатки в Notion або Confluence, повідомлення з каналу Slack.
2. Розбирає обговорення на чотири категорії: здобутки (що спрацювало), проблемні точки (що сповільнювало команду), завдання (що вирішили робити), відкриті питання (невирішені теми).
3. Дедуплікує формулювання з минулими ретро — якщо «повільний CI» обговорювався в sprint 4 і sprint 7, агент пов'язує записи, а не створює нові.
4. Створює завдання в трекері задач (Jira, Linear, YouTrack) для завдань з контекстом з обговорення і посиланням на джерело.
5. Оновлює історичний лог у базі знань: одна сторінка на спринт плюс агрегований індекс тем.
6. Раз на 5-10 спринтів формує звіт про патерни — список тем, які повертаються без вирішення, і завдання, які не зрушили зі статусу відкритий.

Що отримує команда

• Історія ретроспектив доступна в пошуку, а не тільки в пам'яті учасників.
• Пункти дій трекаються як звичайні завдання, не залишаються в нотатках зустрічі.
• Видно повторювані паттерни, які губляться при погляді на один спринт.

Що агент не робить

• Не проводить ретро замість фасилітатора і не замінює живе обговорення в команді.
• Не приймає рішення про організаційні зміни — рішення залишаються за PM, scrum-master і командою.
• Не інтерпретує емоції та міжособистісні конфлікти — лише фіксує те, що було сказано у структурованій формі.

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

Потік даних

1. Тригер. Календарна подія Sprint Retrospective завершилась, або scrum-master вручну завантажив нотатки. У low-code варіанті тригер збирає рушій робочих процесів або Zapier.
2. Збір джерела. Агент отримує транскрипт із Fireflies або Otter, експорт з Miro або Mural або текст із Notion/Confluence — залежно від того, як команда веде ретро.
3. LLM-обробка. AI-модель розбирає текст за схемою: здобутки, проблемні точки, завдання, відкриті питання. Кожен запис отримує відповідального (якщо згаданий), рівень критичності і посилання на першоджерело.
4. Перевірка дублів. Перед записом агент виконує семантичний пошук по історичному логу — якщо схожу больову точку вже фіксували, новий запис лінкується до попереднього, а не дублює його.
5. Запис. Пункти дій надходять до трекера задач (Jira, Linear, YouTrack) зі статусом retro-open. Здобутки і проблемні точки зберігаються в базу знань — одна сторінка на спринт плюс агрегований індекс тем.
6. Періодична агрегація. Раз на 5-10 спринтів запускається окреме завдання, яке будує звіт про патерни: теми без вирішення, завдання зі статусом відкритий довше N спринтів, частота згадувань за категоріями.

Компоненти

Кроки впровадження

1. Вибрати джерело нотаток. Зафіксувати один формат: транскрипт із транскрайбера або шаблон у Notion/Confluence. Без єдиного формату агент буде ламатися на кожному ретро.
2. Підготувати сховище. Створити розділ у базі знань для sprint-ретро та завести в трекері задач окрему мітку або проєкт для retro-action items.
3. Зібрати LLM-пайплайн. Описати схему вихідних даних (JSON), написати промпт, додати валідацію — агент повертає JSON з обов'язковими полями або нічого.
4. Підключити трекер задач. Налаштувати створення задач через API: назва з короткого формулювання, опис з контекстом, виконавець якщо згаданий, мітка retro.
5. Увімкнути дедуплікацію. Перед записом больової точки агент шукає схожі в логу за останні N спринтів і лінкує, а не дублює.
6. Запустити звіт про патерни. Окреме завдання раз на 5-10 спринтів формує зведення і кладе його в базу знань і канал команди.

Low-code реалізація на рушії робочих процесів плюс мовна модель закривається за 2-4 тижні силами одного розробника. Критичні частини — схема вхідних даних і дедуплікація; решта — стандартні інтеграції.

Автоматизація розрахована на команди зі стабільним sprint-ритмом і мінімальною цифровою інфраструктурою для колаборації. Основні вимоги розподіляються на дані, процес і команду.

Дані та доступи

• Формат ретроспективи з голосовим або текстовим записом: транскрипт із Fireflies/Otter, експорт із Miro/Mural або шаблон у Notion/Confluence.
• API-доступ до трекера задач (Jira, Linear, YouTrack) з правами на створення задач і роботу з мітками.
• API-доступ до бази знань (Notion, Confluence) з правами на запис сторінок.
• API-ключ LLM-провайдера (Anthropic для LLM).

Процес команди

• Регулярна retrospective на спринт — мінімум 5-10 спринтів на рік, інакше виявлення патернів не накопичує дані.
• Домовленість про єдиний формат нотаток. Якщо половина команд веде ретро в Miro, а половина — у Slack-треді, агенту потрібно два пайплайни.
• Власник процесу: scrum-master або PM, який відповідає за завантаження і перевірку результату після кожного ретро.

Команда впровадження

• Розробник із досвідом low-code (рушій робочих процесів, Zapier) або Python для LLM-пайплайну.
• Scrum-master або PM як власник автоматизації — відповідає за схему даних і валідацію висновків.

Таймлайн

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