Skip to content

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

Навигация: Назад: DevOps | Далее: Эпики и дорожная карта

Оглавление

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

Scrum / Agile / процессы разработки (адаптировано под текущую команду).

SmartSupport развивается небольшой, но высокоэффективной командой, где каждый участник может выполнять несколько ролей, а большую часть рутины закрывают ИИ-инструменты. Agile-процесс построен вокруг: - быстрых итераций, - активного использования ИИ, - минимума бюрократии, - чётких приоритетов, - постепенного роста компетенций команды.

Ритм команды

Текущий ритм адаптирован под маленькую гибкую команду: - Спринт: 1 неделя (короткий цикл → быстрая обратная связь) - Еженедельное планирование - Demo каждую неделю - Раз в две недели — ретроспектива

Почему именно неделя: - маленькая команда быстрее фокусируется; - задачи небольшие и ИИ ускоряет выполнение; - не нужно держать большие планы в голове; - легко перестраиваться.

Когда команда вырастет — можно перейти к 2-недельным спринтам.

Роли в текущей команде

  1. Product Coordinator / PM (нетехнический участник)
  2. формулирует требования;
  3. формирует backlog;
  4. ведёт коммуникации;
  5. принимает работу;
  6. ведёт Wiki;

  7. обеспечивает ритм.
    Это ключевая роль для маленькой команды.

  8. Technical Generalists (3 человека)
    Все три технических участника — “универсалы”, которые:

  9. могут писать backend/frontend/инфраструктуру по мере необходимости;
  10. активно используют ИИ как соразработчика;
  11. участвуют в архитектурных решениях;
  12. берут задачи в зависимости от загрузки;
  13. могут вести разные модули проекта (Раг, агенты, БЗ, интеграции).

Пока роли распределяются так:
- Tech Lead (совмещённая роль): следит за архитектурой; принимает ключевые технические решения; проводит ревью; отвечает за согласованность сервисов.
- AI & Data Engineer (совмещённая роль): отвечает за RAG; настроит векторную БД; подключает LLM; ведёт работу с KB Curator Agent; помогает готовить датасеты.
- Backend/Integrations Engineer (совмещённая роль): отвечает за ingestion; ticketing; операции; интеграции с внешними сервисами; front для админки/оператора (при необходимости).

Все 3 — взаимозаменяемы.

  1. DevOps (нет выделенной роли)
    Обязанности DevOps делятся между техническими участниками:
  2. один занимается CI/CD;
  3. второй обслуживает сервер;
  4. третий следит за мониторингом.

ИИ (например, GitHub Copilot, ChatGPT, Claude) здесь помогает писать:
- Dockerfile,
- docker-compose,
- Helm-чарты,
- GitLab CI pipeline,
- конфигурации Prometheus/Grafana.

Definition of Ready

Чтобы маленькая команда не тратила время на несформулированные задачи, DoR: - краткое описание задачи; - понятная цель; - мини-спецификация (2–6 предложений); - если нужно — пример (prompt, схема, мок); - маленький размер (влезает в 1 спринт); - нет зависимостей, блокеров.

ИИ помогает сразу подготовить DoR: описать API, код, схемы.

Definition of Done

Задача считается выполненной, если: - ✔ работает так, как описано
- ✔ задокументировано в Wiki
- ✔ протестировано вручную или автотестами (где это возможно)
- ✔ задеплоено на stage
- ✔ прошли smoke-тесты
- ✔ команда понимает, как поддерживать функцию

Документация обязательна, так как маленькая команда должна сохранять коллективное знание.

Процесс планирования спринтов

Планирование включает: 1. Обзор прошлой недели (что сделано, что не успели)
2. Быстрое уточнение приоритетов
3. Выбор 3–6 задач на спринт
4. Оценка трудозатрат (по ощущениям, без сложных схем)
5. Назначение ответственных

ИИ помогает декомпозировать задачи.

Принципы работы с бэклогом

Для маленькой команды важна простота.

Правила: - Top-10 задач — самое важное; - всё остальное — “ледяная гора”: backlog хранится, но без внимания; - любые большие задачи → дробим на спринтовые; - задачи пишутся простым языком, без бюрократии; - приоритеты определяются ощущением ценности:
- P1 — критично (каналы, ИИ, БЗ);
- P2 — важное улучшение;
- P3 — nice-to-have.

Backlog ведётся в Wiki или GitLab Issues.

Формат митингов

  1. Еженедельный созвон (замена Daily и планирования)
  2. 30–45 минут

  3. обсуждаем: что сделано / что делаем / что блокирует / какие улучшения нужны
    Для маленькой команды ежедневно собираться необязательно.

  4. Demo
    Каждую неделю показываем: новый функционал; диаграммы; улучшения ИИ; обновления БЗ; метрики.

  5. Ретроспектива (раз в 2 недели)

  6. что улучшить
  7. что оставить
  8. какие проблемы убрать

  9. какие инструменты ИИ оказались полезными

  10. Технические консультации ИИ
    Вместо внутренних митингов разработчики часто используют:

  11. ChatGPT, Claude, Cursor, GitLab AI, Repo assistants
    Это снижает нагрузку на коммуникации внутри команды.

Как использовать Wiki

Wiki — это центр знаний команды. Она используется для:

  1. Хранения архитектуры: обновлённые диаграммы, описания сервисов, спецификации API.
  2. Описания задач: маленькие фичи, промты, API-контракты, схемы взаимодействия.
  3. Генерации документации ИИ: автоматическое обновление архитектуры, описаний компонентов, инструкций для DevOps.
  4. Фиксации знаний: маленькая команда = все должны знать всё; Wiki — способ не потерять ключевую информацию.

Переход к расширению команды

В Handbook уже можно зафиксировать “путь роста”: - сначала команда маленькая, универсальная; - потом выделяются роли: AI/ML инженер, backend, frontend, devops, qa, full-time PM, support, NOC/SRE.

Но развивать эти роли команда будет естественным образом, по мере роста продукта и заказчиков.

Итог

С учётом текущей команды SmartSupport использует: - краткие спринты, - минимальную бюрократию, - широкую универсальность участников, - максимальное использование ИИ, - Wiki-first подход, - принцип: маленькие итерации → быстрый прогресс.

Это — оптимальная модель для небольшого стартапа, в котором 3 человека могут создать продукт уровня муниципальной и государственной автоматизации.