Daily Scrum
- Винаги по едно и също време, максимум 15 минути
Провежда се всеки ден.
Standing meeting – идеята е да е бърза и ефективна.
- Само Development Team говори
Scrum Master и PO могат да присъстват, но:
Scrum Master не води срещата.
Product Owner не дава задачи.
Development Team сами се организират.
- Какво се обсъжда (3-те класически въпроса)
Всеки отговаря:
Какво направих вчера, което ни помага да постигнем Sprint Goal?
Какво ще правя днес?
Има ли някакви пречки/блокери?
Важно: обсъждането е около Sprint Goal, а не просто статус доклад.
- Може да има допълнителни дейности
Някои екипи (по Agile guide) правят:
обновяване на борда
пренареждане на приоритети
уточняване кой с кого ще работи
Но това е след и извън 15-те мин.
Какво НЕ е Daily Scrum
НЕ е отчет към Scrum Master или PO
НЕ е място да защитаваме защо нещо е закъсняло
НЕ е дълго техническо обсъждане (то се прави след срещата с нужните хора)
Основната цел:
Daily Scrum не е просто разговор. То е:
Инспекция + адаптация на плана за следващите 24 часа.
Тоест екипът си отговаря на въпроса:
„Оставаме ли на път към Sprint Goal? Ако не – какво променяме?“
Примери как звучи добре:
„Взимам task X, завършвам API-то. Имам dependency от DB team – ще го уточним след срещата.“ „Блокиран съм на Deploy. Трябва помощ от DevOps.“ „С Wendy ще pair-нем тестовете днес.“
Пример как звучи лошо:
„Вчера имаше много срещи, затова не направих нищо. Днес ще видя какво има.“
| Най-важното в Daily Scrum | Описание |
|---|---|
| Кратко | Срещата е максимум 15 минути. |
| По същество | Обсъждат се само неща, които влияят на спринта. |
| Фокус върху Sprint Goal | Целта е да се синхронизира прогресът към Sprint Goal. |
| Development Team говори | Екипът сам се организира и планира. |
| Завършва с план за днес | След срещата се знае кой какво ще прави. |
Sprint Review
Sprint Review е едно от основните Scrum събития и се провежда в края на спринта, за да се оцени какво е постигнато и да се съберат обратна връзка и идеи за следващи итерации.
Sprint Review е инспекция и адаптация на продукта, а не на екипа или процеса. Целта е:
да се демонстрира завършената работа (Done increment)
да се събере feedback от stakeholder-и
да се актуализира Product Backlog-а
да се обсъдят следващите стъпки
Не е просто „демо“, а колаборативна работна среща.
Как протича Sprint Review 1) Product Owner дава контекст
Каква беше Sprint Goal
Какво от него е изпълнено и какво – не
Ако има недовършени задачи: какво е причината и какво се прави с тях
2) Development Team демонстрира работещия продукт
Показват се само неща, които са Done според Definition of Done
В реална среда, не screenshot-и
Целта: да покажат стойността за клиента
3) Демонстрацията е интерактивна
Въпроси от stakeholder-и
Дискусия за резултатите
Обратна връзка
Идеи, предложения, рискове
4) Product Owner обновява Product Backlog
Заедно с участниците се обсъжда:
какво следва
приоритети
какво да се промени на базата на feedback-а
нови User Stories, корекции на стари
5) Преглеждат се:
текущото състояние на продукта
време до release
ROI, бизнес стойност
метрики (ако има)
6) Закриване
резултатът е обновен Product Backlog
по-ясна визия за следващия спринт
яснота за следващи цели
Кой участва?
Product Owner
Scrum Master
Development Team
Stakeholders (клиенти, бизнес, QA, дизайнери…)
Продължителност:
За 2-седмичен спринт: до 2 часа За 1-седмичен: около 1 час
Какво не е Sprint Review
Не е:
отчет за производителността на екипа
PowerPoint демо без реална работа
място за оценки на хора
Основна цел в едно изречение:
Sprint Review има за цел да се валидира посоката на продукта чрез показване на работещи резултати и събиране на feedback.
Retrospective
“Weather” (понякога наричана и “Team Weather Report”) е кратка, забавна и много лесна ретроспективна игра, често използвана в Scrum/Agile екипи. Понякога се среща под името Screama Retro Meeting – Weather, но идеята е същата.
Целта е:
Да се „улови“ емоционалното състояние на екипа.
Да се разбере как хората са възприели последния спринт / седмица.
Да се създаде безопасно пространство за откровен разговор.
Да се даде бърз, визуален сигнал на Scrum Master/мениджър кои теми изискват внимание.
- Подготвят се „метеорологични“ категории, например:
☀️ Слънчево – всичко беше супер, работеше се гладко.
⛅ Разкъсана облачност – имаше малки проблеми, но като цяло бе добре.
☁️ Облачно – трудности през повечето време.
🌧️ Дъждовно – много проблеми, работеше се тежко.
⛈️ Буря – сериозни блокери, конфликти или хаос.
Всеки член на екипа избира „времето“, което описва неговия спринт
Без обяснения в началото — само избор на икона.
Може да се използват sticky notes, онлайн борд (Miro, Mural, Jira Whiteboard), чат емотикони и др.
След това се минава към дискусия
Всеки кратко обяснява защо е избрал това „време“.
Scrum Master или фасилитаторът може да зададе:
Какво доведе до това време?
Какво бихме променили?
Кое може да стане по-слънчево следващия спринт?
Извличат се изводи и действия
Идентифицират се общи проблеми.
Формират се action items за подобрение.
Проверява се дали има разминаване между членовете (например половината са „слънчево“, друга половина – „буря“).