Retro

Вопросы для встречи — детальный разбор по темам

Это общий пул тем для обсуждения с командой, разложенный по разделам A–K. На встрече удобно использовать как чек-лист — пройти разделы и убедиться что ни одну тему не пропустили.

Использование: — приоритетный порядок обсуждения; этот файл — разрез по темам, чтобы по каждой теме все вопросы были покрыты.

В PR #832 23.02 Alexis задал вопрос про pre-deployment steps (Comment #2). Плюс я (Андрей) несколько раз поднимал эту тему — говорил и писал в Slack, что нас панчат за это (точные даты найти не получилось).

Темы про процесс / организационная сторона

Это командные вопросы — обсуждаем все вместе.

  1. Self-QA чеклист для frontend / header / responsive PR — есть ли сейчас? Если нет — заводим: владелец черновика (по договорённости команды), куда кладём (wiki, ссылка из PR template, ). Черновик минимума — в блоке «Темы про общий процесс» п. 2. (См. также «Совместно» п. 6 и раздел B.)

  2. Кто и когда делает internal validation pass перед отправкой PR на Stevens? («Совместно» п.п. 3 и 7 — там ownership команды; здесь — как командно фиксируем кто и в какой момент в цикле.)

  3. Pre-agreement (data-cta и т.п.): кто на нашей стороне следит за формулировками «agreed before implementation begins» / «to be confirmed» в спеке и поднимает в Jira до старта работы? (Кейс PR #846 Comment #11.) (См. раздел D, вопрос 12.)

  4. Языковой барьер в комментариях ревью клиенту: нужна ли системная помощь — кто-то из команды (менеджер/второй разработчик) перечитывает большие/важные вопросы перед публикацией? (См. раздел F.)

  5. Правило по коду в PR: никаких TODO / «when approve» в ветке, которая идёт в ревью Stevens — если не готово, только Draft PR. Поддерживаем как обязательное? (Раздел C, вопрос 9 — PR #847.)

  6. После approve: любые новые коммиты — только если явно запрошен повторный ревью (re-review), без «тихих» правок. Фиксируем так? (Тот же кейс PR #847.)

Темы про общий процесс / self-QA

  1. Размер батча (header / PR #846): по опыту это месячная работа или до 2 недель? Можно ли делить (инкременты: sticky / search / CTA и т.д.), кто инициирует декомпозицию в Jira. (Раздел E — для детализации.)

  2. Self-QA — предлагаемый минимум (уточнить/дополнить на встрече, владелец чеклиста — см. п. 1): mockup-overlay (сверка с макетом), responsive (ключевые брейкпоинты), dark mode (если в скоупе), grep / проверка env-vars (нет утечек и заглушек для прод), тесты или ручная проверка на всех декларированных типах страниц (из тикета / спеки). Где в описании PR отмечаем «прогнано»?

Совместно (фиксируем как командные договорённости)

  1. Spec-read правило/чеклист: перед стартом сабтаска прочитать parent-story и приложенные спеки. Если нет — вводим? (Расширение — раздел D, вопрос 10.)

  2. Кто и когда верифицирует реализацию ↔ acceptance criteria до отправки PR на ревью Stevens? (См. раздел B, вопросы 4 и 6.)

  3. Готовы ли мы ввести internal validation pass (как просит Alexis)? Кто его делает — какая комбинация ролей в команде (self-review автора PR / вторая пара глаз / менеджер)? (См. раздел B, вопросы 4–5.)

  4. Contentful environments: какой env для каких задач, доступы, проверка конфигурации до PR, кто отвечает за расхождения env ↔ прод. PR #837 Comment #1 (content model в master вместо develop) — предметно чаще касается зоны Саши Федоренко; на встрече обсуждаем всем, потому что реакция Stevens накопительная, нужно утвердить линию на будущее.

  5. PR template с обязательными секциями (pre-merge tasks, migration plan, validation steps / что прогнали) — вводим для всех PR к Stevens? Кто ведёт и обновляет шаблон в Bitbucket?

  6. Self-review checklist перед "Open PR" (debug-код, lint, schema-spec, миграция данных; плюс пункты из «Темы про общий процесс» п. 8 — overlay, responsive, dark mode, env-vars, типы страниц) — делаем обязательным? Где фиксируем (описание PR, wiki, ссылка из тикета)?

  7. Internal validation pass — кто и когда в цикле (до открытия PR на Stevens, после self-review, перед merge)? Владелец и критерий «готово» — командное решение, не единственная точка ответа на одном человеке. (Связка с п. 11 и разделом B.)

  8. Размер батча (header): см. блок выше — оценка срока и делимость; здесь при необходимости зафиксировать итог для записи в .

A. Контекст и история сигналов

  • Какой у нас должен быть процесс после менеджерского Slack и комментария клиента в PR: как получить явное подтверждение от исполнителя PR, что требование принято к сведению и пройдена проверка (а не только ответ в треде)?
  • Почему через 5 недель в PR #842 повторилась та же линия (pre-merge / описание шагов) — что добавить в процесс до следующего PR?
  • Письмо Alexis от 29.04 — это сюрприз или ожидаемая эскалация по накопившимся замечаниям?
  • Получали ли мы раньше похожие сигналы от Tom (iX) — устно, в Slack, в звонках?

B. Self-QA / internal validation

Пересекается с блоком «Совместно» п.п. 10–11 и п. 15 — можно коротко зафиксировать ownership в «Совместно», здесь уточнить детали. Блок «Темы про процесс» п.п. 1–2 и «Темы про общий процесс» п. 8 — про чеклист frontend/header/responsive и internal validation.

  • Делается ли сейчас на нашей стороне internal validation pass перед отправкой PR на ревью Stevens?
    • Если да — кто, что проверяет, как фиксируется?
    • Если нет — кто должен это делать?
  • Согласны ли ввести обязательный self-QA checklist перед "Open PR" (см. — раздел A)?
    • Что бы добавить/убрать из этого checklist'а?
  • Кто на нашей стороне сравнивает реализацию с acceptance criteria до отправки на ревью Stevens?

C. PR template и workflow

Пересекается с блоком «Совместно» п. 13 — шаблон PR — командная договорённость. Блок «Темы про процесс» п.п. 5–6 — черновик правил draft / без TODO when approve / только явный re-review после approve.

  • Согласны с обязательной структурой PR description (Summary / Changes / Pre-merge tasks / Migration plan / Validation done / Compare URLs)?
  • Какое у нас сейчас правило по squash/rebase? Формализовано ли где-то?
    • Готовы ли ввести правило: после первого push на remote — никаких rebase/force-push?
  • По кейсу PR #847 (commit-after-approve, TODO "when approve PR"):
    • Это разовая ошибка или знак, что у нас нет общего понимания, что approve привязан к конкретному коммиту?
    • Согласны ли с парой правил из «Темы про процесс» п.п. 5–6: нет TODO/when-approve в коде ревью-ветки (не готово → Draft); после approve — изменения только после явного запроса re-review?

D. Спека и parent-тикеты

Пересекается с блоком «Совместно» п. 9. Блок «Темы про процесс» п. 3 — pre-agreement / Jira до старта.

  • Есть ли у нас сейчас правило / чеклист «перед стартом сабтаска прочитать parent-story и приложенные спеки»?
  • Согласны ли ввести Spec-read checkpoint — разработчик перед стартом пишет в Jira-комменте, что прочитал и какие acceptance criteria выписал?
  • Кто следит за фразами "to be confirmed" / "agreed before implementation begins" в спеке (Comment #11 PR #846 — data-cta)?

E. Размер батча и циклы ревью

Пересекается с блоком «Темы про общий процесс» п. 7 — header / делимость.

  • PR #832 — 2+ месяца OPEN, 27+ коммитов. PR #846 — 11 претензий за 2 недели. Можно было разбивать?
    • Если да — почему не разбивали?
    • Если нет — какая структурная причина?
  • Предложение Андрея (мнение, не факт): если на старте видим что задача большая — дробим заранее; если в процессе разрастается — дробим по ходу. Готовы попробовать как практику?

F. Языковой барьер в коммуникации с ревьюерами клиента

Блок «Темы про процесс» п. 4 — системная помощь с формулировками.

  • PR #846 Comment #10 (alignment) — формулировка вопроса на английском была неясной, Michael не понял, потеряли цикл (~3 дня).
  • Должен ли кто-то из команды (менеджер / второй разработчик) перечитывать существенные комментарии к ревьюерам клиента перед публикацией?
  • Английский в комментариях ревью — нужна ли помощь с формулировками (AI-инструмент / вторая пара глаз)?

G. Невыученные уроки между PR

  • VideoObject без uploadDate — пойман в PR #832 и PR #842 в один день (31.03). Между PR урок не закрепился.
  • Какой формат запоминания уроков устраивает команду:
    • A — журнал в репо ()
    • B — Jira/wiki
    • C — короткий список в analysis + ссылка из PR template
    • (См. паттерн 4 и раздел E.)
  • Базовый ритм: после merge — 1–2 строки урока; перед следующим похожим PR — перечитывание; кто первым набросал строку — по командной договорённости.
  • Пилот с ИИ: черновик строки из текста ревью — с человеческой правкой; готовы ли пробовать в узком scope (без секретов)?
  • Владелец ритма (напоминание дописать, перечитывание перед похожим PR) — как распределяем: ротация, исполнитель PR self-check перед Open, общий канал?

H. Знание codebase

  • PR #832 — не использовались существующие абстракции (getExternalPath, Image Wrapper.credit).
  • Делается ли у нас онбординг по архитектуре проекта? Карта компонентов / utilities?
  • Нужна ли практика "перед фичей просмотреть похожие места в codebase / grep по проекту"?

I. AI-tooling (вопрос из письма Alexis)

  • Используем ли мы какие-то AI-инструменты при разработке (Copilot, Cursor, Codex)?
  • Что думаем про предложение Alexis "AI-assisted tooling has helped us during our internal experiments" — стоит ли пилотить?

J. Ответ Stevens — тон и стратегия

  • Какой тон ответа выбираем — оборонительный, согласительный, со встречными предложениями?
  • Что нельзя признать в ответе клиенту? (Например, может быть юридически или коммерчески чувствительно.)
  • Что хотим сами получить от Stevens в ответе? (Например, ясность по спеке, регулярные sync'и, чёткий escalation channel.)

K. После встречи

  • Кто пишет первый черновик ответа Tom/Stevens?
  • К какому сроку нужно отправить ответ?
  • Распределение работ по существующим открытым PR (#832, #842, #846, #847) — как двигаем дальше?