Team

Команда

Состав

Участник	Роль в проекте
Ревягин Денис	Владелец продукта (Product Owner), ведущий разработчик
Соколова Алина	Scrum-мастер
Кузнецов Максим	Разработчик: парсер расписания и база данных
Белов Артём	Разработчик: Telegram-бот
Морозова Екатерина	Тестировщик (QA-инженер)

Внешние стороны проекта:

Сторона	Участие
Преподаватель курса	Принимает результаты этапов (защита лабораторных работ), консультирует
Эксперты-одногруппники	Участвовали в оценке идей проекта (см. Evaluation)
Студенты ЮУрГУ (бета-тестировщики)	Пользуются MVP и сообщают об ошибках и пожеланиях

RACI-матрица

Обозначения:

• R (Responsible) — исполнитель, делает работу;
• A (Accountable) — отвечает за результат и принимает его; в каждой строке ровно один A;
• A/R — участник сам выполняет работу и сам отвечает за результат;
• C (Consulted) — с ним советуются до или во время работы;
• I (Informed) — его ставят в известность о результате. Столбцы матрицы:

Столбец	Участник	Роль
Денис	Ревягин Денис	Владелец продукта, ведущий разработчик
Алина	Соколова Алина	Scrum-мастер
Максим	Кузнецов Максим	Разработчик: парсер и база данных
Артём	Белов Артём	Разработчик: Telegram-бот
Екатерина	Морозова Екатерина	Тестировщик
Преп.	Преподаватель курса	Внешняя сторона
Бета	Бета-тестировщики	Внешняя сторона

Задача	Денис	Алина	Максим	Артём	Екатерина	Преп.	Бета
Формирование и приоритизация бэклога продукта	A/R	C	C	C	C	I	—
Описание задачи и критериев приёмки	A/R	—	C	C	C	—	—
Планирование спринта	A	R	C	C	C	—	—
Проектирование архитектуры	A/R	—	C	C	—	C	—
Проектирование базы данных и миграции	C	—	A/R	I	—	—	—
Разработка парсера расписания	I	—	A/R	—	C	—	—
Разработка Telegram-бота	C	—	C	A/R	C	—	—
Разработка API и рассылки уведомлений	A/R	—	C	C	—	—	—
Модульные тесты	A/R	—	R	R	C	—	—
Проверка кода через пул-реквест	A/R	—	R	R	—	—	—
Тест-план и приёмочное тестирование	C	—	I	I	A/R	—	—
Настройка CI/CD (GitHub Actions)	A/R	I	C	C	C	C	—
Развёртывание на сервере	A/R	I	I	I	C	—	I
Ведение Kanban-доски	R	A/R	R	R	R	—	—
Устранение препятствий в работе команды	C	A/R	C	C	C	—	—
Ведение wiki и README	A/R	R	C	C	C	I	—
Тестирование MVP на пользователях	A	I	I	I	R	—	R
Сбор и разбор обратной связи	A/R	I	C	C	R	—	C
Обзор спринта (ревью)	A/R	R	R	R	R	—	—
Ретроспектива спринта	C	A/R	C	C	C	—	—
Приёмка этапа (защита лабораторной работы)	R	C	C	C	C	A	—

Должностные инструкции

Ревягин Денис — владелец продукта, ведущий разработчик

Цель роли: продукт решает задачу студентов — быстро узнать следующую пару и аудиторию, а техническое решение остаётся простым и поддерживаемым.

Обязанности:

• вести бэклог продукта: формулировать пользовательские истории и критерии приёмки, расставлять приоритеты;
• решать, что входит в спринт, а что откладывается, если не хватает времени;
• принимать или отклонять результат спринта на обзоре;
• проектировать архитектуру системы, разрабатывать API и рассылку уведомлений;
• проверять пул-реквесты разработчиков;
• настраивать CI/CD и развёртывание бота на сервере. Зона ответственности: состав и приоритеты функциональности, достижение цели проекта по SMART, архитектура, ветка main и рабочая версия бота, хранение секретов (токен бота, доступ к базе данных).

Полномочия: изменять приоритеты бэклога, сокращать объём работ ради соблюдения сроков, отклонять пул-реквесты, не соответствующие Definition of Done.

Соколова Алина — Scrum-мастер

Цель роли: команда работает ритмично и предсказуемо, процесс помогает, а не мешает.

Обязанности:

• проводить планирование, дейли и ретроспективу;
• следить за соблюдением правил Kanban-доски и лимитов незавершённой работы;
• выявлять и устранять препятствия: зависшие задачи, ожидание проверки кода, неясные требования;
• поддерживать страницу Development и автоматизацию доски в актуальном состоянии;
• фиксировать решения ретроспектив и контролировать их выполнение. Зона ответственности: процесс разработки, Kanban-доска, ритм спринтов.

Полномочия: вносить изменения в процесс по итогам ретроспективы, останавливать взятие новых задач при превышении лимитов доски.

Кузнецов Максим — разработчик (парсер расписания и база данных)

Цель роли: в базе всегда актуальное расписание, а изменения на сайте вуза не ломают продукт незаметно.

Обязанности:

• разрабатывать и поддерживать парсер расписания с online.susu.ru;
• проектировать схему базы данных и писать миграции;
• поддерживать тесты парсера на сохранённых страницах расписания;
• следить, чтобы парсер работал в щадящем режиме: редкие запросы и кеширование;
• проверять пул-реквесты других разработчиков. Зона ответственности: модули parser/, db/, repositories/, папка migrations/, корректность данных расписания.

Полномочия: выбирать технические решения внутри своих модулей в рамках утверждённого стека.

Белов Артём — разработчик (Telegram-бот)

Цель роли: студенту удобно пользоваться ботом: понятные команды, кнопки и сообщения.

Обязанности:

• разрабатывать обработчики команд, клавиатуры и тексты бота;
• реализовывать сценарии: выбор группы, просмотр расписания, заметки к парам, настройка уведомлений;
• писать модульные тесты для логики бота;
• исправлять ошибки, найденные тестировщиком и пользователями;
• проверять пул-реквесты других разработчиков. Зона ответственности: модуль bot/, пользовательский интерфейс в Telegram.

Полномочия: предлагать изменения пользовательских сценариев владельцу продукта, возвращать задачу на уточнение, если её критерии приёмки неясны.

Морозова Екатерина — тестировщик (QA-инженер)

Цель роли: в рабочую версию не попадают ошибки, которые можно было найти до релиза.

Обязанности:

• составлять тест-план и проверочные сценарии по критериям приёмки задач;
• проверять задачи в статусе Testing в тестовом боте;
• оформлять найденные ошибки как задачи с шагами воспроизведения;
• проводить тестирование MVP с бета-тестировщиками и собирать их отзывы;
• участвовать в описании критериев приёмки, чтобы они были проверяемыми. Зона ответственности: качество каждого инкремента, перевод задач из Testing в Done или обратно в In Progress.

Полномочия: возвращать задачу в разработку, если она не проходит проверку или не соответствует Definition of Done.