Синтез sprint retrospective

Агент превращает сырые заметки с retrospective в структурированные insights и следит за их судьбой между спринтами. Работает как второй участник встречи, который не забывает детали обсуждения и связывает текущий спринт с историей команды.

Что делает агент

1. Получает источник данных: транскрипт ретро, экспорт с Miro или Mural, заметки в Notion или Confluence, сообщения из канала Slack.
2. Разбирает обсуждение на четыре категории: wins (что сработало), pain points (что замедляло команду), action items (что решили делать), open questions (нерешённые темы).
3. Дедуплицирует формулировки с прошлыми ретро — если «медленный CI» обсуждался в sprint 4 и sprint 7, агент связывает записи, а не создаёт новые.
4. Создаёт задачи в issue tracker (Jira, Linear, YouTrack) для action items с контекстом из обсуждения и ссылкой на исходник.
5. Обновляет исторический лог в базе знаний: одна страница на спринт плюс агрегированный индекс тем.
6. Раз в 5-10 спринтов формирует pattern report — список тем, которые возвращаются без resolution, и action items, которые не сдвинулись со статуса open.

Что получает команда

• История ретроспектив доступна в поиске, а не только в памяти участников.
• Action items трекаются как обычные задачи, не остаются в заметках встречи.
• Видны повторяющиеся паттерны, которые теряются при взгляде на один спринт.

Что агент не делает

• Не проводит ретро вместо facilitator и не заменяет живое обсуждение в команде.
• Не принимает решения об организационных изменениях — решения остаются за PM, scrum-master и командой.
• Не интерпретирует эмоции и межличностные конфликты — только фиксирует то, что было сказано в структурированной форме.

Техническая схема сводит три слоя: источник заметок с ретро, LLM-пайплайн для структурирования и две точки записи — issue tracker для action items и knowledge base для истории. Агент работает в push-модели: запускается после окончания ретро, а не опрашивает системы постоянно.

Поток данных

1. Триггер. Календарное событие Sprint Retrospective завершилось, или scrum-master вручную загрузил заметки. В low-code варианте триггер собирает workflow-движок или Zapier.
2. Сбор источника. Агент получает транскрипт из Fireflies или Otter, экспорт с Miro или Mural либо текст из Notion/Confluence — в зависимости от того, как команда ведёт ретро.
3. LLM-обработка. AI-модель разбирает текст по схеме: wins, pain points, action items, open questions. Каждая запись получает owner (если упомянут), severity и ссылку на исходник.
4. Проверка дублей. Перед записью агент делает семантический поиск по историческому логу — если похожий pain point уже фиксировался, новая запись линкуется к предыдущей, а не дублирует её.
5. Запись. Action items уходят в issue tracker (Jira, Linear, YouTrack) со статусом retro-open. Wins и pain points сохраняются в базу знаний — одна страница на спринт плюс агрегированный индекс тем.
6. Периодическая агрегация. Раз в 5-10 спринтов запускается отдельный job, который строит pattern report: темы без resolution, action items в статусе open дольше N спринтов, частота упоминаний по категориям.

Компоненты

Шаги внедрения

1. Выбрать источник заметок. Зафиксировать один формат: транскрипт из транскрайбера или шаблон в Notion/Confluence. Без единого формата агент будет ломаться на каждом ретро.
2. Подготовить хранилище. Создать раздел в базе знаний для sprint-ретро и завести в issue tracker отдельный label или project для retro-action items.
3. Собрать LLM-пайплайн. Описать схему выходных данных (JSON), написать промпт, добавить валидацию — агент возвращает JSON с обязательными полями или ничего.
4. Подключить issue tracker. Настроить создание задач через API: title из краткой формулировки, description с контекстом, assignee если упомянут, label retro.
5. Включить дедупликацию. Перед записью pain point агент ищет похожие в логе за последние N спринтов и линкует, а не дублирует.
6. Запустить pattern report. Отдельный job раз в 5-10 спринтов формирует сводку и кладёт её в knowledge base и канал команды.

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

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

Данные и доступы

• Формат ретроспективы с voice или text записью: транскрипт из Fireflies/Otter, экспорт с Miro/Mural или шаблон в Notion/Confluence.
• API-доступ к issue tracker (Jira, Linear, YouTrack) с правами на создание задач и работу с labels.
• API-доступ к knowledge base (Notion, Confluence) с правами на запись страниц.
• API-ключ LLM-провайдера (Anthropic для LLM).

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

• Регулярная retrospective на спринт — минимум 5-10 спринтов в год, иначе pattern detection не накапливает данные.
• Договорённость о едином формате заметок. Если половина команд ведёт ретро в Miro, а половина — в Slack-треде, агенту нужно два пайплайна.
• Владелец процесса: scrum-master или PM, который отвечает за загрузку и проверку результата после каждого ретро.

Команда внедрения

• Разработчик с опытом low-code (workflow-движок, Zapier) или Python для LLM-пайплайна.
• Scrum-master или PM как product owner автоматизации — отвечает за схему данных и валидацию insights.

Таймлайн

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