Skip to content

FLOW.md

Latest commit

 

History

History
115 lines (84 loc) · 6.24 KB

FLOW.md

File metadata and controls

115 lines (84 loc) · 6.24 KB
Raw

🔄 FLOW работы с документацией (работа с требованиями)

Обновлено: 27.10.2025 Версия: 4.0 (Optimized) Цель: От идеи к коду за 3-5 часов без бюрократии

🎯 Философия

User Story + Technical Design Document = Быстрая реализация качественных фич

  • User Story - ЧТО хочет пользователь (бизнес-потребность)
  • Technical Design - КАК реализовать технически
  • Скорость > Бюрократии - от идеи к коду за 3-5 часов

🔄 Процесс работы (3-5 часов)

Phase 1: User Story Creation (1-2 часа)

  1. Создать из шаблона: docs/requirements/templates/user-story-hybrid-template.md
  2. Определить бизнес-потребность и User Acceptance Criteria
  3. Оценить бизнес-ценность и метрики
  4. Сохранить как docs/requirements/user-stories/US-XXX-название.md

Phase 2: Technical Design (2-3 часа)

  1. Создать из шаблона: docs/requirements/templates/technical-specification-document-template.md
  2. Спроектировать архитектуру и технические требования
  3. Составить план реализации и оценить риски
  4. Сохранить как docs/requirements/tsd/TSD-XXX-название.md

Phase 3: Implementation

  1. Следовать плану из TSD
  2. Обновлять статусы US-XXX и TSD-XXX
  3. Добавлять implementation notes в оба документа

🎯 Когда использовать FLOW

✅ Идеально подходит:

  • Новые функции бота, интеграции, рефакторинги
  • Small teams (1-5 человек)

❌ Не подходит:

  • Simple bug fixes (< 1 часа), documentation updates, configuration changes

🔄 Выбор подхода: FIP vs US+TSD

FIP (Feature Implementation Plan)

Когда использовать: Внутренняя/техническая функциональность

  • Оптимизация производительности базы данных
  • Добавление системы логирования
  • Документ: FIP-XXX-название.md в docs/requirements/

US+TSD (User Story + Technical Specification)

Для пользовательских историй: "Как пользователь, я хочу..." + техническая реализация Когда использовать: Четкая пользовательская история ("Как пользователь, я хочу...")

  • "Как пользователь, я хочу видеть историю своих заявок"
  • Документы: US-XXX-название.md + TSD-XXX-название.md

Decision Tree:

Новая задача → Пользовательская история? → [ДА] US+TSD : [НЕТ] FIP

Templates и структура

Templates: docs/requirements/templates/

  • User Story: business-потребность + acceptance criteria
  • Technical Design: архитектура + implementation plan

Quick Checklist:

  • Перед US: определить пользователя и бизнес-проблему
  • Перед TSD: прочитать US, оценить технические риски
  • После: обновить статусы, добавить implementation notes

Статусы документов

В требованиях используются ТОЛЬКО указанные ниже статусы документов.

Основные статусы

  • Draft 📝 - Черновик.
  • BusinessAnalyzes - Находится на стадии Бизнес-Анализа. Выявляются и оформляются бизнес-требования.
  • SystemAnalyzes - Находится на стади Системного-Анализа. На этой стадии требуется создать техническую спецификацию и план имплементации.
  • Ready - Готов к реализации. На этой стадии завершен бизнес-анализ и системный анализ, есть вся необходимая техническая документация, включая план имплементации.
  • In Progress 🚧 - В процессе разработки
  • Completed ✅ - Завершен и протестирован
  • Production 🚀 - В продакшене

Правила использования статусов

  1. Документы не архивируются - вместо этого используется префикс [DEPRECATED]
  2. Статусы обновляются в процессе работы - Draft → BusinessAnalyzes -> SystemAnalyzes -> Ready -> In Progress → Completed -> Production
  3. Апгрейд статусов возможен только вперед по workflow
  4. Финальный статус для активных документов - Completed или Production

Другие форматы требований (extra)

В будущем возможно использование следующих форматов требования:

  • PDR
  • Feature Brief: Краткое описание функции (1-2 абзаца)
  • User Story Map: Карта пользовательских историй
  • Epic Breakdown: Декомпозиция эпиков на задачи

🔗 Связанные документы

Flow Principle: Единственный источник правды по процессу работы с документацией