Ответ
Sprint Backlog — это набор элементов Product Backlog, отобранных командой разработки для выполнения в рамках текущего спринта. Он представляет собой план работы и обязательство команды.
Содержание Sprint Backlog:
- User Stories (пользовательские истории).
- Технические задачи (рефакторинг, настройка инфраструктуры).
- Баги, которые необходимо исправить.
- Задачи декомпозированные на небольшие, выполнимые части (часто в формате "задача на 1 день").
Пример содержимого:
Sprint Goal: Реализовать вход пользователя через OAuth
Задачи:
- [ ] #US-101: Добавить кнопку "Войти через Google" на страницу логина (5 story points)
- [ ] #TECH-45: Интегрировать библиотеку OAuth2-client (3 story points)
- [ ] #BUG-22: Исправить ошибку валидации email на мобильных устройствах (2 story points)
- [ ] #US-101: Написать E2E-тесты для сценария OAuth (3 story points)Ключевые принципы:
- Формируется на событии Sprint Planning всей командой (Developers, Product Owner, Scrum Master).
- Принадлежит команде разработки, которая сама решает, как выполнить отобранные элементы.
- Может уточняться в течение спринта по мере появления новой информации, но цель спринта (Sprint Goal) неизменна.
- Прогресс отслеживается на Daily Scrum, часто с помощью Burndown Chart.
Ответ 18+ 🔞
Давай разжую эту сухую теорию про спринт бэклог, а то читаешь — и волосы дыбом, как от инструкции к сборке шведской стенки, блядь.
Представь, что спринт — это твой рабочий месяц, а спринт бэклог — это твой план на этот месяц, который ты наконец-то выбил из начальства. Только план этот не на бумажке «сделать всё», а на реальные, осязаемые куски работы.
Спринт бэклог — это, по сути, список дел, на которые команда, ёпта, реально подписалась в этом спринте. Это не «хотелки» продакта (это был проджект бэклог), а конкретный план действий, за который команда готова порвать жопу. Это их обязательство, блядь.
Что там внутри валяется, в этом списке?
- Юзер сторисы — те самые «как пользователь, я хочу…», которые мы будем пилить.
- Технические задачи — всякая подводная хуйня: «поднять сервер», «переписать этот говнокод», «обновить библиотеки».
- Баги — те самые тараканы, которые уже достали всех, и их надо прихлопнуть.
- Задачи, раздробленные в пыль — большие истории разбиты на такие куски, чтобы за день можно было сделать и не сойти с ума.
Вот, смотри, как это выглядит в жизни, а не в учебнике:
Цель спринта (Sprint Goal): Сделать вход через Гугл, чтобы народ не парился с паролями.
Задачи:
- [ ] #US-101: Прилепить кнопку «Войти через Гугл» на форму логина (5 стори поинтов)
- [ ] #TECH-45: Впендюрить в проект библиотеку для OAuth (3 стори поинта)
- [ ] #BUG-22: Починить баг, когда на телефоне email с собачкой не проходил (2 стори поинта)
- [ ] #US-101: Написать сквозные тесты, чтобы эта кнопка потом не отвалилась (3 стори поинта)А теперь главные правила, без которых всё это — просто пиздеж:
- Рождается он на планировании спринта (Sprint Planning). Весь коллектив — разработчики, продакт, скрам-мастер — садятся и решают: «Ну что, пацаны, на что у нас хватит сил в эти две недели?». Это не тиран-продакт диктует, а команда сама оценивает и говорит, что возьмёт.
- Это священная собственность команды разработчиков. Они его сформировали — они за него и отвечают. Как именно делать — их дело. Менеджеру лезть со своими «давайте быстрее» — только волнение ебать.
- Его можно и нужно править по ходу дела. Жизнь-то меняется: выяснилось, что задача — овердохуища, или нашли новый баг. Задачи можно перетасовать, НО! Главная цель спринта (Sprint Goal) — это неприкосновенная священная корова. Её менять низя. Иначе зачем вообще планировали?
- Прогресс смотрят каждое утро на летучке (Daily Scrum). Часто ещё рисуют график сгорания задач (Burndown Chart), чтобы видно было: отстаём мы или, мать его, всё по плану. Если график ползёт вверх — это пидарас шерстяной, значит, задач прибавилось, а не сделалось.