Читаем Все о SCRUM. Изучение, разработка, интеграция полностью

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) В первую очередь сфокусироваться на улучшении кода

б) Не трогать код

в) Взяться за улучшение при выявлении ошибок в существующем коде

г) Добавить тесты ко всему существующему коду

<p>Глоссарий</p>

Agility: способность организации приносить максимум ценности своим пользователям и адаптироваться к изменениям в своей среде.

Burndown-график (или диаграмма сгорания задач): график, показывающий динамику оставшихся задач.

Burnup-график: график, показывающий динамику завершенных задач относительно оставшихся.

Epic: термин, который применяется к элементу бэклога, чтобы указать на необходимость его разделения на части. Это история, которую команда считает слишком большой для реализации.

Impact mapping: техника стратегического планирования, основанная на создании карты разума. Соотносит работу команды разработчиков и ожидаемого воздействия.

Kanban: метод улучшения процесса, основанный на концепции ограничения.

Перейти на страницу:

Все книги серии Библиотека цифровой трансформации

Менеджмент цифрового продукта. От идеи до идеала
Менеджмент цифрового продукта. От идеи до идеала

Цифровизация меняет потребительские услуги и промышленные процессы, проникая во все аспекты нашей жизни, а информационно-технологические компании становятся лидерами в своих отраслях. Традиционные отрасли также включаются в цифровую трансформацию, разрабатывая программное обеспечение для собственных нужд. Успех в этой среде требует управления жизненным циклом цифровых продуктов в условиях быстро меняющегося рынка, конкуренции и постоянного развития. Как управлять такими проектами знает Ярослав Шуваев, эксперт по корпоративным инновациям с более чем 10-летним опытом преподавания UX/UI-дизайна и продакт-менеджмента, основатель shuvaev.com.Независимо от того, в какой точке карьеры вы находитесь, «Менеджмент цифрового продукта» предоставит вам ценные знания и инструменты для успешной адаптации и роста в эпоху инноваций.Из этой книги вы узнаете:• что такое цифровой сервис и как его монетизировать;• какой продукт можно считать жизнеспособным;• какие циклы проходит проект и что делать на каждом этапе;• что нужно для масштабирования работы;• зачем создавать антихрупкую ИТ-компанию.Если вы владеете компанией и планируете внедрить цифровые технологии для улучшения бизнес-процессов, эта книга поможет понять, какие стратегии стоит применять. Она будет полезна и основателям стартапов в фазе кратного роста, и менеджерам продукта, стремящимся повысить свою эффективность, а также архитекторам, дизайнерам, разработчикам, аналитикам и другим участникам процесса создания цифровых продуктов.В формате PDF A4 сохранен издательский макет книги.

Ярослав Александрович Шуваев

Маркетинг, PR
UX/UI дизайн для создания идеального продукта. Полный и исчерпывающий гид
UX/UI дизайн для создания идеального продукта. Полный и исчерпывающий гид

Успех любого цифрового продукта складывается из многих факторов. Ваш продукт может быть уникальным и востребованным, но без проработанного UX ему не суждено заслужить лояльность клиента. Эта простая истина прекрасно известна Ярославу Шуваеву, основателю школы UXAcademy и руководителю крупных digital-проектов для российских и западных компаний, среди которых Администрация Президента, Внешэкономбанк, Coca-Cola, «Газпром», «Татнефть», «Башнефть», Bosco, QIWI, STADA и многие другие.«Моя главная цель – описать факты через призму личного опыта и конкретные жизненные примеры», – пишет Ярослав. Его книга – авторский подход к дизайну, выработанный годами плодотворной работы. Вы сделаете пользовательский опыт лучше, побуждая клиентов возвращаться к вашему продукту снова и снова.

Ярослав Александрович Шуваев

Программирование, программы, базы данных / Учебные пособия, самоучители / Справочники
Нет соединения с сервером, попробуйте зайти чуть позже