Ответ
В нашей DevOps-команде мы работаем по двухнедельным спринтам, что позволяет балансировать между скоростью реакции и стабильностью планирования.
Цикл спринта:
-
Подготовка бэклога (Backlog Grooming): За пару дней до планирования мы вместе с разработчиками и продакт-менеджером уточняем и оцениваем (в story points) задачи в общем бэклоге. Для DevOps это не только фичи, но и инциденты, технический долг, задачи по безопасности и улучшению инфраструктуры.
-
Планирование спринта (Sprint Planning): В начале спринта выбираем задачи из приоритизированного бэклога. Наша цель — сформировать реалистичный и ценный инкремент. Пример задач из нашего Jira:
DEV-451[5sp] Настроить автоматическое масштабирование (HPA) для нового микросервиса платежей в staging.OPS-128[3sp] Обновить Terraform-модуль VPC до новой версии с поддержкой IPv6 (технический долг).SEC-55[8sp] Внедрить сканирование образов в CI/CD пайплайн с помощью Trivy. Мы учитываем емкость команды (учитывая отпуска и дежурства) и стараемся не перегружать спринт более чем на 80%.
-
Ежедневные стендапы (Daily Stand-up): Каждый день в 10:00 отвечаем на три вопроса:
- Что я сделал вчера для целей спринта? (Например: "Закончил настройку алертов для новой базы данных").
- Что планирую сделать сегодня? ("Начну писать playbook для развертывания мониторинг-агента").
- Есть ли блокеры? ("Жду доступ к облачному аккаунту от security-команды"). Фокус на скорейшем устранении блокеров.
-
Работа в спринте: Помимо задач по спринту, мы используем модель «команда дежурных». Один инженер в неделю отвечает за реакцию на инциденты и мелкие операционные запросы, что не срывает фокус всей команды на спринтовых целях.
-
Демо / Ревью спринта (Sprint Review): В конце спринта показываем стейкхолдерам, что сделано. Для DevOps это часто не видимый UI, а работающая инфраструктура: демонстрация нового дашборда в Grafana, показ отказоустойчивости при убийстве ноды в кластере, скриншот успешного пайплайна.
-
Ретроспектива (Sprint Retrospective): Самая важная часть. Анализируем, что прошло хорошо, что можно улучшить. Например, после спринта, где мы тушили несколько серьезных инцидентов, мы решили улучшить документацию по аварийному восстановлению и добавить еще один прогон тестов в ночное время.
Метрики, которые мы отслеживаем:
- Velocity: Среднее количество story points, завершенных за спринт. Помогает в долгосрочном планировании.
- Burndown Chart: Позволяет видеть, успеваем ли мы по плану.
- Lead Time / Cycle Time для изменений: Сколько времени проходит от коммита до продакшена. Стремимся уменьшать.
Гибкость остается ключевой: если возникает критический инцидент или срочный запрос от бизнеса, мы можем пересмотреть план спринта, перенеся менее приоритетную задачу.