Development

Development

Выбор модели жизненного цикла

Для проекта «Хабит» выбрана Agile-модель (Scrum с элементами Kanban). Выбор сделан по основным критериям сравнения моделей жизненного цикла.

Критерий	Ситуация в проекте	Что подходит
Стабильность требований	Требования уточняются по ходу: версии 2 и 3 (серии, статистика, бот) зависят от отзывов пользователей	Итеративные и Agile-модели
Размер и сложность	Небольшое приложение, один основной экран, простая архитектура	Лёгкие процессы без тяжёлой документации
Риски	Главные риски технические (лимиты CloudStorage) и продуктовые (много аналогов), их нужно выявлять рано	Короткие итерации с проверкой результата
Обратная связь	Нужна быстрая реакция на отзывы пользователей и заказчика	Частые релизы небольшими частями
Срок и приоритеты	Срок ограничен, объём гибкий: функции можно переносить между версиями	Работа по приоритетам бэклога
Команда	Небольшая команда из трёх человек	Scrum и Kanban рассчитаны на малые команды

Почему не другие модели:

• Каскадная и V-образная требуют зафиксировать все требования заранее и плохо подходят, когда они меняются.
• Спиральная оправдана для крупных проектов с высокими рисками и избыточна для небольшого приложения.
• Итеративная подходит, но Agile добавляет роли, ритм и инструменты, что важно для командной работы.

Как идёт работа в связи с этим: продукт развивается короткими спринтами по одной неделе. Каждый спринт заканчивается рабочим инкрементом, который можно показать заказчику. Версии продукта (MVP, версия 2, версия 3) складываются из таких инкрементов.

Адаптация методологии

Используется Scrum для ритма и ролей и Kanban для визуализации задач:

• спринты, роли и события берутся из Scrum;
• задачи ведутся на Kanban-доске со статусами и ограничением незавершённой работы;
• документация остаётся минимальной: Wiki, README и описание задач.

Scrum

Роли

Роль	Кто	Ответственность
Product Owner	Самира	Видение продукта, бэклог, приоритеты, приёмка результата спринта
Scrum Master	Лиза	Соблюдение процесса, организация событий, устранение препятствий
Разработчики	Илона Чурина (и Лиза как тестировщик)	Реализация, тестирование и публикация инкремента

События

Событие	Когда	Что происходит
Спринт	1 неделя	Цикл работы, результат которого рабочий инкремент
Планирование спринта	Понедельник, до 1 часа	PO предлагает задачи по приоритету, команда выбирает объём и формирует бэклог спринта
Дейли	Ежедневно, до 15 минут (в чате)	Каждый отвечает: что сделал, что будет делать, что мешает
Ревью спринта	Пятница, до 30 минут	Демонстрация инкремента заказчику и PO, сбор обратной связи
Ретроспектива	Пятница после ревью, до 30 минут	Что получилось, что улучшить в процессе, 1–2 конкретных действия

Артефакты

• Бэклог продукта: упорядоченный список всех задач и идей, ведёт PO (на доске в статусе To Do).
• Бэклог спринта: задачи, выбранные на текущую неделю.
• Инкремент: рабочая версия приложения, опубликованная на GitHub Pages и проверенная в Telegram.

Definition of Done

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

1. Изменение внесено в отдельной ветке и слито в main через Pull Request.
2. Pull Request просмотрен ревьюером, замечания учтены.
3. Приложение проверено вручную в Telegram: новая функциональность работает, старая не сломана.
4. В репозитории нет секретов (токены, .env).
5. Документация обновлена: README (раздел «Что умеет продукт сейчас») и при необходимости Wiki.
6. Изменения опубликованы на GitHub Pages, задача закрыта и находится в статусе Done.

Процесс работы команды

1. Появление задачи. PO заводит задачу (issue) с описанием и критериями приёмки, она попадает на доску в статус To Do.
2. Планирование. В понедельник команда выбирает задачи на спринт из верха списка.
3. Анализ. Если задача требует уточнения, Самира и разработчик обсуждают детали, задача идёт в статус «Аналитика».
4. Разработка. Илона берёт задачу, переводит её в In Progress, создаёт ветку feature/<название> и делает коммиты.
5. Ревью. Разработчик открывает Pull Request, задача переходит в «Ревью». Лиза проверяет изменения и оставляет комментарии.
6. Тестирование. После одобрения изменения проверяются в Telegram, задача находится в статусе «Тестирование».
7. Слияние и публикация. Pull Request сливается в main, GitHub Pages публикует обновление.
8. Приёмка. Самира проверяет результат по критериям, задача закрывается и получает статус Done.
9. Ревью и ретроспектива. В конце недели результат показывается заказчику, команда фиксирует улучшения процесса.

Kanban-доска и правила работы с ней

Статусы (колонки)

Статус	Что значит
To Do	Задача в бэклоге, к работе не приступали
Аналитика	Уточняются требования и критерии приёмки
In Progress	Задача в разработке
Ревью	Открыт Pull Request, идёт проверка кода
Тестирование	Проверка работы приложения в Telegram
Done	Выполнено по Definition of Done

Правила

1. Любая работа начинается с задачи (issue) на доске.
2. Новые задачи попадают в To Do, приоритет определяет PO порядком в колонке.
3. Задача берётся в работу только одним исполнителем, исполнитель указывается в поле Assignees.
4. Ограничение незавершённой работы (WIP): не более двух задач одновременно в статусе In Progress.
5. Один Pull Request решает одну задачу и содержит ссылку на задачу (Closes #номер).
6. Задача не двигается вправо, пока не выполнены условия предыдущего статуса.
7. Блокеры сообщаются на дейли, а в задаче оставляется комментарий.
8. В Done попадают только задачи, соответствующие Definition of Done.

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

Встроенные правила

Настроены в GitHub Projects (вкладка Workflows):

Правило	Что делает
Auto-add to project	Новые задачи и Pull Request из репозитория автоматически попадают на доску
Item added to project	Новая задача получает статус To Do
Item closed	Закрытая задача получает статус Done

Работа правил проверена: три созданные задачи (#5, #6, #7) сразу появились в колонке To Do, а закрытая задача #7 автоматически переехала в Done.

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

Правило	Что делает	Зачем
Code review approved	Статус меняется на Тестирование	После одобрения ревью задача переходит к проверке в Telegram
Code changes requested	Статус меняется на In Progress	Если ревьюер запросил правки, задача возвращается в работу
Item reopened	Статус меняется на In Progress	Переоткрытая задача снова считается взятой в работу

Чем кастомные правила отличаются от встроенной автоматизации

Встроенная автоматизация описывает только базовый путь задачи: новая задача получает To Do, закрытая получает Done. Кастомные правила реагируют на другие события (ревью Pull Request, повторное открытие) и переводят задачу в любой статус нашей доски, включая добавленные Аналитику, Ревью и Тестирование. Так доска следует нашему процессу, а не только трём стандартным статусам.

Какое правило я бы добавила, чтобы доска вела себя под процесс

Правило «Pull request opened → Ревью»: когда разработчик открывает Pull Request, связанная задача сама переходит в колонку Ревью и ревьюеру не нужно передвигать карточку вручную. Сейчас этот переход выполняется вручную.