📚 Справочник терминов

📘 Определение: Набор условий, при выполнении которых задача считается принятой.

💡 Пример: Например, для user story 'Регистрация пользователя' критерии могут быть: форма заполняется, валидация проходит, письмо отправляется.

⚠️ Ошибка: Отсутствие критериев ведёт к недопониманию между разработкой и бизнесом — задача 'сделана', но не решает нужду клиента.

✅ Best Practice: Формулируйте Acceptance Criteria до начала разработки, согласовывая с PO/бизнесом, используйте Given/When/Then.

📎 См. также: User Story, Definition of Done, BDD

🧩 Почему полезно:Позволяют точно определить, что именно должно быть реализовано, обеспечивая прозрачность требований и критерии приемки для всех участников команды.

📘 Определение: Подход, при котором тесты формулируются до начала разработки, с участием бизнеса и QA.

💡 Пример: Сначала пишется приёмочный сценарий, затем код, удовлетворяющий этому тесту.

⚠️ Ошибка: Тесты формулируются слишком поздно и теряют связь с бизнес-требованиями.

✅ Best Practice: Используйте связку ATDD + BDD, вовлекайте бизнес на старте.

🧩 Почему полезно:Позволяет команде лучше понять и применять термин 'Acceptance Test-Driven Development', повышая эффективность совместной работы.

📘 Определение: Проверка системы на соответствие требованиям перед передачей заказчику.

💡 Пример: Продукт-менеджер вручную проверяет поведение согласно AC.

⚠️ Ошибка: Проведение приемки без четко определённых Acceptance Criteria.

✅ Best Practice: Фиксируйте чек-листы, принимайте фичи по DoD.

🧩 Почему полезно:Гарантирует, что система соответствует требованиям заказчика. Используется для формальной проверки перед релизом.

📘 Определение: Общий подход к гибкой разработке программного обеспечения.

💡 Пример: Компания внедрила Agile, перешла к итеративной разработке и еженедельным релизам с обратной связью от пользователей.

⚠️ Ошибка: Agile понимается как 'делаем всё без плана', что ведёт к хаосу и утере цели.

✅ Best Practice: Agile — это про ценности и принципы. Начните с обучения команды и фасилитации изменений через пилотные команды.

🧩 Почему полезно:Помогает организациям быть гибкими и адаптироваться к изменениям требований и приоритетов, обеспечивая быструю поставку ценности пользователю.

📘 Определение: Помогает внедрять и улучшать agile-практики в организации.

💡 Пример: Agile Coach провёл Value Stream Mapping и помог наладить поток поставки в кросс-функциональной команде.

⚠️ Ошибка: Agile Coach становится администратором процессов, а не ментором — команда не развивается.

✅ Best Practice: Фокус на коучинге и фасилитации, а не управлении. Помогайте командам находить решения самостоятельно.

🧩 Почему полезно:Помогает командам и организациям внедрять и развивать гибкие подходы, улучшая процессы, культуру и командную работу.

📘 Определение: Оценка объема работы с учётом неопределённости и сложности задач.

💡 Пример: Использование story points и Planning Poker.

⚠️ Ошибка: Превращение оценки в обязательство на точную дату.

✅ Best Practice: Используйте оценки для сравнения относительной сложности, а не как фиксированные сроки.

🧩 Почему полезно:Позволяет команде оценить объём и сложность задач, не погружаясь в детали реализации, и управлять ожиданиями по срокам.

📘 Определение: Центральная точка входа в систему, через которую проходят все API-запросы и маршрутизируются к нужным сервисам.

💡 Пример: Kong или AWS API Gateway обрабатывают аутентификацию и проксируют трафик между клиентами и микросервисами.

⚠️ Ошибка: Загрузка логики в API Gateway превращает его в новый монолит.

✅ Best Practice: Используйте его только для маршрутизации, логирования, безопасности и лимитов.

🧩 Почему полезно:Обеспечивает единую точку входа для клиентских запросов, упрощает управление API, безопасность и маршрутизацию.

📘 Определение: Список задач и требований к продукту, формируемый PO.

💡 Пример: Backlog интернет-магазина содержит: фильтр по брендам, оплата частями, аналитика корзины.

⚠️ Ошибка: Задачи без приоритета и описания — команда не понимает, что важно и зачем.

✅ Best Practice: Регулярно проводите grooming, уточняйте цели, используйте MoSCoW или RICE для приоритизации.

🧩 Почему полезно:Позволяет централизованно управлять всеми требованиями и задачами команды, помогает расставлять приоритеты и планировать работу.

📘 Определение: Разработка через поведение: тесты формулируются на языке бизнеса.

💡 Пример: Сценарий входа в систему: Given пользователь, When вводит логин/пароль, Then попадает в Личный кабинет.

⚠️ Ошибка: Пишут BDD как обычные автотесты, не вовлекая бизнес в описание сценариев.

✅ Best Practice: Пишите сценарии вместе с аналитиком и PO, используйте Gherkin, внедряйте в CI-пайплайн.

📎 См. также: TDD, Acceptance Criteria

🧩 Почему полезно:Сближает разработчиков, тестировщиков и бизнес через единый язык описания поведения системы.

📘 Определение: Метод развертывания, при котором новая версия выкатывается в параллельной среде и трафик переключается только после проверки.

💡 Пример: Версия 2.0 на «зелёной» среде, трафик переключили после прохождения тестов.

⚠️ Ошибка: Плохая синхронизация данных между средами приводит к ошибкам при переключении.

✅ Best Practice: Используйте в высоконагруженных системах и автоматизируйте процесс.

🧩 Почему полезно:Позволяет безопасно выкатывать обновления без даунтайма, с возможностью быстрого отката.

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

💡 Пример: В контексте "Заказов" слово "Статус" означает одно, а в контексте "Оплат" — другое.

⚠️ Ошибка: Попытка сделать универсальную модель для всех доменов.

✅ Best Practice: Определяйте контексты вместе с бизнесом и избегайте дублирующих терминов между ними.

📎 См. также: Domain-Driven Design, Microservices

🧩 Почему полезно:Позволяет разделить сложную предметную область на независимые части с чёткими границами ответственности.

📘 Определение:Подход к организации веток в системе контроля версий.

💡 Пример:Использование Git Flow или trunk-based development.

⚠️ Ошибка:Слишком сложные схемы приводят к конфликтам и задержкам.

✅ Best Practice:Старайтесь упростить стратегию и синхронизировать её с релизной моделью.

🧩 Почему полезно:Определяет правила работы с ветками в системе контроля версий, помогает избежать конфликтов и упрощает слияние кода.

📘 Определение: График оставшейся работы по спринту или релизу.

💡 Пример: В Scrum-доске отображается снижение задач к 0 — помогает визуализировать прогресс.

⚠️ Ошибка: Обновляется вручную и редко — теряется актуальность и доверие к метрике.

✅ Best Practice: Интегрируйте с системой задач (Jira), автоматизируйте, анализируйте отклонения на ретро.

🧩 Почему полезно:Позволяет отслеживать скорость выполнения задач и выявлять отклонения от плана на ранней стадии.

📘 Определение: Проблема или возможность, которая требует изменений в бизнесе или системе.

💡 Пример: Повысить конверсию с 3% до 5% через упрощение оформления заказа.

⚠️ Ошибка: Начать разработку без осознания потребности и цели изменений.

✅ Best Practice: Явно фиксируйте бизнес-потребности перед сбором требований.

🧩 Почему полезно:Обосновывает запуск проекта или задачи, помогает связать технические инициативы с реальными целями бизнеса.

📘 Определение:Описание того, чего бизнес хочет достичь, включая цели, задачи и потребности.

💡 Пример:Компания хочет увеличить выручку на 15% за счёт автоматизации обработки заказов.

⚠️ Ошибка:Переход к деталям реализации без фиксации бизнес-целей — команда не понимает зачем делает работу.

✅ Best Practice:Собирайте бизнес-требования до формализации функциональных, фиксируйте их в виде SMART-целей.

🧩 Почему полезно:Формализуют цели и задачи бизнеса, лежат в основе функциональных и нефункциональных требований к системе.

📘 Определение: Метод визуализации архитектуры системы на четырёх уровнях: контекст, контейнеры, компоненты, код.

💡 Пример: Архитектор рисует контейнерную диаграмму с фронтендом, API, БД и интеграциями.

⚠️ Ошибка: Смешение уровней C4 и несогласованность между слоями.

✅ Best Practice: Соблюдайте уровни, делайте визуализацию читаемой для разных аудиторий.

📎 См. также: Domain-Driven Design

🧩 Почему полезно:Обеспечивает визуализацию архитектуры системы на разных уровнях детализации, понятную как разработчикам, так и бизнесу.

📘 Определение: Способность выпускать продукт в любое время безопасно и стабильно.

💡 Пример: Команда может задеплоить изменения на прод за 15 минут без ручного тестирования.

⚠️ Ошибка: Нет автоматизированных проверок — релиз превращается в стресс и баги.

✅ Best Practice: Покройте критические сценарии автотестами, внедрите blue-green deployment, конфиг-флаги.

🧩 Почему полезно:Позволяет быстрее и безопаснее доставлять изменения в продакшн, снижая риски и повышая частоту релизов.

📘 Определение: Частое слияние кода с основной веткой с автоматической проверкой.

💡 Пример: Каждый коммит запускает сборку, юнит-тесты, линтеры, и проверку Pull Request.

⚠️ Ошибка: CI работает, но никто не чинит красные билды — система деградирует.

✅ Best Practice: Настройте быструю обратную связь (<10 мин), фейлы должны чиниться в день их появления.

🧩 Почему полезно:Автоматизирует проверку и сборку кода, обеспечивая быструю обратную связь и стабильность основной ветки разработки.

📘 Определение: Процесс проверки кода другим разработчиком до слияния в основную ветку.

💡 Пример: PR проходит ревью двумя коллегами с замечаниями по читаемости и архитектуре.

⚠️ Ошибка: Принятие кода без анализа или поверхностный просмотр — пропускаются баги и долги.

✅ Best Practice: Используйте чек-листы, обсуждайте решения, фокусируйтесь не только на стиле, но и на архитектуре.

🧩 Почему полезно:Повышает качество кода, способствует обмену знаниями в команде и снижает вероятность багов.

📘 Определение: Анализ поведения пользователей, сгруппированных по дате регистрации, действиям или характеристикам.

💡 Пример: Сравнение возврата пользователей, зарегистрированных в январе и феврале.

⚠️ Ошибка: Использование метрик без учёта времени входа пользователей в систему.

✅ Best Practice: Используйте когорты для оценки ретеншена и эффективности фич.

🧩 Почему полезно:Позволяет анализировать поведение пользователей по группам, выявлять закономерности и улучшать продукт.

📘 Определение: Диаграмма, отображающая взаимодействие системы с внешними сущностями: пользователями, другими системами, потоками данных.

💡 Пример: Пользователь → Веб-приложение → API → Сторонняя система оплаты.

⚠️ Ошибка: Отсутствие на диаграмме ключевых интеграций и потоков.

✅ Best Practice: Используйте на старте проекта, вовлекайте архитекторов и бизнес.

🧩 Почему полезно:Наглядно показывает границы системы, её взаимодействие с внешними компонентами и пользователями.

📘 Определение: Визуальное представление всех шагов, через которые проходит клиент при взаимодействии с продуктом или сервисом.

💡 Пример: От осознания потребности → поиск → регистрация → использование → повторное обращение.

⚠️ Ошибка: Игнорирование негативных точек взаимодействия, отсутствие пользовательских эмоций.

✅ Best Practice: Проводите CJM с участием пользователей и межфункциональной команды.

🧩 Почему полезно:Помогает лучше понять опыт и проблемы пользователей на каждом этапе взаимодействия с продуктом.

📘 Определение: Время выполнения задачи от начала разработки до релиза.

💡 Пример: Cycle Time задачи: взята в работу в понедельник, задеплоена в четверг — 4 дня.

⚠️ Ошибка: Считается вручную или не отслеживается — сложно управлять потоком.

✅ Best Practice: Отслеживайте в Jira/YouTrack, визуализируйте, ищите узкие места.

🧩 Почему полезно:Позволяет отслеживать время выполнения задач, выявлять узкие места и повышать производительность команды.

📘 Определение: Ежедневная встреча команды для синхронизации и выявления препятствий.

💡 Пример: Каждый отвечает на 3 вопроса: что сделал, что планирую, есть ли блокеры.

⚠️ Ошибка: Встреча превращается в отчёт перед менеджером — теряется доверие и польза.

✅ Best Practice: Проводите стоя, в одной команде, в фокусе не статус, а сотрудничество.

🧩 Почему полезно:Обеспечивает прозрачность текущего состояния задач, помогает выявить и оперативно устранить блокеры.

📘 Определение: Количество дефектов, не найденных на тестировании и обнаруженных пользователями после релиза.

💡 Пример: Клиенты находят баг, который не зафиксирован в баг-трекере до продакшена.

⚠️ Ошибка: Отсутствие анализа причин приводит к повторным багам в будущем.

✅ Best Practice: Внедряйте RCA и усиливайте покрытия перед релизами.

🧩 Почему полезно:Помогает контролировать качество тестирования, показывая, насколько много дефектов попадает к пользователям.

📘 Определение: Критерии, при которых задача считается завершённой и готовой к релизу.

💡 Пример: В DoD входят: код покрыт тестами, пройден код-ревью, обновлена документация.

⚠️ Ошибка: DoD неформализован — задача 'готова', но баги и долги остаются.

✅ Best Practice: Сформулируйте единый DoD и повесьте рядом с доской команды, обновляйте его на ретро.

📎 См. также: Acceptance Criteria, Definition of Ready

🧩 Почему полезно:Устанавливает общие критерии завершения работы, помогая избегать недопонимания в команде.

📘 Определение: Критерии, которым должна соответствовать задача, чтобы команда могла начать её выполнение.

💡 Пример: Задача оценена, есть макет, понятна бизнес-цель и зависимости.

⚠️ Ошибка: Добавление в спринт неподготовленных задач без DoR.

✅ Best Practice: Согласуйте DoR с командой и отображайте его в документации.

🧩 Почему полезно:Помогает команде брать в работу задачи, полностью готовые к реализации, что снижает риски и ускоряет работу.

📘 Определение: Паттерн, при котором зависимости (например, сервисы) передаются в объект извне.

💡 Пример: Класс UserService получает репозиторий пользователей через конструктор.

⚠️ Ошибка: Создание зависимостей внутри класса — нарушается принцип инверсии зависимостей.

✅ Best Practice: Используйте DI-контейнеры, внедряйте зависимости через конструктор или параметры метода.

🧩 Почему полезно:Позволяет легко управлять зависимостями, упрощает тестирование и улучшает поддерживаемость кода.

📘 Определение: Платформа для создания, доставки и запуска приложений в изолированных контейнерах.

💡 Пример: Приложение запускается через docker-compose с PostgreSQL и backend.

⚠️ Ошибка: Запуск production-системы без ограничения ресурсов и мониторинга контейнеров.

✅ Best Practice: Минимизируйте образы, используйте multistage, следите за CVE.

🧩 Почему полезно:Упрощает развёртывание приложений, делая окружение идентичным на разработке, тестировании и продакшене.

📘 Определение: Методология проектирования ПО вокруг бизнес-домена и его логики.

💡 Пример: Архитектура интернет-магазина строится на доменах: «Каталог», «Корзина», «Оплата».

⚠️ Ошибка: Имитация DDD без участия доменных экспертов и бизнес-языка.

✅ Best Practice: Внедряйте DDD с фасилитацией, моделированием и использованием Bounded Context.

📎 См. также: Bounded Context, Event-Driven Architecture, C4 Model

🧩 Почему полезно:Позволяет эффективно моделировать сложные предметные области, делая архитектуру понятной и масштабируемой.

📘 Определение: Крупная пользовательская история, объединяющая несколько user stories.

💡 Пример: Epic: 'Покупка по подписке'. Включает истории: оформить подписку, управление, списание.

⚠️ Ошибка: Эпики не дробятся — невозможно отслеживать прогресс и инкременты.

✅ Best Practice: Разбивайте эпики на user stories, добавляйте критерии завершения эпика.

📎 См. также: User Story, Story Mapping

🧩 Почему полезно:Группирует несколько связанных пользовательских историй, облегчая планирование на стратегическом уровне.

📘 Определение: Подход к работе с данными: извлечение из источников, трансформация и загрузка в хранилище.

💡 Пример: Сбор данных из CRM, очистка и загрузка в DWH через Airflow.

⚠️ Ошибка: Перенос бизнес-логики в пайплайн данных, отсутствие контроля качества данных.

✅ Best Practice: Разделяйте источники, шаги и автоматизируйте мониторинг пайплайнов.

🧩 Почему полезно:Упрощает и автоматизирует процессы интеграции данных, повышая качество аналитики и отчётности.

📘 Определение: Метод визуального моделирования процессов через события.

💡 Пример: "Пользователь оформил заказ" → "Сформирован счёт" → "Отправлено уведомление".

⚠️ Ошибка: Превращение в обсуждение архитектуры, а не поведения.

✅ Best Practice: Используйте фасилитатора и ограниченное время.

🧩 Почему полезно:Позволяет быстро и наглядно выявить ключевые события и процессы в предметной области, улучшая понимание бизнеса командой.

📘 Определение: Архитектура, при которой компоненты обмениваются событиями через брокеры и реагируют на них асинхронно.

💡 Пример: Сервис «Заказов» публикует событие, а «Склад» и «Платежи» подписаны и реагируют.

⚠️ Ошибка: Отсутствие трассировки событий и хаос в формате сообщений.

✅ Best Practice: Внедряйте схемы сообщений, версионирование и централизованный мониторинг.

📎 См. также: Microservices, Kafka, Domain-Driven Design

🧩 Почему полезно:Создаёт системы с низкой связностью компонентов, повышая гибкость и масштабируемость приложения.

📘 Определение: Метод тестирования без заранее написанных кейсов, основанный на опыте и интуиции тестировщика.

💡 Пример: QA исследует функциональность формы без документации.

⚠️ Ошибка: Отсутствие фиксации найденных дефектов и сценариев для повторного использования.

✅ Best Practice: Делайте короткие сессии с фиксацией выводов и выявленных багов.

🧩 Почему полезно:Помогает быстро выявлять нетривиальные баги и проверять систему в условиях неопределённости.

📘 Определение: Автоматическое переключение на резервный ресурс при отказе основного.

💡 Пример: Переключение DNS на резервный сервер при падении основного.

⚠️ Ошибка: Отсутствие синхронизации данных между основным и резервным узлом.

✅ Best Practice: Регулярно тестируйте failover и поддерживайте синхронную репликацию.

🧩 Почему полезно:Обеспечивает непрерывность работы сервиса при сбоях, автоматически переключая нагрузку на резервные ресурсы.

📘 Определение: Отдельная ветка в системе контроля версий, созданная для разработки одной конкретной фичи или задачи.

💡 Пример: Ветка feature/login-page содержит работу над страницей логина.

⚠️ Ошибка: Затяжная разработка без мерджей — конфликт кода и потеря актуальности.

✅ Best Practice: Периодически обновляйте фича-ветку из основной и делайте маленькие PR.

🧩 Почему полезно:Позволяет параллельно вести разработку нескольких функциональностей, минимизируя конфликты и риски.

📘 Определение: Механизм управления функциями без релиза: включение/выключение логики.

💡 Пример: Фича запускается только для 5% пользователей с помощью флага в конфиге.

⚠️ Ошибка: Флаги не удаляются, копятся — возникает техдолг.

✅ Best Practice: Ведите учёт флагов, удаляйте устаревшие, используйте менеджер фич (LaunchDarkly, Unleash).

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

📘 Определение: Тест, который случайным образом проходит или падает без изменений в коде.

💡 Пример: Автотест на форму регистрации иногда падает из-за таймингов.

⚠️ Ошибка: Игнорирование flaky-тестов ухудшает доверие к CI.

✅ Best Practice: Удаляйте или исправляйте нестабильные тесты немедленно.

🧩 Почему полезно:Обнаружение и исправление нестабильных тестов повышает надёжность и доверие команды к автоматизированному тестированию.

📘 Определение: То, что система должна делать — функциональность, поведение и сценарии работы.

💡 Пример: Пользователь может восстановить пароль через email.

⚠️ Ошибка: Неочевидность требований — разные интерпретации командой.

✅ Best Practice: Используйте формализованный формат: «Система должна…».

🧩 Почему полезно:Чётко описывает ожидаемое поведение системы, обеспечивая соответствие решения бизнес-целям и ожиданиям пользователей.

📘 Определение: Сравнение текущего состояния с желаемым, выявление различий и точек улучшения.

💡 Пример: Сейчас — 60% автозадач, цель — 90% → разрыв в 30% требует улучшений.

⚠️ Ошибка: Неполный анализ или отсутствие метрик затрудняет выводы.

✅ Best Practice: Строите диаграммы «как есть» и «как должно быть» с метриками и сроками.

🧩 Почему полезно:Позволяет выявить разрыв между текущим и желаемым состоянием, упрощая планирование улучшений и изменений.

📘 Определение: Процесс уточнения, оценки и приоритизации задач в бэклоге.

💡 Пример: Команда раз в неделю уточняет формулировки, разбивает крупные задачи, даёт story points.

⚠️ Ошибка: Нет регулярного груминга — backlog устаревает и теряет ценность.

✅ Best Practice: Планируйте grooming заранее, подключайте PO, аналитика, Dev и QA.

🧩 Почему полезно:Обеспечивает постоянную актуализацию задач, помогает команде заранее прояснить требования и избежать задержек.

📘 Определение: Способность системы продолжать работу при сбое компонентов.

💡 Пример: Дублирование сервисов на нескольких зонах доступности.

⚠️ Ошибка: Использование только одного экземпляра критичного компонента.

✅ Best Practice: Дублируйте критичные сервисы и тестируйте отказоустойчивость.

🧩 Почему полезно:Обеспечивает бесперебойную работу системы, минимизируя время простоев и повышая надежность сервиса.

📘 Определение: Увеличение производительности системы за счёт добавления новых экземпляров (серверов, контейнеров, нод).

💡 Пример: В Kubernetes добавляются поды при росте нагрузки.

⚠️ Ошибка: Масштабирование без горизонтальной совместимости компонентов может привести к сбоям.

✅ Best Practice: Обеспечьте stateless-дизайн сервисов и автошкалирование через оркестратор.

🧩 Почему полезно:Позволяет увеличивать производительность системы путём добавления дополнительных ресурсов, не меняя её архитектуру.

📘 Определение: Срочное исправление критической ошибки в продакшене, минуя стандартный цикл релизов.

💡 Пример: Баг в оплате был устранён и деплоен через hotfix-ветку.

⚠️ Ошибка: Отсутствие тестов или ревью увеличивает риски регрессии.

✅ Best Practice: Делайте hotfix минимальным по объему и сопровождайте rollback-стратегией.

🧩 Почему полезно:Позволяет быстро устранять критичные ошибки в продакшене, минимизируя риски и потери для бизнеса.

📘 Определение: Визуальный инструмент планирования: цели → участники → поведение → фичи.

💡 Пример: Для цели 'Повысить вовлечённость': пользователь → повторный вход → push-уведомления.

⚠️ Ошибка: Составляется один раз и забывается, теряя смысл итеративности.

✅ Best Practice: Используйте Impact Map как инструмент итеративного планирования и коммуникации с бизнесом.

🧩 Почему полезно:Помогает командам связывать бизнес-цели с конкретными действиями пользователей и функциями продукта.

📘 Определение: Любая преграда, мешающая команде эффективно выполнять задачи.

💡 Пример: Сломалась CI-сборка, недоступен стенд — это блокирующий impediment.

⚠️ Ошибка: Не фиксируются и не эскалируются — команда буксует, velocity падает.

✅ Best Practice: Визуализируйте impediments на доске, эскалируйте через Scrum Master или PO.

🧩 Почему полезно:Выявление и устранение препятствий позволяет команде сохранять стабильный темп и высокую продуктивность.

📘 Определение: Рабочий, проверенный результат разработки, который можно поставить пользователю.

💡 Пример: По итогам спринта реализован поиск товаров и фильтры — это increment.

⚠️ Ошибка: Инкремент недоступен пользователю — технически не завершён или не задеплоен.

✅ Best Practice: Сделайте CI/CD, slice задач так, чтобы инкремент был в проде по итогам спринта.

🧩 Почему полезно:Позволяет регулярно предоставлять бизнесу и пользователям рабочий результат, снижая риски длительных разработок.

📘 Определение: Подход к управлению инфраструктурой с помощью конфигурационных файлов и скриптов.

💡 Пример: Использование Terraform для создания облачных ресурсов.

⚠️ Ошибка: Ручное вмешательство в конфигурации нарушает принцип IaC и ведёт к "drift".

✅ Best Practice: Храните IaC в репозиториях, ревьюйте и тестируйте как обычный код.

🧩 Почему полезно:Автоматизирует и стандартизирует инфраструктуру, сокращая ошибки и время на развёртывание новых окружений.

📘 Определение:Тестирование взаимодействия между модулями системы.

💡 Пример:Тест API, который вызывает несколько компонентов и проверяет общий результат.

⚠️ Ошибка:Полагаться только на юнит-тесты, игнорируя интеграционные.

✅ Best Practice:Интеграционные тесты обязательны для критичных потоков данных.

🧩 Почему полезно:Помогает проверять взаимодействие компонентов, выявлять дефекты интеграции и повышать общее качество системы.

📘 Определение: Формат описания потребностей: "Когда... Я хочу... Чтобы...", акцент на контексте и мотивации пользователя.

💡 Пример: Когда я опаздываю, я хочу видеть ближайший автобус, чтобы не ждать зря.

⚠️ Ошибка: Подмена user story, не связанная с конкретной задачей пользователя.

✅ Best Practice: Используйте в UX-проектировании и discovery-интервью.

🧩 Почему полезно:Позволяют команде лучше понять мотивы пользователей и задачи, которые они хотят решить с помощью продукта.

📘 Определение: Метод управления потоком задач с визуализацией стадий и ограничением WIP.

💡 Пример: Задачи двигаются по колонкам: To Do → In Progress → Testing → Done.

⚠️ Ошибка: Отсутствие WIP-лимитов ведёт к многозадачности и снижению эффективности.

✅ Best Practice: Ограничивайте WIP, отслеживайте Cycle Time, улучшайте поток.

🧩 Почему полезно:Улучшает прозрачность и управляемость рабочего процесса, помогая выявлять и устранять проблемы на ранних этапах.

📘 Определение: Система оркестрации контейнеров, автоматизирующая развертывание, масштабирование и обновление приложений.

💡 Пример: Автошкалирование подов на основе метрик CPU в K8s.

⚠️ Ошибка: Сложная настройка без базового понимания ресурсов и сети.

✅ Best Practice: Используйте Helm, namespaces, RBAC и контролируйте ресурсы через ограничения.

🧩 Почему полезно:Позволяет эффективно управлять контейнеризованными приложениями, повышая масштабируемость и надёжность системы.

📘 Определение: Время от появления запроса до поставки результата пользователю.

💡 Пример: От идеи фичи до её релиза прошло 14 дней — это Lead Time.

⚠️ Ошибка: Не отделяется от Cycle Time, не используется для анализа эффективности потока.

✅ Best Practice: Ведите аналитику по Lead Time, визуализируйте дашборд по типам задач.

🧩 Почему полезно:Помогает контролировать время от постановки задачи до её выполнения, позволяя быстрее доставлять ценность пользователям.

📘 Определение: Методология минимизации потерь, максимизации ценности и непрерывного улучшения.

💡 Пример: Команда выявила потери времени на ручные проверки и автоматизировала их.

⚠️ Ошибка: Lean путают с 'быстрее и дешевле', забывая про ценность и качество.

✅ Best Practice: Оценивайте потоки создания ценности, устраняйте bottlenecks, внедряйте Kaizen-подход.

🧩 Почему полезно:Помогает сокращать потери и повышать ценность продукта за счёт оптимизации процессов и постоянных улучшений.

📘 Определение:Фреймворк масштабирования Scrum на несколько команд, работающих над одним продуктом.

💡 Пример:3 Scrum-команды работают по одному Product Backlog и синхронизируются на Overall Retrospective.

⚠️ Ошибка:Создание изолированных Scrum-команд с собственными бэклогами нарушает принципы LeSS.

✅ Best Practice:Соблюдайте единый Product Backlog, синхронные спринты и координацию между командами через общие события.

🧩 Почему полезно:Позволяет масштабировать Scrum на несколько команд, сохраняя фокус на едином продукте и эффективности коммуникаций.

📘 Определение: Компонент, распределяющий входящие запросы между несколькими серверами или сервисами.

💡 Пример: NGINX равномерно направляет трафик на backend-сервисы.

⚠️ Ошибка: Один балансировщик без отказоустойчивости становится точкой отказа.

✅ Best Practice: Используйте health-check, failover и DNS-ротацию для надёжности.

🧩 Почему полезно:Распределяет нагрузку между ресурсами системы, улучшая производительность и надёжность приложений.

📘 Определение: Все узлы могут и читать, и писать данные. Требует согласованности.

💡 Пример: Galera Cluster для MySQL с синхронной репликацией.

⚠️ Ошибка: Конфликты при параллельной записи на разных узлах.

✅ Best Practice: Используйте для геораспределённых систем и настройте конфликт-резолвинг.

🧩 Почему полезно:Позволяет обеспечить надёжность и доступность данных за счёт синхронизации между несколькими узлами базы данных.

📘 Определение: Мастер-сервер обрабатывает записи, а слейвы обслуживают только чтение.

💡 Пример: PostgreSQL с настройкой pgpool-II для чтения с реплик.

⚠️ Ошибка: Запросы на запись попадают на слейв, вызывая сбои.

✅ Best Practice: Явно разделяйте операции и следите за консистентностью данных.

🧩 Почему полезно:Обеспечивает эффективную отказоустойчивость и производительность, позволяя разгрузить основной сервер.

📘 Определение: Подход к разработке, при котором приложение разбито на независимые, автономные сервисы, взаимодействующие по API.

💡 Пример: Отдельные сервисы: «Платежи», «Товары», «Отзывы», «Промо».

⚠️ Ошибка: Перенос монолита на микросервисы без изменения командной структуры и ответственности.

✅ Best Practice: Один микросервис = одна бизнес-функция, с изолированными данными и жизненным циклом.

📎 См. также: Service Mesh, API Gateway, Event-Driven Architecture

🧩 Почему полезно:Позволяет строить гибкие и масштабируемые системы, упрощает разработку и сопровождение отдельных компонентов.

📘 Определение: Заглушка, заменяющая реальный компонент при тестировании.

💡 Пример: Mock-сервис подменяет API платежей при автотестировании checkout.

⚠️ Ошибка: Mock не отражает поведение прод-системы — тесты ложно успешны.

✅ Best Practice: Создавайте достоверные моки, используйте их только в scope тестирования.

🧩 Почему полезно:Упрощает тестирование за счёт имитации работы внешних систем и сервисов, ускоряя разработку и повышая надёжность тестов.

📘 Определение: Наблюдение за состоянием системы, её метриками и логами для предупреждения сбоев.

💡 Пример: Grafana показывает повышение latency на продакшене.

⚠️ Ошибка: Отсутствие алертов — инциденты замечаются только пользователями.

✅ Best Practice: Настройте пороговые значения, используйте дашборды и логирование.

🧩 Почему полезно:Обеспечивает непрерывный контроль состояния системы, позволяет быстро выявлять проблемы и реагировать на инциденты.

📘 Определение: Архитектура, при которой вся бизнес-логика, интерфейс и данные реализованы в одном приложении.

💡 Пример: Вся система e-commerce на одной Java-сборке с UI, API и БД.

⚠️ Ошибка: Попытка масштабировать монолит путём клонирования инстансов.

✅ Best Practice: Используйте для MVP и постепенно декомпозируйте по мере роста.

📎 См. также: Microservices, Refactoring

🧩 Почему полезно:Удобен на ранних стадиях проекта, когда важна простота разработки и минимальное количество зависимостей.

📘 Определение: Метод приоритизации: Must, Should, Could, Won’t.

💡 Пример: Функция оплаты — Must, экспорт CSV — Could.

⚠️ Ошибка: Все задачи получают Must — приоритизация теряет смысл.

✅ Best Practice: Ограничивайте Must до 20% задач, валидируйте вместе с PO и аналитиками.

🧩 Почему полезно:Помогает команде и бизнесу чётко определить приоритеты, повышая эффективность планирования и реализации.

📘 Определение: Подход, при котором в код намеренно вносятся ошибки, чтобы проверить, сработают ли тесты.

💡 Пример: Подмена оператора “==” на “!=” — хороший тест должен провалиться.

⚠️ Ошибка: Использование мутационного тестирования без целей и в продакшене.

✅ Best Practice: Используйте для оценки качества автотестов в CI.

🧩 Почему полезно:Повышает качество тестов за счёт выявления слабых мест и улучшения покрытия тестовыми сценариями.

📘 Определение: Минимально жизнеспособный продукт — версия, несущая базовую ценность.

💡 Пример: MVP сервиса — заказ такси без профиля, карты, бонусов.

⚠️ Ошибка: Пытаются сделать 'всё сразу' — MVP превращается в долгострой.

✅ Best Practice: Фокус на быстрой проверке гипотезы и фидбэке от пользователя.

🧩 Почему полезно:Позволяет проверить гипотезы с минимальными затратами, быстро получить обратную связь и снизить риски.

📘 Определение: Требования к производительности, безопасности, масштабируемости системы.

💡 Пример: "Время отклика API должно быть не более 300 мс".

⚠️ Ошибка: Игнорирование NFR приводит к недовольству пользователей и нестабильной работе.

✅ Best Practice: Уточняйте для каждого функционального требования и фиксируйте в документации.

🧩 Почему полезно:Определяют качественные характеристики продукта, такие как производительность, надёжность и безопасность.

📘 Определение: Главная метрика продукта, отражающая основную ценность для пользователя и долгосрочный рост бизнеса.

💡 Пример: Для Spotify — прослушанные минуты, для Airbnb — забронированные ночи.

⚠️ Ошибка: Выбор метрики, не связанной с реальной пользовательской ценностью.

✅ Best Practice: Привязывайте NSM к поведенческим действиям и отслеживайте её в динамике.

🧩 Почему полезно:Позволяет всей компании сфокусироваться на одной ключевой метрике, напрямую отражающей успех продукта.

📘 Определение: Метод управления по целям: Objectives и Key Results.

💡 Пример: O: Увеличить конверсию, KR: на 15% за 2 месяца.

⚠️ Ошибка: KR становятся задачами, а не измеримыми результатами.

✅ Best Practice: Ставьте амбициозные цели, отделяйте 'что' (O) от 'как померим' (KR).

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

📘 Определение: Вымышленный пользователь, отражающий реальные характеристики аудитории.

💡 Пример: Мария, 32 года, мама двоих, пользуется доставкой каждый день.

⚠️ Ошибка: Персоны выдуманы без исследований, не отражают реальное поведение.

✅ Best Practice: Создавайте персоны на основе интервью, данных и поведения.

🧩 Почему полезно:Позволяет команде лучше понять целевую аудиторию и создавать продукт, отвечающий реальным потребностям пользователей.

📘 Определение: Метод командной оценки задач в story points через голосование картами.

💡 Пример: Задача оценивается в 5 баллов после голосования команды.

⚠️ Ошибка: Команда просто соглашается с лидером — оценки теряют смысл.

✅ Best Practice: Обсуждайте расхождения в оценках, используйте референсные задачи.

🧩 Почему полезно:Помогает команде прийти к согласованной оценке задач, обеспечивая вовлечённость каждого участника в планирование.

📘 Определение: Упорядоченный список требований к продукту: фичи, баги, техдолг.

💡 Пример: Product Backlog включает корзину, поиск, отчёты и улучшения UI.

⚠️ Ошибка: Смешивают product backlog и sprint backlog, теряется фокус.

✅ Best Practice: Разделяйте product и sprint backlog, актуализируйте с PO и командой.

🧩 Почему полезно:Помогает структурировать все идеи и задачи продукта, обеспечивая прозрачность и ясность приоритетов для команды.

📘 Определение: Этап до разработки — изучение проблемы, пользователя и тестирование гипотез.

💡 Пример: Интервью + прототип + A/B = проверка ценности до разработки.

⚠️ Ошибка: Начать разработку до понимания пользовательской проблемы.

✅ Best Practice: Проводите discovery перед каждым крупным фичевым запуском.

🧩 Почему полезно:Позволяет снизить риски и лучше понять потребности пользователей, прежде чем начать дорогостоящую разработку.

📘 Определение: Ответственный за ценность продукта, управляет бэклогом и приоритетами.

💡 Пример: PO приоритизирует задачи, отвечает на вопросы команды, участвует в демо.

⚠️ Ошибка: PO не вовлечён в ежедневную работу, backlog устаревает.

✅ Best Practice: Будьте частью команды, общайтесь с пользователями, защищайте продуктовую ценность.

🧩 Почему полезно:Отвечает за приоритизацию задач, обеспечивает связь между бизнесом и командой, гарантируя соответствие продукта ожиданиям пользователей.

📘 Определение: Запрос на слияние изменений в основную ветку репозитория с возможностью ревью.

💡 Пример: Разработчик создал pull request на фичу с новым фильтром товаров.

⚠️ Ошибка: Отсутствие ревью или автоматической проверки кода.

✅ Best Practice: Используйте pull requests как точку контроля качества и обмена знаниями.

🧩 Почему полезно:Позволяет команде лучше понять и применять термин 'Pull Request', повышая эффективность совместной работы.

📘 Определение: Процесс изменения внутренней структуры кода без изменения его внешнего поведения.

💡 Пример: Улучшение читаемости и переименование переменных без изменения логики.

⚠️ Ошибка: Рефакторинг без покрытия тестами может привести к регрессии.

✅ Best Practice: Делайте рефакторинг малыми шагами, с автотестами и в согласованных частях системы.

🧩 Почему полезно:Позволяет команде лучше понять и применять термин 'Refactoring', повышая эффективность совместной работы.

📘 Определение: Процесс разбора и уточнения задач перед спринтом.

💡 Пример: Команда уточняет критерии, добавляет тест-кейсы, оценивает в story points.

⚠️ Ошибка: Refinement проводят без QA и аналитика — задачи остаются размытыми.

✅ Best Practice: Участвуют все роли, обсуждаются риски, критерии, зависимости.

🧩 Почему полезно:Позволяет команде лучше понять и применять термин 'Refinement', повышая эффективность совместной работы.

📘 Определение: Повторное тестирование функционала, чтобы убедиться, что изменения не сломали существующее поведение.

💡 Пример: После изменения API проверяются все формы, которые его используют.

⚠️ Ошибка: Недостаточное покрытие критических путей при регрессии.

✅ Best Practice: Используйте чек-листы и автоматизацию регрессии.

🧩 Почему полезно:Позволяет команде лучше понять и применять термин 'Regression Testing', повышая эффективность совместной работы.

📘 Определение: Документ с кратким описанием изменений, улучшений, фиксов в продукте.

💡 Пример: “Добавили возможность повторной оплаты заказа. Исправили баг с авторизацией.”

⚠️ Ошибка: Отсутствие релиз-нот или написание их техническим языком, непонятным пользователю.

✅ Best Practice: Используйте простой язык, структурируйте по типам изменений.

🧩 Почему полезно:Обеспечивают прозрачность изменений для пользователей и заинтересованных сторон, улучшая коммуникацию и управление ожиданиями.

📘 Определение: Практика группового выпуска версий продуктов по расписанию.

💡 Пример: Все команды выпускаются в прод каждую вторую пятницу месяца.

⚠️ Ошибка: Несогласованность команд приводит к провалу релиза или задержкам.

✅ Best Practice: Синхронизируйте команды и планируйте через PI Planning.

🧩 Почему полезно:Организует регулярные и предсказуемые релизы, улучшая координацию между командами и упрощая планирование поставок.

📘 Определение: Ретроспектива — встреча после спринта для анализа и улучшений.

💡 Пример: Команда фиксирует: что хорошо, что улучшить, какие действия принять.

⚠️ Ошибка: RETRO превращается в жалобы или формальность без действий.

✅ Best Practice: Фиксируйте экшены, возвращайтесь к ним в следующей ретро.

🧩 Почему полезно:Помогает команде регулярно анализировать и улучшать рабочий процесс, повышая эффективность и качество совместной работы.

📘 Определение: Процесс возврата системы к предыдущей стабильной версии в случае критических ошибок после релиза.

💡 Пример: После сбоя на проде DevOps откатили релиз на версию от вчера.

⚠️ Ошибка: Отсутствие автоматизации или резервных копий делает откат невозможным.

✅ Best Practice: Используйте автоматические снапшоты и CI/CD с поддержкой отката.

🧩 Почему полезно:Позволяет быстро вернуться к стабильной версии при возникновении проблем с новым релизом, снижая влияние на пользователей.

📘 Определение:Методология масштабирования Agile для больших организаций, включающая уровни команды, программы и портфеля.

💡 Пример:В компании используется SAFe: Agile Release Train, PI Planning и роли RTE, Epic Owner.

⚠️ Ошибка:Формальное внедрение без изменения культуры приводит к бюрократии вместо гибкости.

✅ Best Practice:Фокусируйтесь на ценностях Lean и потоке ценности. Начинайте с подготовки коучей и пилотных ART.

🧩 Почему полезно:Позволяет крупным организациям координировать работу множества agile-команд и улучшает управление портфелем продуктов.

📘 Определение: Фреймворк гибкой разработки с ролями, событиями и артефактами.

💡 Пример: Работа делится на спринты по 2 недели, с daily, review, retro.

⚠️ Ошибка: Scrum используется формально, без ценностей и обратной связи.

✅ Best Practice: Фокусируйтесь на эмпиризме, адаптации и ценности инкремента.

🧩 Почему полезно:Повышает гибкость, прозрачность и управляемость проектов, позволяя регулярно поставлять ценность пользователям.

📘 Определение: Инфраструктурный слой, обеспечивающий надёжное взаимодействие микросервисов без изменения их кода.

💡 Пример: Istio управляет трафиком между сервисами, добавляя ретраи и трейсинг.

⚠️ Ошибка: Внедрение Service Mesh без понимания сетевых политик и мониторинга.

✅ Best Practice: Используйте при большом количестве сервисов, автоматизируйте TLS, observability и policy control.

🧩 Почему полезно:Упрощает управление взаимодействием микросервисов, повышает наблюдаемость и безопасность приложений.

📘 Определение: Разделение базы данных или сервиса на независимые логические сегменты (шарды).

💡 Пример: MongoDB шардинг коллекции по региону пользователя.

⚠️ Ошибка: Неправильный выбор ключа — неравномерная нагрузка.

✅ Best Practice: Выбирайте шардинг-ключ по анализу нагрузки и запросов.

🧩 Почему полезно:Позволяет масштабировать базы данных горизонтально, повышая производительность и надёжность приложений.

📘 Определение: Подход, при котором тестирование начинается на самых ранних этапах разработки — на уровне требований, UX, архитектуры.

💡 Пример: QA участвует в discovery и уточнении Acceptance Criteria ещё до кода.

⚠️ Ошибка: Отсутствие QA при проектировании ведёт к дорогим ошибкам позже.

✅ Best Practice: Вовлекайте QA в анализ, планирование и код-ревью с самого начала.

🧩 Почему полезно:Снижает затраты и ускоряет выявление дефектов, проводя тестирование на ранних этапах разработки.

📘 Определение: Метрики надёжности: SLA — договор с пользователями, SLO — целевые показатели, SLI — измеряемые метрики (доступность, время ответа).

💡 Пример: SLO: 99.9% аптайма в месяц, SLI: 99.2% по факту — нарушен SLA.

⚠️ Ошибка: Обещания без измерений или недостижимые цели без последствий.

✅ Best Practice: Делайте метрики прозрачными, автоматизируйте алерты и SLA breach detection.

🧩 Почему полезно:Позволяет команде чётко определить и контролировать целевые показатели качества сервиса, обеспечивая прозрачность, управляемость и удовлетворенность клиентов.

📘 Определение: Быстрая проверка ключевых функций, чтобы убедиться, что сборка пригодна к дальнейшему тестированию.

💡 Пример: Проверка логина и загрузки главной страницы сразу после деплоя.

⚠️ Ошибка: Слишком поверхностная проверка, пропускающая критические ошибки.

✅ Best Practice: Делайте smoke-тесты автоматизированными и обязательными в CI/CD.

🧩 Почему полезно:Позволяет быстро проверить основные функции приложения после деплоя, минимизируя риски простоя.

📘 Определение: Исследовательская задача для изучения технологии или подхода.

💡 Пример: Spike: сравнить библиотеки графиков и выбрать подходящую.

⚠️ Ошибка: Spike превращается в разработку без сроков и ценности.

✅ Best Practice: Ограничьте время, зафиксируйте цель и результат в backlog.

🧩 Почему полезно:Позволяет быстро исследовать технические или бизнес-вопросы, чтобы снизить неопределённость перед реализацией функциональности.

📘 Определение:Модель командной организации, ориентированная на автономные скводы, главы и альянсы.

💡 Пример:Команда разбита на скводы с главами по QA, дизайн и продукту. Альянсы координируют стратегию.

⚠️ Ошибка:Слепое копирование структуры без понимания культуры и контекста ведёт к хаосу.

✅ Best Practice:Используйте как вдохновение. Начинайте с принципов автономии и согласованности, а не структуры.

🧩 Почему полезно:Вдохновляет на гибкую структуру команд, где сочетаются автономия и совместная работа через скводы, главы и альянсы.

📘 Определение: Цель спринта — зачем делаются задачи и какую ценность создают.

💡 Пример: Goal: покупка без регистрации. Все задачи спринта это поддерживают.

⚠️ Ошибка: Нет цели — задачи не связаны и не создают инкремента.

✅ Best Practice: Формулируйте цель до планирования, проверяйте соответствие backlog.

📎 См. также: Sprint Goal, Retrospective, User Story

🧩 Почему полезно:Позволяет регулярно поставлять работающий продукт, оперативно реагировать на изменения и эффективно управлять задачами.

📘 Определение: Метод визуализации пользовательского пути и необходимых функций.

💡 Пример: Путь: поиск товара → добавление в корзину → оформление заказа.

⚠️ Ошибка: Story map не обновляется — теряется связь с реальным потоком.

✅ Best Practice: Используйте на старте проекта, как основу для backlog и MVP.

🧩 Почему полезно:Помогает визуализировать пользовательский путь, структурировать задачи и планировать релизы с учетом реальной ценности для пользователей.

📘 Определение: Относительная оценка сложности задачи, обычно по Фибоначчи.

💡 Пример: Простая багфиксация — 1 SP, интеграция с API — 8 SP.

⚠️ Ошибка: Сравниваются между командами — теряется смысл относительности.

✅ Best Practice: Используйте внутри команды, обсуждайте ориентиры, избегайте давления.

🧩 Почему полезно:Позволяют команде оценивать объём задач относительно друг друга, упрощая планирование и прогнозирование сроков реализации.

📘 Определение: Разработка через тестирование: сначала пишутся тесты, затем код.

💡 Пример: Пишется тест на метод расчёта → пишется реализация → проходит тест.

⚠️ Ошибка: Пишут тесты после — это уже не TDD.

✅ Best Practice: Пишите сначала фейл-тест → минимальный код → рефакторинг.

📎 См. также: BDD, Unit Test

🧩 Почему полезно:Формирует поведение через тесты, улучшает архитектуру кода и снижает количество дефектов.

📘 Определение: Последствия технических компромиссов — ухудшение архитектуры, качества.

💡 Пример: Невынесенный UI-компонент усложняет повторное использование.

⚠️ Ошибка: Техдолг копится без учёта, мешает масштабированию.

✅ Best Practice: Ведите учёт, выделяйте capacity, обсуждайте с PO.

🧩 Почему полезно:Позволяет оценивать технические риски и делать осознанные инвестиции в качество системы.

📘 Определение: Исследовательская задача для изучения технологии или оценки сложности.

💡 Пример: Проверка, можно ли реализовать фичу на текущем API.

⚠️ Ошибка: Отсутствие чёткой цели или ограниченного времени на выполнение spike.

✅ Best Practice: Делайте короткие spike (1–2 дня) и фиксируйте результат.

🧩 Почему полезно:Даёт команде возможность исследовать и решить сложные технические вопросы до начала реализации, снижая неопределённость и риски.

📘 Определение: Формальное описание сценария тестирования с шагами и ожиданиями.

💡 Пример: Проверка логина с валидными данными: шаги, входные, результат.

⚠️ Ошибка: Нет привязки к требованиям, кейсы неактуальны.

✅ Best Practice: Обновляйте при изменениях, используйте шаблоны, покрывайте DoD.

📎 См. также: Test Environment, Unit Test

🧩 Почему полезно:Обеспечивает прозрачность тестирования, помогает отслеживать покрытие и повышает надёжность продукта.

📘 Определение: Показывает, насколько требования и сценарии продукта покрыты тест-кейсами.

💡 Пример: 80% сценариев корзины покрыты ручными и автотестами.

⚠️ Ошибка: Высокое покрытие не всегда означает высокое качество тестов.

✅ Best Practice: Анализируйте покрытие в сочетании с баг-репортами.

🧩 Почему полезно:Обеспечивает прозрачность тестирования, помогает отслеживать покрытие и повышает надёжность продукта.

📘 Определение: Процент кода, покрытого автоматизированными тестами.

💡 Пример: "У нас 80% покрытие unit-тестами по бизнес-логике".

⚠️ Ошибка: Слепое стремление к 100% покрытию без пользы.

✅ Best Practice: Стремитесь к разумному балансу между количеством и качеством тестов.

🧩 Почему полезно:Помогает команде выявить участки системы, не покрытые тестами, и обеспечивает прозрачность качества разработки.

📘 Определение: Управление созданием, использованием, очисткой и хранением данных, используемых в тестировании.

💡 Пример: Использование шаблонов пользователей для автотестов и очищающих скриптов.

⚠️ Ошибка: Жёсткое зависимость тестов от нестабильных данных.

✅ Best Practice: Используйте анонимизированные данные, шаблоны и TDM-инструменты.

🧩 Почему полезно:Позволяет эффективно управлять тестовыми данными, повышая качество и надёжность тестирования.

📘 Определение: Изолированная инфраструктура, используемая для выполнения тестов и валидации кода до релиза в продакшен.

💡 Пример: Stage-сервер, настроенный как продакшен, с анонимизированными данными.

⚠️ Ошибка: Различия между тестовой и прод-средой приводят к ложным багам или пропущенным ошибкам.

✅ Best Practice: Синхронизируйте конфигурацию, используйте IaC и автоматизированную валидацию окружений.

📎 См. также: Test Case, Integration Testing

🧩 Почему полезно:Создаёт условия для проведения реалистичных и надёжных тестов, помогая выявлять дефекты до выхода в продакшн.

📘 Определение: Документ, описывающий цели, объём, подходы, ресурсы и график тестирования.

💡 Пример: План на релиз включает smoke, регрессию и UX-тестирование.

⚠️ Ошибка: Нереалистичные сроки и неполный перечень рисков.

✅ Best Practice: Обновляйте план по мере появления новых требований и рисков.

🧩 Почему полезно:Позволяет заранее определить объём, подходы и стратегию тестирования, улучшая контроль качества и предсказуемость релизов.

📘 Определение: Совместное обсуждение задачи между аналитиком, разработчиком и тестировщиком.

💡 Пример: Перед спринтом Dev, QA и Analyst уточняют сценарии для новой фичи поиска.

⚠️ Ошибка: Обсуждение проводится без одной из ролей — требования остаются неясными.

✅ Best Practice: Встречайтесь перед началом реализации, документируйте сценарии и кейсы.

🧩 Почему полезно:Улучшает коммуникацию между аналитиками, разработчиками и тестировщиками, помогая заранее выявить риски и пробелы в требованиях.

📘 Определение: Количество задач, проходящих через систему за единицу времени.

💡 Пример: В спринт команда завершает в среднем 18 задач.

⚠️ Ошибка: Оценивается без учёта типа задач — сравнение некорректно.

✅ Best Practice: Ведите учёт по типам задач, визуализируйте дашбордом.

🧩 Почему полезно:Позволяет оценить продуктивность команды, выявить проблемы и оптимизировать рабочий процесс.

📘 Определение: Фиксированный отрезок времени, за который выполняется активность.

💡 Пример: Retro проводится в таймбоксе 45 минут, независимо от прогресса.

⚠️ Ошибка: Игнорирование timebox — встречи растягиваются, теряется фокус.

✅ Best Practice: Соблюдайте лимит, заранее готовьте повестку и фасилитатора.

🧩 Почему полезно:Помогает команде фокусироваться на результате и контролировать сроки, избегая излишнего затягивания задач.

📘 Определение:Тестирование отдельных функций в изоляции.

💡 Пример:Тест функции, возвращающей сумму двух чисел.

⚠️ Ошибка:Связь юнит-теста с внешним окружением.

✅ Best Practice:Делайте тесты изолированными и быстрыми.

📎 См. также: TDD, Test Case

🧩 Почему полезно:Повышает надёжность и поддерживаемость кода, позволяя быстро выявлять ошибки на ранних стадиях разработки.

📘 Определение: Сценарий взаимодействия пользователя с системой для достижения цели.

💡 Пример: "Пользователь оформляет заказ" — последовательность шагов, ролей и исключений.

⚠️ Ошибка: Недостаточно детализированные шаги или упущенные альтернативные потоки.

✅ Best Practice: Структурируйте в формате Actor → Action → Result.

🧩 Почему полезно:Помогает команде и бизнесу чётко понимать функциональность системы с точки зрения пользователя и корректно формулировать требования.

📘 Определение: Формат описания требований: как <роль>, я хочу <функция>, чтобы <ценность>.

💡 Пример: Как покупатель, я хочу фильтровать товары по бренду, чтобы быстрее находить нужное.

⚠️ Ошибка: Пишут без указания ценности или роли — теряется смысл.

✅ Best Practice: Добавляйте Acceptance Criteria, уточняйте через примеры.

📎 См. также: Epic, Acceptance Criteria, Definition of Done

🧩 Почему полезно:Помогает формулировать требования в формате, понятном команде и ориентированном на пользователя. Упрощает коммуникацию между заказчиком и исполнителями.

📘 Определение: Чёткое объяснение, какую ценность продукт создаёт для клиента и почему он лучше альтернатив.

💡 Пример: «Доставка за 15 минут без переплат» — ценностное предложение для онлайн-магазина.

⚠️ Ошибка: Расплывчатые и не проверенные гипотезы вместо конкретной ценности.

✅ Best Practice: Формулируйте VP с учётом сегмента, проблемы и отличия от конкурентов.

🧩 Почему полезно:Помогает выделить уникальные преимущества продукта, привлекая целевую аудиторию и повышая конкурентоспособность.

📘 Определение: Скорость команды: сколько story points она завершает за спринт.

💡 Пример: Velocity команды — 34 SP в среднем за 3 спринта.

⚠️ Ошибка: Используется для давления или сравнения между командами.

✅ Best Practice: Используйте только внутри команды для планирования и прогноза.

🧩 Почему полезно:Позволяет команде оценивать свою производительность и прогнозировать сроки реализации задач.

📘 Определение: Увеличение ресурсов (CPU, памяти) одного узла или сервера.

💡 Пример: Увеличение объёма памяти на ВМ в облаке для ускорения обработки.

⚠️ Ошибка: Апгрейд может привести к остановке и ограничен пределом хоста.

✅ Best Practice: Используйте только если невозможно горизонтальное масштабирование.

🧩 Почему полезно:Позволяет быстро увеличить производительность системы путём наращивания мощности существующих ресурсов.

📘 Определение: Ограничение количества задач в работе одновременно.

💡 Пример: Максимум 2 задачи в колонке 'In Progress' на человека.

⚠️ Ошибка: WIP Limit отсутствует — команда распыляется, задачи не завершаются.

✅ Best Practice: Определите лимиты и контролируйте соблюдение в доске.

🧩 Почему полезно:Позволяет команде избежать перегрузки и повысить эффективность работы, ограничивая количество задач в работе одновременно.

📘 Определение: Черновой макет интерфейса без визуального оформления.

💡 Пример: Wireframe показывает расположение кнопок и полей регистрации.

⚠️ Ошибка: Считают финальным дизайном — клиент ожидает готовый UI.

✅ Best Practice: Объясняйте цель wireframe, уточняйте функциональность до дизайна.

🧩 Почему полезно:Упрощает обсуждение и согласование пользовательского интерфейса, позволяя быстро протестировать идеи на ранних этапах разработки.