Retro

PR #837 — итоговая позиция (обновлено после нахождения спеки)

PR: https://bitbucket.org/stevens_edu/stevens_main_nextjs/pull-requests/837 Задача: ICUS-216 — Add FAQPageJsonLd for accordion Parent (со спекой): https://cpcs.atlassian.net/browse/ICUS-214 Цикл: 13.03.2026 → 24.03.2026 (11 дней, замержен) Результат: Approved (Bemin Shaker) → Merged (Bemin Shaker)

Краткое резюме

  • Всего значимых комментариев: 5
  • Реальных претензий: 2
  • Координационных/служебных: 2
  • Позитивных (QA passed): 1
#АвторТипТемаОбоснованно
1Bemin ShakerПретензияИзменение content model в master Contentful вместо develop✓ Да
2Vercel botСлужебныйDeploy preview ready—
3Michael ForbesКоординацияMerge master в ветку (next-seo 7.2.0)— (плюс: Иван сделал merge, не rebase)
4Michael ForbesПозитивQA testing — "test passes" во всех 3 сценариях, JSON-LD валидный—
5Michael ForbesПретензияКонфигурация поля не соответствует спеке ICUS-214✓ Да, дословно

Ключевой факт

Спецификация была приложена к нашей родительской задаче ICUS-214 в виде PDF "User Stories for FAQ Schema - Copy.pdf":

  • Кем приложена: Andrii Holubets (наш менеджер)
  • Когда: 2026-03-11, 16:34 (Europe/Warsaw) — за 2 дня до открытия PR Иваном (13.03)
  • Размер: ~153 KB

В ней дословно прописано всё то, что Michael Forbes потом потребовал исправить в Comment #5:

Acceptance Criteria из ICUS-214Реализовано Иваном изначально
Field name: Accordion PurposeДругое имя (по контексту похоже на Enable FAQ Schema)
Type: Single select (Standard Content / FAQ)Boolean-подобное (Yes / No)
Default = Standard ContentНе соответствовало
FAQ schema only when = FAQЛогика была через Yes/No
Help text: "Select FAQ only when content is a list of user-facing questions and answers."Отсутствовал

Это значит: позиция "не дошла спека / не было информации" — несостоятельна. Спека лежала в нашей же Jira до старта разработки.

Объективные факты — что признаём

  1. Изменение content model было сделано не в той среде Contentful (master вместо develop) — процессная ошибка (Comment #1). Разбор «как правильно ходить по env» внутри CPCS — прежде всего к Саше Федоренко; на встрече — общее обсуждение, чтобы из накопительной реакции клиента выйти на одно согласованное правило на будущее.
  2. Конфигурация поля не соответствовала acceptance criteria из ICUS-214 — спецификация была доступна, но не выполнена (Comment #5).
  3. Это прямой пример "deviate considerably from spec" из письма Alexis, и обвинение обоснованно.

Что в нашу пользу (не оправдания, а факты)

  • Сам код (логика генерации JSON-LD) — качественный. Michael дословно: "The code looks great".
  • JSON-LD соответствует schema.org spec (FAQPage / Question / Answer корректны).
  • QA прошёл с первого раза во всех 3 сценариях после исправления, и повторно после переименования значений — регрессий нет.
  • Иван реагирует оперативно — на оба замечания исправление прилетело за 1–2 рабочих дня.
  • Merge, не rebase — Иван интегрировал master через merge (соответствует пожеланию Alexis).
  • PR в итоге Approved + Merged без дополнительных итераций.

Корневые причины (честный разбор)

  • Не "спека не дошла" — спека лежала в ICUS-214 как PDF.
  • Скорее "спека не была прочитана/выполнена" на старте + слабая пред-PR self-QA перед отправкой на ревью Stevens.
  • Это ровно те две вещи, на которые жалуется Alexis в письме от 2026-04-29: deviate from spec + формулировка про internal validation pass prior to sending (у нас закрываем через self-QA checklist и Validation done, без отдельного обязательного gate тимлида/менеджера на каждый PR).

Вопросы к Ивану (для встречи)

  1. Открывал ли ты parent-тикет ICUS-214 и приложенный PDF "User Stories for FAQ Schema" до старта работы по ICUS-216?
  2. Если открывал — почему отступил от acceptance criteria (Single select Standard Content/FAQ, help text и т.д.)?
  3. Если не открывал — это привычка работать по сабтаску без чтения parent? Или сабтаск был сформулирован так, что спека казалась лишней?
  4. Знаешь ли разницу между Contentful environments (master / develop / staging)? Что имел в виду в ответе Bemin'у про "staging environment"?

Вопросы к Антону (для встречи)

  1. Есть ли у нас правило/чеклист "перед стартом сабтаска прочитать parent-story и приложенные спеки"?
  2. Как фиксируем соответствие acceptance criteria до отправки PR на Stevens — self-QA + Validation done в описании PR, без отдельного обязательного gate на каждый PR?
  3. Как мы формализуем работу с Contentful environments?

Что предлагаем как процессные изменения

  1. Spec-read checkpoint перед стартом: Иван явно подтверждает в комментарии тикета, что прочитал parent-story и acceptance criteria.
  2. Self-QA checklist перед "Open PR" и явное Validation done в описании PR (см. — раздел A).
  3. Стандарт описания Contentful-полей в тикете/PR: обязательная таблица field name / type / options / default / required / help text.
  4. Contentful environments — формализованное правило: content model изменения только в develop, никогда в master до approve.

Действия

  • Спека найдена и сохранена → + PDF
  • Обсудить с Иваном: открывал ли он ICUS-214 до старта; знание Contentful environments
  • Обсудить с командой: процессные изменения (spec-read checkpoint, self-QA checklist, PR template) — командное решение, не «только Антон решает»
  • К встрече со Stevens: подготовить честное признание + конкретный план процессных изменений (не оправдываться)

Ключевой вывод (пересмотренный)

PR #837 — подтверждение претензий Alexis, а не их опровержение. Спека была у нас, но не была выполнена. Обсуждение должно идти от факта, что мы признаём проблему, и предлагать конкретные процессные изменения. Качество кода — единственный смягчающий фактор; ссылаться на "не дошла спека" не получится, потому что она была в нашей же Jira.