Development

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

1. Модель жизненного цикла

Сравнение моделей

Критерий	Каскадная	V-образная	Итеративная	Спиральная	Agile-семейство
Требования известны заранее и не меняются	нужно	нужно	не обязательно	не обязательно	не обязательно
Работающий результат появляется рано	нет	нет	да	да	да
Подходит для маленькой команды и малого проекта	да	средне	да	нет	да
Учитывает высокие технические риски	слабо	средне	да	да	да
Обратная связь пользователей в ходе работы	нет	нет	частично	частично	да
Накладные расходы на документацию и процесс	высокие	высокие	средние	высокие	низкие

Выбор: итеративно-инкрементная модель семейства Agile с фиксированным сроком

Почему не каскадная и не V-образная. Требования к продукту будут уточняться после первых пользователей: какие уведомления нужны, за сколько минут напоминать, нужны ли заметки. Каскадная модель предполагает, что всё известно заранее, и даёт результат только в конце проекта.

Почему не спиральная. Она рассчитана на крупные проекты с формальным анализом рисков на каждом витке. Для малого проекта на три месяца это лишние затраты.

Почему Agile.

• Главный технический риск — изменение структуры сайта с расписанием. Его нужно проверить как можно раньше, а не в конце: парсер делается в первой итерации.
• Цель проекта измеряется числом пользователей. Чем раньше студенты получат работающий бот, тем больше времени на доработку по их отзывам.
• Команда из пяти человек работает в тесном контакте, ей не нужны тяжёлая документация и формальные согласования. Ограничение модели. Срок проекта фиксирован (до 20.12.2026), поэтому гибким остаётся только объём. Это совпадает с подходом из Concept: от PMBOK берутся устав, контрольные точки и дата завершения, от Agile — итерации и приоритизированный бэклог.

Как это влияет на работу:

• работа идёт недельными итерациями, каждая заканчивается работающим инкрементом;
• первым делается MVP (парсер и показ расписания), затем заметки, затем уведомления;
• если итерация не укладывается в план, срезается объём, а не переносится срок.

2. Адаптация методологии: Scrumban

Команда из пяти человек укладывается в рекомендуемый размер Scrum-команды, поэтому роли и события Scrum используются полностью. Но разработчики учатся параллельно с проектом и не могут гарантировать одинаковую загрузку каждую неделю, поэтому жёсткие обязательства спринта дополнены потоковой Kanban-доской. Получается Scrumban — сочетание Scrum и Kanban:

• от Scrum — недельные итерации с целью, планирование, обзор и ретроспектива;
• от Kanban — доска со статусами, лимиты незавершённой работы, непрерывный поток задач.

Ритм работы

Период	Что происходит
День	Дейли в чате команды до 12:00: каждый пишет «что сделано / что дальше / что мешает». Scrum-мастер разбирает препятствия. Каждый разработчик ведёт одну задачу за раз.
Неделя (спринт)	Понедельник — планирование: цель спринта и задачи из бэклога. Будни — разработка, проверка кода, тестирование. Пятница — обзор (демонстрация инкремента владельцу продукта) и ретроспектива.
Месяц	Контрольная точка: сверка с планом этапов (MVP → заметки → уведомления), пересмотр приоритетов бэклога, при необходимости сокращение объёма.

Scrum-роли

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

Подробные обязанности — на странице Team.

Scrum-события

Событие	Длительность	Как проводится
Спринт	1 неделя	Понедельник — воскресенье, одна цель на спринт
Планирование	до 1 часа	Владелец продукта предлагает цель спринта, команда выбирает и оценивает задачи
Дейли	15 минут	Текстом в чате команды, препятствия разбирает Scrum-мастер
Ревью (обзор)	до 45 минут	Демонстрация готовых задач в тестовом боте владельцу продукта; на защите — преподавателю
Ретроспектива	до 45 минут	Проводит Scrum-мастер: что получилось, что мешало, что изменить; решения фиксируются в Discussions

Scrum-артефакты

Артефакт	Где хранится
Бэклог продукта	Все задачи в GitHub Project, отсортированные по приоритету
Бэклог спринта	Задачи с полем Iteration, равным текущему спринту
Инкремент	Ветка main после слияния пул-реквестов; позже — развёрнутая версия бота

Definition of Done

Задача считается выполненной, только если выполнены все условия:

1. Код влит в main через пул-реквест, а не прямым коммитом.
2. Автоматические проверки CI (линтер и тесты) проходят.
3. Для новой логики есть тесты; для парсера — тест на сохранённой странице расписания.
4. Критерии приёмки из задачи проверены в тестовом боте.
5. В коде и в репозитории нет секретов (токенов, паролей).
6. README или wiki обновлены, если изменилось поведение продукта или способ запуска.
7. Задача закрыта и находится в колонке Done.

Процесс работы над задачей

1. Появление задачи. Владелец продукта (Ревягин Д.) создаёт issue: пользовательская история и критерии приёмки. Тестировщик (Морозова Е.) проверяет, что критерии можно проверить. Задача автоматически попадает на доску в колонку To Do.
2. Аналитика. Если задача неясна или крупная, она переходит в Аналитика: владелец продукта и разработчик уточняют требования, делят задачу на части, оценивают риски.
3. Разработка. Разработчик, отвечающий за модуль (Кузнецов М. — парсер и база данных, Белов А. — бот, Ревягин Д. — API и уведомления), берёт задачу в In Progress, создаёт ветку feature/<короткое-описание> и пишет код и модульные тесты.
4. Проверка кода. Разработчик открывает пул-реквест со ссылкой на задачу (Closes #N), и задача автоматически переходит в Review. Код проверяет другой разработчик. Если он запрашивает изменения, разработчик дорабатывает код в том же пул-реквесте.
5. Тестирование. После одобрения проверяющего и прохождения CI разработчик переводит задачу в Testing. Тестировщик запускает тестовый бот из ветки пул-реквеста и проверяет критерии приёмки. При ошибке задача возвращается в In Progress с комментарием.
6. Готово. Если проверка пройдена, тестировщик одобряет пул-реквест, и разработчик вливает его в main. Благодаря Closes #N задача закрывается и автоматически попадает в Done. Владелец продукта принимает готовые задачи на обзоре спринта. Тестирование выполняется до слияния, чтобы в main попадал только проверенный код.

Задачу передают через смену статуса на доске и упоминание следующего исполнителя (@ник) в комментарии. Scrum-мастер на дейли следит, чтобы задачи не застревали между этапами.

3. Kanban-доска

Доска: GitHub Project

Колонки

Статус	Смысл	Лимит задач
To Do	Новые задачи и задачи, отобранные в бэклог	—
Аналитика	Уточнение требований, декомпозиция	2
In Progress	Идёт разработка	3
Review	Открыт пул-реквест, идёт проверка кода и CI	3
Testing	Код одобрен, тестировщик проверяет ветку в тестовом боте	2
Done	Выполнены все условия Definition of Done	—

Правила работы с доской

1. Любая работа начинается с задачи (issue) на доске. Работы «вне доски» нет. На доске находятся только задачи; пул-реквесты связываются с ними через Closes #N.
2. У каждой задачи есть критерии приёмки, а у задач спринта — заполненное поле Iteration.
3. Нельзя превышать лимит колонки: сначала завершается текущая задача, потом берётся новая.
4. Задачи двигаются слева направо. Возврат назад допускается только из Review или Testing при найденной ошибке, с комментарием о причине.
5. Задачу, которая больше трёх дней стоит в одном статусе, Scrum-мастер поднимает на ближайшем дейли.
6. В Done задача попадает только после выполнения Definition of Done.

4. Автоматизация доски

Встроенная автоматизация

Событие	Действие
Item added to project — задача добавлена в проект	Статус → To Do
Item closed — задача закрыта	Статус → Done
Auto-close issue — статус изменён на Done	Задача закрывается

Последние два правила работают в паре: закрытая задача попадает в Done, а задача, вручную перенесённая в Done, закрывается. Доска и состояние задач не расходятся.

Кастомные правила (Workflows)

Правило	Настройка	Зачем
Автодобавление в проект	Auto-add to project, репозиторий unlaesh/project, фильтр is:issue is:open	Новые задачи сами попадают на доску. Пул-реквесты не добавляются, чтобы на доске не было дублирующих карточек
Пул-реквест связан с задачей	Pull request linked to issue → статус Review	Задача сама переходит в Review, когда открыт пул-реквест с Closes #N
Повторное открытие	Item reopened → статус In Progress	Если закрытая задача оказалась недоделанной, она возвращается в работу, а не остаётся в Done
Автоархивация	Auto-archive items, фильтр is:closed updated:<@today-14d	Колонка Done не разрастается: закрытые больше двух недель назад задачи уходят в архив