Agile и процессы
Scrum, Kanban, CI/CD и технический долг.
6 вопросов
JuniorТеорияОчень частоЧто такое Scrum, и что ценит манифест Agile?
Что такое Scrum, и что ценит манифест Agile?
Scrum — это Agile-фреймворк на основе итераций фиксированной длины (sprint, ~2 недели); команда берёт обязательства по sprint backlog и поставляет в конце. Манифест Agile ценит людей, работающее ПО и готовность к изменениям.
Типичные ошибки
- ✗Думать, что sprint имеют гибкую длину, задаваемую день ото дня, а не фиксированную
- ✗Считать, что
Agileценит документацию и контракты выше работающего ПО - ✗Полагать, что
Scrumубирает планирование, а не формализует его в sprint planning
Уточняющие вопросы
- →Какие роли и церемонии определяет
Scrumвокруг sprint? - →Как «готовность к изменениям» работает, когда требования меняются посреди sprint?
JuniorТеорияЧастоВ чём разница между CI и CD?
В чём разница между CI и CD?
CI часто сливает код в общую ветку, собирая и тестируя каждый merge. CD — это либо Continuous Delivery (пайплайн до ручного подтверждения деплоя в prod), либо Continuous Deployment (выкатка изменений в prod без шлюза).
Типичные ошибки
- ✗Считать, что
CIдеплоит в prod — он лишь собирает, тестирует и сливает код - ✗Путать Continuous Delivery (ручной шлюз деплоя) с Continuous Deployment (без шлюза)
- ✗Думать, что
CDозначает «документацию кода», а не delivery или deployment
Уточняющие вопросы
- →Какие практики делают пайплайн Continuous Deployment безопасным для авто-запуска?
- →Почему частая интеграция в
CIснижает болезненные конфликты слияния?
JuniorТеорияЧастоЧто такое технический долг?
Что такое технический долг?
Это будущая цена выбора быстрого, неоптимального решения сейчас — как финансовый долг, выплачиваемый позже с процентами. В исходном смысле Каннингема это осознанный компромисс ради ранней поставки, а не небрежный код.
Типичные ошибки
- ✗Сводить технический долг только к плохому коду, игнорируя осознанный стратегический долг
- ✗Считать, что долг не нужно выплачивать и у него нет растущей цены-процента
- ✗Путать метафору с буквальным финансовым или лицензионным долгом
Уточняющие вопросы
- →Чем осознанный стратегический долг отличается от случайного безрассудного долга?
- →Какие признаки говорят, что накопленный долг уже замедляет команду?
MiddleТеорияЧастоЧем различаются Scrum и Kanban?
Чем различаются Scrum и Kanban?
Оба относятся к Agile. Scrum работает фиксированными sprint с зафиксированным объёмом, мера — velocity; цель — завершить sprint. Kanban — непрерывный поток без sprint, переприоритизация всегда, мера — Cycle Time.
Типичные ошибки
- ✗Приписывать фиксированные двухнедельные sprint
Kanban, у которого sprint нет - ✗Думать, что
Scrumпозволяет свободно менять задачи посреди sprint без срыва обязательств - ✗Менять метрики местами — у
Scrumэтоvelocity, уKanban—Cycle Time
Уточняющие вопросы
- →Когда выбрать
KanbanвместоScrumдля команды поддержки или ops? - →Как лимит WIP в
KanbanулучшаетCycle Time?
MiddleТеорияИногдаКак команды управляют техническим долгом?
Как команды управляют техническим долгом?
Стратегии: инкрементальный рефакторинг с задачами на долг в backlog рядом с фичами, полное переписывание при потере гибкости или осознанное принятие. Профилактика тоже помогает: MVP-прототипы, версионированные API и чёткий definition of done.
Типичные ошибки
- ✗Считать полное переписывание единственным законным способом справиться с долгом
- ✗Отказываться вести задачи на долг в
backlogрядом с фичами - ✗Считать осознанное принятие долга недопустимым компромиссом в любом случае
Уточняющие вопросы
- →Как приоритизировать задачу на долг против клиентской фичи?
- →Что делает
definition of doneэффективным в предотвращении нового долга?
SeniorТеорияИногдаЧто требует Continuous Deployment сверх CI/CD?
Что требует Continuous Deployment сверх CI/CD?
Поскольку каждое изменение автоматически уходит в prod без шлюза, это требует сильного мониторинга, быстрого отката, feature flags и высокой уверенности в авто-тестах — команды обычно сначала автоматизируют staging и держат prod в один клик.
Типичные ошибки
- ✗Считать, что авто-деплой позволяет более слабые тесты, а не более сильные
- ✗Путать его с Continuous Delivery, где сохраняется ручной шлюз перед prod
- ✗Считать мониторинг и быстрый откат необязательными, а не обязательными
Уточняющие вопросы
- →Как feature flags разделяют деплой кода и релиз фичи для пользователей?
- →Какая стратегия отката защищает пользователей от плохого авто-деплоя?
