Расскажи про процессы в текущей команде

Процессы в текущей команде

Команда

Текущая команда состоит из:

• 3 разработчика 1С (mid, mid, junior)
• 1 тестировщик (автоматизированное и ручное тестирование)
• 1 бизнес-аналитик (сбор требований, документирование)
• 1 lead/архитектор (code review, планирование, архитектура)

Методология разработки

Scrum/Kanban гибрид

Мы используем 2-недельные спринты, но с элементами kanban:

• Планирование — в начале спринта определяем задачи
• Daily standup — 15 мин каждый день о проделанной работе и планах
• Backlog — постоянный список задач от бизнеса, приоритизированный
• Доска (Jira/GitLab) — задачи делятся на To Do → In Progress → Code Review → Testing → Done

Процесс разработки

1. Получение задачи

• Бизнес-аналитик пишет требования в Jira
• На планировании обсуждаем оценки и сложность
• Разработчик берёт задачу и создаёт feature branch

2. Разработка

- Пишу код в отдельной ветке (feature/XYZ-123)
- Регулярно коммитю (логичные блоки, понятные комментарии)
- Самостоятельно тестирую
- Пушу в origin

3. Code Review

• Создаю merge request/pull request
• Lead или коллега проверяет код
• Обсуждаем архитектуру, стиль, потенциальные проблемы
• Исправляю замечания, пинаю на ревью снова
• После одобрения merge в develop

4. Интеграционное тестирование

• Тестировщик берёт задачу из backlog
• Проверяет требования, функциональность, граничные случаи
• Если находит баги — возвращает в разработку
• Если ОК — переводит в Done

5. Deploy

• На staging (тестовое окружение) — автоматический при merge в develop
• На production — ручной, обычно раз в неделю (после встречи с бизнесом)
• Используем blue-green deployment для нулевого downtime

Инструменты

Версионирование:

• Git (GitLab/GitHub)
• Две постоянные ветки: develop (тестирование) и main (production)
• Feature branches: feature/XYZ-123, bugfix/XYZ-456

CI/CD:

• GitLab CI (или GitHub Actions)
• При push в feature branch: автоматический lint, unit-тесты
• При merge в develop: полный набор тестов + deploy на staging
• При merge в main: deploy на production

Коммуникация:

• Slack для быстрых вопросов
• Jira для задач и истории
• Confluence для документации
• Встречи (standup, планирование, ретро) в Zoom

Стандарты качества

Code Style:

// Русские имена для переменных (в 1С это стандарт)
Процедура ОбновитьДанные()
    ОписаниеСтруктуры = Новый Структура();
    ОписаниеСтруктуры.Вставить("Наименование", "");
КонецПроцедуры;

Тестирование:

• Unit тесты минимум на 80% покрытие
• Интеграционные тесты для критичных процессов
• E2E тесты для основных user flows
• Все тесты запускаются в CI перед merge

Documentation:

• Сложная логика должна быть задокументирована в коде (комментарии)
• Архитектурные решения — в Confluence
• Инструкции для новых разработчиков — в README

Встречи

Daily standup (15 мин)

• Что вчера сделал
• Что сегодня буду делать
• Есть ли блокеры

Planning (2 часа в начале спринта)

• Обсуждение задач
• Оценка story points
• Распределение задач

Code Review meeting (по мере необходимости)

• Обсуждение архитектурных решений
• Разбор сложных pull requests

Retro (1 час в конце спринта)

• Что хорошо
• Что плохо
• Как улучшить процесс

Challenges и improvements

Текущие проблемы:

• Знания сидят в головах — нужна лучше документация
• Тестирование на проде — иногда баги находятся только в production
• Зависимость от lead — сложные архитектурные решения требуют одобрения

Что улучшаем:

• Внедрение feature flags для безопаснейшего deploy
• Автоматизация smoke-тестов на production
• Больше knowledge sharing сессий
• Создание runbooks для типовых операций

Итог

Процессы структурированы, но не перегруженные. Есть ясные роли, регулярная коммуникация, и главное — фокус на качество и скорость доставки. Команда работает как слаженный механизм, где каждый знает свою роль и ответственность.