Development — процесс разработки Password Generator

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

Выбрана итеративная модель из семейства Agile с адаптированными практиками Scrum и визуализацией потока задач через Kanban в GitHub Projects.

Обоснование выбора:

• Размер команды: проект ведёт один разработчик, поэтому необходим лёгкий процесс без лишних согласований.
• Требования: базовая идея определена, но удобство интерфейса, обработка ошибок и отдельные возможности могут уточняться в процессе.
• Срок: по концепции проекта планируется четыре недели; короткие недельные итерации позволяют регулярно оценивать результат.
• Риски: функциональность генерации паролей нужно проверять по мере реализации, не откладывая тестирование на конец.
• Обратная связь: изменения можно показывать и корректировать после каждой итерации.

Каскадная модель была бы менее гибкой при уточнении требований, а спиральная и V-образная — избыточно формальными для небольшого учебного веб-приложения. Применяется адаптация Scrum, а не утверждается, что проект соответствует всем правилам Scrum Guide для полноценной команды.

2. Участник и Scrum-роли

Все роли выполняет один человек — владелец репозитория JUSUKE-MOMENT:

• Product Owner: цель продукта, приоритеты, критерии приёмки.
• Scrum Master: организация ритма, доска, устранение препятствий, ретроспектива.
• Developer: реализация, тестирование, документация и поставка работающего результата.

Распределение обязанностей подробно приведено на странице Team.

3. Рабочий ритм и события

Период	Практика	Результат
Ежедневно (5–10 минут)	Личная проверка задач: что сделано, что будет сделано, что мешает	Актуальные статусы и список препятствий
В начале недели (20–30 минут)	Планирование спринта	Цель спринта и выбранные задачи Sprint Backlog
В течение недели	Разработка в отдельных ветках, самопроверка, тестирование	Готовые изменения и Pull Request
В конце недели (15–20 минут)	Sprint Review: демонстрация результата и проверка критериев	Принятые или возвращённые задачи
В конце недели (10–15 минут)	Ретроспектива	1–2 улучшения процесса на следующую неделю
По окончании четырёх недель	Итоговая проверка результата и документации	Учебный инкремент проекта

Это личные аналоги Scrum-событий: групповые встречи не проводятся, результаты кратко фиксируются в задачах или заметках проекта.

4. Артефакты

• Product Backlog: все требования, улучшения и ошибки в GitHub Issues/Projects, упорядоченные по приоритету.
• Sprint Backlog: задачи, выбранные на текущую неделю, с понятными критериями завершения.
• Increment: проверенная работоспособная версия приложения после итерации.
• Definition of Done: общие критерии готовности, приведённые ниже.

5. Процесс прохождения задачи

1. Постановка: оформить GitHub Issue с описанием, целью и проверяемыми критериями приёмки.
2. Планирование: определить приоритет и добавить задачу в GitHub Project со статусом To Do.
3. Разработка: перенести в In Progress, создать тематическую Git-ветку (feature/... или fix/...), выполнить изменения и коммиты.
4. Самопроверка: открыть Pull Request, связать с Issue, перенести в Review, посмотреть diff и проверить соответствие критериям. Поскольку участник один, внешнее ревью не предполагается.
5. Тестирование: перенести в Testing, запустить доступные проверки проекта и вручную проверить основные и граничные сценарии. При дефекте вернуть в In Progress.
6. Завершение: после принятия результата объединить Pull Request с main, обновить документацию при необходимости, закрыть Issue и перевести в Done.

Небольшие задачи без изменения кода могут завершаться без PR, если это явно указано в Issue.

6. Definition of Done (DoD)

Задача считается завершённой, когда:

• Реализованы все её критерии приёмки.
• Изменения не нарушают существующие функции генератора.
• Выполнены доступные проверки проекта (например, lint и сборка, если такие команды предусмотрены в package.json), ошибки устранены.
• Для изменений поведения выполнена ручная проверка, включая невалидные и граничные значения; для интерфейса — проверка адаптивности.
• Код самостоятельно проверен по diff; нет случайных файлов, секретов и отладочного мусора.
• Для задач с кодом изменения слиты в main через Pull Request.
• При необходимости обновлены README/Wiki.
• Issue закрыта, карточка на доске имеет статус Done.

7. Kanban-доска GitHub Projects

Для проекта создаётся отдельный GitHub Project с представлением Board и полем Status:

Статус	Смысл	Правило перехода
To Do	Задача сформулирована и ожидает выполнения	Есть понятные критерии приёмки
In Progress	Идёт реализация	Работа начата, есть рабочая ветка при изменениях кода
Review	Самопроверка кода и требований	Открыт PR либо подготовлен результат без кода
Testing	Проверка функциональности и граничных случаев	Ошибки отправляются назад в In Progress
Done	Задача завершена	Выполнен DoD, Issue закрыта

Рекомендуемое ограничение одновременно выполняемых задач: не более 1–2 в In Progress. Доска обновляется при изменении фактического состояния, а не только по итогам недели.

Ссылка на доску

8. Автоматизация

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

1. При добавлении новой задачи в проект устанавливать Status = To Do (настройка значения по умолчанию для новых элементов, а при необходимости — отдельный workflow при добавлении).
2. Когда связанная Issue закрывается, устанавливать Status = Done с помощью встроенного workflow Item closed.

Кастомные Workflows

Планируемые правила, которые нужно создать и проверить в интерфейсе Workflows:

1. При переходе карточки в Done заполнять поле даты завершения Completed, если такой триггер и действие доступны в текущем GitHub Projects.
2. При добавлении Issue в проект назначать её владельцу репозитория, если поддерживается действие назначения исполнителя.

Если интерфейс GitHub Projects не поддерживает соответствующую комбинацию триггера и действия, нужно выбрать доступные кастомные правила и обновить данный раздел по реально работающей настройке. Нельзя считать правила настроенными только из-за их описания в Wiki.

9. Инструменты

• GitHub Issues — формулировка задач и критериев приёмки.
• GitHub Projects — Kanban и статусы задач.
• Git / GitHub Pull Requests — история изменений и самопроверка.
• React + TypeScript + Vite — реализация веб-приложения.
• README и GitHub Wiki — документация проекта и процесса.

10. Эволюция продукта

В лабораторных 1–2 были сформированы концепция, документация и базовая структура репозитория. В лабораторной 3 вводится порядок разработки и контроля задач. Новые продуктовые задачи и их реализация будут оформляться в лабораторной 4. Наличие описанного процесса само по себе не означает, что все планируемые функции реализованы.

← Home · Команда и RACI →