Lab 1

[the-homeless-god]

• напишите критерии приемки US
• сформулируете DoR
• сформулируете DoD

[the-homeless-god]

ex

US3: Я как инвестор хочу видеть дашборд статистики использовании ИИ
в IDE с ежемесячной выгрузкой

DoR:

• - Известны логины инвестеров в системе чтобы им можно было отобразить данные
• - Есть шаблон текста письма
• - Уточнены необходимости отправки по выходным

DoD:

• - Инвесторы получили ссылку на дашборд
• - У инвестеров есть доступ на дашборд
• - Провели пилот на 1 инвесторе в рамках статистики выгрузки
• - В дашборде показываются все секции токеномики использования ИИ
• - Протестирована ежемесячная отправка
• - В конфигурации есть возможность указывать timebox отправки уведомлений

[the-homeless-god]

AC:

Acceptance Criteria:

• - В дашборде присутствуют исторические данные
• использования ИИ по пользователям
• - Рассылка не приходит по праздникам
• - В конце года приходит еще дополнительная рассылка за год
• - Пользователи без роли инвестор не имеют доступа к дашборду
• - В токеномике отсутствуют Pii
• - В дашборде логины пользователей отображаются uuid-ом
• - Выгрузка соответствует приложенному файл Excel

[the-homeless-god]

[N-N0th1n9]

Команда (4/42):
Цыганов Влад
Ячейка общества Беловых (Степан, Мария)
Канашин Дмитрий

US1.1: Я как наниматель Могу нажать кнопку “Создать чат”, которая создаст GoogleDocs и скинет на него ссылку.

DoR:

• Определено точное расположение кнопки «Создать чат» в UI
• Согласован формат имени создаваемого Google Docs документа
• Определены права доступа к документу (Viewer / Commenter / Editor) для участников чата
• Уточнено, в какой папке Google Drive создается документ
• Описаны требования к логированию и мониторингу

DoD:

• Кнопка «Создать чат» реализована в UI и доступна согласно требованиям
• При создании чата автоматически создается документ через API Google Docs
• Документ создается в формате .docx с корректным именем
• Документ размещается в нужной папке Google Drive с заданными правами доступа
• Ссылка на документ сохраняется и доступна для дальнейшего использования (в БД)

Критерии приемки:

• Пользователь может нажать кнопку «Создать чат» и инициировать процесс
• После создания чата автоматически создается Google Docs документ
• Документ создается в правильной папке и с корректным именем
• Участники чата получают доступ к документу согласно настройкам прав
• Ссылка на созданный документ автоматически отправляется в чат и отображается в UI

US2.1 Я как пользователь ожидаю что при открытии IDE отображается ссылка на Wiki -страницу

DoR:

• Уточнены условия открытия
• Согласован способ отображения (внешняя вкладка)
• Описаны базовые сценарии ошибок

DoD:

• При открытии IDE инициируется загрузка Wiki-страницы
• Wiki корректно отображается в интерфейсе IDE
• Реализовано логирование загрузок

Критерии приемки:

• При запуске IDE автоматически открывается заданная Wiki-страница
• Страница отображается корректно без UI-ошибок
• Загружается правильная страница в зависимости от контекста
• При ошибке загрузки пользователь видит понятное сообщение
• Пользователь может продолжить работу независимо от состояния Wiki

US2.2 Я как пользователь хочу иметь в Wiki страницу с FAQ

DoR:

• Определено расположение Wiki и URL FAQ-страницы
• Согласована структура FAQ
• Определен владелец контента (кто поддерживает актуальность)
• Определены права доступа (чтение/редактирование)
• Описан способ навигации к FAQ

DoD:

• FAQ-страница создана и доступна по URL
• Контент корректно отображается (верстка, ссылки)
• Настроены права доступа согласно требованиям
• Реализована навигация к FAQ из системы

Критерии приемки:

• В Wiki существует отдельная страница FAQ
• Страница доступна по ссылке пользователям
• FAQ содержит структурированный список вопросов и ответов
• Контент отображается без ошибок
• Пользователь может перейти к FAQ через интерфейс

US3.1.1 Я как инвестор хочу получать на почту статистику использовании ИИ в конце каждого рабочего дня в формате Excel

DoR:

• Согласована структура Excel-отчета
• Определен источник данных и правила агрегации
• Согласован шаблон письма (тема и содержимое)

DoD:

• Реализована генерация Excel-файла
• Реализована отправка email с вложением
• Отправка выполняется только в рабочие дни
• Реализована обработка ошибок и логирование
• Данные в отчете валидированы и соответствуют источнику

Критерии приемки:

• Инвестор получает письмо с Excel-файлом в конце рабочего дня
• Письмо не отправляется в выходные и праздники
• Excel-файл открывается без ошибок
• Данные в отчете соответствуют фактической статистике
• При ошибке отправки выполняется retry или логируется ошибка

US3.1.2 Я как разработчик хочу скачивать excel отчет по использованию ИИ из ollama dashboard и отправлять ero по mail.ru

DoR:

• Определено, что такое Ollama dashboard и доступы к нему
• Уточнены параметры email (получатель, тема, содержимое)
• Описаны базовые сценарии ошибок (скачивание, отправка)

DoD:

• Реализована возможность скачивания Excel-отчета
• Реализована отправка email с вложением
• Реализовано логирование операций и ошибок
• Функциональность протестирована и принята

Критерии приемки:

• Пользователь может скачать Excel-отчет из dashboard
• Файл открывается без ошибок
• Пользователь может отправить отчет по email
• При ошибках отображается понятное сообщение

-----------------------------------------------------------------------------------------------------------------------------------

Цыганов Влад (CLAUDE)
Промпт (RCTF)
Ты выступаешь как опытный бизнес-аналитик и системный архитектор, специализирующийся на продуктовых требованиях и Agile-практиках. Я работаю над пользовательской историей: «Как инвестор, я хочу получать на почту статистику использования ИИ в конце каждого рабочего дня в формате Excel.» Контекст: нужно формализовать требования для разработки функционала отправки ежедневных отчетов по использованию ИИ. В системе предполагается сбор метрик, их агрегация и экспорт в Excel с последующей отправкой на email. Эти требования будут использоваться командой разработки и тестирования. Твоя задача: Сформировать:
Definition of Ready (DoR) — критерии готовности задачи к разработке
Definition of Done (DoD) — критерии завершенности задачи
Acceptance Criteria — конкретные проверяемые критерии приемки пользовательской истории Важно:
Учитывай backend + frontend + инфраструктуру (cron/worker, email service, генерация Excel)
Критерии должны быть конкретными, измеримыми и проверяемыми
Избегай абстракций вроде «система должна работать корректно»
Покрой позитивные и негативные сценарии
Учитывай edge cases (нет данных, ошибка отправки, пустой отчет и т.д.)
Формулируй в виде, удобном для команды разработки и QA Формат ответа:
Четкие списки
Разделы: DoR / DoD / Acceptance Criteria
В Acceptance Criteria используй формат
Без лишней воды, максимально структурировано

ОТВЕТ
Definition of Ready (DoR)
Задача готова к спринту, если выполнены ВСЕ пункты:
Бизнес

• Определён список получателей отчёта (роль «инвестор»): email-адреса, возможность изменения списка через UI или конфиг.

Данные

• Согласован перечень метрик в отчёте: список полей, их источник, единицы измерения и способ агрегации (sum / avg / count).
• Определено понятие «конец рабочего дня»: конкретное время и часовой пояс (например, 18:00 UTC+3 или настраиваемо).
• Оговорено поведение при отсутствии данных за день: отправлять пустой отчёт с уведомлением или не отправлять совсем.

Формат

• Утверждён макет Excel-файла: структура листов, названия столбцов, форматирование чисел и дат, наличие сводных формул.

Инфраструктура

• Выбран и задокументирован email-провайдер (SMTP / SendGrid / SES): креды, лимиты, шаблон письма.
• Определён механизм планировщика: cron, Celery Beat, Temporal и т.д.; окружение и права доступа согласованы.

Нефункциональное

• Согласованы SLA: максимально допустимая задержка отправки (±5 мин), политика повторных попыток при ошибке.

Тест-данные

• В staging-среде доступны тестовые данные метрик за минимум один полный рабочий день.

Definition of Done (DoD)
Задача считается выполненной, если выполнены ВСЕ пункты:
Код

• Реализованы и смёрджены: агрегация метрик, генератор Excel, задача планировщика, email-отправка — код прошёл code review.

Тесты

• Покрытие unit-тестами ≥ 80% для модулей агрегации и генерации Excel; интеграционные тесты end-to-end запускаются в CI без ошибок.
• Протестированы edge-cases: нет данных за день, ошибка SMTP, недостижимый получатель, частичные данные.

Инфраструктура

• Cron/worker задеплоен в prod/staging; расписание подтверждено логами успешного запуска.

Наблюдаемость

• Логируются: старт задачи, статус отправки (success / error), ID письма от провайдера, время генерации файла.
• Настроены алерты на неуспешную отправку (Slack / PagerDuty / email команды) с дедупликацией по задаче.

Документация

• Обновлены: README с описанием конфигурации, runbook с описанием действий при ошибке, схема данных отчёта.

Приёмка

• Product Owner подтвердил соответствие Excel-файла согласованному макету на реальных данных.

Acceptance Criteria
Позитивные сценарии
AC-01 · Своевременная отправка
Given: данные об использовании ИИ за рабочий день собраны и доступны в БД
When: наступает запланированное время запуска планировщика
Then: письмо с Excel-вложением доставлено каждому получателю в течение 5 минут после триггера
AC-02 · Корректность Excel-файла
Given: за день зафиксированы N вызовов ИИ с известными метриками
When: получатель открывает вложенный .xlsx
Then: файл содержит все оговоренные поля; агрегированные значения совпадают с эталоном с погрешностью ≤ 0.01%; даты и числа форматированы по макету; файл открывается без ошибок в Excel и LibreOffice
AC-03 · Корректность темы и тела письма
Given: успешная генерация отчёта
When: письмо получено
Then: тема содержит дату отчёта в формате YYYY-MM-DD; вложение называется ai_usage_YYYY-MM-DD.xlsx; тело содержит краткую сводку (число запросов, общий токен-расход)
AC-04 · Идемпотентность при ручном перезапуске
Given: отчёт за день уже успешно отправлен
When: оператор запускает задачу повторно для той же даты
Then: система обнаруживает дубликат и не отправляет повторное письмо; в логах запись SKIPPED: report already sent for {date}

Негативные сценарии
AC-05 · Ошибка SMTP / email-провайдера
Given: Excel сгенерирован успешно
When: email-провайдер возвращает ошибку 5xx
Then: задача делает 3 повторные попытки с экспоненциальным отступом (30s / 2m / 10m); после исчерпания попыток — алерт команде; статус задачи FAILED с сохранением файла для ручной отправки
AC-06 · Невалидный email получателя
Given: в конфиге один из адресов содержит синтаксическую ошибку
When: задача формирует список рассылки
Then: невалидный адрес пропускается с предупреждением в логах; валидным получателям письмо отправляется без блокировки; алерт содержит список пропущенных адресов
AC-07 · Ошибка генерации Excel
Given: данные есть в БД, но библиотека генерации бросает исключение
When: задача выполняется
Then: письмо не отправляется; ошибка залогирована с stack trace; алерт команде; статус задачи FAILED

Edge cases
AC-08 · Нет данных за день (нерабочий день / нулевая активность)
Given: за текущий день в БД нет ни одной записи об использовании ИИ
When: планировщик срабатывает
Then: [решение принимает PO до старта разработки]
Вариант A — отправляется письмо с Excel, содержащим заголовки и строку «Нет данных за {date}»
Вариант B — письмо не отправляется, в лог пишется INFO: no data for {date}, skipping
AC-09 · Частичные данные (агрегация прервана)
Given: данные есть, но не все источники успели записать метрики к моменту запуска
When: задача завершает агрегацию
Then: Excel содержит пометку «Частичные данные» или маркер пропущенных источников; тело письма содержит предупреждение; задача завершается со статусом COMPLETED_WITH_WARNINGS
AC-10 · Задача не запустилась в плановое время
Given: планировщик был недоступен в момент триггера (рестарт pod / downtime)
When: планировщик восстанавливается
Then: при включённом catchup=true пропущенный запуск выполняется автоматически; при catchup=false — фиксируется missed execution в логах и алерт; дублирование исключено через механизм AC-04
AC-11 · Очень большой объём данных
Given: за день зафиксировано более 100 000 событий
When: задача генерирует отчёт
Then: Excel содержит только агрегаты (не построчные данные); размер файла ≤ 10 МБ; время генерации ≤ 2 минут

Вывод:
Ответ, полученный от Claude с использованием RCTF-промптом, как я считаю, является более точным и с меньшим кол-вом неопределенности. Покрыты edge-cases, негативные сценарии. DoR включает инфраструктуру.

---------------------------------------------------------------------------------------------------------------------------------------

Белова М.А. - DeepSeek
Промпт (RCTF):
Ты выступаешь как кросс-функциональная команда (Junior, Middle, Senior специалисты в области бизнес-анализа, QA и разработки). Сгенерируй консолидированный ответ, отражающий мнения всех уровней экспертизы.
Используй стратегию RCTF:
R (Role) — определи роли экспертов
C (Context) — учти контекст задачи
T (Task) — выполни конкретную задачу
F (Format) — соблюдай строгий формат ответа
Контекст (C):
Пользовательская история (User Story):
US3: Я как инвестор хочу получать на почту статистику использования ИИ в конце каждого рабочего дня в формате Excel.
Задача (T):
Сформулировать критерии приемки (Acceptance Criteria) для данной User Story.
Сформулировать Definition of Ready (DoR).
Сформулировать Definition of Done (DoD).
Требования к ответу (F):
Ответ должен быть разбит на 3 блока:
Acceptance Criteria
Definition of Ready (DoR)
Definition of Done (DoD)
В каждом блоке должно быть не более 3 пунктов
Каждый пункт должен быть четким, проверяемым и лаконичным
Ответ должен быть консолидированным (объединять взгляды Junior, Middle и Senior специалистов)
Избегай воды и общих формулировок — только практичные и применимые критерии
Роль (R):
Учитывай три уровня экспертизы при формировании ответа:
Junior — фокус на базовые проверки и понятность
Middle — фокус на полноту и применимость
Senior — фокус на риски, масштабируемость и бизнес-ценность
Сгенерируй итоговый ответ в соответствии с указанными требованиями.

Ответ
Acceptance Criteria
AC1: В конце каждого рабочего дня (последний будний день согласно календарю биржи) в 21:00 по времени сервера система автоматически отправляет на зарегистрированный email инвестора письмо с вложенным файлом AI_Usage_Stats_YYYY-MM-DD.xlsx.
AC2: Файл Excel содержит не менее 3 обязательных листов: сводка использования (запросы/токены), разбивка по юрисдикциям и топ-5 моделей; все числовые показатели отображаются в формате, исключающем ручное форматирование получателем (без текстовых комментариев внутри ячеек с формулами).
AC3: При сбое отправки (недоступность SMTP, ошибка генерации отчета) система фиксирует инцидент в логе с уровнем Error и отправляет уведомление в канал поддержки; повторная попытка отправки не производится во избежание дублирования, инвестор получает только свежий отчет за прошедший день.
Definition of Ready (DoR)
DoR1: Согласован и зафиксирован в Confluence макет отчета (структура столбцов и формулы агрегации данных по ИИ-провайдерам) с подписью владельца продукта и представителем инвестора.
DoR2: В переменных окружения (GitHub Secrets) развернута тестовая SMTP-конфигурация, а email-адрес инвестора добавлен в белый список песочницы.
DoR3: Определен идентификатор рабочего дня относительно UTC+0 для корректного расчета отчетного периода и исключения праздничных дней биржи.
Definition of Done (DoD)
DoD1: Функционал отправки развернут в Production окружении, активирован Cron Job, проведена ручная верификация доставки письма с валидным XLSX-файлом на реальный почтовый ящик инвестора за один полный тестовый день.
DoD2: В системе мониторинга (например, Grafana) добавлен дашборд, отображающий статус последних 7 джобов и количество ошибок отправки; алерт настроен на отсутствие метрики успеха в течение 30 минут после планового окна.
DoD3: Документация в Runbook обновлена: описана процедура смены email-адреса получателя и ручного перезапуска джобы за конкретную дату (с проверкой идемпотентности через audit log).

Вывод:
Требования стали ещё более детализированными и операционными, чем даже во втором варианте:
добавлены конкретные условия времени (21:00, учёт календаря биржи, UTC+0)
чётко описана структура файла (листы, содержание, формат данных)
Acceptance Criteria теперь не просто тестируемые, а приближены к реальным эксплуатационным сценариям (ошибки, отсутствие retry, поведение системы при сбоях).
DoR стал инфраструктурно ориентированным (Confluence, GitHub Secrets, sandbox SMTP) — в первом варианте этого уровня не было.
DoD включает production-ready требования:
мониторинг (Grafana)
алерты
runbook и операционные процедуры
в первом варианте DoD был больше про “сделано”, а здесь — про “эксплуатируется”.
Появилась терминология enterprise-уровня (идемпотентность, audit log, sandbox, cron, runbook).

---------------------------------------------------------------------------------------------------------------------------------------

Белов С.М. - GPT
Промпт (RCTF)
Role:
Ты Senior Agile Business Analyst с опытом работы в Scrum-командах и построении метрик продуктов.
Constraints:

• В каждом блоке (Acceptance Criteria, DoR, DoD) должно быть не более 3 пунктов
• Критерии должны быть конкретными, измеримыми и проверяемыми
• Ответ должен агрегировать и учитывать точки зрения специалистов уровней: Junior, Middle, Senior
• Избегать воды, только практичные формулировки
  Task:
  На основе пользовательской истории:
  US3: Я как инвестор хочу получать на почту статистику использовании ИИ в конце каждого рабочего дня в формате Excel
  Сформировать:

1. Acceptance Criteria (критерии приемки)
2. Definition of Ready (DoR)
3. Definition of Done (DoD)
   Format:
   Ответ представить в следующей структуре:
   US3:
   Acceptance Criteria:

• ...
• ...
• ...
  DoR:
• ...
• ...
• ...
  DoD:
• ...
• ...
• ...
  Без дополнительных пояснений.

Ответ
US3:

• Acceptance Criteria:
• Письмо с Excel-файлом отправляется инвестору автоматически каждый рабочий день до 18:00 (локальное время сервера)
• Excel-файл содержит минимум: дата, количество запросов к ИИ, уникальные пользователи, среднее время ответа; данные совпадают с источником (расхождение ≤1%)
• Письмо успешно доставлено (статус SMTP 250) и файл открывается без ошибок в Excel

DoR:

• Определён список метрик и их источники данных (согласовано с бизнесом и техкомандой)
• Есть шаблон Excel (структура, названия колонок, формат данных)
• Настроены почтовые реквизиты инвестора и подтверждены требования к времени отправки

DoD:

• Реализована автоматическая генерация Excel и отправка письма по расписанию (cron/job), покрытая логированием
• Проведено тестирование: юнит + интеграционное (генерация файла, корректность данных, отправка email) — все тесты успешны
• Функционал задеплоен, мониторинг настроен (алерты при сбое отправки >1 дня)

Вывод:
Во втором варианте требования стали конкретными и измеримыми: появились точные метрики (≤1% расхождения, SMTP 250, до 18:00), вместо общих формулировок.
Acceptance Criteria стали тестируемыми, а не описательными.
DoR и DoD стали более фокусированными и минималистичными — убраны лишние детали, оставлены только критичные условия готовности.
Добавлена техническая конкретика (cron/job, типы тестов, мониторинг, алерты), чего почти не было в первом варианте.
Структура стала более строгой и инженерной, без расплывчатых формулировок

---------------------------------------------------------------------------------------------------------------------------------------

Канашин Д.И (Grok)
Промпт (RCTF)
Ты — Senior QA Engineer в компании с 30-летним стажем, которая занимается разработкой ПО для проведения собеседований. Сейчас в нашей компании идёт стадия внедрения ИИ.
Role:
Ты отвечаешь исключительно от лица Senior QA Engineer.
Твой взгляд должен быть глубоким, профессиональным и ориентированным на риски, масштабируемость, безопасность, производительность и лучшие практики тестирования в HR-системах с элементами ИИ.
Context:
Ты — Senior QA Engineer в компании с 30-летним стажем, которая занимается разработкой ПО для проведения собеседований. Сейчас в нашей компании идёт стадия внедрения ИИ.
Поэтому все критерии должны учитывать важность корректной работы с ИИ-статистикой, надёжность отправки отчётов инвесторам, конфиденциальность данных, точность статистики и специфику HR-систем.
US3: Как инвестор, я хочу получать на почту статистику использования ИИ в конце каждого рабочего дня в формате Excel.
Task:
Для US выполни следующее:
Напиши Критерии приемки (Acceptance Criteria) с акцентом на тестируемые условия
Сформулируй DoR (Definition of Ready) — критерии готовности истории к тестированию
Сформулируй DoD (Definition of Done) — требования к качеству и тестированию перед закрытием задачи
Format:
Строго соблюдай структуру. Используй ровно 3 пункта в каждом блоке.
US3: Как инвестор, я хочу получать на почту статистику использования ИИ в конце каждого рабочего дня в формате Excel.
Критерии приемки:
пункт 1
пункт 2
пункт 3
DoR:
пункт 1
пункт 2
пункт 3
DoD:
пункт 1
пункт 2
пункт 3

Ответ:
US3: Как инвестор, я хочу получать на почту статистику использования ИИ в конце каждого рабочего дня в формате Excel.

Критерии приемки US3:

• Система автоматически формирует и отправляет Excel-файл со статистикой использования ИИ (количество сессий, точность моделей, время обработки, расход токенов) на верифицированный email инвестора ежедневно ровно в 18:00 по времени компании (UTC+3), с проверкой на соответствие агрегированным данным БД.
• Данные в отчёте полностью анонимизированы, точны (расхождение не более 0,1 %), защищены паролем на уровне файла и передаются только по TLS 1.3; при любом расхождении или утечке тест падает.
• В случае сбоя доставки (SMTP, спам-фильтры, quota) запускается retry-механизм (3 попытки с экспоненциальной задержкой), логируются все события, а инвестор и администратор получают fallback-уведомление; отчёт остаётся доступным в защищённом архиве 30 дней.

DoR для US3:

• Критерии приемки утверждены Product Owner, Security Officer и Senior QA Engineer с учётом рисков конфиденциальности HR-данных и точности ИИ-метрик.
• Реализация завершена: cron-задача, генератор Excel (openpyxl с валидацией), интеграция с email-сервисом и мок-окружение для AI-статистики готовы и прошли code review.
• Подготовлена тестовая среда (staging) с синтетическими данными за 5 рабочих дней, верифицированными email-инвесторов и мониторингом доставки (MailHog + Prometheus).

DoD для US3:

• Все 3 критерия приемки покрыты 100 % автоматизированными (API + UI) и мануальными тестами, включая edge-кейсы (выходные, downtime, высокая нагрузка).
• Проведён полный security- и compliance-ревью (GDPR/HIPAA-подобные требования к ИИ-статистике), подтверждена нулевая утечка PII в отчётах.
• Документация обновлена (тест-кейсы, риски, SLA доставки 99,9 %), задача протестирована в production-like окружении и закрыта только после успешной отправки отчёта за полный рабочий день.

[Fuflick]

[KILADELPHIA]

Группа 4/42: Озерский Александр

US1: Я как дата инженер хочу иметь возможность загружать данные из источника в хранилище автоматически по расписанию

DoR:

• Определён источник данных и формат входных файлов
• Согласовано расписание запуска
• Описана схема целевой таблицы в хранилище
• Уточнено поведение при дублях
• Определены ответственные за мониторинг пайплайна

DoD:

• Пайплайн реализован и задеплоен в prod-среде
• Расписание настроено и проверено на stage слое
• Реализовано логирование каждого запуска (старт, конец, кол-во записей)
• Настроены алерты при падении пайплайна
• Написаны unit-тесты на трансформации

Критерии приемки:

• Пайплайн запускается автоматически согласно расписанию без ручного вмешательства
• При успешной загрузке данные появляются в целевой таблице в течение 5 минут после триггера
• При ошибке в источнике команда получает уведомление в маттермост
• Дубли не попадают в целевую таблицу
• Исторические запуски отображаются в аирфлоу

US2: Я как аналитик хочу видеть витрину данных с агрегированными метриками продаж за текущий месяц

DoR:

• Согласован список метрик и их формулы расчёта
• Определены источники: какие таблицы, какой слой DWH
• Уточнена гранулярность (день / неделя / месяц)
• Согласован SLA обновления витрины
• Определены пользователи витрины и их уровень доступа

DoD:

• Витрина создана в слое dm в DWH
• Данные обновляются по расписанию в рамках SLA
• Проведена сверка данных с источником
• Написана документация на витрину в конфе
• Доступ для аналитиков настроен

Критерии приемки:

• Витрина содержит все согласованные метрики с корректными формулами
• Данные за текущий месяц обновляются ежедневно до 6 утра
• Отклонение от источника не превышает 0,1%
• Аналитик без прав admin не может изменить данные в витрине
• При задержке обновления более 30 минут срабатывает алерт

US3: Я как тимлид хочу получать еженедельный отчёт о качестве данных по ключевым пайплайнам

DoR:

• Определён список ключевых пайплайнов для мониторинга
• Согласованы метрики качества
• Определён получатель и формат отчёта
• Уточнен день и время отправки
• Описан порог, при котором метрика считается плохой

DoD:

• Реализован сбор метрик качества по каждому пайплайну
• Реализована генерация и отправка отчёта по расписанию
• Отчёт протестирован на реальных данных
• В конфигурации можно добавлять/убирать пайпы без изменения кода

Критерии приемки:

• Тимлид получает отчёт каждый понедельник до 8 утра
• Отчёт содержит статус по каждому пайплайну
• Метрики в отчёте соответствуют фактическим данным в системе мониторинга
• При значении метрики ниже порога строка выделяется красным
• Отчёт не отправляется в праздничные дни (переносится на след рабочий день)

[KILADELPHIA]

p.s посмотрите плиз личку в тг у @kiladelphia8 я писал вам с вопросом

[EugeneWWolf]

4-147 Ермакова Ксения

Дополнение 2026-04-09:
Если прогнать через нейронку более "улучшенные" промпты со всеми вводными данными, что есть на уме, и различными предостережениями по поводу содержания (по типу того, что критерии приёмки - это непосредственно сценарий выполнения, а не описание, и то, что не нужно писать то, что не согласовано в DoR в DoD), то получится более крепкий костяк, который всё равно придётся править, но это хоть что-то.

Если кратко, что изменилось: нейронка стала писать приёмку в виде конкретных сценариев выполнения, а не описывать просто на словах. Стала более хорошо изначально, без моих правок, согласовывать DoR и DoD между собой. Теперь случаев недосказанности в разы меньше при первом же "драфте". И само по себе описание DoR и DoD от нейронки стало более полным, так как был предоставлен более большой контекст того, как приложение вообще должно выглядеть в теории, даже до самых мелочей.

Приложение для языкового обмена

US1: Я как пользователь хочу найти партнёра для языкового обмена по моим параметрам

DoR:

• Определены фильтры поиска (язык, уровень, часовой пояс, интересы)
• Согласован алгоритм матчинга (по скольким параметрам считается совпадение)
• Уточнено, видит ли пользователь профиль партнёра до подтверждения матча
• Определено максимальное количество активных пар одновременно на одного пользователя
• Описано поведение системы при отсутствии подходящих партнёров

DoD:

• Экран поиска с фильтрами реализован и покрыт UI-тестами
• Алгоритм матчинга задеплоен, протестирован и задокументирован
• Пользователь получает пуш-уведомление при нахождении партнёра
• Логирование матчей и отказов реализовано
• Реализовано предупреждение команде при деградации качества матчинга (< N совпадений в час)

Критерии приёмки:

• Пользователь может выставить фильтры и запустить поиск одним действием
• Система предлагает только тех партнёров, у которых родной язык совпадает с изучаемым языком пользователя, и наоборот
• Пользователь видит карточку партнёра с уровнем, интересами и часовым поясом до подтверждения матча
• При отсутствии подходящих партнёров отображается понятное сообщение с конкретным предложением расширить фильтры
• Пользователь без верифицированного профиля не может запустить поиск - система подсказывает, что нужно заполнить, какие действия выполнить, чтобы получить подтверждённый аккаунт
• Пользователь не видит в результатах партнёров, которых уже отклонил ранее

US1.1: Я как пользователь хочу заполнить языковой профиль, чтобы система понимала мой уровень

DoR:

• Согласован формат уровней (A1-C2 по CEFR или собственная шкала приложения)
• Определён список поддерживаемых языков на старте (минимальный выбор из наиболее распространнёных языков)
• Уточнено, обязателен ли профиль для входа в приложение или только для поиска
• Описан способ верификации уровня: "placement test", самооценка скилла самими пользователем, или оба варианта сразу
• Согласовано максимальное количество одновременно изучаемых языков

DoD:

• Экран заполнения профиля реализован и доступен при регистрации и из настроек
• Пользователь может указать родной язык и до 3 изучаемых языков с уровнями
• "placement test" из 10-15 вопросов реализован для каждого поддерживаемого языка
• Данные профиля сохраняются в БД и передаются в алгоритм матчинга
• Изменения профиля обновляют позицию пользователя в матчинге в течение 1 минуты

Критерии приёмки:

• Пользователь может указать родной язык и один или несколько изучаемых языков с уровнем каждого
• После прохождения "placement test"а система автоматически предлагает уровень с пояснением результата
• Пользователь может вручную скорректировать предложенный уровень без повторного прохождения теста
• Профиль невозможно сохранить без указания родного языка - поле подсвечивается красным, и рядом всплывает подсказка
• После сохранения изменений поиск партнёров отражает обновлённые данные в течение 1 минуты
• Пользователь не может указать один и тот же язык одновременно как родной и изучаемый

US2: Я как пользователь хочу общаться с партнёром в чате с функцией языкового обмена

DoR:

• Определён формат сессии обмена (длительность каждого языкового блока, кто начинает)
• Согласовано, как визуально фиксируется смена активного языка в интерфейсе чата
• Определены поддерживаемые форматы сообщений: текст, голос, фото (фото для тех случаев, если участник разговора захочет показать что-нибудь на примере)
• Определены триггеры автоматической модерации (стоп-слова, спам, нежелательный контент на всех поддерживываемых языках в приложении), и действия при срабатывании этой автомодерации
• Уточнено поведение чата при потере соединения одним из участников

DoD:

• Чат в реальном времени между двумя пользователями реализован (вебсокет)
• Таймер смены языка реализован с уведомлением обоих участников
• Поддержаны текстовые и голосовые сообщения, загрузка фото
• Функция выделения ошибки в сообщении партнёра с комментарием реализована
• Реализована жалоба на сообщение с передачей в очередь модерации
• Покрыто e2e-тестами: отправка, получение, исправление, смена языка

Критерии приёмки:

• Оба участника видят сообщения в реальном времени с задержкой не более 2 секунд
• Таймер автоматически уведомляет обоих участников о смене активного языка сессии
• Пользователь может выделить любой фрагмент сообщения партнёра и оставить исправление с комментарием
• Исправление отображается отдельным блоком под оригиналом и не заменяет его
• Голосовое сообщение воспроизводится прямо в чате без перехода на другой экран
• При потере соединения сообщения, отправленные оффлайн, доставляются после восстановления связи

US2.1: Я как пользователь хочу получать транскрипцию и перевод голосовых сообщений партнёра

DoR:

• Определён список языков, для которых поддерживается транскрипция на старте
• Согласован минимально допустимый порог точности транскрипции (>=85%)
• Уточнено, хранятся ли голосовые сообщения на сервере, как долго и в каком регионе
• Определён STT-провайдер и резервный провайдер при недоступности основного
• Согласовано поведение при языках, для которых транскрипция не поддерживается

DoD:

• Транскрипция генерируется автоматически сразу после получения голосового сообщения
• Перевод транскрипции на язык получателя реализован через согласованный провайдер
• Пользователь может скрыть или показать транскрипцию нажатием одной кнопки
• Для неподдерживаемых языков отображается корректная заглушка без ошибок
• Реализовано логирование ошибок распознавания с метриками качества

Критерии приёмки:

• Транскрипция появляется под голосовым сообщением не позднее чем через 20 секунд после получения
• Пользователь может нажать "показать перевод" и увидеть текст на своём языке без перехода в сторонние приложения (переводчики, нейронки)
• При низком качестве аудио система отображает предупреждение вместо некорректной транскрипции
• Пользователь может полностью отключить автотранскрипцию в настройках, и это решение сохраняется между сессиями
• Для языка без поддержки транскрипции отображается понятное сообщение, а не пустое поле

US3: Я как пользователь хочу отслеживать прогресс изучения языка внутри приложения

DoR:

• Определены метрики прогресса: количество сессий, минут практики, полученных и отправленных исправлений
• Согласован внешний вид дашборда (макет или референс)
• Уточнено поведение стрика: обнуляется ли при пропуске одного дня или есть фича для "прощения косяков" (не знаю, как лучше её назвать)
• Определён список достижений (бейджей), условия получения и возможность повторной выдачи
• Согласовано, что считается "достигнутым уровнем" для бейджа "Полиглот" - минимальный порог (например, не ниже B1) или любой другой подтверждённый уровень (у других языков могут быть другие "ступеньки" знания языка, B1 чисто пример для английского)
• Согласован период хранения уже завершённых чатов пользователя и связанных с этим данных (голосовухи, фото, текст)

DoD:

• Экран прогресса реализован с графиком активности по дням и неделям
• Счётчик стрика реализован с хранением исторического максимума
• Система бейджей реализована с пуш-уведомлением при получении
• Данные обновляются после каждой завершённой сессии без перезагрузки экрана
• Реализован выбор временного периода для просмотра статистики (неделя / месяц / всё время)

Критерии приёмки:

• Пользователь видит количество сессий, минут практики и исправлений за выбранный период
• Стрик увеличивается при наличии хотя бы одной завершённой сессии за календарный день
• При пропуске дня стрик обнуляется, но исторический максимум остаётся виден
• Бейдж "Первые 10 сессий" выдаётся автоматически с пуш-уведомлением сразу после завершения 10-й сессии
• Бейдж "Полиглот" выдаётся автоматически с пуш-уведомлением сразу после того, как пользователь достигает любого подтверждённого уровня (по результатам "placement test"а или ручной оценки партнёра) на 2 и более изучаемых языках. Бейдж выдаётся один раз и не повторяется при добавлении новых языков
• Пользователь без сессий видит экран-заглушку с призывом найти партнёра, а не пустой дашборд с нулями
• Данные на дашборде соответствуют фактической активности с точностью до одной сессии

US3.1: Я как пользователь хочу получать еженедельный дайджест своего прогресса на электронную почту

DoR:

• Согласован шаблон письма: какие метрики включены, есть ли визуализация
• Определён день и время отправки с учётом часового пояса пользователя
• Уточнено поведение при нулевой активности за неделю (отдельное письмо или не отправлять)
• Описан механизм отписки от мейл-рассылки
• Согласован провайдер для отправки писем и резервный при недоступности
• Подтверждено, что настройки мейл-рассылки и пуш-уведомлений независимы друг от друга
• Согласован критерий отбора топ-3 исправлений: по частоте повторяющейся ошибки за неделю, при равенстве — случайная выборка

DoD:

• Генерация еженедельного письма реализована по расписанию с учётом часового пояса каждого пользователя
• Письмо содержит количество сессий, минут практики и топ-3 типа ошибок по частоте за неделю
• Реализована одноклик-отписка прямо из письма без необходимости авторизоваться
• При нулевой активности отправляется мотивационное письмо без статистики
• Реализовано логирование отправок уведомлений (мейл/пуш) пользователю с фиксацией статуса и причины ошибки; настроено предупреждение команде при превышении порога неуспешных отправок
• Статус отписки от мейл-рассылки сохраняется в профиле и отображается в настройках раздела "мейл-уведомления", не затрагивая раздел "пуш-уведомления"

Критерии приёмки:

• Пользователь получает письмо каждое воскресенье до 10:00 по своему часовому поясу
• Данные в письме полностью соответствуют статистике в приложении за ту же неделю
• При нулевой активности пользователь получает мотивационное письмо, а не письмо с нулями
• Пользователь с неподтверждённой электронной почтой не получает рассылку и видит в приложении напоминание подтвердить её
• При ошибке отправки система выполняет повторную попытку и логирует результат
• Отписка от мейл-рассылки отражается только в разделе "мейл-уведомления" и никак не влияет на настройки пуш-уведомлений
• Пользователь может независимо управлять мейл-рассылкой и пуш-уведомлениями в настройках приложения

[CBEPXPA333YM]

Группа 4/147 Выполнили Лебедев Егор и Архипов Алексей

Сделано для приложения для заказа еды

Лебедев Егор:
ChatGPT RCTF-промпт:
Role:
Ты - опытный бизнес-аналитик в продуктовой команде, разрабатывающей мобильное приложение для заказа еды.
Context:
Приложение позволяет пользователям выбирать рестораны, просматривать меню, добавлять блюда в корзину и оформлять заказ.
Сейчас нужно описать User Story про просмотр меню ресторана.
Task:
Сформулируй User Story в формате «Как [роль], я хочу [действие], чтобы [ценность]», а также DoR, DoD и критерии приемки в виде коротких предложений.
Format:
User Story - 1 предложение
DoR, DoD, Acceptance Criteria - список из 3–5 пунктов

Ответ:
User Story:
Как пользователь, я хочу просматривать меню ресторана, чтобы выбрать подходящие блюда для заказа.

DoR (Definition of Ready):

Описаны основные элементы меню (категории, блюда, цены).
Определены требования к отображению (список, фото, описание).
Согласованы UX-макеты экрана меню.
Понятны источники данных (API ресторана).
Определены ограничения по производительности.

DoD (Definition of Done):

Меню корректно загружается и отображается в приложении.
Отображаются категории, названия, цены и описания блюд.
Интерфейс соответствует утвержденному дизайну.
Проведено тестирование (UI и интеграционное).
Нет критических багов.

Acceptance Criteria:

Пользователь может открыть меню выбранного ресторана.
Блюда сгруппированы по категориям.
Для каждого блюда отображается название, цена и описание.
Меню загружается не более чем за X секунд.
При ошибке загрузки отображается уведомление пользователю.

Архипов Алексей:
DeepSeek (RCTF)
Роль:
Ты - опытный системный аналитик (Business Analyst),
специализирующийся на написании пользовательских историй для мобильных и веб-приложений заказа еды.

Контекст:
Разрабатывается приложение для заказа еды (аналог Delivery Club, Яндекс Еда, Uber Eats).
Необходимо описать пользовательскую историю для клиента,
которая позволяет просматривать меню ресторанов.

Задача:
Сгенерируй пользовательскую историю US 1.1 "Просмотр меню ресторана"
согласно описанному контексту и формату.

Формат:
Формат ответа - строго по шаблону:

1. User Story ("Как... я хочу... чтобы...")
2. DoR 4-5 пунктов
3. DoD 4-5 пунктов
4. Acceptance Criteria - 4-5 пунктов

Ответ:

1. User Story
   Как голодный клиент, который выбирает блюдо в ресторане,
   я хочу просматривать меню ресторана с分组 по категориям (закуски, горячее, напитки), ценами, описанием и фотографиями блюд,
   чтобы легко ориентироваться в ассортименте, сравнивать блюда и принимать решение о заказе.

2. DoR (Definition of Ready) — 4–5 пунктов
   Актуальный бэкенд API для получения меню ресторана (список категорий, блюда, цены, опции) готов к интеграции.

Дизайн-макет экрана меню (включая карточку блюда, категории, скролл, состояние загрузки) утверждён с Product Owner.

Настроены тестовые данные — минимум 3 тестовых ресторана с полным меню (от 2 категорий, от 3 блюд в каждой).

Определены приоритеты — история оценена командой (например, 5 story points) и запланирована в спринт.

Нет известных блокеров по доступности ресторанов (например, все рестораны в истории имеют статус «открыт»).

3. DoD (Definition of Done) — 4–5 пунктов
   Код реализован и покрыт юнит-тестами (ViewModel/UseCase для получения меню) с успешным прохождением всех тестов.

UI-тесты (или скриншотные тесты) проверяют отображение категорий и карточек блюд на разных разрешениях экрана.

Произведён code review двумя разработчиками и ревью аналитика по acceptance criteria.

Функция задокументирована в Swagger/Confluence (для API) и в руководстве пользователя (для мобильного/веб-приложения).

Ручное тестирование завершено — баги с приоритетом выше «минор» отсутствуют, история принята Product Owner.

4. Acceptance Criteria
   Отображение категорий — при открытии экрана меню пользователь видит список категорий (например, «Пицца», «Салаты», «Напитки») с возможностью переключения между ними (табы или горизонтальный скролл).

Карточка блюда — каждое блюдо содержит: название, актуальную цену, краткое описание (макс. 2 строки), фотографию (или плейсхолдер, если фото отсутствует).

Адаптация при ошибке загрузки — если меню не загрузилось (нет сети или 500 ошибка), показывается понятный текст «Не удалось загрузить меню» и кнопка «Повторить».

Пустое состояние категории — если в выбранной категории нет блюд, отображается сообщение «В этой категории пока ничего нет».

Интерактивность — при нажатии на карточку блюда происходит переход на экран деталей блюда (описание, вес, состав, опции).

[goutosama]

Команда (4/147):
Чадов Сергей, Баранников Артём, Смолов Денис

US 1 Я как интервьюер хочу иметь возможность ставить таймкоды с заметками во время видеозвонка, чтобы быстро вернуться к ключевым моментам кандидата после интервью

DoR (Definition of Ready):

• Известен минимальный и максимальный размер заметки, поддерживаемые вложения (смайлики, прикрепляемые файлы, картинки и т.д.)
• Известен формат таймкода (например, ЧЧ:ММ:СС)
• В приложении существует режим повтора, в который можно встроить функцию отматывания к заметкам с таймкодом
• Определены макеты UI и UX описание

DoD (Definition of Done):

• Интерфейс соответствует UI и UX описанию
• В интерфейсе присутствует кнопка быстрого добавления заметки, открывающая окно с небольшим текстовое полем и отображающим таймкод (время, когда была нажата кнопка) в заголовке и кнопки сохранения и отмены заметки
• К функционалу быстрых заметок имеет доступ только интервьюер
• В режиме повтора полоса прокрутки имеет засечки, соответствующие выставленным заметкам, а также при наведении на засечку отображается текст заметки
• В режиме повтора можно редактировать заметки и создавать новые, они записываются в файл записи видеозвонка
• В режиме повтора и во время видеозвонка есть кнопка, открывающая сайдбар со всеми заметками видеозвонка

Acceptance criteria:

• Пользователи могут создавать заметки в доступных им файлах видеозаписей звонка
• Интервьюер может создавать заметки во время видеозвонка
• В просмотре всех заметок и на полосе прокрутки отображаются все заметки видеозвонка
• В случаях экстренных случаях недоступности ПО заметки можно достать из файла записи видеозвонка или видеофайл имеет прикреплённые субтитры, содержащие заметки
• При выборе таймкода воспроизведение записи начинается с соответствующего момента
• При создании таймкода интервьюеру доступно текстовое поле для ввода заметки
• Таймкод сохраняет точное время (с точностью до секунды) относительно записи интервью

US 2 Я как кандидат хочу пройти тест микрофона и камеры перед началом интервью, чтобы убедиться, что интервью не будет сорвано из-за технических проблем

DoR:

1. Определены требования к проверке микрофона (уровень громкости, состояние записи) и камеры (отображение видео)
2. Определены поддерживаемые устройства
3. Определены макеты или UX-описание
4. Определены требования к обработке ошибок

DoD:

1. Реализована проверка камеры (видео с камеры отображается пользователю)
2. Реализована проверка микрофона (есть визуальный индикатор уровня звука или записи)
3. Обрабатываются ошибки (отказ в доступе к устройствам, отсутствие устройств)
4. UI соответствует макетам

АС:

1. Пользователь может открыть экран тестирования перед интервью
2. Пользователь может проверить камеру: если камера доступна - отображается видео, если камера недоступна - отображается сообщение об ошибке
3. Пользователь может проверить микрофон: если микрофон доступен - отображается индикатор записи/индикатор уровня звука, если микрофон недоступен - отображается сообщение об ошибке
4. При отсутствии доступа к устройствам отображается инструкция по получению доступа
5. После прохождения теста пользователь может начать интервью

US 3 Я как HR-менеджер хочу автоматически получать запись интервью и краткое резюме разговора, чтобы не тратить время на пересмотр полного видео

DoR:

1. Выбран инструмент транскрибации аудио в текст
2. Выбран ИИ-инструмент генерации краткого резюме из транскрибации
3. Определён макет краткого резюме разговора
4. Определено, где будет храниться запись интервью
5. Определён размер краткого резюме
6. Определён срок хранения записи и резюме

DoD:

1. Система автоматически запускает запись интервью
2. По окончании интервью генерируется резюме
3. Запись сохраняется в защищённом хранилище
4. HR-менеджер получает уведомление со ссылкой на запись и резюме интервью

AC Критерии приёмки:

1. Точность транскрибации составляет не менее 90% верно распознанных слов
2. Краткое резюме соответствует общим темам, озвученным на интервью
3. Если запись невозможна, система отправляет соответствующее уведомление
4. Запись хранится и доступна для скачивания HR-менеджером в течение 30 дней
5. Возможно удаление записи в любой момент по запросу HR-менеджера или кандидата
6. Запись можно прослушать/просмотреть онлайн без скачивания
7. Резюме отображается рядом с записью

С помощью LLM

Выбранный US: 1. Я как интервьюер хочу иметь возможность ставить таймкоды с заметками во время видеозвонка, чтобы быстро вернуться к ключевым моментам кандидата после интервью
Выбранный метод промптинга: RCTF

Баранников Артём (DeepSeek, Эксперт)

Промпт

Ты — эксперт по гибким методологиям и опытный владелец продукта. Контекст: команда разрабатывает функцию для платформы видеособеседований, которая позволяет интервьюерам ставить таймкоды с заметками во время звонка для последующего быстрого перехода к ключевым моментам. Пользовательская история: "US 1 Я как интервьюер хочу иметь возможность ставить таймкоды с заметками во время видеозвонка, чтобы быстро вернуться к ключевым моментам кандидата после интервью". Задание: сгенерируй для этой истории Definition of Ready (DoR), Definition of Done (DoD) и Acceptance criteria (AC) в виде четких пунктов. Формат: каждый из трех разделов начни с заголовка DoR:, DoD:, AC:, затем пронумерованный список. Для DoR укажи 4 условия готовности задачи к разработке, для DoD — 4 критерия завершения, для AC — 3-5 приемочных критериев в формате "Дано-Когда-Тогда".

Ответ

DoR:

1. Пользовательская история детализирована в формате US и оценена командой в story points с четким пониманием объема работ.
2. Дизайн-макеты элементов интерфейса (кнопка добавления таймкода, модальное окно заметки, список заметок в послезвонковом просмотре) утверждены стейкхолдерами и доступны команде.
3. Определен формат хранения таймкода и заметки в базе данных и согласован протокол взаимодействия с видеоплатформой (WebRTC/Jitsi/внешний API) для получения текущего времени звонка.
4. Отсутствуют блокирующие зависимости от других команд; API для сохранения и получения заметок согласовано с бэкенд-разработкой.

DoD:

1. Функционал реализован согласно макетам: в интерфейсе звонка присутствует активный элемент для добавления таймкода с возможностью ввода текста заметки.
2. Написан и пройден полный набор автоматизированных тестов (юнит-тесты для логики клиента, интеграционные тесты для сохранения и загрузки таймкодов).
3. Код функции залит в основную ветку репозитория, успешно прошел код-ревью и статический анализ без критических замечаний.
4. Функция развернута на тестовом окружении, проведено ручное функциональное тестирование сценариев "счастливого пути" и краевых случаев (потеря связи, закрытие браузера до сохранения).

AC:

1. Дано я нахожусь в активном видеозвонке с кандидатом, Когда я нажимаю кнопку «Добавить заметку» (или горячую клавишу), Тогда интерфейс фиксирует текущий таймкод звонка (мм:сс) и открывает поле для ввода текста заметки с возможностью сохранить или отменить.
2. Дано я ввел текст заметки и сохранил её, Когда звонок завершился и я перешел на страницу деталей прошедшего интервью, Тогда я вижу хронологический список всех добавленных таймкодов с соответствующими текстовыми заметками.
3. Дано на странице деталей интервью отображается список заметок с таймкодами, Когда я кликаю по конкретному таймкоду в списке, Тогда встроенный плеер записи звонка (при наличии) перематывается точно на этот момент времени и начинает воспроизведение.
4. Дано во время звонка у меня пропало соединение с интернетом, Когда я нажимаю кнопку сохранения заметки в офлайн-режиме, Тогда интерфейс выводит уведомление о невозможности сохранить данные и предлагает повторить попытку после восстановления связи (без потери введенного текста из буфера поля ввода).
5. Дано я участвую в звонке в роли наблюдателя или второго интервьюера, Когда первый интервьюер добавляет таймкод с заметкой, Тогда в моем интерфейсе звонка появляется соответствующая иконка на временной шкале записи (если функция реализована), но интерфейс быстрого перехода доступен только мне после окончания звонка в общем списке заметок.

Чадов Сергей (ChatGPT)

Промпт

Ты — Agile-коуч, помогающий команде уточнить требования. Контекст: история описывает возможность интерактивной разметки видеозвонка — интервьюер кликает по таймлайну, вводит заметку, и система сохраняет связку (время + текст), позже по клику на таймкод воспроизведение перематывается на нужный момент. Задание: разработай DoR, DoD и Acceptance criteria, учитывая, что критерии должны быть измеримыми и понятными для разработчика. Формат: выведи результат в виде трех блоков, помеченных маркерами: • DoR: (4 пункта) • DoD: (4 пункта) • AC: (список с 3-5 критериями, каждый как "Допустим... Когда... Тогда..."). Сделай акцент на отсутствии зависимостей в DoR и на автотестах в DoD.

Ответ

• DoR:

1. Требования описаны в терминах пользовательских действий и ожидаемого результата (создание, сохранение, переход по таймкоду), без неоднозначностей.
2. Определены все входные и выходные данные: формат заметки (строка, макс. длина), формат времени (например, HH:MM:SS или миллисекунды), идентификатор видеозвонка.
3. Отсутствуют внешние блокирующие зависимости (доступ к API видеоплеера, хранилищу данных, UI-компонентам уже обеспечен или замокан).
4. Подготовлены UX-макеты/прототипы с указанием точки клика по таймлайну, поля ввода и отображения заметок.

---

• DoD:

1. Реализована функциональность создания, сохранения и перехода по заметкам с привязкой ко времени; данные корректно сохраняются и извлекаются.

2. Покрытие автотестами:

   • unit-тесты (логика сохранения/парсинга времени),
   • интеграционные тесты (взаимодействие с хранилищем),
   • e2e-тест (создание заметки → переход по таймкоду).

3. Обработаны граничные случаи: пустая заметка, некорректный таймкод, клик вне диапазона видео.

4. Код соответствует стандартам качества (линтеры, code review), документация обновлена (описание API/поведения).

---

• AC:

1. Допустим пользователь просматривает видеозвонок,
   Когда он кликает по таймлайну и вводит текст заметки,
   Тогда система сохраняет запись с точным временем клика (погрешность не более ±100 мс) и текстом.

2. Допустим сохранено несколько заметок,
   Когда пользователь открывает список заметок,
   Тогда каждая заметка отображается с корректным таймкодом и текстом.

3. Допустим пользователь видит сохранённую заметку,
   Когда он кликает на её таймкод,
   Тогда воспроизведение перематывается к соответствующему моменту (погрешность не более ±100 мс).

4. Допустим пользователь пытается сохранить пустую заметку,
   Когда он нажимает «Сохранить»,
   Тогда система отклоняет действие и отображает сообщение об ошибке.

5. Допустим видеозвонок длится N минут,
   Когда пользователь кликает по таймлайну в любой точке в пределах [0, N],
   Тогда создаётся заметка с валидным таймкодом внутри этого диапазона.

Смолов Денис (Grok, Эксперт)

Промпт

Ты — технический писатель и аналитик. Контекст: пользовательская история требует реализации фичи, где таймкоды создаются кнопкой или горячей клавишей, заметки редактируются, а все сохраненные метки отображаются в боковой панели во время и после звонка. Задание: сформулируй Definition of Ready (условия, когда историю можно брать в спринт), Definition of Done (критерии, подтверждающие завершение работы) и Acceptance criteria (сценарии приемки с конкретными примерами). Формат: представь ответ в виде трех разделов, каждый с подзаголовком [DoR], [DoD], [AC]. В DoR перечисли 4 условия (например, уточнены ли UI/UX и API). В DoD включи тестирование, документирование и отсутствие регрессов. В AC опиши 3 сценария в виде таблицы "Действие пользователя — Ожидаемый результат".

Ответ

[DoR]

1. Уточнены и утверждены UI/UX-дизайны (макеты, wireframes, flow) для кнопки создания таймкода, горячей клавиши, формы редактирования заметки и боковой панели с отображением меток.
2. Определены и задокументированы API-эндпоинты (схема запросов/ответов, обработка ошибок) для создания, редактирования, получения и хранения таймкодов/заметок.
3. Полностью описаны нефункциональные требования (производительность, оффлайн-режим, доступность по ARIA, поддержка мобильных устройств).
4. Выявлены и согласованы все зависимости (backend-сервисы, библиотека горячих клавиш, состояние звонка) и определены критерии приоритезации edge-кейсов.

[DoD]

• Код написан, прошёл code review и успешно merged в main-ветку.
• Написаны и пройдены unit-тесты (≥80% покрытия) и integration-тесты для ключевых сценариев.
• Выполнено полное manual-тестирование по всем Acceptance Criteria, включая позитивные/негативные кейсы.
• Обновлена техническая документация (Swagger/OpenAPI, README, Confluence) и пользовательская инструкция.
• Проведено regression-тестирование существующих функций звонка и заметок — регрессов не выявлено.
• Фича прошла QA, одобрена Product Owner и готова к деплою.

[AC]

Действие пользователя	Ожидаемый результат
Во время активного звонка пользователь нажимает кнопку «Создать таймкод» в панели управления и сразу вводит текст заметки «Обсудили бюджет»	Таймкод с текущим временем звонка и заметкой мгновенно сохраняется на сервере; в боковой панели появляется новая запись с этим таймкодом и заметкой; при клике на запись воспроизводится видео/аудио с этого момента
Во время звонка пользователь нажимает горячую клавишу (по умолчанию Ctrl + Shift + T)	Создаётся новый таймкод с текущим временем (заметка пустая); запись сразу появляется в боковой панели; фокус автоматически переходит в поле редактирования заметки для быстрого ввода
После завершения звонка пользователь открывает боковую панель истории звонка, кликает по существующей метке и редактирует текст заметки на «Обсудили бюджет на Q2»	Изменения сохраняются мгновенно; обновлённая заметка отображается в панели как во время звонка, так и при повторном открытии истории; при воспроизведении звонка используется новый текст

[Egorius1268]

Фролов Егор 4/42

US 1.1: Я как наниматель могу получить ссылку на чат в Google Docs, когда нажимаю кнопку "Создать чат"

DoR:

• дизайн и расположение кнопки в UI утверждены
• у команды есть доступ к Google Drive API для создания документа и настройки доступа к нему в зависимости от прав
• утверждены роли, в зависимости от которых будут выданы права пользователям
• утвержден шаблон создаваемого документа
• есть доступ к Google Docs API для того, чтобы при создании документ редактировался по утвержденному шаблону
• утверждено время и формат хранения данного документа
• при регистрации в системе пользователь может привязать свой Google-аккаунт
• есть возможность хранения Google-аккаунтов пользователей для выдачи прав

DoD:

• у нанимателя есть доступ к созданию чата
• документ создается в Google Docs
• у соискателя есть доступ к документу по созданной ссылке
• приемочные тесты успешно пройдены
• функционал соответствует критериям приемки

AC:

• наниматель видит кнопку Создать чат и может ее нажать
• после нажатия кнопки нанимателем появляется кликабельная ссылка на документ в Google Docs
• документ создается в формате .docx
• ссылка на документ достоверна
• нанимателю и соискателю выдается соответствующая роль со своим функционалом
• соискателю доступна ссылка на документ
• соискатель не может редактировать созданный документ, если роль, к которой он принадлежит, это предполагает (например он пишет в чате только через функцию комментирования, чтобы он не мог удалять сообщения нанимателя)
• кнопка Создать чат становится неактивной при уже созданном чате
• соискатель не видит кнопки Создать чат, она доступна только нанимателю

AT (приемочные тесты):

• Сценарий 1. Пусть наниматель авторизован И чат не создан. Когда наниматель нажимает Создать чат, Тогда кнопка Создать чат становится неактивной, при успешном создании документа появляется ссылка на созданный в Google Docs по шаблону документ, в котором права выданы согласно ролям
• Сценарий 2. Пусть чат уже создан. Когда наниматель нажимает кнопку создать чат, Тогда новый документ не создается, а кнопка остается неактивной,
• Сценарий 3. Пусть Google Drive API недоступен ИЛИ Google Docs API недоступен. Когда наниматель нажимает кнопку Создать чат, Тогда появляется сообщение с текстом об ошибке: "Сервис недоступен, повторите попытку позднее", кнопка Создать чат продолжает быть активной, новый документ не создается
• Сценарий 4. Пусть чат создан И соискателю доступна ссылка на созданный документ И в роли соискателя при создании документа отключена возможность его редактирования. Когда соискатель переходит по ссылке на созданный документ, Тогда он переходит на Google Docs под своим аккаунтом и ему доступно только комментирование документа
• Сценарий 5. Пусть соискатель авторизован в системе И создан чат И его Google аккаунт не привязан к аккаунту в системе. Когда соискатель нажимает по ссылке для перехода к документу, Тогда появляется сообщение "Ошибка. Ваш аккаунт не привязан к Google аккаунту" и кнопка для авторизации через Google
• Сценарий 6. Пусть наниматель авторизован И его аккаунт Google не имеет прав для создания чата. Когда наниматель нажимает кнопку Создать чат, Тогда появляется сообщение: "Ошибка. У вас нет прав на создание чата. Обратитесь в поддержку.", кнопка продолжает быть активной, чат не создается

US 2.1: Я как пользователь ожидаю, что при открытии IDE в его UI отображается ссылка на Wiki страницу

DoR:

• расположение ссылки в UI IDE утверждено
• создан аккаунт для создания Wiki
• утвержден начальный пул Wiki-страниц
• утверждено содержание главной страницы Wiki
• утвержжден URL данной Wiki страницы

DoD:

• при открытии пользователем IDE в утвержденном месте отображается кликабельная ссылка
• ссылка ведет на главную страницу Wiki
• ссылка представлена в виде гиперссылки, а не чистого URL
• ссылка открывается в браузере в отдельной вкладке
• приемочные тесты успешно пройдены
• функционал соответствует критериям приемки

AC:

• при открытии IDE пользователь видит ссылку на вики в формате гипертекста в определенном месте UI
• содержание главной страницы соответствует утвержденному содержанию
• если Wiki недоступна, то пользователь видит сообщение об ошибке "Wiki временно недоступна"
• после нажатия на гиперссылку во внешнем браузере открывается главная страница Wiki в новой вкладке
• содержание Wiki и доступ к ней не зависят от роли пользователя

AT:

• Сценарий 1. Пусть пользователь авторизован в системе. Когда пользователь открывает IDE, Тогда в определенном месте UI отображается ссылка на Wiki-страницу в формате гиперссылки
• Сценарий 2. Пусть пользователь авторизован в системе И открыл IDE. Когда пользователь нажимает по гиперссылке "Wiki", Тогда в браузере в новой вкладке открывается главная страница Wiki
• Сценарий 3. Пусть пользователь открыл IDE И сервера Wiki недоступны. Когда пользователь нажимает по гиперссылке "Wiki", Тогда в самом IDE отображается сообщение об ошибке: "Wiki временно недоступна", никаких вкладок в браузере не открывается

US 2.2: Я как пользователь хочу видеть страницу с FAQ, когда захожу на Wiki

DoR:

• утверждено расположение страницы FAQ в иерархии всех страниц Wiki
• собран перечень часто задаваемых вопросов относительно продукта и соответствует реальным обращениям пользователей
• утвержден пул самых часто задаваемых вопросов
• утвержден текст ответов на утвержденный пул часто задаваемых вопросов

DoD:

• страница FAQ существует в Wiki в утвержжденном месте иерархии и доступна по постоянной ссылке
• страница FAQ имеет все утвержденные вопросы и ответы
• приемочные тесты успешно пройдены
• функционал соответствует критериям приемки

AC:

• в Wiki присутствует страница с названием "FAQ"
• на странице FAQ присутствуют все утвержденные вопросы
• на каждый вопрос есть соответствующие утвержденные ответы
• в тексте отсутствуют технические и грамматические ошибки
• страница FAQ доступна для всех пользователей и не зависит от ролей

AT:

• Сценарий 1. Пусть пользователь открыл главную страницу Wiki. Когда пользователь переходит в раздел, где находятся важные ссылки, Тогда он видит ссылку на страницу FAQ
• Сценарий 2. Пусть пользователь нажал на ссылку, ведущую на страницу FAQ. Когда пользователь переходит на страницу FAQ, Тогда он видит каждый вопрос из утвержденного пула часто задаваемых вопросов, на который присутствует соответствующий утвержденный ответ, в тексте вопросов и ответов не содержится грамматических и технических ошибок

US 3.1.1: Я как инвестор хочу, чтобы на почту приходила статистика использования ИИ в формате Excel когда наступает конец рабочего дня

DoR:

• известна почта инвесторов
• есть утвержденный шаблон текста для отправки по почте
• утверждены метрики для отслеживания в статистике
• есть утвержденный шаблон Excel документа
• время отправки сообщения утверждено

DoD:

• инвесторы получили на почту сообщение с утвержденным шаблоном текста и с прикрепленным файлом Excel
• протестирована отправка в конце рабочего дня
• файл Excel открывается без ошибок
• приемочные тесты успешно пройдены
• функционал соответствует критериям приемки

AC:

• инвесторам на почту пришло сообщение в конце рабочего дня
• текст сообщения соответствует утвержденному шаблону
• к сообщению прикреплен файл Excel
• в файле Excel присутствует статистика по утвержденным метрикам за прошедший рабочий день
• даже если за день не было использовано ИИ, сообщение все равно отправляется на почту в конце рабочего дня, Excel файл пустой
• если файл Excel поврежден, то письмо не отправляется, а администратору приходит уведомление

AT:

• Сценарий 1. Пусть наступило оговоренное время конца рабочего дня И за день были зарегистрированы использования ИИ, Когда срабатывает триггер для отправки сообщения, Тогда каждому инвестору на почту приходит сообщение с текстом, который соответствует утвержденному шаблону, а к сообщению прикреплен Excel файл, который содержит статистику за данный рабочий день по всем утвержденным метрикам
• Сценарий 2. Пусть наступило время конца рабочего дня И Excel файл создан с ошибкой. Когда срабатывает триггер отправки письма, Тогда инвестор не получает письмо и администратору отправляется уведомление об ошибке
• Сценарий 3. Пусть за рабочий день не было ни одного использования ИИ. Когда наступает время окончания рабочего дня, Тогда инвесторам отправляется письмо с утвержденным текстом и прикрепленным Excel файлом, сам Excel файл содержит нули

US 3.1.2: Я как разработчик хочу, чтобы можно было скачивать excel отчет по использованию ИИ из ollama dashboard, когда я нажимаю кнопку "Скачать отчет" и отправлять его по mail.ru, когда нажимаю кнопку "Отправить файл"

DoR:

• есть метрики для сбора статистики по использованию ИИ
• есть почта разработчика
• есть шаблон текста письма
• есть формат Excel документа
• утверждено, какие данные и за какой срок должны быть в отчете
• есть макет UI с кнопкой для скачивания статистики
• утвержден способ отправки отчета по mail.ru

DoD:

• разработчик может скачать Excel-отчет из Ollama Dashboard через кнопку "Скачать отчет"
• скачанный файл содержит утвержденные метрики и открыватся без ошибок
• есть функция отправки отчета через mail.ru через кнопку "Отправить файл"
• письмо успешно доставляется на указанную почту
• приемочные тесты успешно пройдены
• функционал соответствует критериям приемки

AC:

• разработчик видит в интерфейсе Ollama Dashboard кнопку "Скачать Excel-отчет"
• при нажатии на кнопку скачивается файл в формате .xlsx
• файл содержит утвержденные метрики за определенный срок
• файл открывается без ошибок
• имеется возможность отправки данного отчета по mail.ru через отдельную кнопку
• письмо успешно доставляется на указанную почту, текст соответствует утвержденному шаблону
• к письму прикреплен корректный Excel-файл
• если скачивание файла не удалось, то пользователь видит сообщение об ошибке: "Скачивание файла не удалось"
• если отправка на почту не удалась, то пользователь видит сообщение об ошибке: "Отправка файла не удалась"

AT:

• Сценарий 1. Пусть разработчик авторизован в системе. Когда разработчик нажимает кнопку "Скачать Excel-отчет", Тогда браузер начинает скачивание файла с расширением .xlsx, в котором содержатся все утвержденные метрики
• Сценарий 2. Пусть разработчик авторизован в системе И скачал файл со статистикой. Когда разработчик нажимает кнопку "Отправить на mail.ru" и вводит корректный почтовый адрес, Тогда система показывает сообщение "Файл отправлен", после чего на почту приходит файл с текстом, соответствующим утвержденному шаблону и с прикрепленным Excel-файлом с утвержденными метриками.
• Сценарий 3. Пусть разработчик авторизован в системе И сервера Ollama Dashboard недоступны. Когда разработчик нажимает кнопку "Скачать Excel-отчет", Тогда система показывает сообщение: "Ошибка скачивания, повторите позднее"
• Сценарий 4. Пусть разработчик авторизован в системе И сервера mail.ru недоступны. Когда разработчик нажимает кнопку "Отправить файл", Тогда система показывает сообщение "Ошибка отправки файла, повторите позднее"

==================================================================================

C помощью LLM

Модель: Deepseek
Чтобы не городить еще больше это полотно, будет рассмотрена только одна пользовательская история
US 3.1.1: Я как инвестор хочу, чтобы на почту приходила статистика использования ИИ в формате Excel когда наступает конец рабочего дня

---

Zero-shot

Промпт: "вот у меня есть такая пользовательская история:
US 3.1.1: Я как инвестор хочу, чтобы на почту приходила статистика использования ИИ в формате Excel когда наступает конец рабочего дня
Напиши для нее критерий приемки, DoR, DoD и приемочные тесты"
Результат:
Вот структурированный набор артефактов для пользовательской истории US 3.1.1 на русском языке.

1. Критерии приёмки (Acceptance Criteria)

1. Время отправки: Система автоматически отправляет письмо на указанный email инвестора в момент наступления конца рабочего дня (согласно часовому поясу, указанному в профиле инвестора или настройках системы). Допустимая задержка отправки — не более 5 минут.
2. Формат вложения: Письмо содержит вложение с расширением .xlsx (Microsoft Excel), которое корректно открывается в Excel 2016+, Google Sheets и LibreOffice.
3. Содержимое файла:
   • В файле присутствует минимум 2 листа: «Сводка за день» и «Детализация по запросам».
   • На листе «Сводка» отображается: Общее кол-во запросов к ИИ за день, Среднее время ответа, Топ-5 использованных функций/моделей, Кол-во активных пользователей.
   • Данные в файле соответствуют периоду: от 00:00 до времени отправки текущих суток.
4. Тема и тело письма: Тема письма содержит дату отчета (например: Статистика использования ИИ за ДД.ММ.ГГГГ). В теле письма есть краткое текстовое резюме основных цифр (повторяющее сводку).
5. Адресат: Письмо отправляется только на верифицированный email инвестора, указанный в разделе «Управление подписками».

2. DoR (Definition of Ready) — Критерии готовности к разработке

История считается готовой к взятию в спринт, если:

• Уточнён и задокументирован источник данных статистики ИИ (конкретные таблицы БД или логи).
• Определён часовой пояс для расчёта «конца рабочего дня» (UTC, МСК или время из настроек аккаунта).
• Согласован макет Excel-отчета (названия колонок, формат чисел, типы диаграмм, если есть).
• Известен механизм доставки писем (какой SMTP-сервер/почтовый сервис используется).
• Определены нефункциональные требования: максимальный объём файла (например, не более 5 МБ) и поведение при отсутствии данных за день.

3. DoD (Definition of Done) — Критерии завершённости

История считается выполненной, когда:

• Реализован фоновый процесс/крон-задача, запускаемая по расписанию в расчётное время.
• Написан и протестирован алгоритм выгрузки данных из системы аналитики ИИ.
• Реализовано формирование .xlsx файла (с помощью библиотек типа OpenXML, EPPlus или аналогов).
• Реализована отправка письма с вложением через выбранный почтовый сервис.
• Добавлено логирование успешных/неудачных попыток отправки.
• Проведено ручное тестирование на тестовом окружении с проверкой получения письма и открытия файла.
• Код смержен в основную ветку и развернут на тестовом стенде.
• Документация для инвестора (инструкция как подписаться/отписаться от рассылки) обновлена в базе знаний.

4. Приёмочные тесты (Acceptance Tests)

1. Своевременность: Письмо уходит в 18:00 ± 5 мин при наличии активности.
2. Формат: Файл открывается в Excel/Sheets без ошибок.
3. Нулевая активность: Отчёт приходит с показателями «0» или пометкой «Нет данных».
4. Дата: Тема и тело содержат корректную дату отчётного дня.
5. Выходные: Письмо отправляется ежедневно (если не оговорено иное).
6. Сбой отправки: Лог ошибки + повторная попытка при восстановлении связи.

---

Zero-Shot CoT:

---

Промпт: "Есть вот такая пользовательская история:
US 3.1.1: Я как инвестор хочу, чтобы на почту приходила статистика использования ИИ в формате Excel когда наступает конец рабочего дня
Нужно написать для нее критерий приемки, DoR, DoD и приемочные тесты
Задача непростая, поэтому давай подумаем шаг за шагом"

Результат:
Давай разберем задачу последовательно. Сначала определим, что означает каждый артефакт в контексте пользовательской истории, а затем детально пропишем их содержание.

Краткий словарь терминов

• DoR (Definition of Ready) — критерии готовности истории к взятию в разработку. Без их выполнения команда не начинает работу.
• Критерии приемки (Acceptance Criteria) — конкретные, проверяемые условия, которым должна удовлетворять функциональность с точки зрения заказчика/пользователя. Это часть требования.
• Приемочные тесты (Acceptance Tests) — сценарии проверки выполнения критериев приемки, часто в формате "Given-When-Then" или контрольный список.
• DoD (Definition of Done) — общекомандные условия, при которых задача считается полностью завершенной (включая код, тесты, документацию, деплой и т.д.).

1. Definition of Ready (DoR) для US 3.1.1

Перед тем как разработчик начнет реализацию, должны быть выполнены следующие условия:

• Определен шаблон Excel-отчета (утвержден инвестором/заказчиком): какие конкретно столбцы/графики должны быть (например, кол-во запросов к ИИ, среднее время ответа, топ используемых моделей, распределение по часам и т.д.).
• Согласовано понятие "конец рабочего дня" с учетом часового пояса инвестора и возможных праздничных/выходных дней (календарь рабочих дней).
• Согласован список получателей письма (один инвестор или группа рассылки).
• Определен источник данных для статистики (API сервиса ИИ, лог-файлы, БД) и подтверждена доступность этих данных для сценария формирования отчета.
• Утверждены нефункциональные требования: допустимое время доставки после завершения рабочего дня, размер файла, частота отправки (ежедневно, только в будни и т.п.).
• Определен метод отправки email (какой SMTP-сервер, от какого адреса, требования к безопасности/аутентификации).
• Уточнено поведение при отсутствии данных за день (отправлять пустой отчет, не отправлять ничего или отправлять уведомление об отсутствии активности).

2. Критерии приемки (Acceptance Criteria)

1. Отправка в конце рабочего дня

   • Система автоматически формирует и отправляет отчет на указанную почту в заданное время (например, 18:00 по часовому поясу инвестора) только в рабочие дни, согласно утвержденному календарю.
   • Если день выходной/праздничный, отчет не отправляется.

2. Формат отчета Excel

   • Отчет прикреплен к письму в виде файла с расширением .xlsx.
   • Имя файла содержит дату отчета в формате Статистика_ИИ_ГГГГ-ММ-ДД.xlsx.
   • Структура файла соответствует утвержденному шаблону (набор колонок, наличие итоговой строки, возможно график).

3. Содержание письма

   • Тема письма: Статистика использования ИИ за [ДД.ММ.ГГГГ].
   • Тело письма содержит краткое текстовое резюме (например, "Добрый день! Во вложении отчет по использованию ИИ за [дата].") и подпись отправителя.

4. Данные в отчете

   • Отчет включает статистику только за прошедший рабочий день (с 00:00 до 23:59 или с учетом рабочих часов, если оговорено).
   • Отображаются следующие метрики (пример):
     • Общее количество запросов к ИИ.
     • Количество уникальных пользователей.
     • Среднее время ответа.
     • Топ-5 используемых функций/моделей.
   • При полном отсутствии данных за день отчет всё равно формируется с нулевыми значениями и отправляется.

5. Надежность и обработка ошибок

   • Если в момент формирования отчета источник данных недоступен, система должна выполнить повторную попытку (до 3 раз с интервалом 5 минут). В случае окончательной неудачи — отправить уведомление администратору (или инвестору) об ошибке.
   • Если отправка письма не удалась из-за проблем с почтовым сервером, должна быть предусмотрена повторная попытка и логирование ошибки.

6. Безопасность

   • Доступ к данным для формирования отчета имеет только авторизованный сервисный аккаунт.
   • Пароль почтового ящика или ключ API хранится в зашифрованном виде (в secrets менеджере).

3. Приемочные тесты (Acceptance Tests)

Сценарий 1: Успешная отправка отчета в будний день

Given сегодня рабочий день (например, вторник), время 17:59 (по часовому поясу инвестора)
And в системе есть данные использования ИИ за текущий день
When наступает 18:00
Then

• Запускается процесс формирования отчета
• Создается файл Excel с корректной датой в имени и данными за день
• На email инвестора отправляется письмо с темой, содержащей дату, и вложением
• В логах фиксируется успешная отправка

Сценарий 2: Отсутствие данных за рабочий день

Given сегодня рабочий день, но за прошедший день не было ни одного обращения к ИИ
When наступает время отправки
Then

• Формируется Excel-файл с нулевыми значениями во всех полях (количество запросов = 0 и т.д.)
• Письмо отправляется с тем же форматом темы и тела
• Инвестор получает отчет, явно отражающий отсутствие активности

Сценарий 3: Выходной/праздничный день

Given сегодня суббота или официальный праздник (согласно календарю)
When наступает 18:00
Then

• Процесс отправки отчета не запускается
• В логах появляется запись "Отчет не отправлен, так как сегодня нерабочий день" (или отсутствует запись о запуске)

4. Definition of Done (DoD) для задачи

• Код функциональности написан и проходит статический анализ (линтеры, форматтеры).
• Написаны и успешно пройдены модульные тесты для логики формирования отчета и отправки письма.
• Написаны и успешно пройдены интеграционные тесты (включая мок почтового сервера).
• Выполнены все перечисленные приемочные тесты (ручные или автоматизированные) в тестовом окружении.
• Проведено код-ревью другим разработчиком, замечания исправлены.
• Конфигурация времени отправки и часового пояса вынесена в настройки окружения.
• Добавлена документация для администратора: как изменить шаблон Excel, список получателей, расписание.
• Функциональность развернута в прод-окружении и проверена отправка тестового отчета в нерабочее время.
• Задача отмечена как завершенная в трекере, актуализирован статус в доске.

---

RCTF:

---

Промпт: "Ты - опытный Scrum-мастер с двадцатилетним опытом в этой и смежных профессиональных сферах
Наша команда разрабатывает приложение для помощи в поиске работы соискателями, в это приложение встроен ИИ, чтобы помогать соискателю в собеседованиях
У нас есть следующая пользовательская история: "US 3.1.1: Я как инвестор хочу, чтобы на почту приходила статистика использования ИИ в формате Excel когда наступает конец рабочего дня". К данной пользовательской истории надо написать критерии приемки, DoD, DoR и приемочные тесты.
Оформи ответ в виде структурированных списков, разделив текст на 4 четких блока (Критерии, DoD, DoR, Тесты)"
Результат:
Как опытный Scrum-мастер, вижу, что запрос инвестора на автоматическую отчетность — это классическая история с высокими рисками на стыке data engineering и инфраструктуры доставки. Здесь важно не только «сделать файл», но и обеспечить надежность, чтобы инвестор не звонил в панике в 19:01, когда письма нет.

Вот структурированный набор артефактов для команды разработки.

Блок 1. Критерии приемки (Acceptance Criteria)

Эти пункты являются контрактом между PO и командой о том, что именно должно работать в конце спринта.

• AC1: Временной триггер

  • Отправка отчета происходит автоматически строго в 18:00 по часовому поясу головного офиса (UTC+3 / МСК).
  • Данные в отчете должны охватывать период с 00:00:00 до 23:59:59 предыдущих календарных суток.
  • Уточнение: Если инвестор находится в другом часовом поясе, система должна отправлять отчет в 18:00 по времени сервера компании, а не по времени подписчика.

• AC2: Формат и содержимое вложения

  • Файл должен быть в формате Microsoft Excel (.xlsx).
  • Имя файла должно содержать дату в формате YYYY-MM-DD. Пример: AI_Usage_Report_2026-04-10.xlsx.
  • Файл должен содержать минимум 3 вкладки (Sheets):
    1. Summary (Дашборд): Ключевые метрики крупно (Total Sessions, Avg Duration, Top 3 Questions).
    2. Daily Usage: Детализированная таблица с разбивкой по часам.
    3. Interviews: Статистика по длительности и тематикам собеседований.

• AC3: Состав данных (Обязательные поля в Excel)

  • Total AI Sessions: Количество уникальных сессий, где пользователь взаимодействовал с ИИ-тьютором.
  • Avg Session Length (min): Средняя продолжительность тренировки собеседования.
  • Questions Asked: Общее количество вопросов, заданных ИИ.
  • Avg Response Time (sec): Среднее время ответа модели (важный технический показатель стабильности).
  • Top Failure Area: Самая частая категория ошибок соискателей по мнению ИИ (например, "Рассказ о себе", "Зарплатные ожидания").

• AC4: Отказоустойчивость отправки

  • Если первая попытка отправки письма провалилась (SMTP error), система должна совершить 3 ретрая с интервалом в 15 минут.
  • Если все попытки провалились, в 21:00 отправляется Alert в Slack / Teams администратору с пометкой "CRITICAL: Report Delivery Failed for Investor".

• AC5: Администрирование получателей

  • Email-адрес(а) для отправки должны настраиваться в Admin-панели, а не быть захардкожены в коде.
  • Должна быть возможность добавить до 5 получателей для данной рассылки.

Блок 2. Определение готовности к спринту (Definition of Ready, DoR)

Прежде чем команда начнет пулл этой задачи в спринт, проверяем наличие следующих артефактов.

1. Доступ к данным: Подтверждено, что данные для отчета уже сохранены в аналитической БД или Data Lake (история не требует предварительной разработки сбора метрик с нуля).
2. Дизайн Excel-файла: Утвержден макет Excel-файла (образец в Confluence/SharePoint). Команда точно знает, как выглядят заголовки колонок.
3. Учетная запись SMTP: Выделен и передан команде сервисный почтовый ящик (noreply-report@company.com) с паролем/токеном для отправки.
4. Оценка: Задача оценена в Story Points и декомпозирована на технические подзадачи (Backend CRON, Excel Generator Service, SMTP Client).
5. Нефункциональные требования: Определена политика хранения сгенерированных файлов (хранить на сервере 7 дней, затем удалять для экономии места).

Блок 3. Определение готовности (Definition of Done, DoD)

Это технический чек-лист, общий для всех задач команды, применимый к данной US.

1. Разработка:
   • Код залит в основную ветку develop или main через Pull Request.
   • Проведено Code Review минимум одним другим разработчиком (комментарии исправлены).
2. Тестирование:
   • Написаны и проходят модульные тесты (Unit tests) на логику генерации Excel-файла (например, проверка формул подсчета средних значений).
   • Написан интеграционный тест, эмулирующий вызов CRON-задачи.
   • Проведено ручное тестирование на тестовом окружении (STAGE): письмо пришло, файл открывается без ошибок в MS Excel и Google Sheets.
3. Документация:
   • Описан алгоритм пересчета метрик в Confluence (что именно мы считаем "сессией с ИИ").
   • Обновлены Runbooks Ops-команды (инструкция на случай падения сервиса рассылки).
4. Мониторинг:
   • Добавлены метрики в Grafana/Prometheus: cron_job_report_duration_seconds, cron_job_report_failure_total.
5. Релиз: История задеплоена на Production окружение.

Блок 4. Приемочные тесты (Acceptance Tests)

Сценарии для QA-инженера и Product Owner на демо.

ID	Название теста	Шаги (Given-When-Then)
AT-1	Генерация отчета за предыдущий день	Given: Сегодня 11 апреля 2026 года, 17:55. В системе есть данные за 10 апреля: 150 сессий, 1200 вопросов. When: Наступает 18:00 (запускается CRON). Then: Инвестор получает письмо с вложением AI_Usage_Report_2026-04-10.xlsx. And: В файле на вкладке Summary указано "Total AI Sessions: 150".
AT-2	Проверка часового пояса	Given: Время на сервере 18:00 МСК. В настройках админа указана отправка "End of Work Day". When: Запуск джобы. Then: Отправка происходит именно в 18:00 МСК, даже если SMTP-сервер находится в датацентре в Ирландии (UTC+0).
AT-3	Пустой отчет в выходной день	Given: Сегодня понедельник. За воскресенье не было ни одной сессии с ИИ. When: Срабатывает отправка отчета за воскресенье. Then: Письмо все равно отправляется. And: Файл содержит данные с нулями (Total AI Sessions: 0).
AT-4	Сбой SMTP сервера	Given: SMTP сервер не отвечает (симуляция ошибки 550). When: CRON пытается отправить отчет в 18:00. Then: В логах приложения появляется запись об ошибке. And: Система автоматически повторяет попытку в 18:15, затем в 18:30.
AT-5	Целостность Excel файла	Given: Отчет сгенерирован и получен. When: Пользователь открывает файл и нажимает "Сохранить как". Then: Не возникает ошибок повреждения контента ("File is corrupted"). And: Даты в колонке Date отображаются в читаемом формате.
AT-6	Добавление нового инвестора	Given: В админке в список получателей добавлен investor2@fund.com. When: Наступает 18:00. Then: Письмо с одинаковым содержанием уходит на investor1@fund.com И на investor2@fund.com.

---

Итог

Ответы LLM намного сильнее углубили первоначально написанный мной ответ. Критерии приемки намного более конкретизированы, добавлены различные параметры, требования и т.д. DoD больше соответствует определению из Agile и относится не конкретно к этой пользовательской истории, а в целом ко всей задаче. В DoR были расширены разные требования и зафиксированы предварительные условаия. Приемочные тесты написаны намного подробнее, чем в исходном тексте.
Однако все эти подробности сделали критерии довольно избыочными, добавляются пункты, которые не предполагались в изначальной постановке задачи, а приемочные тесты из-за избыточной детализации уже становятся функциональными тестами, которые проверяют не бизнес-логику а техническую сторону
В целом, лучше всего справился промптинг RCTF, добавивший глубины , однако для завершения задачи вскты и е равно придется редактировать ответы ИИ, отсекая лишние пункты и упрощая слишком детализированные приемочные тесты и критерии приемки

[Victor2004]

Пыжов Виктор 4/147
LLM: deepseek

Применены техники: Zero‑shot (первичная генерация), Few‑shot (структура DoR/DoD/AC из примера доставки), CoT (выявление пробелов), ToT (ветвление альтернатив), RCTF (самопроверка противоречий).

US1: Поиск партнёра + заполнение профиля (объединено)

DoR

• Фильтры: язык, уровень (A1–C2), часовой пояс (±2 ч), интересы (категории + ручной ввод).
• Матчинг: родной язык А = изучаемый язык Б, и наоборот + хотя бы 1 общий интерес.
• Максимум активных пар: 5. При отсутствии – предложение расширить фильтры.
• Уровни: по CEFR, для языков с другой системой – таблица соответствия.
• Верификация: тест (15 вопросов) или самооценка (бейдж «неподтверждённый»).

DoD

• Экран поиска с фильтрами и кнопкой «Найти», UI‑тесты.
• REST‑эндпоинт /match (<500 мс), алгоритм задокументирован.
• Push при найденном партнёре. Логирование матчей и отказов.
• Экран профиля: родной язык (обяз.), до 3 изучаемых с уровнем и способом верификации.
• Тест генерирует уровень с пояснением, возможна ручная корректировка.
• Мониторинг: алерт при снижении матчей (<10% от активных пользователей в час).

Критерии приёмки (сценарии)

1. Пользователь выставил фильтры → система возвращает карточки партнёров с именем, фото, уровнем, интересами, рейтингом (без контактов до взаимного подтверждения).
2. Нет партнёров → сообщение «Никого не найдено. Расширить уровень или часовой пояс?» с кнопкой автоматического расширения.
3. Неподтверждённый профиль → при попытке поиска показывает, что нужно заполнить (родной язык, 1 изучаемый, фото, тест/самооценка).
4. Пользователь пытается указать родной язык как изучаемый → ошибка «Нельзя изучать родной язык».
5. После сохранения профиля изменения отражаются в матчинге в течение 1 минуты.

US2: Чат с языковым обменом + транскрипция (объединено)

DoR

• Сессия: 15 мин на язык А, затем 15 мин на Б (настраивается до старта). Смена языка визуально (цвет пузырьков, таймер, звук за 30 сек).
• Поддерживается: текст (до 2000 символов), голос (до 2 мин), фото (до 5 МБ).
• Автомодерация: стоп-слова на 12 языках – сообщение не отправляется, после 3 нарушений блокировка чата на 24 ч.
• Транскрипция для 8 языков (англ., исп., фр., нем., ит., порт., рус., кит.). Минимальная точность 85% (WER).
• Офлайн: сообщения сохраняются локально, отправляются после восстановления связи.

DoD

• Чат через WebSocket, реконнект, очередь офлайн‑сообщений.
• Таймер серверный, синхронизация через WebSocket.
• Голосовые сообщения: запись, транскодирование в MP3, хранение 30 дней.
• Исправление: выделить текст → добавить комментарий → блок под оригиналом.
• Транскрипция асинхронная (STT + перевод через API), кнопка «Показать транскрипцию»/«Перевести». При низком качестве – предупреждение.
• Логирование ошибок распознавания, дашборд метрик.

Критерии приёмки

1. Отправка текста → доставка партнёру с задержкой p95 < 2 секунды, цвет пузырька соответствует активному языку.
2. За 30 секунд до смены языка → звуковой сигнал, через 30 сек смена цвета и сброс таймера.
3. Выделение ошибки в сообщении → появление блока исправления под оригиналом (оригинал не меняется).
4. Голосовое сообщение на поддерживаемом языке → через ≤20 сек появляется кнопка «Показать транскрипцию», текст с точностью ≥85%. При низком качестве – сообщение «Транскрипция недоступна».
5. Пропал интернет на 2 минуты, отправлено 3 сообщения → после восстановления все доставляются в том же порядке.

US3: Прогресс + еженедельный дайджест (объединено)

DoR

• Метрики: сессии, минуты, отправленные/полученные исправления.
• Стрик: +1 за день с хотя бы одной сессией, обнуляется при пропуске. Исторический максимум сохраняется. Один раз в месяц можно «заморозить» день.
• Бейджи (12 штук), в т.ч. «Полиглот»: подтверждённый уровень (тест или оценка от 3 партнёров) не ниже B1 на двух изучаемых языках.
• Дайджест: каждое воскресенье 9:00 по часовому поясу пользователя. При нулевой активности – мотивационное письмо.
• Отписка: одноклик из письма или переключатель в настройках (независимо от push).

DoD

• Экран прогресса: график активности, диаграммы по языкам. Данные через /api/progress.
• Cron ежедневно обновляет стрик. При получении бейджа – push и запись в user_badges.
• Дайджест: генерация по расписанию (учёт часовых поясов), шаблон письма. Логирование отправок, алерт при ошибках >5%.
• Хранение: текст сообщений – 1 год, голос/фото – 30 дней.

Критерии приёмки

1. После 3 сессий по 15 мин и 5 исправлений → на дашборде (период «Всё время») отображается 3 сессии, 45 мин, 5 отправленных исправлений.
2. Сессии в понедельник, вторник, четверг → стрик = 2 (обнулился в среду), исторический максимум = 2.
3. Завершена 10‑я сессия → push «Вы получили бейдж "Первые 10 сессий"!».
4. Пользователь получил B1 по испанскому (тест) и B2 по французскому (оценки 3 партнёров) → выдан бейдж «Полиглот» (однократно).
5. Активный пользователь из Москвы → в воскресенье 9:00 получает письмо с сессиями, минутами, топ-3 ошибок. При нулевой активности – мотивационное письмо без статистики.
6. Отписка по ссылке из письма → в настройках приложения переключатель «Email дайджест» выключен, push‑уведомления продолжают работать.

Итог

Применение CoT и ToT позволило систематически покрыть все недостатки. RCTF добавил итеративную проверку на конфликты (например, одновременное хранение данных 30 дней и 1 год – теперь разнесено по типам). Few-shot на примере сервиса доставки задал правильную структуру (DoR/DoD/AC как сценарии). Zero-shot обеспечил базовую генерацию без переобучения под конкретные шаблоны.

[Thegad1411]

Абрамов Владислав 4/147

Платформа для управлениями онлайн-хакатонами

Us 1.1: я как Организатор хочу иметь конструктор этапов хакатона с возможностью настройки дедлайнов и критериев оценки, чтобы автоматизировать управление ходом мероприятия.

DoR (Definition of Ready):

1. Определены типы этапов (регистрация, отбор, работа над проектом, финал).
2. Существует утвержденный UI/UX макет личного кабинета организатора.
3. Согласована логика уведомлений участников при смене этапа.
4. Определены системные ограничения по количеству участников и команд.

DoD (Definition of Done):

1. Реализована возможность создания, редактирования и удаления этапов.
2. Валидация дат работает корректно (дата окончания этапа не может быть раньше даты начала).
3. Интерфейс полностью соответствует макетам в Figma.
4. Код прошел Code Review и покрыт Unit-тестами (покрытие не менее 80%).

AC (Acceptance Criteria)

1. Организатор может задать название, описание и временные рамки для каждого этапа.
2. При наступлении дедлайна этапа система автоматически блокирует возможность загрузки решений для участников.
3. Организатор может прикрепить файл с регламентом к конкретному этапу.
4. Изменения в расписании мгновенно отображаются в календаре событий у всех участников.

US 2.1: я как Участник хочу иметь функционал «Поиск команды», чтобы найти единомышленников со стеком технологий, дополняющим мой.

DoR (Definition of Ready):

1. Определен список тегов для навыков. Например тег языков (Python or C++) и теги навыков(Backend, fronted or fullstack).
2. Разработана схема базы данных для хранения профилей участников и их поисковых запросов.
3. Определен алгоритм ранжирования (по совпадению навыков или по времени создания анкеты).

DoD (Definition of Done):

1. Пользователь может создать карточку «Ищу команду» с описанием своего опыта.
2. Реализован фильтр по навыкам и ролям.
3. Кнопка «Откликнуться» отправляет уведомление капитану команды или другому участнику.
   4.Функционал протестирован на мобильных устройствах (адаптивная верстка).

AC (Acceptance Criteria):

1. В профиле пользователя отображается статус «В команде» или «В поиске».
2. Поиск позволяет фильтровать анкеты по минимум 3-м критериям одновременно (роль, язык программирования, часовой пояс).
3. Участник получает push-уведомление или письмо на почту, когда кто-то предлагает вступить в команду.
4. Пользователь может скрыть свою анкету из поиска в любой момент.

US 3.1: я как Ментор хочу иметь единую панель мониторинга прогресса закрепленных за мной команд, чтобы вовремя давать консультации и отслеживать проблемные места.

DoR (Definition of Ready):

1. Определены метрики прогресса (заполнение ТЗ, ссылка на репозиторий, пройденные чек-ин сессии).
2. Выбран инструмент для интеграции с внешними сервисами (например, GitHub API).
3. Разработан макет дашборда ментора.

DoD (Definition of Done):

1. Создан интерфейс со списком всех закрепленных команд и их текущим статусом.
2. Реализована возможность оставлять «Менторские заметки», видимые только организаторам и другим менторам.
3. Система автоматически подсвечивает команды, которые не обновляли статус проекта более 12 часов.

AC (Acceptance Criteria):

1. Ментор видит список ссылок на рабочие материалы команды (Figma, GitHub, Notion) в одном окне.
2. В панели мониторинга есть кнопка быстрого вызова видеосвязи с командой.
3. Ментор может выставить оценку за промежуточный этап («Чек-ин»), которая сохранится в общей базе рейтинга.
4. Точность отображения статуса репозитория (последний коммит) составляет не более 5 минут задержки от реального времени.

[GitSwaggCat]

Команда 4/147:
Новосёлов Николай, Балясова Елена

Биржа криптовалют

US1: Я как пользователь хочу получать уведомления о снижении цены на токены или коины.

DoR (Definition of Ready):

• Определён список поддерживаемых криптовалют (BTC, ETH, SOL, TON, USDT и др.)
• Уточнён источник цен (WebSocket API биржи / агрегатор)
• Определены способы доставки уведомлений (Push в интерфейсе биржи / Telegram / Email)
• Определён формат ввода целевой цены (в USD / USDT / BTC)
• Уточнены настройки оповещения: Разовое или с определенным временем повтора

DoD (Definition of Done):

• Реализован интерфейс создания оповещения (страница / модальное окно)
• Реализована фоновая служба мониторинга цен (сравнение текущей цены с целевой для всех оповещений)
• Пользователь может настроить уведомления(порог цены, интервал времени, название токена или коина и т.д)
• Реализована привязка Telegram и Email в настройках профиля (если выбраны эти способы)
• Написаны юнит-тесты (проверка срабатывания порога, защита от дублирования)

AC (Acceptance Criteria):

• Пользователь может создать оповещение, и оно отработает при определенных условиях
• Если Telegram или Email не привязаны, при попытке выбрать этот способ показывается подсказка: «Сначала привяжите в настройках профиля»
• Текст совпадает с критериями определенными разработчиками
• Пользователь может удалить оповещение
• Пользователь может редактировать оповещение

US2: Я как разработчик хочу иметь автоматическое логирование и уведомление об ошибках API при торговле

DoR (Definition of Ready):

• Определён список API-эндпоинтов, которые подлежат мониторингу (например, /order, /balance, /ticker)
• Уточнены коды ошибок, которые считаются критическими (4xx, 5xx, таймауты)
• Определены каналы уведомлений (Telegram / Slack / Email) и их приоритеты
• Уточнён формат лога: timestamp, endpoint, HTTP-метод, статус, тело запроса, тело ответа (без чувствительных данных)
• Уточнена политика хранения логов (срок, ротация, удаление)

DoD (Definition of Done):

• Реализован middleware для логирования всех исходящих API-запросов, логи сохраняются в централизованное хранилище
• Реализовано распознавание кодов ошибок (4xx, 5xx, таймаут)
• Реализована отправка уведомлений
• Написаны юнит-тесты (генерация ошибок, маскирование, защита от дублирования)
• Проведено нагрузочное тестирование (логгер не замедляет API-вызовы)

AC (Acceptance Criteria):

• Каждый вызов API логируется с полями(timestamp, endpoint, method, status_code, duration_ms)
• При успешном ответе (2xx) уведомления не отправляются
• Фильтрация логов для более удобного анализа
• При ошибке (5xx) отправляется уведомление с пометкой "CRITICAL"
• В уведомлении не используются чувствительные данные

US3: Я как финансовый специалист хочу автоматически получать финансовые отчеты

DoR (Definition of Ready):

• Определены типы финансовых отчётов (баланс по кошелькам, оборот комиссий, объёмы торгов, P&L биржи)
• Утверждены форматы отчётов (PDF / Excel / CSV)
• Уточнены периодичности отправки (ежедневно / еженедельно / ежемесячно / ежеквартально)
• Определены каналы доставки
• Определено поведение при ошибке отправки (повторные попытки / уведомление администратору)

DoD (Definition of Done):

• Реализован интерфейс настройки автоматических отчётов
• Реализована фоновая служба (cron) для запуска генерации по расписанию
• При ошибке отправки выполняется повторная итерация, после повторной ошибки отправляется уведомление администратору
• Реализован журнал всех отправок
• Написаны юнит-тесты (генерация отчёта, отправка, обработка ошибок)

AC (Acceptance Criteria):

• Финансовый специалист может зайти в раздел «Автоматические отчёты» и увидеть список доступных типов отчётов
• Для каждого отчёта можно настроить расписание, получатели, формат
• В назначенное время отчёт автоматически генерируется и отправляется
• Генерация отчёта с N+ строками занимает не более N секунд
• В разделе «История отправок» видны все автоматические отправки с датой, временем, статусом (успех / ошибка)

C помощью LLM

US1: Я как пользователь хочу получать уведомления о снижении цены на токены или коины.

<GigaChat(Рассуждение), Zero-shot>

Prompt: "US1: "Я как пользователь хочу получать уведомления о снижении цены на токены или коины." Вот User Story сделай DoR, DoD, AC.

DoR (Definition of Ready):

• Есть список токенов/коинов, по которым пользователь хочет получать уведомления.
• Определён порог снижения цены (в процентах или абсолютных значениях).
• Выбран способ получения уведомлений (push, email, Telegram и др.).
• Настройки пользователя сохранены и доступны для обработки системой.
• Интеграция с источником актуальных цен токенов реализована и протестирована.

DoD (Definition of Done):

• Пользователь может добавить/удалить токены/коины для отслеживания.
• Система корректно фиксирует снижение цены по выбранным токенам.
• Уведомление отправляется пользователю при достижении заданного порога.
• Пользователь получает уведомление выбранным способом.
• Система не отправляет дублирующие уведомления до следующего изменения цены.
• Все настройки пользователя сохраняются между сессиями.
• Реализована защита от ошибок при недоступности источника цен.

AC (Acceptance Criteria):

• Пользователь может выбрать один или несколько токенов/коинов для отслеживания.
• Пользователь задаёт порог снижения цены (например, -5% или -100 рублей).
• Система ежедневно (или чаще) проверяет актуальную цену выбранных токенов.
• При снижении цены до заданного порога пользователь получает уведомление.
• Уведомление содержит: название токена, текущую цену, величину снижения, время события.
• Пользователь может изменить или отключить уведомления в любой момент.
• Система не отправляет уведомления, если цена не достигла порога или уже была ниже него.
• В случае сбоя получения данных система сообщает об ошибке и повторяет попытку позже.

<GigaChat(Рассуждение), Chain of Thought>

Prompt: "US1: "Я как пользователь хочу получать уведомления о снижении цены на токены или коины." Вот User Story сделай DoR, DoD, AC. Реши эту задачу, рассуждая шаг за шагом

DoR (Definition of Ready):

• Требования к функциональности описаны подробно и однозначно.
• Определены все необходимые нефункциональные требования (производительность, безопасность, доступность).
• Выявлены и задокументированы все ключевые сценарии использования.
• Оценены и учтены все известные риски и зависимости от внешних факторов или систем.
• Согласованы сроки и бюджет реализации.
• Разработаны критерии приемки (AC).
• Подтверждено понимание команды разработчиков и заинтересованных лиц.

DoD (Definition of Done):

• Реализована полная функциональность согласно требованиям.
• Проведено успешное тестирование (функциональное, регрессионное, нагрузочное).
• Продукт соответствует установленным стандартам качества и надежности.
• Подготовлена документация и руководство пользователя.
• Обеспечена интеграция с существующими системами и сервисами.
• Успешно пройдены процедуры контроля качества и безопасности.
• Готовность продукта к релизу и эксплуатации подтверждена всеми участниками процесса.

AC (Acceptance Criteria):

• Пользователь имеет возможность выбрать интересующие его токены или коины для мониторинга.
• Система фиксирует снижение цены актива относительно заданного пользователем порогового значения.
• Уведомление отправляется пользователю удобным способом (push-уведомления, email, SMS и др.) в течение установленного временного интервала (не более X минут).
• Интерфейс настройки уведомлений интуитивно понятен и удобен для пользователя.
• Поддерживаются индивидуальные настройки частоты и формата уведомлений.
• Система сохраняет историю изменений цен и отправленных уведомлений для последующего анализа.
• Функционал устойчив к высоким нагрузкам и пиковым изменениям рыночных котировок.
• Предусмотрен механизм подтверждения успешной доставки уведомлений.
• Предоставляется отчетность по эффективности системы уведомлений.

<GigaChat(Рассуждение), RCTF>

Prompt: Ты выступаешь в роли Product Owner. Команда работает над новой возможностью в приложении, связанном с криптовалютой. Пользователь должен получать сообщение, если цена выбранной монеты или токена упала. Это нужно для того, чтобы он не пропустил важное изменение стоимости и мог вовремя среагировать. User Story: «Я как пользователь хочу получать уведомления о снижении цены на токены или коины». Нужно подготовить для этой истории DoR, DoD и Acceptance Criteria в виде простых и понятных пунктов.
Формат:
Сначала напиши заголовки DoR:, DoD: и AC:.Под каждым заголовком сделай нумерованный список.
В разделе DoR напиши от 4 до 6 пункта о том, что должно быть понятно до начала работы.
В разделе DoD напиши от 4 до 6 пункта о том, как понять, что задача уже сделана.
В разделе AC напиши от 4 до 6 критериев в формате «Дано — Когда — Тогда».

DoR (Definition of Ready):

• Определены все монеты и токены, для которых пользователь может включить уведомления.
• Согласован формат и каналы доставки уведомлений (например, push, email, in-app).
• Установлены пороги и логика срабатывания уведомлений (например, снижение на 5% за час).
• Проработаны сценарии управления подписками: пользователь может выбрать, для каких монет получать уведомления.
• Есть понимание, как часто и при каких условиях система будет проверять изменение цены.
• Определены требования к хранению пользовательских настроек и данных о подписках.

DoD (Definition of Done):

• Реализован механизм отслеживания изменения цены выбранных пользователем монет или токенов.
• Система отправляет уведомление пользователю при срабатывании условия снижения цены.
• Пользователь может управлять своими подписками: добавлять, удалять, временно отключать уведомления.
• Проведено тестирование на корректность срабатывания уведомлений и отсутствие ложных срабатываний.
• Реализована обработка ошибок: если данные о цене недоступны, пользователь получает соответствующее сообщение.
• Вся функциональность задокументирована и добавлена в справочные материалы приложения.

AC (Acceptance Criteria):

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

<ChatGPT Plus, Zero-shot>

Prompt: "US1: "Я как пользователь хочу получать уведомления о снижении цены на токены или коины." Вот User Story сделай DoR, DoD, AC.

DoR (Definition of Ready):

• Определено, какие именно активы считаются токенами/коинами в системе.
• Понятно, откуда берётся актуальная цена актива.
• Определено, что считается снижением цены
• Уточнено, кто может настраивать уведомления
• Определены каналы уведомлений
• Понятно, как часто проверяется изменение цены.
• Уточнено, должен ли пользователь сам задавать порог снижения.
• Описаны ограничения:
• Есть макеты или описание UI для настройки уведомлений.
• Согласованы бизнес-правила и критерии приёмки с командой/заказчиком.

DoD (Definition of Done):

• Пользователь может включить уведомление о снижении цены для выбранного токена или коина.
• Пользователь может указать условие срабатывания уведомления.
• Система корректно получает и обрабатывает актуальные цены активов.
• При выполнении условия снижения цены пользователю отправляется уведомление.
• Уведомление содержит понятную информацию
• Пользователь не получает повторяющиеся уведомления без нового изменения цены или нового события.
• Реализована обработка ошибок при недоступности данных о цене.
• Функциональность протестирована
• Обновлена документация/описание функционала.
• Функция принята PO/заказчиком и соответствует AC.

AC (Acceptance Criteria):

• Given пользователь авторизован в системе When он выбирает токен или коин и настраивает уведомление о снижении цены Then система сохраняет эту настройку.
• Given у пользователя настроено уведомление для актива When цена актива снижается до заданного порога или ниже Then пользователь получает уведомление.
• Given цена актива не достигла заданного условия снижения When система проверяет цену Then уведомление не отправляется.
• Given произошло снижение цены по заданному условию When система отправляет уведомление Then оно содержит название актива, текущую цену и факт снижения цены.
• Given уведомление уже было отправлено при достижении порога When цена остаётся на том же уровне без нового существенного изменения Then повторное уведомление не отправляется.
• Given пользователь ранее настроил уведомление When он изменяет порог или отключает уведомление Then система применяет новые настройки для следующих проверок.
• Given источник цены временно недоступен When система не может получить актуальную цену Then приложение не создаёт ложное уведомление и корректно обрабатывает ошибку.

<ChatGPT Plus, Chain of Thought>

Prompt: "US1: "Я как пользователь хочу получать уведомления о снижении цены на токены или коины." Вот User Story сделай DoR, DoD, AC. Реши эту задачу, рассуждая шаг за шагом

DoR (Definition of Ready):

• User Story сформулирована и понятна команде.
• Определено, для каких активов работает функционал: токены, коины, либо оба типа.
• Уточнено, по какому условию определяется снижение цены
• Определён источник получения актуальной цены.
• Понятно, каким способом отправляются уведомления:
• Уточнено, должен ли пользователь сам настраивать правило уведомления.
• Определено, как часто система проверяет изменение цены.
• Описаны ограничения и исключения
• Есть UX/UI-макеты или описание экрана настройки уведомлений.
• История декомпозирована и оценена командой.

DoD (Definition of Done):

• Реализована возможность выбора токена или коина для отслеживания.
• Реализована настройка условия снижения цены.
• Система автоматически отслеживает цену выбранного актива.
• При выполнении условия пользователь получает уведомление.
• В уведомлении содержится понятная информация
• Реализована обработка ошибок получения цены и отправки уведомлений.
• Проведено тестирование основной логики и граничных случаев.
• Функциональность протестирована и принята командой/заказчиком.
• Код прошёл review.
• Обновлена документация, если это требуется в проекте.

AC (Acceptance Criteria):

• Настройка уведомления: Допустим, пользователь находится в системе И выбрал токен или коин Когда он задаёт условие уведомления о снижении цены Тогда система сохраняет это условие для выбранного актива.
• Срабатывание уведомления: Допустим, у пользователя настроено уведомление на снижение цены актива Когда цена актива снижается до заданного порога или ниже него Тогда система отправляет пользователю уведомление.
• Содержание уведомления: Допустим, условие уведомления выполнено Когда пользователь получает уведомление Тогда в уведомлении указаны: название токена/коина; текущая цена; условие, по которому сработало уведомление.
• Отсутствие ложных уведомлений: Допустим, пользователь настроил уведомление Когда цена актива не достигла заданного условия снижения Тогда уведомление не отправляется.
• Работа с ошибками: Допустим, системе не удалось получить актуальную цену актива Когда происходит очередная проверка цены Тогда система не отправляет ложное уведомление И фиксирует ошибку для последующей обработки.

<ChatGPT Plus, RCTF>

Prompt: Ты выступаешь в роли Product Owner. Команда работает над новой возможностью в приложении, связанном с криптовалютой. Пользователь должен получать сообщение, если цена выбранной монеты или токена упала. Это нужно для того, чтобы он не пропустил важное изменение стоимости и мог вовремя среагировать. User Story: «Я как пользователь хочу получать уведомления о снижении цены на токены или коины». Нужно подготовить для этой истории DoR, DoD и Acceptance Criteria в виде простых и понятных пунктов.
Формат:
Сначала напиши заголовки DoR:, DoD: и AC:.Под каждым заголовком сделай нумерованный список.
В разделе DoR напиши от 4 до 6 пункта о том, что должно быть понятно до начала работы.
В разделе DoD напиши от 4 до 6 пункта о том, как понять, что задача уже сделана.
В разделе AC напиши от 4 до 6 критериев в формате «Дано — Когда — Тогда».

DoR (Definition of Ready):

• Понятно, для каких монет и токенов пользователь может включать уведомление о падении цены.
• Определено, какое именно снижение цены считается основанием для уведомления: например, падение на заданный процент или ниже указанного значения.
• Понятно, где и как пользователь настраивает такое уведомление в приложении.
• Согласован текст уведомления и способ его доставки пользователю внутри приложения или через push.

DoD (Definition of Done):

• Пользователь может выбрать монету или токен и настроить уведомление о снижении цены.
• Система отправляет уведомление, когда цена достигает заданного условия падения.
• Уведомление содержит понятную информацию: название актива, текущую цену и факт снижения.
• Функция протестирована, и сценарии создания, получения и отключения уведомления работают без ошибок.

AC (Acceptance Criteria):

• Дано пользователь выбрал монету и установил уведомление при падении цены ниже заданного значения, Когда цена монеты становится ниже этого значения, Тогда пользователь получает уведомление о снижении цены.
• Дано пользователь настроил уведомление на падение цены токена на определённый процент, Когда цена токена падает на указанный процент или больше, Тогда система отправляет пользователю уведомление.
• Дано пользователь отключил уведомление о падении цены, Когда цена выбранного актива снижается, Тогда уведомление пользователю не отправляется.
• Дано пользователь получил уведомление о падении цены, Когда он открывает уведомление, Тогда он видит, по какому активу пришло уведомление и какая цена стала актуальной.
• Дано у пользователя настроены уведомления для нескольких активов, Когда цена каждого из них достигает своего условия снижения, Тогда система отправляет уведомление отдельно по каждому активу.

[0x0e4]

Группа 4/42
Выполнили:
Боков Кирилл
Ермолаев Михаил
Самойлов Игорь

US1.1: Я как наниматель могу нажать кнопку "создать чат", которая создаст Google Docs и предоставит ссылку на него

AC:

• При нажатии кнопки создаётся новый Google Docs документ
• Пользователь получает валидную ссылку на документ
• Пользователь без нужных прав кнопку не видит
• При ошибке создания пользователь видит сообщение об ошибке
• Один клик = один документ (нет дубликатов)

DoR:

• Есть доступ для работы с Google API
• Понятно, где именно в UI находится кнопка "создать чат"
• Определено, как и где будет отображаться ссылка
• Уточнены права доступа к документу (кто может читать/редактировать)
• Дано определение роли "Наниматель" в системе и определена его зона ответственности
• Есть описание ожидаемого поведения системы при нажатии кнопки
• Определены требования к логированию
• Есть возможность проверить, какая роль нажала на кнопку "Создать чат" по логам

DoD:

• Реализована кнопка "создать чат" в UI
• При нажатии создаётся Google Docs документ
• Ссылка корректно генерируется и отображается пользователю
• Проверены права доступа к документу
• Обработаны ошибки (например, недоступность Google API)
• Проверено скрытие кнопки у тех, у кого нет нужных прав
• Тестировщик убедился в том, что документ не создаётся повторно при повторном нажатии на кнопку
• Проведено тестирование интеграции с Google API
• Логирование реализовано и проверено

US2.1: Я как пользователь ожидаю, что при открытии IDE отображается ссылка на Wiki страницу

AC:

• При открытии IDE пользователь видит ссылку на Wiki
• Ссылка ведёт на корректную страницу
• Ссылка доступна всем авторизованным пользователям
• При недоступности Wiki отображается уведомление
• Наличие логирования при сбоях
• Открытие ссылки происходит без заметных задержек

DoR:

• Определено, что такое Wiki (внутренний ресурс или внешний)
• Есть URL Wiki страницы
• Понятно, где в IDE отображается ссылка
• Определены роли пользователей и доступ к Wiki
• Уточнено поведение при недоступности Wiki

DoD:

• Ссылка на Wiki отображается в IDE
• Ссылка кликабельна и ведёт на корректную страницу
• Проверена доступность ссылки для всех авторизованных пользователей
• Реализован fallback (если Wiki недоступна)
• Проверено отсутствие критических задержек при открытии ссылки
• Протестировано логирование ошибок при сбоях
• Проверено отображение во всех поддерживаемых браузерах

US2.2: Я как пользователь хочу иметь Wiki страницу с FAQ

AC:

• Wiki содержит раздел FAQ
• FAQ содержит актуальные вопросы и ответы
• Пользователь может открыть FAQ без дополнительных авторизаций
• Страница корректно отображается
• Контент читаем и структурирован

DoR:

• Определён список FAQ
• Согласован контент с заинтересованными сторонами
• Определена структура Wiki страницы
• Определены ответственные за обновление FAQ
• Уточнены требования к языку и локализации

DoD:

• Добавлен раздел FAQ
• Контент проверен и согласован
• Настроены права доступа
• Проведена проверка отображения

US3.1.1: Я как инвестор хочу получать на почту статистику использования ИИ в конце каждого рабочего дня в формате Excel

AC:

• Инвестор получает письмо в конце рабочего дня
• Письмо содержит Excel файл
• Рассылка не приходит в выходные/праздники
• В отчёте отсутствуют персональные данные, пользователи анонимизированы (например, UUID)
• Данные в отчёте корректны

DoR:

• Определён список инвесторов
• Определён формат Excel отчёта
• Определено, что считается "рабочим днём"
• Уточнены источники данных по использованию ИИ
• Есть шаблон письма
• Зафиксированы ключевые метрики, которые должны быть отражены в статистике
• Определены правила обработки персональных данных
• Определено, зачем инвестору эта статистика, какая конечная её цель и что он хочет в ней видеть

DoD:

• Генерируется Excel отчёт с данными
• Настроена автоматическая ежедневная отправка
• Рассылка работает по расписанию c учетом праздничных/выходных дней
• Проверено расписание отправки
• Проведён пилот на группе инвесторов
• Тестировщик убедился в том, что система логирует процесс получения отчёта
• Данные в отчёте валидированы
• Проверена анонимизация данных

US3.1.2: Я как разработчик хочу скачивать Excel отчёт по использованию ИИ из Ollama dashboard и отправлять его по mail.ru

AC:

• Пользователь может скачать Excel отчёт
• Файл открывается без ошибок
• Данные соответствуют dashboard
• Отправка через mail.ru проходит успешно
• При недоступности dashboard или сбое генерации отчёт не создаётся, система корректно уведомляет о проблеме
• При сбое отправки письма тестировщик получает информацию о невозможности доставки
• Все ограничения доступа соблюдены

DoR:

• Есть доступ к Ollama dashboard
• Определён формат Excel отчёта
• Понятно, где находится кнопка скачивания
• Есть доступ к почтовому сервису mail.ru
• Уточнены ограничения на отправку писем
• Определено, как проверить, что вложение открывается и соответствует ожидаемому Excel

DoD:

• Реализована возможность скачивания Excel из dashboard
• Файл корректно формируется
• Пользователь может скачать файл локально
• Пользователь может отправить файл через mail.ru
• Обработаны ошибки скачивания и отправки
• Проверено получение информации тестировщиком о сбоях отправки писем

---

Боков Кирилл (ChatGPT | Zero-Shot, RCTF, reflexion)

US 1.1 "Я как наниматель могу нажать кнопку "создать чат", которая создаст Google Docs и предоставит ссылку на него". LLM: ChatGPT, без предварительной настройки.

zero-shot, prompt (US 1.1 "Я как наниматель могу нажать кнопку "создать чат", которая создаст Google Docs и предоставит ссылку на него" Сделай DoR DoD и AC для неё.):
DoR (Definition of Ready)
User story описана и понятна команде
Определён актор: наниматель (пользователь с соответствующей ролью)
Понятно, где находится кнопка "создать чат" (страница/раздел интерфейса)
Есть доступ к Google API (Google Docs + авторизация)
Определены требования к создаваемому документу (название, шаблон, права доступа)
..... ИТД (самостоятельно удалил лишнее)
DoD (Definition of Done)
Реализована кнопка "создать чат" в интерфейсе
При нажатии создаётся новый Google Docs документ
Документ создаётся с корректным названием/шаблоном
Пользователь получает ссылку на созданный документ
Настроены права доступа (например: доступ нанимателю или по ссылке)
..... ИТД (самостоятельно удалил лишнее)
AC (Acceptance Criteria)
Наниматель видит кнопку "создать чат"
При нажатии на кнопку:
создаётся новый Google Docs документ
документ создаётся без ошибок
После создания:
пользователю отображается ссылка на документ
ссылка кликабельна
документ доступен пользователю
Если произошла ошибка:
отображается понятное сообщение об ошибке
Повторное нажатие создаёт новый (уникальный) документ
Время создания документа не превышает допустимый лимит (например, ≤ N секунд)

RCTF, prompt (Роль: Ты - профессиональный аналитик с опытом более 10 лет и эксперт в своей области и многих смежных областях. Контекст: Не давай слишком длинный ответ. Не используй нечёткие формулировки. Вписывай в ответ только то, в чём уверен. Прежде, чем давать ответ, проверь критически, корректно ли ты написал элемент. Задача: Напиши DoR, DoD и AC для US 1.1 "Я как наниматель могу нажать кнопку "создать чат", которая создаст Google Docs и предоставит ссылку на него" Формат: Представь в виде списка из трёх разделов - DoR, DoD и AC. Количество элементов в списке не должно превышать 5 в каждом разделе.):
DoR (Definition of Ready)
Описан пользовательский сценарий: кто, где и как нажимает кнопку «создать чат».
Определены требования к интеграции с Google Docs API (доступы, авторизация).
Понятен формат создаваемого документа (пустой или с шаблоном).
Определено, где и как отображается ссылка пользователю.
Согласованы ограничения прав доступа к документу (владелец, шаринг).

DoD (Definition of Done)
Кнопка «создать чат» доступна в интерфейсе и работает без ошибок.
При нажатии создаётся новый Google Docs документ.
Пользователь получает корректную кликабельную ссылку.
Права доступа к документу соответствуют требованиям.
Покрыто тестами (минимум: позитивный сценарий + ошибка создания).

AC (Acceptance Criteria)
При нажатии кнопки создаётся новый уникальный документ.
Ссылка возвращается пользователю не позднее X секунд (SLA задан).
Пользователь может открыть документ по ссылке без дополнительных запросов доступа (если это требование).
При ошибке создания отображается понятное сообщение.
Повторное нажатие создаёт новый документ, а не переиспользует старый.

reflexion, prompt(‍После того, как ты дашь ответ, проанализируй его по следующим критериям: 1. Полнота информации 2. Научная точность 3. Ясность изложения Затем предложи улучшения к своему первоначальному ответу, основываясь на этом анализе. Примени полученные улучшения):

DoR (Definition of Ready)
Описан пользовательский сценарий (где расположена кнопка, шаги пользователя).
Определены требования к интеграции с Google Docs API (OAuth, scope, квоты).
Зафиксирован формат документа (пустой или конкретный шаблон с описанием структуры).
Определён способ возврата ссылки (UI-элемент, уведомление или API-ответ).
Согласованы права доступа (владелец документа и уровень шаринга).

DoD (Definition of Done)
Кнопка «создать чат» доступна и инициирует процесс без ошибок.
Документ создаётся через Google Docs API с учётом retry при временных сбоях.
Пользователь получает корректную кликабельную ссылку.
Права доступа применены согласно требованиям.
Реализованы тесты (позитивный сценарий, ошибки) и настроено логирование/мониторинг.

AC (Acceptance Criteria)
При нажатии кнопки создаётся новый уникальный Google Docs документ.
Ссылка предоставляется пользователю не позднее 3 секунд.
Переход по ссылке возвращает HTTP 200 и открывает документ.
Пользователь может открыть документ без запроса доступа (если это требование).
При каждом нажатии создаётся новый документ; при ошибке отображается понятное сообщение.

Заметка:
При zero-shot промптинге нейронка выдала огромное полотно текста, где-то по делу, где-то нет. Она не знала формат и ограничения, поэтому выдала всего и побольше. Из-за этого много лишних и притянутых за уши критериев, много неточностей и формулировок с использованием "или", т.е. не до конца решённых задач.
RCTF позволил выдать конкретный ответ и соответствующий ожиданиям. Reflexion позволил нейронке самостоятельно найти ошибки и контекстно обучиться, благодаря чему данный чат стал более продуктивным при следующих задачах такого типа.

---

Ермолаев Михаил (DeepSeek | Zero-Shot, CoT, RCTF)

US2.1 Я как пользователь ожидаю, что при открытии IDE отображается ссылка на Wiki страницу
Zero-Shot

AC

При запуске IDE (без дополнительных действий) на экране присутствует кликабельный элемент (ссылка/иконка/баннер) с текстом, ведущим на Wiki.
Ссылка заметна на стандартном рабочем экране (не требует скролла, если это не оговорено отдельно).
При наведении (в статус-баре или тултипе) отображается правильный URL Wiki-страницы.
При клике по ссылке открывается системный браузер по умолчанию с указанной Wiki-страницей (а не встроенный браузер IDE, если иное не требуется).
При повторном запуске IDE ссылка снова отображается (не исчезает после первого использования).
Если нет интернета или Wiki недоступна, ссылка либо остается (но браузер показывает ошибку), либо отображается информативное сообщение (согласно спецификации).
Текст ссылки соответствует языку интерфейса IDE (например, “Wiki” / “Справочная страница”).

DoR

Четко определено, какая именно Wiki-страница должна открываться (URL указан и доступен).
Указано конкретное место ссылки в IDE (например, «нижний правый угол статус-бара» или «меню Help»).
Подтверждено, что ссылка должна появляться при каждом запуске, а не только при первом.
Есть мокап или описание стиля ссылки (шрифт, цвет, иконка).
Известно, нужно ли ждать инициализацию ядра IDE перед показом ссылки (или она рисуется раньше).
Все AC из первого чек-листа измеримы и объективны (нет «красиво», «удобно»).
Задача оценена и включена в текущий спринт/итерацию.

DoD

Реализован показ ссылки при старте IDE (в соответствии с AC).
Написаны тесты на метод формирования URL и проверку кликабельности (или на соответствующую логику).
Автотест запускает IDE и проверяет наличие ссылки и переход (или хотя бы наличие href).
Тестировщик подтвердил все пункты Acceptance Criteria.
Новая ссылка не сломала существующий функционал (например, логотип или другие ссылки).
Обновлена пользовательская документация (если есть) или хотя бы добавлен комментарий в README/Release Notes.
Изменение попало в целевую среду (тестовый стенд / production) и доступно для проверки заказчиком.
Код прошел ревью как минимум одним другим разработчиком.
В баг-трекинге нет открытых багов на эту функцию с приоритетом «Блокер» или «Критический».

CoT

AC

При первом запуске IDE в интерфейсе присутствует кликабельная ссылка с текстом «Wiki» или «Перейти на Wiki».
Ссылка ведёт на действующую Wiki-страницу (URL соответствует требованиям проекта).
Ссылка открывается в новой вкладке браузера по умолчанию.
Ссылка отображается на видном месте (например, на стартовом экране или в панели навигации).
При повторных запусках IDE ссылка также остаётся доступной.

DoR

User story оценена и приоритизирована.
Требования к URL Wiki-страницы определены и доступны.
Есть макет/описание, где именно должна быть ссылка.
Команда понимает, как проверять открытие в новой вкладке.
Доступна тестовая среда для проверки IDE.

DoD

Код реализован и проходит ревью.
Ссылка добавлена в интерфейс IDE.
URL Wiki-страницы соответствует утверждённому.
Функция открытия в новой вкладке работает.
Написаны автотесты (если требуются) или выполнено ручное тестирование по AC.
Баги отсутствуют (критические — закрыты).
Задача отмечена как завершённая в трекере.

RCTF

AC

Запустить IDE → на экране присутствует элемент «Ссылка на Wiki».
Текст ссылки соответствует спецификации.
При клике открывается браузер с ожидаемой Wiki-страницей.
Отсутствие ошибок консоли при рендеринге IDE.

DoR

Требование к ссылке на Wiki-страницу зафиксировано в User Story.
Известен URL или путь до целевой Wiki-страницы.
Определено место размещения ссылки в IDE (например, стартовая вкладка / меню Help).
Критерии проверки согласованы с PO.
Есть дизайн или описание поведения (открытие в том же/новом окне).

DoD

При открытии IDE ссылка отображается в указанном месте.
Ссылка ведет на корректную Wiki-страницу.
Ссылка кликабельна и открывает Wiki в браузере.
Поведение ссылки одинаково на всех поддерживаемых ОС.
Код проверен и залит в основную ветку.

Итог:
С Zero-Shot мы получаем много лишней информации, неточностей с абсолютно ненужными пунктами (например, "Все AC из первого чек-листа измеримы и объективны" в DoR). Метод CoT дал более сжатый формат, требования уже не такие четкие (всё таки абсолютную четкость здесь излишне давать), но всё ещё присутствуют лишние пункты (например, "Ссылка открывается в новой вкладке браузера по умолчанию" в AC). В целом с помощью RCTF получился лучший результат, поскольку здесь мы имеем чётко расписанные пункты в небольшом количестве, они не такие конкретные, как в Zero-Shot.

---

Самойлов Игорь (Claude Sonnet 4.6 | Zero-Shot, RCTF, CoT, ToT)

US3.1.2: Я как разработчик хочу скачивать Excel отчёт по использованию ИИ из Ollama dashboard и отправлять его по mail.ru
Zero-Shot
Промпт: Сделай DoR, DoD и AC для US3.1.2 "Я как разработчик хочу скачивать Excel отчёт по использованию ИИ из Ollama dashboard и отправлять его по mail.ru"

DoR
Команда понимает, что такое Ollama dashboard и какие данные он отображает

Известно, какие метрики попадают в отчёт и за какой период

Есть рабочий доступ к dashboard у разработчика

Определено, как именно отправляется файл через mail.ru (вручную или автоматически)

Согласовано, что считается "успешной отправкой"

Известны ограничения mail.ru на размер вложений

DoD
В dashboard есть экспорт в Excel, файл скачивается без ошибок

Содержимое файла совпадает с тем, что отображается на dashboard

Разработчик может прикрепить файл и отправить письмо через mail.ru

Ошибки на каждом шаге (генерация, скачивание, отправка) обработаны и видны пользователю

Тестировщик прошёл полный сценарий от скачивания до получения письма

AC
Нажатие на кнопку экспорта инициирует скачивание .xlsx файла

Файл содержит корректные данные — без пустых ячеек в обязательных полях

Письмо с вложением уходит через mail.ru и доставляется адресату

При недоступности dashboard экспорт заблокирован с понятным объяснением

При неудачной отправке разработчик видит конкретную причину сбоя

RCTF
Промпт: Роль: Ты — опытный системный аналитик. Контекст: пиши кратко, только то, в чём уверен, избегай размытых формулировок. Задача: DoR, DoD, AC для US3.1.2. Формат: три раздела, максимум 5 пунктов каждый.

DoR
Описан путь пользователя: какая страница dashboard, какой элемент запускает экспорт

Зафиксирована структура файла: поля, типы данных, период выборки

Определён способ отправки через mail.ru и ограничения сервиса

Согласованы права: кто может экспортировать данные

Описано поведение при сбое на каждом этапе

DoD
Экспорт в .xlsx работает, файл соответствует согласованной структуре

Отправка через mail.ru завершается успехом в штатном сценарии

Все ошибочные пути покрыты тестами и логируются

AC
Файл формируется за время, определённое в DoR (SLA)

Данные в файле идентичны отображаемым на dashboard

При сбое генерации файл не отдаётся, пользователь видит объяснение

При сбое отправки — явное уведомление, без молчаливого провала

Chain-of-Thought (CoT)
Промпт: Рассуждай последовательно: определи цель разработчика → что нужно для старта → как проверить завершённость → критерии приёмки. На основе этого напиши DoR, DoD, AC для US3.1.2.

Рассуждение: Разработчик хочет получить данные об использовании ИИ и переслать их. Важна точность данных и простота пути. Завершённость — не просто "кнопка есть", а весь путь работает. Принять можно только если ошибки не замалчиваются.

DoR
Ясно, откуда dashboard берёт данные об использовании ИИ

Определена структура отчёта и период, который он охватывает

Согласовано: разработчик отправляет вручную или это автоматизировано

DoD
Полный сценарий (скачать → отправить) воспроизводим без ошибок

Данные в файле проверены на соответствие источнику

Тестировщик подтвердил работу и граничные случаи

AC
Экспортированный файл содержит те же данные, что и экран dashboard

Если dashboard упал — разработчик не получает пустой или битый файл

При любом сбое отображается понятное сообщение с причиной

Tree-of-Thought (ToT)
Промпт: Представь трёх экспертов: продуктовый аналитик, QA-инженер и backend-разработчик. Каждый смотрит на US3.1.2 со своей стороны. Объедини лучшее от каждого в финальные DoR, DoD, AC.

DoR
Определена бизнес-цель: зачем разработчику этот отчёт и кому он его шлёт

Описана структура .xlsx: колонки, типы, источник каждого поля

Описаны все возможные сбои и ожидаемая реакция системы на каждый

DoD
Данные проверены на соответствие источнику в Ollama dashboard

Письмо с файлом успешно доставлено в тестовый ящик mail.ru

Покрытие тестами: позитивный путь + недоступность dashboard + сбой отправки

AC
Содержимое файла совпадает с данными dashboard на момент экспорта

Отправка через mail.ru завершается, письмо доходит до адресата

Если письмо не ушло — пользователь видит явный фидбек, не тишину

Как изменился ответ:
Zero-Shot: Ответ получился слишком объемным. Из-за того, что не было четких ограничений, нейросеть добавила много общих пунктов, которые в реальной работе будет сложно проверить.

RCTF: Результат стал намного точнее. Заданная роль и лимиты помогли отфильтровать лишнее, в итоге остались только конкретные и измеримые критерии.

CoT: Рассуждение по шагам сделало ответ более логичным. Пункты DoR, DoD и AC теперь связаны и вытекают друг из друга, поэтому разработчикам будет проще понять задачу.

ToT: Самый полезный и сбалансированный вариант. Взгляд со стороны аналитика, тестировщика и программиста позволил учесть сразу всё: и бизнес-задачу, и технические моменты, и нюансы тестирования.