36 записей с тегом "tutorial"

В инженерной культуре Google есть правило: до первой строчки кода для любой нетривиальной задачи пишется design doc. Не 40-страничный монумент, а обычно 5-12 страниц, с двумя ревьюерами и комментариями на полях. Команда Engineering Practices из Google публично называла это одним из самых дешёвых рычагов качества в компании.

Большинство команд вне Google либо пропускают этот шаг, либо прикручивают шаблон в Confluence к существующему процессу и смотрят, как он атрофируется. Шаблон ниже — тот, который реально выживает при встрече с уставшим ревьюером в 16:45 в четверг. Это тот момент, когда спека живёт или умирает.

Команда из 40 инженеров за 8 месяцев приняла одно и то же архитектурное решение дважды — в июне и в феврале, оба раза откатила. После второго отката наконец внедрили RFC-процесс. Разбирая историю коммитов, они обнаружили: оригинальный контекст остался в Slack-треде, который автоматически архивировался через 90 дней, а инженер, который владел решением, уже уволился. RFC-документ стоил бы 4 часа на написание и сэкономил бы примерно 3 инженеро-недели переделок.

RFC-процессы существуют потому, что технические решения переживают людей, которые их приняли. Stripe, Cloudflare, Oxide Computer и проект Rust публично описывают свои RFC-форматы — и общая структура уже, чем кажется большинству команд. Эта статья — тот самый шаблон, к которому они сходятся, плюс реалистичный ревью-цикл для команд 10-80 человек, плюс честные цифры о том, когда RFC просто тратят время.

Fintech-команда в Варшаве сократила средний рабочий день на 45 минут — и стала катить больше фич. SaaS из 40 человек в Сингапуре запретил митинги до 11 утра — медиана lead time на PR упала на 22%. Ни одна команда ничего не изобрела — они внедрили защищённые блоки deep work. UC Irvine, Gloria Mark, почти два десятилетия публикует (The Cost of Interrupted Work: More Speed and Stress, 2008, и follow-ups): одно прерывание стоит ~23 минут на рефокус. Cal Newport Deep Work (2016) популяризировал термин у инженерных лидеров. Данные устоялись; имплементация — там, где команды расходятся.

Эта статья проходит по 5 реальным расписаниям команд. Что сработало, что сломалось, и что мы увидели в IDE-телеметрии, когда паттерн стабилизировался.

Спринт 47, команда из 8 человек. Стандартный нарратив ретро звучал бы так: «velocity упал на 20%, было много багов, в следующем спринте поприоритезируем лучше». Тот же вайб, что и в спринте 46. И в спринте 45. Теперь добавьте на то же ретро один показатель: общая стоимость спринта — $32 800, из них $11 600 (35%) ушли на тикеты с багами, против $14 200 (43%) на фичи. Скользящее среднее по багам у этой команды — 18%. Одна строка — «мы потратили на баги вдвое больше обычного» — переключила команду с «сделаем лучше» на «первые три дня спринта 48 — только bug-prevention, без исключений».

Этот пост показывает, как встроить один финансовый показатель в 30-минутное ретро так, чтобы оно производило решения, а не ощущения.

Команда из 6 инженеров с 15-минутным daily standup стоит вам 7,5 человеко-часов в неделю только в запланированном времени. Добавьте цену переключения контекста — Gloria Mark (UC Irvine) измерила ~23 минуты на возврат к задаче после прерывания — и реальная стоимость ближе к 15 часам в неделю. Для команды, тянущей фичу 10 недель, это 150 инженер-часов. Это не встреча. Это part-time инженер, которого вы наняли и сразу поставили говорить.

Standup'ы не плохи сами по себе. Они решают реальную задачу: выносят блокеры на поверхность, пока те не сгнили. Вопрос в том, единственный ли синхронный ежедневный формат её решает — и лучший ли. Отчёт State of Agile 2024 показывает, что 32% команд активно экспериментируют с async-first альтернативами, и наиболее чистые данные из IDE-телеметрии говорят, что эти альтернативы возвращают 1-2 часа focus time на разработчика в неделю без ущерба доставке.

Это сравнение 5 альтернатив standup, когда какая подходит, и как выбрать свою.

Большинство «remote-ритуалов» — это синхронные встречи в remote-костюме. Ежедневный стендап в 9 утра UTC, на который пятеро инженеров в четырёх часовых поясах ходят нехотя — это не ритуал, это офисный косплей. GitLab Remote Work Report 2024: 71% remote-инженеров называют «слишком много синхронных встреч» главным drain'ом продуктивности распределённой работы. Проблема не в remote; проблема в импортировании colocated-ритуалов целиком.

Это список из 7 ритуалов, которые реально выживают в remote-инженерных командах, которые мы измеряем — командах, где телеметрия показывает, что они не просто счастливее, но и шипают быстрее.

Sprint planning, запланированный "на 10 утра, чтобы всем было удобно", — быстрейший способ потерять инженерное время в распределённой организации. Математика простая: с инженерами в Americas, EMEA и APAC слота "все могут прийти" не существует — хотя бы одна таймзона теряет 3+ часа, встречаясь в неудобное время. Microsoft Work Trend Index 2022 по 61 000 сотрудников: встречи вне локального 9-17 снижают вовлечённость на 52% и увеличивают частоту последующих недопониманий в 2.4×.

Это чеклист — не философское рассуждение — как запускать sprint planning для команды из 3+ таймзон. Он построен на паттернах нашего IDE heartbeat датасета, конкретно на 62 командах, работающих с распределённым планированием.

Средний engineering manager тратит 4 часа в неделю на перетаскивание тикетов в Jira. Не планирование, не 1:1 — сортировку, напоминания, закрытие stale и гонки за полями, которые забыли заполнить. Мы опросили 31 EM у B2B-клиентов; 27 назвали Jira главной временной дырой после встреч.

Atlassian поставляет довольно мощный engine автоматизации в каждом плане Jira (да, даже в Standard). Команды его игнорируют. Или, что хуже, используют для одного правила — auto-close на "Done" — и упускают 11, которые имеют значение. Ниже — набор 12 правил, которые вместе сокращают admin-нагрузку EM с 4 ч/нед до ~40 минут. Мы используем варианты у себя в PanDev Metrics и у трёх on-prem клиентов.

14-минутный CI-пайплайн — это не просто 14 минут ожидания. GitHub Octoverse 2024 отчитался: медианный enterprise-репозиторий прогоняет pull request через CI 4.2 раза перед merge — ретраи, пуши после ревью, починка flaky-тестов. Это почти час компьюта на один PR. В команде, шипящей 200 PR в неделю, CI-бюджет вам ничего не приносит, а context-switch налог стоит вам четверга senior-разработчика.

Это how-to. Шесть шагов, которые стабильно режут время GitHub Actions CI на 50%+ на реальных репо, которые мы помогали оптимизировать. Без теории; у каждого шага есть патч, который можно адаптировать.

Финтех на 40 инженеров, с которыми я говорил в прошлом месяце, платил $960 в месяц за GitHub Copilot Business на всю команду, но их юристы только что заблокировали использование после compliance-review: телеметрия code completion уходила через облако Microsoft. CTO задал мне обманчиво простой вопрос: «Можем ли мы self-host'ить эквивалент?»

Ответ — «да, но только если пройдёте три фильтра». Stack Overflow Developer Survey 2024 показал, что 76% разработчиков используют или планируют использовать AI-инструменты, но в регулируемых индустриях adoption отстаёт на 20-30 пунктов. Разрыв — не в скепсисе, а в инфраструктуре. Большинство команд хотят приватный inference, но недооценивают, во что «self-hosted» обходится по GPU capex, времени SRE и компромиссу в качестве модели.

Это фреймворк, который мы даём командам, обдумывающим переход: когда self-hosted LLM бьёт облако, когда нет, и три точки, где математика переворачивается.