Ответ
Основное событие — Планирование спринта (Sprint Planning). Его цель — сформировать план работы на предстоящий спринт.
Два основных вопроса, на которые отвечает команда:
-
Что может быть сделано в этом спринте?
- Владелец продукта (Product Owner) представляет приоритетные элементы бэклога и цель спринта (Sprint Goal).
- Команда разработки анализирует элементы, задает уточняющие вопросы.
-
Как будет сделано выбранное?
- Команда разбивает выбранные пользовательские истории на конкретные технические задачи.
- Происходит оценка усилий (например, в story points или часах) с учетом своей пропускной способности (capacity).
Результат планирования:
- Четко сформулированная Цель спринта (Sprint Goal).
- Бэклог спринта (Sprint Backlog) — список задач, которые команда берет в работу.
- План по достижению цели — обычно в виде набора задач на доске (Kanban, Scrum board).
Пример Sprint Backlog:
Цель: Реализовать авторизацию через OAuth 2.0 от Google.
Задачи:
- [ ] Интегрировать SDK Google OAuth (8h)
- [ ] Создать endpoint для callback (5h)
- [ ] Настроить хранение токенов (3h)
- [ ] Протестировать сценарии входа/выхода (4h)
- [ ] Обновить документацию (2h)После планирования начинается непосредственно работа над задачами спринта.
Ответ 18+ 🔞
А, ну вот, подъехали к самому сокровенному — Планированию Спринта (Sprint Planning). Это когда вся ватага собирается и пытается ответить на два главных вопроса, от которых потом вся жизнь пойдёт, либо в пизду, либо в рай.
Вопрос первый, ёпта: "Что, блядь, мы успеем за эту неделю/две?" Тут выходит наш главный по желаниям — Владелец Продукта (Product Owner). Он такой: "Ребята, слушайте сюда, вот это — овердохуища важная фича, а вот это — просто пиздец как нужно, а вот это... ну, в общем, тоже неплохо бы". И кидает нам кучу историй из бэклога. А мы, команда разработки, сидим и думаем: "Э, сабака, сука... А что это за кнопка 'сделать всё хорошо'? А где тут ТЗ, блядь?" Вопросы задаём, уточняем, пока не станет хоть немного понятно.
Вопрос второй, уже посерьёзнее: "А КАК, мать вашу, мы это будем делать?" Вот тут начинается магия, или цирк, смотря как повезёт. Берём эти красивые истории от владельца и начинаем их рвать на куски, как ту самую собаку Муму, блядь. "Реализовать авторизацию" — это не задача, это пиздёж. Задача — это "интегрировать SDK", "создать endpoint", "настроить хранилище". Разложили по полочкам. Потом начинаем гадать на кофейной гуще — сколько это займёт. "Э, бошка, думай! Восемь часов? Да ты, мудак, там на одну настройку среды неделю потратишь!" Оцениваем, спорим, смотрим, сколько у нас вообще человеко-часов в запасе.
И что на выходе-то получается, спросите вы? А получается намётанный план, а не просто "пойдём туда, не знаю куда".
- Цель Спринта (Sprint Goal) — одна фраза, ради которой всё и затевается. Не "сделать кучу всего", а, например, "дать пользователям возможность заходить через гугл, чтобы не париться с паролями".
- Бэклог Спринта (Sprint Backlog) — это уже наш, внутренний, расчленённый и понятный список дел. Не "сделать авторизацию", а конкретные технические шаги.
- План на доске — все эти задачи раскидываем по колонкам "To Do", "In Progress", "Done". Чтобы было видно, кто где встрял.
Вот, смотри, как это выглядит вживую:
Цель: Реализовать авторизацию через OAuth 2.0 от Google, чтобы народ не матерился, вспоминая пароль.
Задачи:
- [ ] Прикрутить SDK от Google (8h) <-- вот тут обычно и выясняется, что документация у них написана через жопу
- [ ] Сделать endpoint для callback (5h)
- [ ] Настроить, куда складывать токены (3h)
- [ ] Протестировать: зашёл, вышел, а хули не работает? (4h)
- [ ] Обновить документацию, чтобы следующие такие же мудаки не страдали (2h)Вот, нарисовали этот план, все такие довольные, разошлись. А на следующий день начинается самое интересное — работа. И выясняется, что тот, кто оценивал задачу в 3 часа, просто забыл, что у нас база данных на хуй сломана ещё с прошлого спринта. Но это уже совсем другая история, блядь.