Анализ фактической трудоемкости работ и продуктивности команды - shoumq/bybit_scalp GitHub Wiki

  1. Трудоёмкость задач

Общий анализ времени

Этап Плановое время (ч) Фактическое время (ч) Отклонение (ч) Комментарий
Анализ задач и формализация ТЗ 6 9 +3 Долго формулировались ключевые сценарии (работа по сигналам, взаимодействие с биржей).
Изучение API Bybit и документации 8 11 +3 Были проблемы с подпиской на нужные WebSocket-каналы и авторизацией.
Архитектура и структура проекта 6 10 +4 В ходе работы решили реорганизовать main.go в несколько логических модулей.
Реализация логики торговли 14 17 +3 Заняло больше времени из-за обработки ошибок и добавления безопасных проверок.
Работа с конфигурацией и ключами 4 6 +2 Дополнительно внедрили поддержку viper и dotenv.
Логирование и обработка ошибок 4 7 +3 Разработка собственного логгера и форматирования логов.
Тестирование (ручное) 5 7 +2 Тестирование реакции бота на резкие изменения цен и прерывание соединения.
Итого 47 часов 67 часов +20 часов Отклонение составило +42%.

Разбиение по участникам

Участник Затраченное время (ч) Запланированное (ч) Основные задачи Проблемы
Иван (тимлид) 30 25 Организация проекта, работа с API Bybit, REST-интерфейс, логика торговли Перегрузка по задачам, не всё делегировалось вовремя
Андрей (архитектор) 27 22 Разработка архитектуры, реализация многопоточности, конфигурация Трудности с согласованием структуры кода и стандартизации
Эльес (тестировщик) 10 14 Ручное тестирование, логирование, журнал сделок Не всегда был доступен для проверки релизов вовремя
  1. Продуктивность команды

Положительные моменты

Минимальная инфраструктура: не использовались тяжёлые фреймворки — проект быстро разворачивался и компилировался в один исполняемый файл. Реальная отладка с биржей: работа велась на живом API Bybit, что дало ценный опыт. Хорошая структура в коде: выделены базовые функции и части логики (подключение, ордера, сигналы). Работа с WebSocket: успешно реализована подписка на тикеры и стакан.

Проблемные моменты

Централизация кода в main.go: изначально вся логика была в одном файле, что мешало читаемости. Недостаточная автоматизация тестирования: всё тестирование проводилось вручную. Ограниченное логирование: потребовалось время на внедрение нормального форматированного логгера. Слабая документация: отсутствовали подробные комментарии и README (частично компенсировано ретроспективно).

  1. Итоги

A. Общие результаты

Плановая трудоёмкость: 47 ч Фактическая трудоёмкость: 67 ч Отклонение: +20 ч (+42%)

B. Что удалось

Рабочая MVP-версия: соединение с биржей, базовая логика входа/выхода из позиции. Использована архитектура Go + gorilla/websocket + viper. Принято решение о постепенной декомпозиции (разделение на config.go, order.go, strategy.go).

C. Ожидаемые изменения

Перевод на многомодульную структуру; Увеличение уровня тестового покрытия; Добавление Telegram-уведомлений или простого web-интерфейса для мониторинга.

D. Рекомендации

  1. Структурировать код:

Разделить логику на отдельные файлы/пакеты: api, order, utils, strategy. Использовать шаблон cmd/main.go + internal/.

  1. Делегировать и фиксировать задачи:

Внедрить трекер (например, GitHub Projects или YouTrack). Установить сроки по каждому микрозадаче (сигналы, риск-менеджмент, алерты и т.д.)

  1. Внедрить систему автоматического тестирования:

Использовать Go-модули testing, httptest и мок-фреймворки.

  1. Улучшить документацию:

README с описанием запуска, переменных среды, сценариев работы.

  1. Перейти на паттерн MVC/Layered:

Бизнес-логика → отдельно. Сеть/API → отдельно. Стратегии → подключаемые через интерфейсы.

Заключение

Команда справилась с разработкой первой версии бота в разумные сроки, несмотря на трудности с архитектурой и разделением ответственности. Сильной стороной стало использование Go и прямое взаимодействие с WebSocket API Bybit. В дальнейшем фокус будет направлен на масштабирование, автоматизацию тестов и отделение стратегий от основного ядра.