update team, test

docs/architecture/02-classic-layer-based-arch.md

@@ -3,3 +3,108 @@ sidebar_position: 2
 ---
 
 # Классическая архитектура
+Источник: DeepSeek
+
+Layer-based architecture (архитектура на основе слоёв) — это подход к организации кода, при котором приложение разделяется на несколько логических слоёв, каждый из которых отвечает за определённый аспект функциональности. Этот метод широко используется как во фронтенд-, так и в бэкенд-разработке и помогает создавать структурированные, поддерживаемые и масштабируемые приложения.
+
+## Основные идеи Layer-based Architecture
+1. **Разделение ответственности:**
+   - Каждый слой отвечает за определённую часть функциональности (например, отображение данных, управление состоянием, работа с API).
+   - Это упрощает понимание кода и снижает вероятность ошибок.
+2. **Изоляция слоёв:**
+   - Слои взаимодействуют друг с другом через чётко определённые интерфейсы, что делает их независимыми.
+   - Изменения в одном слое минимально влияют на другие.
+3. **Повторное использование:**
+   - Логика, вынесенная в отдельные слои, может быть переиспользована в разных частях приложения.
+
+## Основные слои во фронтенд-разработке
+1. Presentation Layer (Слой представления):
+   - Отвечает за отображение данных и взаимодействие с пользователем.
+   - Включает компоненты, стили и UI-логику.
+   - Пример: React-компоненты, Vue-компоненты, Angular-шаблоны.
+2. Application Layer (Слой приложения):
+   - Управляет бизнес-логикой приложения.
+   - Координирует взаимодействие между слоем представления и слоем данных.
+   - Пример: хуки, сервисы, контроллеры.
+3. Data Layer (Слой данных):
+   - Отвечает за работу с данными: получение, хранение, обновление.
+   - Включает API-запросы, управление состоянием (например, Redux, MobX), локальное хранилище (localStorage, IndexedDB).
+   - Пример: Redux slices, GraphQL-запросы, REST API-клиенты.
+4. Infrastructure Layer (Инфраструктурный слой):
+   - Включает вспомогательные функции, утилиты и инструменты, которые используются во всех слоях.
+   - Пример: хелперы, утилиты, конфигурация приложения.
+
+Пример структуры проекта с Layer-based Architecture
+```
+src/
+│
+├── components/            # Presentation Layer: UI-компоненты
+│   ├── Button/
+│   ├── Header/
+│   └── Footer/
+│
+├── pages/                 # Presentation Layer: Страницы
+│   ├── HomePage/
+│   └── ProfilePage/
+│
+├── hooks/                 # Application Layer: Хуки для бизнес-логики
+│   ├── useAuth/
+│   └── useCart/
+│
+├── store/                 # Data Layer: Управление состоянием (Redux, Zustand)
+│   ├── slices/
+│   │   ├── authSlice.ts
+│   │   └── cartSlice.ts
+│   └── index.ts
+│
+├── api/                   # Data Layer: Работа с API
+│   ├── authApi.ts
+│   └── cartApi.ts
+│
+├── utils/                 # Infrastructure Layer: Утилиты и хелперы
+│   ├── formatDate.ts
+│   └── validateForm.ts
+│
+└── App.tsx                # Основной файл приложения
+```
+
+## Преимущества Layer-based Architecture
+1. **Чёткая структура:**
+   - Код легко понять и поддерживать благодаря разделению на слои.
+2. **Упрощение тестирования:**
+   - Каждый слой можно тестировать изолированно.
+3. **Гибкость:**
+   - Слои можно заменять или модифицировать без влияния на другие части приложения.
+4. **Повторное использование:**
+   - Логика, вынесенная в отдельные слои, может быть переиспользована.
+
+## Недостатки Layer-based Architecture
+1. **Избыточность для небольших проектов:**
+   - В маленьких приложениях такая структура может показаться излишне сложной.
+2. **Зависимость между слоями:**
+   - Если не соблюдать чёткие границы, слои могут стать слишком связанными.
+3. **Сложность настройки:**
+   - Требуется время и усилия для правильной организации слоёв.
+
+## Пример взаимодействия слоёв
+1. **Presentation Layer:**
+   - Компонент CartList отображает список товаров в корзине.
+2. **Application Layer:**
+   - Хук useCart управляет логикой корзины.
+3. **Data Layer:**
+   - Redux slice управляет состоянием корзины.
+4. **Infrastructure Layer:**
+   - Утилита для форматирования цены.
+
+## Когда использовать Layer-based Architecture
+- В проектах среднего и крупного размера.
+- Когда требуется чёткое разделение ответственности.
+- В командах, где разные разработчики работают над разными аспектами приложения.
+
+Альтернативные подходы
+1. **Feature Slice Design:**
+   - Организация кода вокруг функциональных блоков (фич).
+   - Подходит для крупных проектов с множеством фич.
+2. **Domain-driven Design (DDD):**
+   - Организация кода вокруг доменных областей (например, `user`, `order`, `product`).
+   - Часто используется в бэкенд-разработке.

docs/architecture/03-atomic-design.md

@@ -3,3 +3,99 @@ sidebar_position: 3
 ---
 
 # Atomic design
+Источник: DeepSeek
+
+Atomic Design — это методология проектирования и организации пользовательских интерфейсов, предложенная Брэдом Фростом (Brad Frost). Она основана на идее разделения интерфейса на небольшие, независимые и переиспользуемые компоненты, которые затем комбинируются для создания более сложных структур. Название методологии вдохновлено химией: так же, как молекулы состоят из атомов, интерфейсы состоят из базовых компонентов.
+
+## Основные принципы Atomic Design
+1. **Иерархия компонентов:**
+   - Компоненты организуются в иерархию от простых к сложным.
+   - Каждый уровень иерархии имеет своё назначение и уровень абстракции.
+2. **Переиспользуемость:**
+   - Компоненты проектируются так, чтобы их можно было использовать в разных частях интерфейса.
+3. **Модульность:**
+   - Каждый компонент изолирован и независим, что упрощает тестирование и поддержку.
+4. **Масштабируемость:**
+   - Методология подходит как для небольших, так и для крупных проектов.
+
+## Уровни Atomic Design
+1. Атомы (Atoms):
+   - Наименьшие и базовые элементы интерфейса, которые нельзя разделить на более мелкие части.
+   - Примеры: кнопки, инпуты, иконки, текстовые элементы.
+2. Молекулы (Molecules):
+   - Комбинация нескольких атомов, которые вместе выполняют определённую функцию.
+   - Примеры: форма поиска (инпут + кнопка), карточка товара (изображение + заголовок + цена).
+3. Организмы (Organisms):
+   - Более сложные компоненты, состоящие из молекул и/или атомов.
+   - Примеры: шапка сайта (логотип + навигация + форма поиска), футер (ссылки + текст + иконки).
+4. Шаблоны (Templates):
+   - Макеты страниц, которые определяют структуру и расположение организмов.
+   - Пример: шаблон главной страницы (шапка + список карточек товаров + футер).
+5. Страницы (Pages):
+   - Конкретные реализации шаблонов с реальными данными.
+   - Пример: главная страница сайта с заполненными карточками товаров.
+
+## Пример структуры проекта с использованием Atomic Design
+```
+src/
+│
+├── components/
+│   ├── atoms/              # Атомы
+│   │   ├── Button/
+│   │   ├── Input/
+│   │   └── Text/
+│   │
+│   ├── molecules/          # Молекулы
+│   │   ├── SearchForm/     # Форма поиска (Input + Button)
+│   │   └── ProductCard/    # Карточка товара (Image + Text + Button)
+│   │
+│   ├── organisms/          # Организмы
+│   │   ├── Header/         # Шапка сайта (Logo + Navigation + SearchForm)
+│   │   └── Footer/         # Футер (Links + Text + Icons)
+│   │
+│   ├── templates/          # Шаблоны
+│   │   ├── HomeTemplate/   # Шаблон главной страницы
+│   │   └── ProductTemplate/# Шаблон страницы товара
+│   │
+│   └── pages/              # Страницы
+│       ├── HomePage/       # Главная страница
+│       └── ProductPage/    # Страница товара
+│
+└── App.tsx                 # Основной файл приложения
+```
+
+## Преимущества Atomic Design
+1. **Переиспользуемость:**
+   - Компоненты можно использовать в разных частях интерфейса, что сокращает дублирование кода.
+2. **Масштабируемость:**
+   - Методология подходит для проектов любого размера.
+3. **Упрощение разработки:**
+   - Чёткая структура помогает разработчикам быстро находить и изменять нужные компоненты.
+4. **Согласованность интерфейса:**
+   - Использование атомов и молекул обеспечивает единообразие дизайна.
+5. **Упрощение тестирования:**
+   - Компоненты можно тестировать изолированно.
+
+## Недостатки Atomic Design
+1. **Сложность для небольших проектов:**
+   - В маленьких проектах такая структура может показаться излишне сложной.
+2. **Требует дисциплины:**
+   - Необходимо строго следовать принципам, чтобы избежать смешения уровней.
+3. **Ограниченная гибкость:**
+   - В некоторых случаях строгая иерархия может ограничивать возможности кастомизации.
+
+## Пример реализации Atomic Design
+1. **Атом:** Кнопка (Button)
+2. **Молекула:** Форма поиска (SearchForm)
+3. **Организм:** Шапка сайта (Header)
+4. **Шаблон:** Главная страница (HomeTemplate)
+5. **Страница:** Главная страница (HomePage)
+
+## Когда использовать Atomic Design
+- В проектах с большим количеством переиспользуемых компонентов.
+- Когда требуется высокая согласованность интерфейса.
+- В командах, где дизайнеры и разработчики тесно взаимодействуют.
+
+
+
+

docs/architecture/04-ddd-domain-driven-design.md

@@ -3,3 +3,101 @@ sidebar_position: 4
 ---
 
 # Доменная архитектура
+Источник: DeepSeek
+
+**Domain-Driven Design (DDD)** — это подход к разработке программного обеспечения, который фокусируется на моделировании бизнес-логики и организации кода вокруг доменных областей (бизнес-контекстов). Хотя DDD изначально был разработан для бэкенд-разработки, его принципы могут быть успешно применены и во фронтенде, особенно в сложных приложениях с богатой бизнес-логикой.
+
+## Основные концепции DDD
+1. **Домен (Domain):**
+   - Это предметная область, которую решает приложение (например, электронная коммерция, управление проектами, финансы).
+   - Домен состоит из поддоменов (например, заказы, продукты, пользователи).
+2. **Модель (Model):**
+   - Абстракция, которая описывает ключевые концепции и процессы в домене.
+   - Модель включает сущности, значения, агрегаты и сервисы.
+3. **Ограниченный контекст (Bounded Context):**
+   - Чётко определённая область, в которой применяется конкретная модель.
+   - Например, в одном контексте "пользователь" может быть клиентом, а в другом — администратором.
+4. **Универсальный язык (Ubiquitous Language):**
+   - Общий язык, который используется разработчиками, дизайнерами и бизнес-экспертами для описания домена.
+   - Помогает избежать недопонимания и упрощает коммуникацию.
+5. **Слои (Layers):**
+   - DDD разделяет приложение на слои: доменный слой, слой приложения, инфраструктурный слой и презентационный слой.
+
+## Применение DDD во фронтенде
+Во фронтенде DDD может быть использован для организации кода вокруг бизнес-логики, что особенно полезно в сложных приложениях, таких как CRM-системы, платформы для электронной коммерции или аналитические панели.
+
+## Основные принципы DDD во фронтенде
+1. **Организация кода вокруг доменов:**
+   - Код структурируется по доменам, а не по техническим слоям (например, `components`, `pages`).
+   - Каждый домен включает всё необходимое для своей работы: компоненты, логику, состояние, API-запросы.
+2. **Изоляция доменов:**
+   - Домены максимально независимы друг от друга.
+   - Это позволяет разрабатывать, тестировать и изменять их без влияния на другие части приложения.
+3. **Использование универсального языка:**
+   - Названия компонентов, функций и переменных отражают бизнес-концепции, что делает код более понятным.
+4. **Фокус на бизнес-логике:**
+   - Логика, связанная с доменом, выносится в отдельные модули, что упрощает её тестирование и поддержку.
+
+Пример структуры проекта с использованием DDD
+```
+src/
+│
+├── domains/                # Домены
+│   ├── cart/               # Домен "Корзина"
+│   │   ├── components/     # Компоненты, специфичные для корзины
+│   │   ├── hooks/          # Хуки для корзины
+│   │   ├── store/          # Логика состояния (например, Redux slice)
+│   │   ├── api/            # API-запросы, связанные с корзиной
+│   │   └── index.ts        # Экспорт домена
+│   │
+│   └── auth/               # Домен "Авторизация"
+│       ├── components/
+│       ├── hooks/
+│       ├── store/
+│       ├── api/
+│       └── index.ts
+│
+├── shared/                 # Общие компоненты и утилиты
+│   ├── ui/                 # UI-компоненты (кнопки, инпуты и т.д.)
+│   └── lib/                # Утилиты и хелперы
+│
+├── app/                    # Основная логика приложения
+│   ├── routing/            # Роутинг
+│   ├── providers/          # Провайдеры (например, Redux, Theme)
+│   └── index.ts
+│
+└── pages/                  # Страницы приложения
+    ├── HomePage/           # Страница "Главная"
+    └── ProfilePage/        # Страница "Профиль"
+```
+
+## Преимущества DDD во фронтенде
+1. **Чёткая структура:**
+   - Код организуется вокруг бизнес-контекстов, что делает его более понятным.
+2. **Упрощение разработки:**
+   - Разработчики могут фокусироваться на одной доменной области, не отвлекаясь на остальные части приложения.
+3. **Улучшение поддерживаемости:**
+   - Изменения в одном домене не затрагивают другие.
+4. **Гибкость:**
+   - Домены можно легко добавлять, удалять или заменять.
+5. **Тестируемость:**
+   - Бизнес-логика может быть протестирована изолированно.
+  
+## Недостатки DDD во фронтенде
+1. **Сложность для небольших проектов:**
+   - В маленьких приложениях такая структура может показаться излишне сложной.
+2. **Требует глубокого понимания домена:**
+   - Необходимо тесное взаимодействие с бизнес-экспертами.
+3. **Оверхеад:**
+   - Требуется время и усилия для правильной организации кода.
+
+## Пример реализации домена "Корзина"
+1. Компонент: CartList
+2. Хук: useCart
+3. Redux slice: cartSlice
+4. API: cartApi
+
+## Когда использовать DDD во фронтенде
+В сложных приложениях с богатой бизнес-логикой.
+В командах, где разработчики и бизнес-эксперты тесно взаимодействуют.
+Когда требуется высокая степень модульности и переиспользуемости.

docs/architecture/05-fsd-feature-slice-design.md

@@ -3,6 +3,7 @@ sidebar_position: 5
 ---
 
 # Feature slice design
+Источник: DeepSeek
 
 **Feature Slice Design (FSD)** — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения.
 

docs/architecture/06-micro-frontend.md

@@ -3,6 +3,7 @@ sidebar_position: 6
 ---
 
 # Micro frontend
+Источник: DeepSeek
 
 Микрофронтенды (Micro Frontends) — это архитектурный подход, который позволяет разделить фронтенд-приложение на независимые, слабо связанные части, каждая из которых может разрабатываться, тестироваться и развертываться отдельно. Этот подход вдохновлен микросервисной архитектурой и применяется для создания масштабируемых и поддерживаемых фронтенд-приложений.
 

docs/architecture/07-tdd.md

@@ -3,6 +3,7 @@ sidebar_position: 7
 ---
 
 # Test driven development
+Источник: DeepSeek
 
 TDD (Test-Driven Development) — это методология разработки программного обеспечения, в которой написание тестов предшествует написанию кода. Основная идея TDD заключается в том, что разработчик сначала пишет тест для новой функциональности, а затем реализует код, который делает этот тест успешным. Этот процесс повторяется для каждой новой функции или улучшения.
 

docs/team/01-methodology.md

@@ -0,0 +1,164 @@
+---
+sidebar_position: 1
+---
+
+# Методологии разработки
+Источник: DeepSeek
+
+## Waterfall
+
+Waterfall (каскадная модель) — это традиционный подход к управлению проектами и разработке программного обеспечения, который предполагает последовательное выполнение этапов. Каждый этап должен быть завершен до перехода к следующему, что делает процесс линейным и предсказуемым.
+
+Waterfall контрастирует с Agile, где гибкость и итеративность являются ключевыми принципами.
+
+### Основные принципы Waterfall:
+1. Последовательность этапов:
+   - Проект делится на четкие этапы, которые выполняются один за другим.
+   - Типичные этапы: сбор требований, проектирование, реализация, тестирование, внедрение и поддержка.
+2. Жесткая структура:
+   - Каждый этап имеет четкие цели и результаты, которые должны быть завершены до перехода к следующему этапу.
+   - Изменения требований на поздних этапах сложно внедрить.
+3. Документирование:
+   - На каждом этапе создается подробная документация, которая служит основой для следующего этапа.
+   - Например, требования фиксируются в документе спецификации, который используется для проектирования.
+4. Минимум обратной связи:
+   - Обратная связь от клиента или пользователей обычно происходит только на этапе тестирования или внедрения.
+   - Это может привести к тому, что продукт не полностью соответствует ожиданиям.
+5. Предсказуемость:
+   - Waterfall подходит для проектов с четкими и неизменными требованиями.
+   - Бюджет, сроки и ресурсы планируются заранее.
+
+### Преимущества Waterfall:
+- Подходит для проектов с четкими и стабильными требованиями.
+- Легко управлять и контролировать процесс.
+- Хорошо документированный процесс.
+
+### Недостатки Waterfall:
+- Сложно адаптироваться к изменениям требований.
+- Ошибки, обнаруженные на поздних этапах, могут быть дорогостоящими.
+- Ограниченная обратная связь с клиентом до завершения проекта.
+
+### Когда использовать Waterfall:
+- Когда требования четко определены и unlikely to change.
+- Для небольших проектов с понятной структурой.
+- В отраслях с жесткими стандартами (например, строительство, аэрокосмическая промышленность).
+
+## Agile
+Agile (гибкая методология) — это подход к управлению проектами и продуктами, который emphasizes гибкость, итеративность и сотрудничество. Он широко используется в разработке программного обеспечения, но также применяется в других областях.
+
+Agile помогает командам быстрее реагировать на изменения, улучшать качество продукта и повышать удовлетворенность клиентов.
+
+### Основные принципы Agile:
+1. Итеративность и инкрементальность: Работа делится на небольшие этапы (итерации или спринты), по итогам которых создается работающий продукт или его часть.
+2. Гибкость: Возможность быстро адаптироваться к изменениям требований или условий.
+3. Сотрудничество: Тесное взаимодействие между командами и заинтересованными сторонами.
+4. Фокус на ценности: Приоритет отдается удовлетворению потребностей клиента и доставке ценного продукта.
+5. Самоорганизация: Команды самостоятельно принимают решения и распределяют задачи.
+
+### Популярные фреймворки Agile:
+- Scrum: Использует короткие итерации (спринты) и роли (Scrum Master, Product Owner, команда).
+- Kanban: Визуализация workflow и ограничение задач в процессе.
+- Extreme Programming (XP): Акцент на техническом совершенстве и частых релизах.
+
+## Scrum
+Scrum — это популярный фреймворк Agile, который используется для управления проектами и разработки продуктов. Он основан на итеративном и инкрементальном подходе, где работа делится на короткие циклы (спринты), по итогам которых создается готовый к использованию продукт или его часть.
+
+Scrum подходит для проектов с изменчивыми требованиями и сложными задачами, где важна быстрая адаптация и постоянное улучшение.
+
+### Основные принципы Scrum:
+1. **Итеративность и инкрементальность:**
+   - Работа выполняется в коротких итерациях (спринтах), обычно длительностью 1-4 недели.
+   - В конце каждого спринта команда предоставляет готовый к использованию продукт или его часть.
+2. **Самоорганизация команды:**
+   - Команда самостоятельно распределяет задачи и принимает решения.
+   - Нет жесткого управления сверху, что способствует ответственности и мотивации.
+3. **Прозрачность:**
+   - Все аспекты работы (задачи, прогресс, проблемы) видимы для всех участников.
+   - Используются инструменты, такие как Scrum-доска, чтобы визуализировать workflow.
+4. **Адаптация:**
+   - Команда регулярно анализирует результаты и процессы (на ретроспективах) и вносит улучшения.
+   - Гибкость к изменениям требований и приоритетов.
+5. **Фокус на ценности:**
+   - Приоритет отдается задачам, которые приносят наибольшую ценность для клиента.
+   - Product Owner отвечает за управление бэклогом продукта и определение приоритетов.
+
+### Роли в Scrum:
+1. **Владелец продукта (Product Owner):**
+   - Определяет требования и приоритеты задач.
+   - Управляет бэклогом продукта (списком задач).
+2. **Scrum Master:**
+   - Фасилитатор, который помогает команде следовать принципам Scrum.
+   - Устраняет препятствия и обеспечивает эффективность процессов.
+3. **Команда разработки (Development Team):**
+   - Самоорганизующаяся группа специалистов, которая выполняет задачи.
+   - Обычно состоит из 3-9 человек.
+
+### Артефакты Scrum:
+1. **Бэклог продукта (Product Backlog):**
+   - Список всех задач и требований к продукту.
+   - Упорядочен по приоритетам.
+2. **Бэклог спринта (Sprint Backlog):**
+   - Список задач, выбранных для выполнения в текущем спринте.
+3. **Инкремент продукта (Product Increment):**
+   - Результат работы за спринт — готовый к использованию продукт или его часть.
+
+### События Scrum:
+1. **Планирование спринта (Sprint Planning):**
+   - Команда выбирает задачи из бэклога продукта и планирует работу на спринт.
+2. **Ежедневный Scrum (Daily Standup):**
+   - Короткая встреча (15 минут), где каждый участник рассказывает, что сделал, что планирует сделать и какие есть препятствия.
+3. **Обзор спринта (Sprint Review):**
+   - В конце спринта команда демонстрирует результат заинтересованным сторонам.
+4. **Ретроспектива спринта (Sprint Retrospective):**
+   - Команда анализирует процесс и ищет способы улучшить работу в следующем спринте.
+
+### Преимущества Scrum:
+- Гибкость к изменениям.
+- Быстрая доставка ценности клиенту.
+- Улучшение коммуникации и прозрачности.
+
+## Kanban
+**Kanban** — это метод управления рабочими процессами, который focuses на визуализации задач, ограничении объема работы в процессе (work in progress, WIP) и непрерывном улучшении. Он originated в производственной системе Toyota, но сейчас широко используется в IT, разработке программного обеспечения и других областях.
+
+Kanban часто сравнивают с Scrum, но в отличие от Scrum, Kanban не требует фиксированных итераций (спринтов) и ролей. Он больше focuses на непрерывном потоке задач и улучшении процессов.
+
+### Основные принципы Kanban:
+1. **Визуализация workflow:**
+   - Рабочий процесс визуализируется с помощью Kanban-доски, которая разделена на столбцы (этапы работы).
+   - Каждая задача представляется карточкой, которая перемещается по столбцам по мере выполнения.
+2. **Ограничение объема работы в процессе (WIP):**
+   - Устанавливаются лимиты на количество задач, которые могут находиться на каждом этапе одновременно.
+   - Это помогает избежать перегрузки команды и улучшает поток задач.
+3. **Управление потоком:**
+   - Фокус на обеспечении плавного и непрерывного движения задач через workflow.
+   - Анализируются узкие места и устраняются препятствия.
+4. **Прозрачность:**
+   - Все задачи и их статус видны всем участникам команды.
+   - Это улучшает коммуникацию и понимание текущего состояния работы.
+5. **Непрерывное улучшение (Kaizen):**
+   - Регулярно анализируются процессы и вносятся улучшения.
+   - Команда стремится к оптимизации workflow и повышению эффективности.
+
+### Элементы Kanban:
+1. **Kanban-доска:**
+   - Физическая или цифровая доска, разделенная на столбцы (например, "To Do", "In Progress", "Done").
+   - Карточки представляют задачи и перемещаются по столбцам.
+2. **Карточки (Cards):**
+   - Каждая карточка представляет одну задачу и содержит информацию о ней (например, описание, приоритет, ответственный).
+3. **Лимиты WIP:**
+   - Устанавливаются ограничения на количество задач, которые могут находиться в каждом столбце одновременно.
+   - Например, в столбце "In Progress" может быть не более 5 задач.
+4. **Поток (Flow):**
+   - Анализ и оптимизация движения задач через workflow.
+   - Используются метрики, такие как время выполнения (cycle time) и пропускная способность (throughput).
+
+### Преимущества Kanban:
+- **Гибкость:** Kanban легко адаптируется к изменениям требований и процессов.
+- **Прозрачность:** Все задачи и их статус видны всем участникам.
+- **Снижение перегрузки:** Лимиты WIP помогают избежать перегрузки команды.
+- **Непрерывное улучшение:** Регулярный анализ и оптимизация процессов.
+
+### Когда использовать Kanban:
+- Для проектов с постоянно меняющимися требованиями.
+- Для поддержки и улучшения существующих процессов.
+- Для команд, которые хотят улучшить прозрачность и управление workflow.

docs/team/01-processes.md

@@ -1,5 +0,0 @@
----
-sidebar_position: 1
----
-
-# Процессы в команде

docs/team/02-methodology.md

@@ -1,5 +0,0 @@
----
-sidebar_position: 2
----
-
-# Методологии разработки

docs/team/02-processes.md

@@ -0,0 +1,186 @@
+---
+sidebar_position: 2
+---
+
+# Процессы в команде
+Источник: https://www.youtube.com/watch?v=zCamBnDSbxs
+
+01:52 Методологии работы
+В канбан-методологии нет четкого планирования на следующий день.
+В скрам-методологии спринты имеют определенное планирование.
+Спринты автоматизируют процесс разработки, но требуют постоянного планирования.
+
+02:51 Спринты и их структура
+Спринты состоят из десяти рабочих дней, включая выходные.
+В спринте делается только одна основная фича.
+Обычно идет два спринта параллельно.
+
+04:39 Этапы разработки
+Первый этап: подготовка, где аналитики и дизайнеры работают над ТЗ.
+Второй этап: реализация, где команда работает над задачей.
+Груминг и планирование обсуждают задачи на следующий спринт и текущий спринт соответственно.
+
+06:41 Оценка задач и синхронизация
+Каждая задача оценивается по времени на планировании.
+Важно, чтобы все команды были синхронизированы, чтобы избежать рассинхрона.
+Идеальный менеджмент должен учитывать возможные изменения в командах.
+
+10:04 Введение в синхронизацию команд
+Важность синхронизации команд для успешной работы.
+Проблемы, возникающие при увольнении члена команды.
+Два варианта решения проблемы: уменьшение нагрузки или переработка.
+
+11:57 Роль менеджера в синхронизации
+Менеджер передает задачи от бизнеса команде.
+Важность правильного объяснения задач команде.
+Влияние менеджера на мотивацию и эффективность команды.
+
+12:51 Груминг задач
+Груминг как процесс выбора задач для работы.
+Пример задачи по созданию сторис.
+Декомпозиция задачи на более мелкие и выполнимые части.
+
+15:39 Роль продакт-менеджера
+Продакт-менеджер как связующее звено между бизнесом и командой.
+Важность поддержки бизнеса и команды.
+Влияние продакт-менеджера на процесс принятия решений.
+
+17:28 Планирование и ретроспективы
+Планирование спринтов и ежедневных задач.
+Роль менеджера в успокоении бизнеса.
+Ретроспективы как отчет о проделанной работе.
+
+19:17 Заключение
+Важность планирования и синхронизации для успешной работы.
+Примеры использования инструментов для планирования.
+Обзор различных подходов к отображению задач в проекте.
+
+20:02 Декомпозиция задач и груминг
+Аналитики, дизайнеры и бэкендеры проводят груминг, уточняя задачи и подготавливая их для разработчиков.
+Цель груминга - расхламление бэклога, удаление неактуальных задач и багов.
+Груминг помогает понять, справится ли команда с задачами и уменьшить количество задач в бэклоге.
+
+21:59 Оценка задач в стори пойнтах
+Оценка задач в стори пойнтах помогает понять сложность задачи.
+Стори пойнты абстрактны и не всегда точны, но полезны для понимания команды.
+Задачи оцениваются по шкале от одного до тринадцати пойнтов, где один пойнт - простая задача, а тринадцать - очень сложная и абстрактная.
+
+24:52 Проблемы с грумингом и планированием
+Если задачи на груминге слишком сложные и абстрактные, это указывает на проблемы с декомпозицией.
+На планировании должны быть задачи с оценкой один-пять пойнтов, а большие задачи нужно дробить.
+Планирование помогает менеджеру и команде понять, что делать на спринт, и доказать, что все задачи поняты и спланированы.
+
+28:28 Оценка задач в часах и стори пойнтах
+Команды обычно работают в часах, а не в стори пойнтах.
+Оценка задач в часах и стори пойнтах одновременно сложна и требует дополнительной абстракции.
+Плайн-покер позволяет разработчикам оценивать задачи в часах и стори пойнтах, что помогает экономить время и деньги компании.
+
+29:27 Проблемы с оценкой задач
+Оценка задач может сильно различаться, что требует уточнения.
+Если оценки сильно отличаются, это может указывать на разные уровни понимания задачи.
+В слабых командах лучше выбирать среднюю оценку, чтобы избежать срывов сроков.
+
+31:21 Декомпозиция задач и оценка
+Декомпозиция задач помогает менеджеру убедиться, что все члены команды понимают ТЗ.
+Важно, чтобы вся команда присутствовала на встречах для оценки задач.
+Пример из практики: андроид-команда отставала на полгода, что привело к рассогласованию работы.
+
+32:55 Дейлики и их значение
+Дейлики помогают менеджеру понять, что команда делает и планирует на день.
+Дейлики включают ответы на три вопроса: что сделано вчера, что будет сделано сегодня, и есть ли блоки.
+Дейлики могут быть бесполезными, так как команды работают над разными задачами.
+
+34:26 Проблемы с дейликами
+Дейлики могут быть скучными и бесполезными, так как команды обсуждают разные задачи.
+Важно планировать свою речь на дейликах, чтобы не тратить время впустую.
+Делики помогают менеджеру понять, что команда работает в одном направлении.
+
+35:26 Адаптация к делитам
+В первые месяцы работы важно активно участвовать в делитах и планировать свою речь.
+Делиты могут быть разными в разных командах, и важно адаптироваться к их стилю.
+Важно понимать, что делиты могут быть сухими и по фактам, или затягиваться на час, обсуждая детали.
+
+38:20 Введение в ежедневные встречи
+Важно адаптироваться к стилю общения в команде.
+Ориентируйтесь на всех членов команды, а не только на менеджера.
+Повторяйте структуру и стиль общения команды на ежедневных встречах.
+
+39:19 Ежедневные ритуалы и их значение
+Ежедневные встречи могут длиться от 5 до 40 минут.
+Важно мимикрировать под команду и её поведение.
+Ежедневные встречи помогают менеджеру понимать текущую ситуацию в команде.
+
+40:13 Демонстрация и её значение
+Демонстрация показывает результаты работы всех отделов.
+На демонстрации могут присутствовать представители бизнеса и крупные игроки.
+Цель демонстрации — показать бизнесу, что команда выполнила задачи и попросить больше ресурсов.
+
+41:12 Процесс демонстрации
+Демонстрация включает показ работы всех команд продукта.
+На демонстрации могут быть голосования и раздачи мерча.
+Презентация включает демонстрацию функционала и планы на будущее.
+
+44:03 Ретроспектива и её значение
+Ретроспектива проходит в конце спринта и обсуждает результаты работы.
+Демонстрация и ретроспектива помогают бизнесу понять, что команда выполнила задачи.
+Важно, чтобы на демонстрации показывался реально рабочий функционал.
+
+44:44 Демонстрация работы продукта
+Демонстрация работы продукта часто скрывает ошибки и недоработки.
+Команды могут показывать только часть функционала, чтобы создать иллюзию работы.
+Проблемы с бэкендом, тестированием и аналитикой могут привести к задержкам и ошибкам.
+
+47:25 Ретроспектива и её значение
+Ретроспектива помогает выявить проблемы и избежать их в будущем.
+Встреча может быть как позитивной, так и негативной, в зависимости от команды и менеджера.
+Важно, чтобы вся команда присутствовала и делилась фидбеком.
+
+48:22 Процесс ретроспективы
+Ретроспектива включает обсуждение успехов и неудач спринта.
+Команда делится фидбеком анонимно, часто через карточки.
+Менеджер зачитывает фидбек и создает тикеты для будущих улучшений.
+
+49:39 Ретроспектива и планирование
+Ретроспектива проводится в конце спринта для подведения итогов.
+Груминг может быть в середине недели для планирования.
+Компании могут экономить на аналитиках, что негативно сказывается на подготовке к разработке.
+
+51:50 Релизные циклы
+Релизные циклы включают двухнедельный спринт и отправку на ревью.
+В понедельник проходят созвоны и планирование, в пятницу подводятся итоги.
+Разработка занимает 5-6 дней, остальное время уходит на общение и тестирование.
+
+54:27 Код-ревью и тестирование
+Код-ревью помогает привести код к стандартам компании.
+Тестирование проводится после код-ревью для проверки работоспособности.
+Тестировщики могут отправлять сборки на тестирование в среду или четверг.
+
+57:20 Работа с багами
+Баги фиксируются в личных сообщениях или тикетах.
+Второй вариант с публичными отчетами о багах менее эффективен.
+Быстрое решение багов в личных сообщениях экономит время и деньги компании.
+
+59:14 Решение проблем в личных чатах
+Решение проблем в личных чатах или личных сообщениях нормально.
+Не обязательно создавать тикеты для каждой мелочи.
+Важно, чтобы все работало и соответствовало документации.
+
+01:00:12 Быстрое выполнение задач
+Бизнесу важно быстро выполнить задачу, даже если код не всегда чистый.
+Пример с приготовлением салата: можно быстро сделать вкусный салат из доступных ингредиентов.
+Важно получить результат, а не стремиться к идеальному качеству.
+
+01:01:08 Правило Парето
+80% усилий приносят 80% результата, и наоборот.
+Пример с салатом: можно быстро приготовить вкусный салат, сэкономив время.
+Бизнесу важен результат, а не детали.
+
+01:02:06 Рефакторинг и чистота кода
+Рефакторинг существует, несмотря на чистый код.
+Не стоит беспокоиться о чистоте кода, главное – соответствие требованиям.
+Важно соответствовать запросам бизнеса, а не стремиться к идеалу.
+
+01:03:05 Срезы и сборки
+Срез – это актуальная версия кода для тестировщиков.
+Срез может называться по-разному, но суть остается той же.
+Важно понимать, что это просто актуальная версия приложения.

docs/testing/01-testing.md

@@ -0,0 +1,62 @@
+---
+sidebar_position: 1
+---
+
+# Тестирование 
+
+Тестирование фронтенд-приложений — это важный этап разработки, который помогает убедиться, что приложение работает корректно, соответствует требованиям и предоставляет пользователям качественный опыт. Вот основные аспекты и виды тестирования фронтенд-приложений:
+
+## Виды тестирования фронтенд-приложений
+1. Функциональное тестирование
+   - Проверка, что все функции приложения работают так, как ожидается. Примеры:
+   - Проверка корректности работы форм, кнопок, ссылок.
+   - Тестирование взаимодействия с API (например, отправка и получение данных).
+   - Проверка валидации данных (например, ввод некорректных данных в поля формы).
+2. Юзабилити-тестирование
+   - Оценка удобства использования интерфейса:
+   - Насколько интуитивно понятен интерфейс.
+   - Удобство навигации.
+   - Соответствие ожиданиям пользователей.
+3. Кросс-браузерное тестирование
+   - Проверка корректности отображения и работы приложения в разных браузерах (Chrome, Firefox, Safari, Edge и т.д.) и их версиях.
+4. Кросс-платформенное тестирование
+   - Тестирование на разных устройствах и операционных системах (десктопы, мобильные устройства, планшеты).
+5. Тестирование производительности
+   - Проверка скорости загрузки страниц, отзывчивости интерфейса и работы приложения под нагрузкой.
+6. Тестирование доступности (Accessibility)
+   - Проверка, что приложение доступно для людей с ограниченными возможностями (например, поддержка screen readers, контрастность, управление с клавиатуры).
+7. Визуальное тестирование
+   - Проверка соответствия интерфейса макетам (например, с использованием инструментов вроде Percy или Applitools).
+8. Регрессионное тестирование
+   - Проверка, что новые изменения не сломали существующий функционал.
+
+Инструменты для тестирования фронтенд-приложений
+1. Фреймворки для модульного и интеграционного тестирования
+   - Jest: популярный фреймворк для unit- и интеграционных тестов.
+   - Mocha: гибкий фреймворк для тестирования.
+   - Cypress: инструмент для end-to-end тестирования.
+   - Puppeteer: библиотека для автоматизации браузера (Chrome/Chromium).
+2. Инструменты для кросс-браузерного тестирования
+   - BrowserStack: облачный сервис для тестирования на разных устройствах и браузерах.
+   - Sauce Labs: аналогичный сервис для кросс-браузерного тестирования.
+3. Инструменты для тестирования производительности
+   - Lighthouse: встроен в Chrome DevTools, анализирует производительность, доступность и SEO.
+   - WebPageTest: онлайн-инструмент для анализа скорости загрузки страниц.
+4. Инструменты для тестирования доступности
+   - axe: библиотека для автоматического тестирования доступности.
+   - WAVE: онлайн-инструмент для проверки доступности веб-страниц.
+5. Инструменты для визуального тестирования
+   - Percy: сервис для визуального тестирования.
+   - Applitools: инструмент для автоматического сравнения скриншотов.
+
+## Подходы к тестированию
+1. Ручное тестирование
+   - Тестирование вручную, когда тестировщик проверяет функционал и интерфейс вручную. Полезно для юзабилити-тестирования и exploratory testing.
+2. Автоматизированное тестирование
+   - Написание скриптов для автоматического выполнения тестов. Подходит для регрессионного, функционального и кросс-браузерного тестирования.
+3. End-to-End (E2E) тестирование
+   - Тестирование всего потока приложения от начала до конца (например, от входа пользователя до завершения заказа).
+4. Unit-тестирование
+   - Тестирование отдельных компонентов или функций приложения (например, тестирование отдельной функции JavaScript).
+5. Интеграционное тестирование
+   - Проверка взаимодействия между различными модулями или компонентами приложения.

docs/testing/index.md

@@ -1,3 +0,0 @@
----
-sidebar_position: 1
----