Retro

Pre-read для Антона перед звонком

Антон, прочти до встречи. Здесь сжатая картина: что случилось, что я уже ответил клиенту, по каким PR конкретно претензии, и о чём поговорим. Полная детализация со скринами и разбором каждого комментария — на сайте: https://ix-stevens-retro.pages.dev/

Контекст в пяти строках

  1. 29.04 22:28 — пришло письмо от Alexis Watson (Stevens IT) "Development Workflow" с четырьмя претензиями к нашему процессу: deviate from spec, commit squashing, post-deployment tasks, smaller batches. Прямо упомянуты PR #846 (header) и PR #847.
  2. 30.04 09:50 — я (Андрей) ответил клиенту (Alexis, Tom + cc Michael, Vincent). Среди прочего обещал avoid squashing after share, run instructions в PR, retro по header.
  3. 30.04 ~17:37 — на PR #846 случился squash (по словам Michael — «2 hours ago»).
  4. 30.04 19:37 — пришло второе письмо, от Michael Forbes, с конкретным примером squashing на PR #846. Адресовано мне напрямую; Tom (iX), ты, Vincent, Bemin — в копии.
  5. 30.04 19:58 — Alexis смягчил тон: "Not looking to micromanage... golden rule about avoiding a rebase on a shared collaboration branch".
  6. 30.04 20:12 EU — я ответил Michael (reply-all): принял ответственность ("This one is on me"), пообещал разобрать кейс на внутренней встрече и вернуться с результатом.
  7. 30.04 20:21 — финалка от Alexis: "Appreciated as always, Andrii. I think this paired with a quick check against the spec prior to pushing will put us in a good place" — эскалация закрыта позитивно. Но Michael и Alexis ждут follow-up после нашей встречи.

Хронология

Дата / времяСобытие
2026-04-29 22:28Письмо Alexis Watson "Development Workflow"
2026-04-30 09:50Мой ответ клиенту (Alexis/Tom + cc Michael/Vincent)
2026-04-30 ~17:37Squash/rewrite history на PR #846
2026-04-30 19:37Письмо Michael Forbes — конкретный пример squash на PR #846
2026-04-30 19:58Alexis — "not looking to micromanage", формулирует «golden rule»
2026-04-30 20:12 EUМой reply-all Michael — принял ответственность, обещал follow-up после встречи
2026-04-30 20:21Alexis — "Appreciated as always... will put us in a good place" — закрытие
2026-05-05 (запланировано)Внутренняя встреча — мы / Иван
(после встречи)Follow-up Stevens с тем что договорились

Тексты писем

1. Alexis Watson, 29.04 22:28 — четыре основных тезиса

  1. Deviate from spec — "deliverables (such as the header) that deviate considerably from spec and require revisiting".
  2. Commit squashing — "on other occasions, such as PR #847, the use of commit squashing... can make minor adjustments very difficult to parse out if the branch has already been shared".
  3. Avoid rebasing after share — "we'd kindly ask to avoid rebasing after code is shared to preserve history".
  4. PRs with post-deployment tasks accompanied by such + предложение про smaller batches и internal validation pass, упоминание AI-tooling.

Прямо упомянуты: PR #846 (header) и PR #847.

2. Мой ответ Alexis, 30.04 09:50

Hi, Team!

Regarding squash commits. Approaches can differ from project to project. Thanks for pointing this out, we will take it into account and avoid squashing commits after a branch has already been shared. If you have any documented workflow guidelines, we would appreciate it if you could share them. That will help us align with your process more quickly.

From our side, we have already taken previous feedback into account. For each PR where needed, we include run instructions so anyone on the team can verify the changes.

Regarding the header, I will run a retro with the team and come back with feedback.

Что обещано клиенту: не squashить после share; присылать run instructions с PR; провести retro по header'у и вернуться.

3. Michael Forbes, 30.04 19:37

Hi Andrii,

Here is an example of the type of squashing or rebasing (or something along those lines) that happened 2 hours ago: https://bitbucket.org/stevens_edu/stevens_main_nextjs/pull-requests/846/commits

Typically that list of commits would have at least one commit (more is also fine) each time a change is made in response to a PR comment, so that a reviewer could just look at the changes. But in this PR we reviewed the initial offering, a small change was made that we would have a quick glance at by looking in that list, except that instead the list has just 1 monolithic commit that combines all of the already-reviewed code with the small thing that changed. This means the next code review takes a very long time instead of being quick turnaround. It also prevents pulling the changes into an existing local checkout without first deleting the local branch, when shared history is rewritten.

Thanks for your help on this so we can get through approvals much more rapidly!

Боль ревьюера: не видит дельту изменений → следующий ревью дольше; не может pull без удаления локальной ветки (история переписана force-push'ем).

4. Мой ответ Michael, 30.04 20:12 EU (reply-all)

Hi Michael,

Thanks for flagging this with the concrete example — that's actually really helpful.

This one is on me. I sent out our reply this morning committing to avoid squashing after a branch is shared, but I didn't manage to pass that on to Ivan before he made the changes, so the situation repeated itself just hours after we promised it wouldn't. Feel free to send a bunch of dislikes my way

We have an internal team meeting tomorrow where we'll go through this case specifically, formalize the rule on our side, and make sure it actually reaches the developer (not just the inbox). I'll come back to you with what we agreed.

Apologies for the noise on PR #846 in the meantime.

Перед клиентом: ответственность принята, обещан follow-up после встречи. Это deadline — после нашего разговора Michael ждёт письма с тем что договорились.

5. Alexis Watson, 30.04 19:58 (между письмом Michael и моим ответом)

Thanks, folks.

Not looking to micromanage how the work gets done, especially before it gets pushed to the shared repo. We just want to make sure we're minimizing ground that any of us have to retread (in this example, by following the "golden rule" about avoiding a rebase on a shared collaboration branch), that's all.

Тон смягчён — Alexis явно дистанцируется от «диктовать workflow». «Golden rule» — формулировка которую возьмём в наши правила.

6. Alexis Watson, 30.04 20:21 (финалка после моего ответа Michael)

Appreciated as always, Andrii.

I think this paired with a quick check against the spec prior to pushing will put us in a good place.

In case we don't get to chat before then, have a great rest of your week!

Положительное закрытие. Эскалация закрыта со стороны клиента. Альянс предложений: наше «no rebase after share» + их «quick check against the spec prior to pushing» = «good place». Это значит надо включить в наш Self-QA / PR template отдельный пункт «spec sweep перед push» (легче чем полный internal validation pass, но закрывает основную долю «deviate from spec»).

Сводка по PR (что разобрал заранее)

В каждой строке — две ссылки: разбор на сайте (наш доклад) и PR в Bitbucket (исходник у клиента). Открывай в новой вкладке.

PRBranch / StatusГлавное
#837 — ICUS-216 FAQ schema · Bitbucket ↗merged 24.032 претензии: Contentful env (поле в master вместо develop); конфигурация поля не по acceptance criteria из спеки ICUS-214. Код «looks great», QA прошёл.
#842 — IX-SIT60 YouTube schema · Bitbucket ↗OPEN 16+ дней4 претензии: debug console.log, отсутствие pre-merge tasks (build сломался у ревьюера), невалидная VideoObject schema (без uploadDate), ~700 existing entries не синканы. Контекст: Contentful App для sync — задача Саши Федоренко; Иван в этом PR делал только фронтовую часть (читал поле через Delivery API + рендерил schema). Contentful App PR ↗
#832 — IX-SIT60 schema for pages · Bitbucket ↗OPEN 2+ месяца, 9 замечаний, REQUESTED CHANGESКонцентрирует все 4 пункта письма Alexis. Ещё 23.02 Alexis в комментарии PR прямо спросил: "Are there any additional steps we need to take prior to deployment?" — Иван ответил «no additional steps». Через 5 недель в PR #842 та же тема повторилась.
#846 — IX-SIT67 update header · Bitbucket ↗OPEN, прямо упомянут в письме Alexis11 замечаний за 8 дней: 8 — наши self-QA промахи (logo, dropdown, регрессия, search styling, дублирование CTA, dark mode contrast); 3 — пробелы в спеке (sticky на 1024+, alignment, data-cta stability). Реактивность Ивана хорошая, но слишком много долетает до ревьюера. Это header из письма Alexis "deviates from spec".
#847 — FAQPage hotfix @id · Bitbucket ↗OPEN, прямо упомянут в письме AlexisАрхитектурно решение лучше shortcut Michael (page-level aggregation вместо просто @id). Branch reuse — по прямой рекомендации Michael. Главная отдельная находка: в коде есть TODO "remove and uncomment const questions when approve PR" — то есть commit-after-approve намерение, нарушение базового правила PR-workflow.

Что уже сказано клиенту (наши коммитменты)

  • Squash workflow: не делаем squash/rebase после того как ветка расшарена. Конкретный кейс на PR #846 30.04 признан, обещан разбор и follow-up.
  • Run instructions в PR: включаем где нужно (по факту было не везде — нужен PR template).
  • Header retro: проводим, возвращаемся с findings.
  • Просим у клиента их workflow guidelines (если есть документированные).

К встрече — что предлагаю обсудить

Порядок по приоритету: сначала то что имеет накопительный эффект (self-QA, workflow violations, технические правила), потом точечные кейсы.

  1. Self-QA / internal validation pass — это главная корневая причина бо́льшей части претензий клиента. 8 из 11 замечаний на PR #846 — наши self-QA промахи; в PR #832 — undefined URL на проде, debug-код, hardcoded значения; в PR #842 — console.log, нет guard на пустое поле. Что вводим как обязательную практику (self-QA checklist перед "Open PR"; Validation done секция в описании; что входит — RWD-проход через breakpoints, dark mode contrast, mockup overlay, env-var grep, schema validation, проверка expanded states)? Alexis в финалке (20:21) добавила: "a quick check against the spec prior to pushing will put us in a good place" — закрепляем как обязательный шаг.

  2. PR #847 commit-after-approve — обсудить TODO «when approve PR» как отдельный workflow-violation. Договариваемся: не готов код → Draft PR; никаких изменений после approve без явного re-request.

  3. PR #846 squashing 30.04 — что именно произошло (squash-merge через UI / force-push / локальный rebase + push)? Открываем Bitbucket commits page вместе с Иваном. Договариваемся о правиле «после первого push на remote — никаких rebase / force-push / squash локально» (формулировка Alexis: "the golden rule about avoiding a rebase on a shared collaboration branch").

  4. PR template — обязательные секции (Summary / Changes / Pre-merge tasks / Migration plan / Validation done / Compare URLs). PR #842 Comment #2 («build сломался у Michael») — прямой кейс что текущего описания не хватает. Run instructions в PR мы уже договаривались внутри команды раньше — нужен механизм закрепления (PR template / чек-лист).

  5. Spec-read checkpoint — перед стартом задачи разработчик пишет в Jira-комменте: "Read parent ICUS-X + attachments. Acceptance criteria: [список]. Questions: [если есть]". Подтверждение со стороны менеджера/тимлида.

  6. YouTube schema PR #842 — разделение Саша / Иван — Contentful App вёл Саша Федоренко (или Alex.Rudenok? — уточнить); Иван делал фронт. Найден репо App: stevens_main_ctfapps PR #1. Нужна синхронизация мерджа фронта и App.

  7. Lessons learned log (формат на встречу выберем) — журнал повторяющихся ошибок (VideoObject без uploadDate ловили дважды 31.03 в PR #832 и #842).

  8. Размер батча (моё предложение, нужно согласование) — если на старте видим что задача большая, дробим заранее; если в процессе разрастается — дробим по ходу.

  9. Точечный кейс 30.04: коммитмент клиенту не дошёл до Ивана (я был на 5 митах, не сложилось донести). Не системная проблема, но процесс закрепления обещаний всё равно проговорим: Андрей пишет в общий канал → команда подтверждает текстом ("понял, принял", не реакция-галочка).

  10. Ответ Stevens после встречи — Michael ждёт письмо с тем что договорились; Alexis в финалке (20:21) подразумевает закрепление практики quick check against the spec.

Что от тебя нужно подумать заранее

  • Согласен ли с правилом "после первого push на remote — никаких rebase/force-push"? Если есть нюансы (например, rebase на свежий master до share — ок) — проговорим.
  • Делаем ли сейчас на нашей стороне internal validation pass перед отправкой PR клиенту? Если нет — кто должен (тимлид, менеджер, разработчик self-review, комбинация)?
  • Как ты видишь Spec-read checkpoint — формальный ритуал или излишне?
  • Размер PR-батча — твоё мнение про предложение делить заранее.
  • Тон ответа Stevens — оборонительный, согласительный, со встречными предложениями (внутренние guidelines, регулярные sync'и)?

Полные материалы

Если что-то непонятно или хочешь предварительно обсудить любой пункт — напиши, созвонимся коротко до основной встречи.