Repository navigation
Team
Проект Password Generator разрабатывается одним участником — владельцем репозитория JUSUKE-MOMENT. Это учебный проект, поэтому обязанности аналитика, руководителя проекта, разработчика, тестировщика и ответственного за документацию совмещаются одним человеком.
Вместо формального разделения между сотрудниками ниже описано разделение обязанностей по ролям. Указанные роли не означают наличие дополнительных участников команды.
- Определяет цель продукта и потребности пользователей.
- Формирует и упорядочивает Product Backlog.
- Задаёт критерии приёмки и принимает результаты завершённых задач.
- Следит за соответствием функций концепции проекта.
- Поддерживает выбранный ритм работы и правила Kanban-доски.
- Следит за прозрачностью статусов задач и соблюдением Definition of Done.
- Находит препятствия и улучшает рабочий процесс по результатам ретроспективы.
- В учебном проекте применяются адаптированные практики Scrum, а не полноценная командная Scrum-организация.
- Анализирует технические требования и проектирует изменения.
- Реализует интерфейс и логику генерации паролей на React и TypeScript.
- Создаёт тематические ветки Git, коммиты и Pull Request.
- Исправляет ошибки и поддерживает читаемость кода.
- Проверяет корректность генерации и пользовательских настроек.
- Тестирует граничные значения и нестандартные сценарии.
- Проверяет интерфейс, в том числе различные размеры экрана.
- Документирует обнаруженные дефекты и повторно проверяет исправления.
- Поддерживает README и GitHub Wiki в актуальном состоянии.
- Описывает правила разработки, структуру проекта и изменения.
- Следит за связью задач, Pull Request и документации.
R — выполняет работу (Responsible); A — отвечает за итог и принимает решение (Accountable); C — консультирует/проверяет с точки зрения роли (Consulted); I — информируется о результате (Informed).
| Вид работы | Product Owner | Scrum Master | Разработчик | Тестировщик | Документация |
|---|---|---|---|---|---|
| Определение требований и критериев приёмки | A/R | I | C | C | I |
| Приоритизация Product Backlog | A/R | C | C | I | I |
| Планирование недельного спринта | A | R | C | C | I |
| Реализация функциональности | C | I | A/R | C | I |
| Проверка кода и технических изменений | I | C | A/R | C | I |
| Тестирование и регистрация ошибок | I | I | C | A/R | I |
| Приёмка результата задачи | A/R | I | C | C | I |
| Поддержка Kanban и ретроспектива | C | A/R | C | C | I |
| Обновление README и Wiki | C | I | C | C | A/R |
Примечание: каждую роль выполняет один и тот же человек. В матрице указан ровно один A на каждую работу. Независимого code review в таком составе нет: вместо него используется самостоятельная проверка изменений по чек-листу перед слиянием Pull Request.
- В роли Product Owner определить задачу и критерии приёмки.
- В роли Scrum Master запланировать её и добавить на Kanban-доску.
- В роли разработчика выполнить изменения в отдельной ветке.
- В роли тестировщика проверить результат и зафиксировать проблемы.
- В роли Product Owner принять или вернуть задачу в работу.
- В роли ответственного за документацию обновить необходимые страницы.
LLM использовалась для подготовки первоначального варианта обязанностей и RACI-матрицы. Затем распределение ролей было адаптировано под одного реального участника: исключены фиктивные сотрудники, уточнена ответственность за приёмку и самостоятельную проверку кода.