Устав проекта - aksay-dev/Delta-PRO GitHub Wiki

Устав проекта: Microtec v0.3.0

Версия: 0.2.4 Дата: 12.08.2025
Статус: На согласовании
Дата первого релиза 31.07.2025 г.


1. Цели проекта

  • Основная цель: Разработать, протестировать и запустить в производство новое поколение промышленных стабилизаторов напряжения Microtec v0.3.0, которое превосходит предыдущие версии Delta-PRO v1.1.0, v0.2.0 по точности, функциональности и интеграции, превосходит конкурентов по некоторым характеристикам.
  • Ключевые цели:
    • Достичь точности стабилизации выходного напряжения ±3.4%.
    • Расширить диапазон рабочих входных напряжений до 90-270 В.
    • Реализовать 16 ступеней стабилизации.
    • Разработать и внедрить в версии Microtec v0.3.0 индикацию на цветном IPS-дисплее.
    • Обеспечить удалённое управление и мониторинг через:
      • Мобильные приложения (Android, iOS).
      • Веб-интерфейс (через браузер).
    • Обеспечить интеграцию в системы умного дома и IoT (Home Assistant Server).
    • Обеспечить интеграцию с системами голосового управления (Яндекс Алиса, Google Assistant).
    • Запустить производство первой партии прототипов к 01.01.2026 г.

2. Команда проекта и Роли

Команда работает по методологии Agile. Все роли и обязанности являются общедоступными (Единый источник истины).

Роль (Role) Обязанности (Responsibilities) Назначен (Assigned to)
Project Manager (Менеджер проекта) • финансовое управление проектом, проведение маркетинговых мероприятий, планирование производства, обеспечение заказов
• Представление интересов бизнеса.
Коммуникация с заинтересованными сторонами.
Сергей Полупанов
Product Owner (Владелец продукта) • Определение и приоритезация бэклога продукта (Product Backlog).
• Принятие решений по функциональности и приоритетам.
• Утверждение результатов спринтов.
Коммуникация с заказчиком / бизнесом — помогает трансформировать бизнес-требования в технические задачи.
[не определен]
Agile Master (Агил-мастер) • Фасилитация Agile-процессов (стендапы, планирование, ретроспективы).
• Удаление препятствий и блокеров для команды • Обеспечение соблюдения Agile-принципов.
• Поддержка самоорганизации команды.
Наставничество (Mentorship) — обучение, развитие и поддержка менее опытных участников.
Олег Хачкинаев
Team Lead (Руководитель группы проекта) Архитектура и проектирование решений — выбор архитектурного стека, проектирование технических решений.
Управление командой:
Наставничество (Mentorship) — обучение, развитие и поддержка менее опытных участников.
Распределение задач
Развитие команды — выявление потребностей в обучении, росте, найме новых членов.
Решение конфликтов — сглаживание разногласий внутри команды и между командами.
Работа в Agile-процессе
Коммуникация и взаимодействие
Стратегическое мышление.
Олег Хачкинаев
System Hardware and Firmware Architect (Системный архитектор оборудования и встроенных программ проекта) • Определение общей архитектуры системы (железо, прошивка, ПО).
• Координация работы между членами команды по техническим вопросам.
• Технический надзор и принятие ключевых технических решений.
Андрей Аксайский
System Software Architect (Системный архитектор программного обеспечения проекта) • Определение общей программной архитектуры системы.
• Координация работы между членами команды по вопросам ПО.
• Надзор и принятие ключевых программных решений.
Дмитрий Емельяненко
Hardware Engineer (Инженер-электронщик) • Разработка и тестирование схемы стабилизатора.
• Выбор и валидация компонентов (трансформатор, ключи).
• Разработка алгоритмов управления на уровне железа.
Андрей Аксайский
Firmware Developer (Разработчик прошивки) • Разработка и отладка прошивки на C/C++ для микроконтроллера.
• Реализация алгоритмов True RMS, Adaptive Zero Cross, Hysteresis, коррекции по cos(φ) и т.д.
• Интеграция с датчиками и периферией.
Андрей Аксайский
Constructor (Конструктор) Разработка и контроль качества корпуса стабилизатора. Сборка стабилизатора. [не определен]
Software Developer (Разработчик ПО) • Разработка мобильных приложений (Android/iOS).
• Разработка веб-интерфейса (Frontend/Backend).
• Реализация API для IoT-интеграции.
Дмитрий Емельяненко
IoT & Integration Specialist (Специалист по IoT) • Настройка и реализация Wi-Fi/LAN подключения.
• Интеграция с платформами Home Assistant Server, Яндекс Алиса, Google Assistant.
• Обеспечение безопасности коммуникаций.
Дмитрий Емельяненко
UX/UI Designer (Дизайнер) • Проектирование пользовательского опыта (UX) для дисплея, приложений и веб-интерфейса.
• Создание визуального дизайна (UI).
[не определен]
Инженер по тестированию (Test Engeneer) • Разработка тест-планов и тест-кейсов.
• Проведение функционального, нагрузочного, стресс- и регрессионного тестирования.
• Тестирование безопасности и UX.
• Ведение баг-трекера.
Дмитрий Емельяненко
QA Engineer (Инженер по качеству) Обеспечение качества продукта
Разработка тестов
Участие в Agile-процессах
Взаимодействие с командой
Интеграция с CI/CD и DevOps-практиками
Аналитика и контроль качества
Обучение и развитие
• Дополнительно (если QA — единственный или ведущий в команде):
• Формирование Definition of Done и Definition of Ready.
• Ведение документации по качеству.
•Тестирование на уровне требований (review user stories на корректность и полноту).
Поддержка качества кода — внедрение и соблюдение стандартов кодирования, тестирования и CI/CD.
[не определен]
DevOps Engineer Автоматизация CI/CD (Continuous Integration / Continuous Delivery)
Управление инфраструктурой
Обеспечение безопасности (DevSecOps)
Поддержка тестирования
Мониторинг и логирование
Управление конфигурациями и зависимостями
Взаимодействие с командой
Непрерывная доставка и релизы
Аналитика и улучшение процессов
• DevOps в Agile — это:
“Не просто про серверы — а про культуру ответственности, автоматизации и совместной работы всей команды над качественным и быстрым выпуском продукта.”
Дмитрий Емельяненко

3. Методологии и Инструменты

  • Методология: Agile.
    • Спринты: 2 недели.
    • Встречи: Еженедельные онлайн стендапы (30 - 60 мин.), Планирование спринтов, Ревью спринтов, Ретроспектива.
  • Инструменты:

4. Основные процессы и политики

  1. Единый источник истины (Аксиома 2):

    • Актуальное состояние проекта, задачи, баги — в RedMine.
    • Исходный код, прошивка — в приватном Git репозитории.
    • Корпус, схемы, платы — в RedMine.
    • Документация (включая этот Устав, спецификации, руководства) — в GitHub WiKi GitHub WiKi.
    • Правило: Если информация существует, она должна быть в одном из этих мест. Никаких "я говорил это в личке".
  2. Стартовая точка (Аксиома 3):

  3. Принятие решений (Аксиома 1 - Наименьшее удивление):

    • Любое решение, вызывающее вопрос "какого черта?", должно быть немедленно вынесено на обсуждение в команде (на стендапе или в отдельной онлайн встрече).
    • Решения по продукту принимает Product Owner.
    • Ключевые технические и программные решения принимаются Team Lead после консультации с командой разработки.
    • Цель: Добиться, чтобы решение было настолько логичным, что любой член команды сказал бы: "я бы тоже сделал именно так".
  4. Управление версиями:

    • Используется семантическое версионирование (SemVer): MAJOR.MINOR.PATCH (например, v0.3.0).
    • Каждый релиз сопровождается changelog.md.
  5. Политика коммитов:

    • Все изменения кода и документации — только через Pull Request (PR) / Merge Request (MR).
    • Каждый PR должен быть проверен (code review) хотя бы одним другим членом команды перед слиянием.
  6. Доступность (Аксиома 4):

    • Устав проекта, бэклог, репозиторий и основная документация доступны всем членам команды без исключения

5. Резервное копирование всех ресурсов проекта

  • Резервному копированию подлежат:

    • Актуальное состояние проекта, задачи, баги, корпус, схемы, платы, файлы проекта — в RedMine.
    • Исходный код, прошивка — в приватном Git репозитории.
    • Документация (включая этот Устав, спецификации, руководства) — в GitHub WiKi GitHub WiKi.
  • Резервное копирование производится:

    • Через день.
  • Копии хранятся:

    • Актуальное состояние проекта, задачи, баги, корпус, схемы, платы, файлы проекта (RedMine) - на арендованном VDS beget.com.
    • Исходный код, прошивка — на зеркале проекта в GitHub.
    • Документация (включая этот Устав, спецификации, руководства) — на зеркале проекта в GitHub.
  • Аудит:

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

    • Назначенный уставом DevOps.
⚠️ **GitHub.com Fallback** ⚠️