Метрики и оценка
Velocity (Скорость Команды)
Velocity (Скорость Команды) — это ключевая метрика в Scrum, которая измеряет среднее количество работы (выраженное в Story Points), которое Разработчики успешно выполняет и доводит до Definition of Done (DOD) за один Спринт.
Burndown Chart (Диаграмма Сгорания): Как Отслеживать Прогресс Спринта
Burndown Chart (Диаграмма Сгорания) — это графический инструмент, который используется для визуализации оставшейся работы (обычно в Story Points или часах) в рамках Спринта или всего Продукта. Она показывает, сколько работы уже сделано и сколько осталось до завершения заданного периода.
Story Points (Очки Истории): Почему Мы Не Используем Часы?
Story Points (Очки Истории) — это единица измерения сложности, трудозатрат и неопределенности для оценки задач (User Stories) в Product Backlog. В отличие от часов, Story Points отражают относительную оценку: задача в 8 очков не в два раза длиннее, чем задача в 4 очка, а в два раза сложнее.
Planning Poker: Руководство по Оценке Задач и Достижению Консенсуса в Scrum
Planning Poker — это один из самых популярных и эффективных методов для оценки трудоемкости задач (User Stories или элементов Бэклога) в гибких командах. Вместо того чтобы полагаться на мнение одного эксперта, этот метод использует мудрость толпы и игру, чтобы быстро выявить и обсудить те части задачи, которые члены команды понимают по-разному.
Практики и работа с требованиями
Definition of Done: Определение Готовности и Стандарт Качества Инкремента (DOD)
Definition of Done (DoD) — это формальный список критериев, которым должен соответствовать каждый элемент Бэклога, чтобы считаться завершенным. Это обязательство по качеству. Если задача не прошла хотя бы один пункт из DoD, её нельзя показывать на Обзоре Спринта и тем более выпускать к пользователям.
Definition of Ready (DoR): Критерии Готовности Задачи к Спринту
Definition of Ready (DoR) — это список условий, при которых задача считается достаточно понятной, чтобы команда взяла её в Спринт. Это не официальный артефакт Scrum Guide, но критически важный инструмент для защиты команды от хаоса и неясных требований.
Product Backlog Refinement (PBR): Как Обеспечить Качество и Готовность Задач
Product Backlog Refinement (PBR), или Проработка Бэклога Продукта, является непрерывным процессом, в ходе которого Product Owner и Разработчики совместно детализируют будущие задачи, превращая общие идеи в готовые к реализации элементы.
Spike (Спайк) в Scrum: Инструмент для Снижения Неопределенности и Риска
Spike (Спайк) — это короткая задача-исследование. Её цель не в том, чтобы написать работающий код, а в том, чтобы добыть информацию. Спайк помогает команде снизить риски и неопределенность, когда нужно изучить новую технологию или разобраться в запутанном чужом коде.
User Story Mapping: Картирование Пользовательских Историй
User Story Mapping (Картирование Пользовательских Историй) — это визуальный метод приоритизации и организации Product Backlog‘а, который фокусируется на пути пользователя (или клиента) и его взаимодействии с продуктом. Это двумерная структура, которая позволяет увидеть полную картину продукта.
Time-Boxing (Фиксация Времени): Фундаментальный Принцип Scrum
Time-Boxing (Фиксация Времени) — это ключевой принцип Agile, при котором каждому событию (Спринту, митингу, встрече) выделяется фиксированный, максимальный промежуток времени, который не может быть превышен. Это обеспечивает эффективность и дисциплину.
Технический Долг: Понятие, Причины и Стратегии Управления в Agile
Технический долг — это метафора для «быстрых и грязных» решений. Они позволяют выпустить продукт сегодня, но замедляют команду завтра. Как и в случае с деньгами, по долгу приходится платить проценты. В разработке проценты это время, которое команда тратит на борьбу с кривым кодом вместо создания новых фич
User Story: Как описывать задачи, чтобы разработчики вас понимали (Гайд по INVEST)
В официальном Руководстве по Scrum (Scrum Guide 2020) нет термина “User Story”. Там используется понятие Product Backlog Item (Элемент Бэклога Продукта). Однако 95% Agile-команд в мире используют именно формат Пользовательских Историй.
Техники приоритизации: RICE и MoSCoW. Как выбрать, что делать в первую очередь
Одна из самых сложных задач Владельца Продукта (Product Owner) — сказать нет. В бэклоге всегда больше идей, чем команда физически может реализовать. Если пытаться сделать всё сразу, мы не сделаем ничего