29. Средняя скорость команды равнялась 17, но на шестом спринте снизилась до 13. Состав команды тот же. Вы Scrum-мастер. Как вы поступите?
a) Никак, в следующем спринте нагоним
б) Подниму этот вопрос на ретроспективе
в) Серьезно поговорю с командой
г) Пересчитаю скорость команды
30. Вы должны выполнить релиз к концу сезона, то есть через 4 спринта. Скорость вашей команда равняется 22. Выполнение технической работы позволит увеличить скорость на 3 и оценивается в 5 story points. Что делать?
a) Выполнить ее в следующем спринте
б) Выполнить ее в последнем спринте этого сезона
в) В этом сезоне ничего не делать
г) Зависит от разных факторов
31. Спринт начинается уже завтра, но готовых историй недостаточно. Что посоветуете делать?
a) Запустить спринт в любом случае
б) Помочь Владельцу продукта подготовить истории до завтра
в) Отложить начало спринта на несколько дней, чтобы Владелец продукта успел подготовить истории
г) Начать спринт без пользовательских историй и сосредоточиться на рефакторинге
32. Владелец продукта хочет добавить новую историю по ходу спринта. Что вы ему ответите?
a) Категорически откажусь
б) Запрошу премию
в) Соглашусь, у меня нет выбора
г) Соглашусь, но взамен мы исключим другую историю, работа над которой еще не была начата
33. Команда работает над несколькими проектами в параллели. Как следует поступить?
a) Для каждого проекта свой бэклог и свой Scrum-мастер
б) Для каждого проекта свой бэклог, Scrum-мастер один для всех
в) Один бэклог и один Scrum-мастер для всех
г) Не применять Scrum в данных условиях, команда не должна работать над несколькими проектами одновременно
34. Один из участников вашей команды сообщает, что задача, которую он начал два дня назад, еще не завершена. Он говорит, что, по идее, закончит ее завтра, но ничего не обещает.
a) Дождемся завтра и посмотрим, выполнил ли он задачу
б) Подробно расспросим, что ему осталось сделать
в) Потребуем от него, чтобы завтра задача была точно выпонена
г) Предложим ему работать с кем-то в паре
35. Представляемая на демо история функционирует и проходит все четыре теста, которые были для нее написаны, но вдруг обнаруживается тест, о котором команда даже не думала. Что делать?
a) Команда быстро исправляет код
б) История не может считаться завершенной
в) История считается завершенной, в бэклог добавляется новая запись
г) История считается завершенной на 80%
36. Общий тренинг по работе с инструментом управления проектами для отслеживания времени (timetracking) попадает на следующий спринт. Как следует поступить Scrum-команде?
a) Хорошо, команда пройдет тренинг, но добавит соответствующую историю в бэклог
б) Scrum-мастер против тренинга
в) Команда пользуется этой возможностью, чтобы остановить поток post-it
г) Команде не нужен тренинг по инструменту, который неприменим для работы в Scrum-фреймворке
37. Один из разработчиков считает, что диаграмма последовательности UML может помочь в понимании дизайна истории. Вы Scrum-мастер. Как вы поступите?
a) Откажу, пусть пишет код напрямую
б) Почему бы и нет, если ему так удобнее
в) Спрошу, что думает по этому поводу команда
г) Нет, у нас нет подходящего инструмента
38. Задача, начатая четыре дня назад, все еще не завершена. Вы Scrum-мастер. Как вы поступите?
a) Надавлю на разработчика, чтобы он завершил свою задачу
б) Завершу задачу самостоятельно
в) Совместно выявим препятствия
г) Отложим задачу на следующий спринт
39. Скорость команды в двух прошедших спринтах равнялась 13, затем 11. В конце планирования спринта команда говорит, что рассчитывает на 20 story points в спринте. Вы Владелец продукта. Что будете делать?
a) Увидев такое воодушевление команды, попробую добавить еще одну историю
б) Ничего, это ответственность команды
в) Спрошу, каким образом команда рассчитала такое увеличение скорости
г) Пообещаю им бутылку шампанского к концу спринта, если они справятся
40. Проект опирается на код весьма посредственного качества. Что делать?
a) В первую очередь сфокусироваться на улучшении кода
б) Не трогать код
в) Взяться за улучшение при выявлении ошибок в существующем коде
г) Добавить тесты ко всему существующему коду
Agility: способность организации приносить максимум ценности своим пользователям и адаптироваться к изменениям в своей среде.
Burndown-график (или диаграмма сгорания задач): график, показывающий динамику оставшихся задач.
Burnup-график: график, показывающий динамику завершенных задач относительно оставшихся.
Epic: термин, который применяется к элементу бэклога, чтобы указать на необходимость его разделения на части. Это история, которую команда считает слишком большой для реализации.
Impact mapping: техника стратегического планирования, основанная на создании карты разума. Соотносит работу команды разработчиков и ожидаемого воздействия.
Kanban: метод улучшения процесса, основанный на концепции ограничения.