Agile и процессы
Слово «Agile» на собеседовании почти никогда не означает разговор о ценностях — проверяют механику. Сколько длится sprint и кто вправе его отменить. Что физически запрещает лимит WIP и как он вскрывает узкое место. Чем Continuous Delivery отличается от Continuous Deployment. Почему долг в коде, который никто не трогает, можно не выплачивать. Манифест 2001 года — четыре строки, которые сами по себе ничего не предписывают; всё исполняемое живёт в двух фреймворках поверх него, в конвейере сборки и в дисциплине учёта долга.
Python добавляет одну особенность, которая меняет вес каждого пункта. У Python нет этапа компиляции — ничто не помешает опечатке в редко импортируемом модуле доехать до продакшена и превратиться в NameError под нагрузкой. Роль отсутствующего компилятора берёт на себя CI: ruff и mypy ловят ровно тот класс ошибок, который в компилируемых языках не доживает до коммита. По той же причине здесь тише накапливается технический долг — мёртвый код и подавления # type: ignore не мешают сборке и всплывают лишь при рефакторинге.
Три ловушки назовём сразу. CI — это практика частого слияния в общую ветку, а не купленный сервер сборки. У Kanban нет sprint — у него есть лимиты WIP и Cycle Time. Технический долг в исходном смысле Каннингема — осознанный компромисс ради ранней поставки, а не вежливое название плохого кода.
Карта темы
- Scrum и манифест Agile — четыре ценности манифеста и жёсткий каркас Scrum: три роли, пять событий, три артефакта и их таймбоксы.
- Scrum против Kanban — итерация против непрерывного потока, лимит
WIPкак механизм и почемуvelocityиCycle Timeнельзя менять местами. - CI/CD — конвейер — что делает CI на самом деле, два разных значения аббревиатуры CD и почему стадии пайплайна выстроены именно в таком порядке.
- Технический долг — метафора Каннингема, тело долга против процентов и квадрант Фаулера как способ не называть долгом всё подряд.
- Управление долгом — три стратегии выплаты, профилактика через
Definition of Doneи измеримые признаки вместо ощущений.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
Считать, что длина sprint подбирается под объём работы | Длина фиксирована по определению; плавающий sprint лишает velocity смысла и превращает планирование в торг о сроке |
Приписывать Kanban двухнедельные итерации, а Scrum — метрику Cycle Time | Метрики поменяны местами: Scrum меряет velocity за итерацию, Kanban — время прохождения элемента через доску |
| Считать CI сервером сборки, а не практикой частого слияния | Ветка живёт неделями, конфликты растут быстрее её возраста, а зелёный пайплайн даёт ложное чувство интегрированности |
| Путать Continuous Delivery и Continuous Deployment | Собеседник и кандидат обсуждают разные процессы; ручной шлюз перед prod — это черта Delivery, а не Deployment |
| Считать, что при автоматическом деплое тесты можно ослабить | Убран единственный человеческий шлюз — компенсировать его обязаны более сильные тесты, мониторинг и быстрый откат |
| Сводить технический долг к плохому коду | Пропадают понятия осознанного долга и процентов, а вместе с ними исчезает всякая основа для приоритизации |
| Держать задачи на долг в отдельном трекере «на потом» | Они не конкурируют с фичами за ёмкость команды и не выполняются никогда — отдельный список это способ не платить |
| Выбирать полное переписывание как стратегию по умолчанию | Выбрасываются годы исправленных пограничных случаев, а паритет достигается поздно — старая система всё это время уезжает вперёд |
Значение для собеседований
Блок процессов идёт в начале разговора и служит быстрой калибровкой: работал ли кандидат в команде или читал про команды. На junior-уровне спрашивают три вещи — что такое Scrum (фреймворк с итерациями фиксированной длины, обязательствами по Sprint Goal и поставкой в конце), что ценит манифест (люди, работающий продукт, сотрудничество, готовность к изменениям — с обязательной оговоркой «то, что справа, тоже ценно») и что такое технический долг. На последнем половина кандидатов отвечает «это плохой код», и разговор переходит в разбор ошибки: метафора Каннингема — про будущую цену быстрого решения, выплачиваемую процентами с каждого изменения, и про осознанный выбор, а не про неряшливость.
С middle идут два вопроса, где видно практику. Первый — сравнение Scrum и Kanban: правильный ответ строится от ограничения (в Scrum ограничено время итерации, в Kanban — количество одновременной работы), из него сами выводятся и разные метрики, и разное отношение к переприоритизации, и выбор Kanban для поддержки и ops, где заявки приходят непредсказуемо. Второй — управление долгом: ждут инкрементальный рефакторинг с задачами в общем backlog, полное переписывание как крайний случай, осознанное принятие как законный вариант и профилактику через MVP-прототипы, версионирование API и чёткий Definition of Done. Senior-вопрос почти всегда один — что требуется для Continuous Deployment сверх обычного пайплайна; здесь проверяют, понимаете ли вы, что снятие ручного шлюза это не упрощение, а перенос ответственности на мониторинг, быстрый откат, feature flags и покрытие тестами.