Роман Сахаров "Зміна Scope спринту посередині розробки: хто винен і що робити?"
Зміна Scope спринту
посередині розробки: хто
винен і що робити?
Sakharov Roman @ E5
Давайте знайомитись ;)
Роман Сахаров
Lead Business Analyst & Resource
manager @ EPAM Systems
Certified Scrum Master, Trainer
Пройшов шлях від бізнес аналітика
до resource менеджера, успішно
впроваджую процеси і проводжу
тренінги в EPAM Systems по
гнучкими методологіями розробки
та бізнес аналізу. Створюю власні
тренінги.
Ситуація…
- У мене нова геніальна
фіча, давай робити!
…
- Що?.. Середина
спринту? Ну і що, фіча
ж мега-важлива! Робіть
ВЖЕ!
А що, власне, відбувається?
Product Owner хоче додати в sprint
нові user stories
Розробник під час роботи розуміє,
що user story більше, ніж думали
спочатку
Тестувальники під час тестування /
написання тест кейсів розуміють,
що у user story потрібно зробити
більше, ніж вважали розробники
Чому?
Нові ідеї, які здаються
Product Owner терміновими
(або такими і є)
PO не розуміє / йому все
одно, що sprint scope не
можна змінювати
Мітинг PO з бізнесом після
вашого sprint planning та
затвердження їм sprint scope
Що робити?
1. З'ясовуємо чому РО хоче
додати нові Stories
2. Пояснюємо наслідки для Sprint-у
3. Кажемо «Ні» (без фанатизму)
4. Пропонуємо варіанти вирішення:
1. Зробити це в наступному sprint
2. Прибрати щось на замін
3. Граємося з класикою проектного
менеджменту ;)
Resources
Quality
Scope
Як попередити?
Навчаємо Product Owner Agile,
Scrum
Задіюємо PO в плануванні (робимо
частиною команди)
Показуємо втрати компанії в у.о.
внаслідок таких дій
Створюємо і оновлюємо план релізів
з розбивкою на спринти, зі всіма
зацікавленими
Робимо PBR до того як бізнес / РО
затвердили sprint scope
Чому?
Розробник не вникав в
суть історії під час
планування / PBR
Технічна складність
виявилась вищою при
розробці
PO не надав всю
інформацію спочатку і
не відповів на
уточнюючі питання
Що робити?
1. Оцінюємо об’єм змін
2. Вам пощастило і ви
встигаєте (happy end)
3. Вам не пощастило… ідемо
до РО з варіантами рішень:
1. Виділити це в окрему
історію
2. І знову цей трикутник ;)
Resources
Quality
Scope
Як попередити?
Мотивуємо розробників читати
історії перед PBR
Домовляємося з РО про
виділення часу на дослідження
Пишемо recaps & follow-ups на
PBR та додаємо питання в
конкретні історії
Не беремо історію без всієї
інформації, використовуємо
definition of ready для story
Проводимо дворівневе
планування
Чому?
Тестувальники не
залучені в планування /
PBR / естімацію
Тестувальники
неправильно оцінили
обсяг роботи
Нові деталі внаслідок
кращого розуміння
продукту
Що робити?
Загалом те ж що і у випадку
розробника…
1.Оцінюємо об’єм змін
2.Вам пощастило і ви
встигаєте (happy end)
3.Вам не пощастило… ідемо
до РО з варіантами рішень:
1. Виділити це в окрему
історію
2. Знову цей трикутник;)
Як попередити?
Мотивуємо тестувальників
читати історії перед PBR
Додаємо в definition of story
ready затвердження її
тестувальниками
Оцінка історії
тестувальниками - must have
Пишемо тест кейси на
початку спринту
Обговорюємо тест кейси з
розробниками
1. Всі відповіді надані
2. Деталі реалізації готові
(wireframes, mockups,
scenarios)
3. Пріоритети виставлені
4. Чітке розуміння
1. Дрібні уточнення
2. Проблеми?
1. Розуміння спринту
scope наступного
2. Оформлення доопрацювань
PBR – Product Backlog
Refinement
1.Вичитка
2.Запитання
3.Попередня оцінка
4.Попередній вибір команди