Для кластера
Перейти к навигации
Перейти к поиску
Организация процесса внутри кластера
В данной статье описывается процесс взаимодействия между владельцем продукта (Product Owner, PO) и IT-лидером (Tech Lead, TL) внутри команды. Каждая команда работает над своим направлением (МЛМ, БНПЛ, МФО), но процессы организации работы стремятся быть унифицированными.
Структура кластера
Применимо к каждой команде кластера:
- Каждая команда имеет владельца продукта (PO) и IT-лидера (TL)
- Внутри команды работают системные аналитики, тестировщики, разработчики
- Архитектор и DevOps находятся вне команд, предоставляя услуги всему кластеру
Роли и ответственность
Владелец продукта (PO)
- Отвечает за бизнес-цели и приоритеты продукта
- Формирует бэклог задач
- Взаимодействует с заинтересованными сторонами
- Принимает решения о том, что будет реализовано в следующем спринте/релизе
- Контролирует соответствие продукта ожиданиям пользователей
IT-лидер (TL)
- Отвечает за техническую реализацию продукта
- Координирует работу внутри команды (разработчики, тестировщики, аналитики)
- Разрабатывает технические решения совместно с архитектором
- Гарантирует качество кода и соблюдение стандартов разработки
- Решает технические конфликты и балансирует нагрузку между участниками команды
Границы ответственности
| Вопрос | Ответственный |
|---|---|
| Определение бизнес-целей | Владелец продукта (PO) |
| Техническая реализация | IT-лидер (TL) |
| Приоритизация задач | Владелец продукта (PO) + IT-лидер (TL) |
| Качество продукта | IT-лидер (TL) + тестировщики |
| Инфраструктура | DevOps (по запросу) |
| Архитектурные решения | Архитектор + IT-лидер (TL) |
Процесс взаимодействия
1. Сбор требований
- Владелец продукта собирает требования от заинтересованных сторон
- Владелец продукта формирует эпики (epic) и user stories
- Владелец продукта передает требования IT-лидеру для оценки их технической реализуемости
2. Оценка задач
- IT-лидер проводит технический анализ требований вместе с системными аналитиками и архитектором
- Команда оценивает трудозатраты (story points) на выполнение задач
- Владелец продукта и IT-лидер согласовывают приоритеты и сроки реализации
3. Планирование
- Владелец продукта составляет backlog для спринта
- IT-лидер распределяет задачи внутри команды
- Архитектор и DevOps предоставляют необходимые ресурсы и инфраструктуру
4. Разработка
- Разработчики пишут код под руководством IT-лидера
- Тестировщики проверяют качество продукта
- Владелец продукта получает демо-версии и дает фидбек
5. Релиз
- IT-лидер координирует выпуск продукта
- DevOps настраивает CI/CD и деплоит изменения
- Владелец продукта информирует заинтересованных сторон о релизе(выпуск realise notes)
6. Обратная связь
- Владелец продукта собирает отзывы пользователей, корректирует метрики
- IT-лидер анализирует технические проблемы и предлагает улучшения
Управление приоритетами
- Если решение принимает PO:
- PO определяет бизнес-приоритеты на основе целей компании и обратной связи от заинтересованных сторон
- TL предоставляет информацию о технических ограничениях и рисках
- Если решение принимает TL:
- TL может пересмотреть приоритеты в случае технических сложностей или рисков для стабильности продукта
- Важно, чтобы TL обосновывал свои решения перед PO
Роль архитектора
- Архитектор работает на уровне кластера, но временно выделен на одно направление
- Для других направлений архитектор должен быть доступен для консультаций
- Рекомендуется:
- Проводить регулярные встречи между архитектором, PO и TL для согласования решений
- Документировать архитектурные решения, чтобы они были доступны всем командам
Роль DevOps
- DevOps предоставляют услуги по запросу, но важно:
- Создать четкие SLA (Service Level Agreements) для реакции на запросы
- Автоматизировать процессы CI/CD, чтобы минимизировать зависимость от DevOps
Инструменты управления проектами
- Бэклог: Ведется в облачной таблице
- Задачи на спринт: Заводятся в "Сфере.Задачи"
Метрики успеха
Базовые показатели:
- Для PO: скорость выпуска функционала, удовлетворенность пользователей
- Для TL: качество кода, количество багов, время на исправление ошибок
- Для команды: скорость выполнения задач (velocity), процент выполненных задач в спринте
Дополнительные мероприятия
- Еженедельные встречи PO и TL для согласования приоритетов и обсуждения текущих проблем
- Общие ретроспективы на уровне кластера для выявления узких мест во взаимодействии между командами
- Создание матрицы RACI для четкого распределения ролей между PO, TL и другими участниками
Матрица RACI
Матрица RACI для процессов разработки и тестирования
Введение
Матрица RACI определяет распределение ролей и ответственности в процессах разработки программного обеспечения. Данная матрица охватывает ключевые роли от владельца бэклога до DevOps-инженеров.
Определение ролей
| Роль | Описание |
|---|---|
| Владелец Бэклога | Формирует и приоритизирует задачи разработки |
| Ответственный за развитие ИС | Обеспечивает развитие информационных систем |
| Корпоративный технолог | Разрабатывает технологические стандарты |
| Технолог Решения | Формирует требования к решениям |
| Системный аналитик | Разрабатывает функциональные требования |
| Архитектор Решения | Проектирует архитектуру системы |
| Разработчик | Реализует функциональность |
| Тестировщик | Обеспечивает контроль качества |
| Корпоративный DevOps | Разрабатывает CI/CD процессы |
Полная матрица RACI
| Процесс | Владелец Бэклога | Ответств. за ИС | Корп. технолог | Технолог решения | Систем. аналитик | Архитектор | Разработчик | Тестировщик | DevOps |
|---|---|---|---|---|---|---|---|---|---|
| Формирование бэклога | R | I | C | A | C | C | I | I | I |
| Приоритизация бэклога | R | I | C | A | C | C | I | I | I |
| Разработка требований | A | C | C | R | R | C | I | C | I |
| Проектирование архитектуры | I | C | C | C | C | R | C | I | C |
| Разработка компонентов | I | I | I | I | C | C | R | I | I |
| Создание тест-кейсов | I | I | I | I | C | I | C | R | I |
| Проведение тестирования | I | I | I | I | C | I | C | R | I |
| Автоматизация тестирования | I | I | I | I | I | I | C | R | C |
| Разработка CI/CD | I | I | I | I | I | C | C | I | R |
| Управление техдолгом | A | C | C | C | C | R | C | I | C |
| Приемка результатов | R | I | I | A | C | C | I | A | I |
| Разработка стандартов | I | I | R | C | C | C | I | I | R |
Условные обозначения
- R (Responsible) - непосредственно выполняет работу
- A (Accountable) - утверждает и несет окончательную ответственность
- C (Consulted) - должен быть проконсультирован
- I (Informed) - должен быть информирован о результате
Ключевые взаимодействия
- Архитектурные решения требуют согласования между архитектором, технологом решения и корпоративным технологом
- Приемка функциональности осуществляется владельцем бэклога по результатам тестирования
- Технический долг управляется архитектором при участии всех технических ролей