Skip to content

Development

Jump to bottom
JUSUKE edited this page Oct 15, 2026 · 2 revisions

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 →

Clone this wiki locally