---

Нужно написать с нуля учебное веб-приложение на Spring Boot: менеджер отмечает задачи из бэклога, а система раздаёт их сотрудникам по их реальной скорости из истории и показывает шанс успеха спринта числом. Ниже всё, что нужно для работы: процесс, ограничения, данные, алгоритм, страницы и проверки.
1. Как работать с этим документом
Ты нейросеть-разработчик. Прочитай документ целиком, затем строй приложение этапами из раздела 13. Этот документ единственный источник требований.
• Если чего-то не хватает или требования противоречат друг другу, остановись и задай вопрос. Не придумывай недостающее.
• Делай только версию 1. Расширения из раздела 14 не добавляй, пока тебя не попросили.
• Не добавляй библиотеки, слои и аннотации сверх разделов 5 и 6.
• Работай этапами. После каждого этапа покажи файлы целиком и скажи, что ты проверил запуском, а что нет.
• Числа из раздела 12 должны получаться на демо-данных из раздела 8. Если не получаются, найди причину в коде. Не подгоняй данные.
• Если ты не можешь запустить код, прямо напиши, что не запускал его.
• Требования экзамена из раздела 15 имеют приоритет над этим документом.
Готовый запрос для вставки в нейросеть вместе с этим документом:
Прочитай приложенное ТЗ «Планировщик спринтов» и реализуй версию 1 по этапам из раздела 13. После каждого этапа покажи файлы целиком и жди моего подтверждения. Если в ТЗ чего-то не хватает или есть противоречие, спроси, а не придумывай.
2. Что строим и зачем
Проблема. Многие команды работают по Agile, то есть спринтами: короткими отрезками (1-2 недели), на которые берут заранее выбранный набор задач. Каждой задаче команда ставит Story Point (SP), условную оценку сложности. Но один разработчик делает 1 SP за 3 часа, другой за 5, поэтому реальный срок задачи неизвестен, и спринты срываются.
Решение. Менеджер отмечает задачи из бэклога и одной кнопкой собирает план. Приложение берёт историю фактических часов, считает скорость каждого сотрудника по каждому типу задач, раздаёт задачи подходящим сотрудникам и показывает шанс успеха: вероятность, что все задачи уложатся в часы сотрудников. К каждому назначению есть объяснение «почему так».
Чем отличается от обычных трекеров. Они считают скорость всей команды одним числом. Здесь скорость считается по паре «сотрудник × тип задач», учитывается специальность, а результат показывается вероятностью, посчитанной симуляцией на истории.
Словарь
Термин
Значение
Спринт
Отрезок времени (1-2 недели), на который берут набор задач
Бэклог
Список задач, которые ещё не взяты в работу
Story Point (SP)
Условные очки сложности задачи. Это не часы: 5 SP примерно в 2,5 раза сложнее, чем 2 SP
Ёмкость
Сколько часов сотрудник может отдать спринту (с учётом созвонов, отпусков)
Специальность
Роль сотрудника: backend, frontend, tester. Задачу может получить только сотрудник её специальности
Тип задачи
bugfix, feature, integration, testing. По типу считается скорость
История работы
Записи о выполненных задачах: оценка в SP и реально потраченные часы
Скорость (ч/SP)
Среднее число часов, которое сотрудник тратит на 1 SP задач данного типа. Чем больше число, тем он медленнее
Разброс
Стандартное отклонение ч/SP: насколько результат сотрудника «гуляет» от задачи к задаче
Симуляция (Монте-Карло)
1000 компьютерных «прогонов» спринта со случайными отклонениями времени
Шанс успеха
Доля прогонов, в которых никто не вышел за свою ёмкость
Менеджер
Единственная роль пользователя. Входа в систему нет
3. Бизнес-процесс
Путь менеджера
1. Менеджер открывает главную страницу. Слева бэклог (задача, тип, SP, специальность), справа команда (имя-ссылка, специальность, ёмкость).
2. Ставит галочки у задач, которые хочет взять в спринт.
3. Нажимает «Собрать план». Браузер отправляет POST /plan со списком отмеченных задач.
4. Видит страницу плана: шанс успеха, карточки всех сотрудников с загрузкой (часы из ёмкости), у каждой задачи раскрывающееся «Почему так?» с расчётом, список задач, которые не поместились.
5. Если шанс низкий или есть не поместившиеся задачи, возвращается на главную, снимает галочку с лишней задачи и собирает план заново. «Вынести задачу» значит снять галочку: задача остаётся в бэклоге, ничего не удаляется.
6. По ссылке на сотрудника смотрит его скорость (ч/SP) по типам задач.
План нигде не сохраняется: каждый расчёт независим и ничего не меняет в данных.
Как строится план (кратко, подробности в разделе 9)
1. Берутся отмеченные задачи в порядке их id (меньший id важнее).
2. Для каждой задачи отбираются сотрудники той же специальности.
3. Для каждого кандидата считается ожидаемое время: SP × его средние ч/SP на этом типе задач (из истории).
4. Если время не помещается в оставшуюся ёмкость кандидата, он отпадает.
5. Из оставшихся выбирается тот, у кого итоговая загрузка после этой задачи будет наименьшей. Так нагрузка выравнивается, и лучший по скорости не забирает всё.
6. Если кандидатов не осталось, задача попадает в «не поместились».
7. Симуляция Монте-Карло (1000 прогонов) даёт шанс успеха по размещённым задачам.
Бизнес-правила
• Задачу получает только сотрудник её специальности.
• Загрузка сотрудника не может превышать его ёмкость.
• Время задачи зависит от человека: одна и та же задача в 5 SP у разных сотрудников занимает разное время.
• Шанс успеха считается только по размещённым задачам. Если часть задач не поместилась, это показывается отдельно.