Development - elizabet24/project GitHub Wiki
Development — процесс разработки
1. Модель жизненного цикла
Для проекта выбрана итеративная модель (Agile-семейство, Scrum + Kanban).
Обоснование:
- Объём работ неизвестен заранее. EDA — исследовательский процесс: состав признаков, визуализаций и выводов уточняется по ходу.
- Требования уточняются. Нельзя сразу определить, какие именно выбросы, пропуски и аномалии найдутся в данных.
- Малый масштаб и один исполнитель. Каскадная модель (Waterfall) здесь неэффективна — она требует фиксированных требований и длинных фаз.
- Быстрая обратная связь. Преподаватель и эксперт-ревьюер дают замечания по ходу — Agile позволяет встраивать их в следующие итерации.
- V-образная и спиральная модели слишком формальны для учебного проекта на 2 месяца.
Как будет идти работа: короткими итерациями (спринтами) по 1 неделе. В конце каждой итерации — рабочий инкремент (например, готовая описательная статистика, затем графики, затем диагностика выбросов).
2. Процесс работы команды
Ритм команды:
| Интервал | Активность | Результат |
|---|---|---|
| День | 15 минут само-standup (запись в Kanban: что сделано, что дальше, есть ли блокеры) | Обновлённая доска |
| Неделя | Спринт: планирование в начале, обзор и ретро в конце | Инкремент + заметки |
| 2 недели | Демонстрация промежуточного результата эксперту | Обратная связь |
| Месяц | Обновление Wiki и README, синхронизация с преподавателем | Обновлённые артефакты |
Последовательность шагов (типовой цикл задачи):
- Идея / задача попадает в бэклог (GitHub Issues).
- Задача получает статус To Do (автоматически).
- При старте работы задача переводится в In Progress.
- Исполнитель пишет код / документацию в отдельной ветке (
feature/...). - Открывается Pull Request.
- Ревью (Нуреева С.Р. или самопроверка по чек-листу).
- После слияния PR задача переводится в Done (автоматически).
- На ретроспективе анализируется, что улучшить.
3. Scrum-роли, события, артефакты
Роли
| Роль | Кто | Задачи |
|---|---|---|
| Product Owner | Лобанова Е.С. | Ведёт бэклог, приоритизирует задачи |
| Scrum Master | Лобанова Е.С. | Организует процесс, устраняет блокеры |
| Разработчик | Лобанова Е.С. | Реализует код и документацию |
| Эксперт | Нуреева С.Р. | Даёт обратную связь |
В учебном проекте один участник совмещает три Scrum-роли. Это допустимо и отмечено в Wiki.
События
- Спринт — 1 неделя.
- Планирование спринта — выбор задач из бэклога, оценка трудозатрат.
- Daily — ежедневная короткая запись о статусе.
- Sprint Review — демонстрация инкремента (себе, эксперту).
- Ретроспектива — что получилось, что улучшить.
Артефакты
- Product Backlog — все задачи проекта (GitHub Issues).
- Sprint Backlog — задачи текущего спринта (метка
sprint-1и т.п.). - Инкремент — рабочий результат спринта (обновлённый README, Wiki, код, отчёт).
4. Definition of Done (DoD)
Задача считается выполненной, если:
- ✅ Код написан и работает без ошибок.
- ✅ Код слит через Pull Request (не напрямую в main).
- ✅ PR прошёл ревью (экспертом или самопроверку).
- ✅ Документация обновлена (README, Wiki или docstring).
- ✅ Задача переведена в статус Done на Kanban-доске.
- ✅ Нет незакоммиченных изменений (
git statusчист). - ✅ Если это анализ — построены графики и сформулированы выводы.
- ✅ Если это документ — он проверен на орфографию и логику.
5. Kanban-доска
Доска создана в GitHub Projects:
- Список проектов: https://github.com/elizabet24/project/projects
- Прямая ссылка на доску: https://github.com/users/elizabet24/projects/1
Колонки (статусы)
| Колонка | Что означает |
|---|---|
| Backlog | Задачи, которые ещё не запланированы в спринт |
| To Do | Задачи на текущий спринт |
| In Progress | В работе |
| Review | Pull Request открыт, ждёт ревью |
| Testing / Analysis | Проверка качества, анализ результатов |
| Done | Задача завершена и соответствует DoD |
Правила работы с доской
- Новая задача автоматически попадает в To Do.
- Перед началом работы задача переводится в In Progress.
- После открытия PR задача переводится в Review.
- После слияния PR задача автоматически переводится в Done.
- Задачи не остаются в In Progress дольше 3 дней без движения — это сигнал о блокере.
- Backlog пересматривается на планировании каждого спринта.
6. Автоматизация
Встроенная автоматизация
| Событие | Действие |
|---|---|
| Новая задача добавлена в проект | Статус → To Do |
| Задача закрыта | Статус → Done |
Кастомные правила (Workflows)
Настроены через Projects → Workflows:
- Правило 1: когда статус задачи меняется на Done → заполнить поле Completed текущей датой.
- Правило 2: когда задача закрывается → автоматически добавлять метку
completed.
Вопросы
Чем кастомные правила Workflows отличаются от встроенной автоматизации?
Встроенная автоматизация покрывает только два триггера («новая → To Do», «закрыта → Done»). Workflows позволяют задавать свои условия: по изменению статуса, по метке, по добавлению в проект, по закрытию PR и т.д. Это гибкая механика уровня проекта без дополнительной инфраструктуры.
Какое правило я бы добавила, чтобы доска «сама вела себя» под мой процесс?
Правило: «Когда PR сливается в main → перевести связанную задачу в Review → Done». Это сократит ручные переключения и свяжет Git-флоу с Kanban.