Scrum - продвинутый уровень, тестирование навыков hh.ru
Основными ролями в Scrum являются владелец продукта (Product Owner), Scrum-мастер(Scrum Master) и команда разработчиков(Development Team). Scrum фокусируется на ценности, взаимодействии и быстрых итерациях, что позволяет легко адаптировать проект в процессе работы и обеспечивать высокое качество продукта.
В этом контексте, для продвинутых пользователей важно понимать следующие ключевые аспекты:
- Управление Scrum-командами — эффективное распределение ролей и ответственности для обеспечения сотрудничества и достижения целей.
- Масштабирование Scrum — адаптация Scrum в больших проектах, где участвует несколько команд.
- Scrum of Scrums — метод для координации работы нескольких Scrum-команд, работающих над одним проектом.
- Nexus — фреймворк для масштабирования Scrum, который помогает управлять множеством команд, сохраняя общую цель и взаимодействие.
- LeSS (Large Scale Scrum)— расширение Scrum для больших организаций, где несколько команд работают по Scrum, но управляются единым бэклогом продукта и владельцем продукта.
Тестирование на "Scrum - продвинутый уровень" поможет вам оценить знания этих подходов и правильно применять их в сложных проектах.
Данный материал подготовлен исключительно в образовательных целях и предназначен для изучения и подготовки к профессиональному развитию. Обратите внимание, что материалы и тесты на платформе hh.ru могут периодически обновляться, чтобы отражать текущие тенденции и требования рынка.
Вопрос 1:
Какая из ситуаций иллюстрирует принципы распределения ответственности и полномочий в команде, характерные для Scrum?
Варианты ответа:
- При постановке задач Scrum-мастер (Scrum-мастер) отслеживает, что количество задач между членами команды распределено равномерно
- В команде выделяется самостоятельная подкоманда (юнит), ответственная за мобильную разработку сервисов
- Решение о найме новых разработчиков принимает владелец продукта (Product Owner) исходя из бюджета команды
- За готовность инкремента (Increment) к концу спринта назначают ответственным опытного в этой области разработчика
- Для принятия решений по реализации функции разработчики общаются с заинтересованными лицами (stakeholders) напрямую
Обоснование:
Этот вариант соответствует принципам Scrum, так как он подчеркивает самоорганизацию команды и прямую ответственность разработчиков за взаимодействие с заинтересованными сторонами для уточнения требований. В Scrum команда разработки является кросс-функциональной и автономной, что позволяет ей самостоятельно принимать решения, необходимые для достижения целей спринта.
Правильный ответ:
5. Для принятия решений по реализации функции разработчики общаются с заинтересованными лицами (stakeholders) напрямую
Вопрос 2:
В основе Scrum-методологии лежат итеративный и инкрементальный подходы. Какое из утверждений о преимуществе этих подходов НЕВЕРНО?
Варианты ответа:
- Итеративный подход позволяет команде быстро реагировать на изменения тенденций рынка
- В итеративном подходе просто управлять версиями и изменениями в продукте
- Инкрементальный подход позволяет быстро проверять гипотезы о продукте
- В инкрементальном подходе наиболее важные функции выпускаются уже на ранних этапах разработки продукта
- Инкрементальный подход обеспечивает представление о состоянии разработки продукта для заинтересованных лиц
Обоснование:
Это утверждение некорректно, так как управление версиями и изменениями может быть сложным в итеративном подходе, особенно если процессы не организованы должным образом. Итерации часто вносят изменения в предыдущие версии, что требует четкого контроля версий, чтобы избежать путаницы и несоответствий.
Правильный ответ:
2. В итеративном подходе просто управлять версиями и изменениями в продукте
Вопрос 3:
Вы управляете командой, которая создает контент для платформы с онлайн-тренировками. Ваша текущая продуктовая цель — повысить среднюю продолжительность платной подписки пользователя на сервис.
Ваш Scrum-мастер организовал встречу для приоритизации бэклога продукта, поскольку считает процессы в команде неэффективными. С точки зрения Scrum, какая из задач в бэклоге продукта является наиболее приоритетной?
- Создать подкаст о пользе спорта на сторонней площадке.
- Создать бесплатный онлайн-курс по фитнесу для начинающих.
- Оптимизировать рабочий процесс для сокращения времени создания новых материалов.
- Создать детальный контент-план по выпуску ближайших программ тренировок.
- Повысить разнообразие предлагаемых типов тренировок.
Обоснование:
Эта задача наиболее соответствует текущей продуктовой цели — повышению средней продолжительности платной подписки пользователя на сервис. Разнообразие тренировок увеличивает ценность платформы для пользователей, мотивирует их оставаться дольше и снижает вероятность отказа от подписки.
Остальные задачи, хотя и полезны, либо не связаны напрямую с целью, либо имеют меньший приоритет:
Создание подкаста или бесплатного курса привлекает новых пользователей, но не удерживает текущих.
Оптимизация рабочих процессов и создание контент-плана касаются внутренних процессов команды, а не пользовательской ценности.
Правильный ответ:
5. Повысить разнообразие предлагаемых типов тренировок.
Вопрос 4:
Ваша команда разрабатывает функцию поиска предметов одежды по их цвету для онлайн-магазина. Вы приближаетесь к концу спринта, но не успеваете протестировать новую функцию на всех устройствах.
Каким образом, с точки зрения Scrum, будет НАИМЕНЕЕ предпочтительно действовать в этом спринте, чтобы исправить эту ситуацию?
Варианты ответов:
- Увеличить продолжительность спринта, чтобы успеть провести тестирование.
- Определить наиболее важные устройства для тестирования и протестировать только их.
- Привлечь к тестированию пользователей продукта.
- Использовать инструменты автоматизированного тестирования, потратив часть бюджета следующего спринта.
- Перераспределить задачу по тестированию между участниками команды.
Обоснование:
Scrum-фреймворк предусматривает четкое соблюдение временных рамок спринтов. Спринт имеет фиксированную продолжительность, и ее изменение подрывает один из ключевых принципов методологии — предсказуемость и ритм работы. Вместо этого команда должна адаптировать свои действия внутри текущего спринта или перенести оставшиеся задачи в следующий спринт, если они не успевают. Увеличение длительности спринта нарушает процесс планирования и мешает установленному рабочему циклу.
Правильный ответ:
Увеличить продолжительность спринта, чтобы успеть провести тестирование.
Вопрос 5:
Перед вами — диаграмма сгорания задач наоборот (burnup chart) по одному проекту. Какой из выводов о работе команды за этот период соответствует этому графику?
Варианты ответов:
- На протяжении всего периода работы команда выполняла задачи быстрее, чем ожидалось.
- К концу проекта команда сократила объем запланированной работы, чтобы закончить проект в срок.
- После третьего спринта команда стала работать больше часов.
- В середине периода в команду пригласили дополнительных сотрудников, чтобы ускорить процессы.
- Команда задержала срок сдачи проекта.
Обоснование:
Если на графике видно, что линия "Запланировано" снижается к концу периода, это указывает на то, что объем работы был сокращен, чтобы успеть завершить проект в установленные сроки. Такой подход применяется, когда изначально запланированный объем оказывается слишком большим для выполнения.
Правильный ответ:
К концу проекта команда сократила объем запланированной работы, чтобы закончить проект в срок.
Вопрос 6:
Вы хотите совмещать Kanban и Scrum в управлении командой. Какое из утверждений о сходстве подходов Scrum и Kanban ОШИБОЧНО?
Варианты ответов:
- И Scrum, и Kanban основаны на итеративном и инкрементальном подходах.
- И Scrum, и Kanban предполагают организацию ежедневных коротких командных встреч.
- И Scrum, и Kanban предполагают создание бэклога задач на весь спринт перед началом этого спринта.
- И в Scrum, и в Kanban применяются различные способы оценки и прогнозирования сроков выполнения задач.
- И Scrum, и Kanban поддерживают гибкое планирование задач и расстановку приоритетов.
Обоснование:
Это утверждение неверно, так как только Scrum предполагает планирование задач на весь спринт перед его началом. В Kanban задачи добавляются на доску по мере необходимости, и бэклог формируется динамически, без фиксированного временного ограничения, такого как спринт.
Kanban фокусируется на постоянном потоке задач и управлении ограничениями (Work In Progress, WIP), в то время как Scrum использует временные итерации (спринты) с заранее определенным объемом работы.
Правильный ответ:
И Scrum, и Kanban предполагают создание бэклога задач на весь спринт перед началом этого спринта.
Вопрос 7:
Вас пригласили помочь команде по созданию функционала сообществ внутри крупной социальной сети. В команде работает 15 разработчиков и менеджеров. Команда сталкивается с систематической проблемой задержки выпуска новых инкрементов, поскольку многие задачи зависят от работы, которую выполняют внешние команды платформы и баз данных, и они регулярно задерживаются. Вы предложили команде внедрение фреймворка Nexus для решения этой проблемы.
С точки зрения фреймворка Nexus, какой способ разрешить эту проблему будет наиболее подходящим?
Варианты ответов:
- Визуализировать все этапы разработки в компании с помощью потока создания ценности (Value Streams), чтобы оптимизировать их.
- Проанализировать продуктовый бэклог (Product Backlog) команды платформы и баз данных, чтобы повысить приоритет задач, связанных с функционалом сообществ.
- Пригласить внешних подрядчиков заниматься задачами, которые не успевают выполнить команды платформы и баз данных.
- Объединить команду функционала сообществ с командами платформы и баз данных.
- Создать в компании интеграционную команду (Integration Team), которая идентифицирует зависимости между задачами и поможет управлять ими.
Обоснование:
- Фреймворк Nexus специально разработан для управления несколькими командами, работающими над одним продуктом, с акцентом на управление зависимостями и интеграцией. Создание интеграционной команды (Integration Team) — это ключевой элемент Nexus. Эта команда:
- Обеспечивает прозрачность всех зависимостей между командами.
- Устраняет или минимизирует задержки, связанные с ожиданием работы других команд.
- Облегчает координацию задач и своевременную интеграцию инкрементов.
- Таким образом, именно этот подход наиболее эффективно адресует вашу проблему. Другие варианты либо не устраняют зависимость, либо сложно реализуемы в контексте существующих процессов и специализаций команд.
Правильный ответ:
Создать в компании интеграционную команду (Integration Team), которая идентифицирует зависимости между задачами и поможет управлять ими.
Вопрос 8:
Вы работаете в Scrum-команде, которая занимается продвижением продукции и бренда производителя здорового питания в социальных сетях. Соотнесите каждую проблему с методикой, внедрение которой поможет разрешить возникшую проблему.
Проблемы:
- A — Команда не поняла, какие изменения в брендинге компании ожидают руководители.
- B — Команда не может оценить объем работы, связанной с запуском кулинарного YouTube-канала для продвижения продукции.
- C — Команда не ощущает улучшений в рабочих процессах после привычных ретроспектив спринтов.
Варианты методик:
- Ежедневные стендапы (Daily Scrum)
- Покер планирования(Planning Poker)
- Ревью спринта (Sprint Review)
- Ретроспектива Морская Звезда (Starfish Retrospective)
Обоснование:
- A (Команда не поняла, какие изменения в брендинге компании ожидают руководители) - 3 (Ревю спринта):Ревю спринта — это событие, на котором демонстрируются результаты работы команды заинтересованным сторонам. Во время ревю можно уточнить ожидания руководителей и внести необходимые изменения в последующих спринтах.
- B (Команда не может оценить объем работы, связанной с запуском кулинарного YouTube-канала) - 2 (Покер планирования): Покер планирования — это техника для оценки задач. Она позволяет всей команде обсуждать объем работы, связанный с запуском нового проекта, и прийти к консенсусу по оценке.
- C (Команда не ощущает улучшений в рабочих процессах после привычных ретроспектив спринтов) - 4 (Ретроспектива Морская Звезда): Ретроспектива "Морская Звезда" помогает глубже анализировать рабочие процессы, рассматривая пять аспектов: что продолжать делать, что начать делать, что прекратить, что усилить и что уменьшить. Этот метод может улучшить качество ретроспектив и помочь команде выявить конкретные действия для изменений.
Правильный ответ:
A — 3, B — 2, C — 4
Вопрос 9:
В этом спринте вы с командой создаете новый игровой уровень для вашей видеоигры. Дизайнер уровней считает эту задачу несложной, поскольку, по его мнению, она требует только создания новых игровых объектов. В то же время опытный разработчик с большим игровым опытом считает, что разработка такого уровня потребует полного пересмотра баланса игровой сложности.
С точки зрения Scrum, какой из способов разрешения этой ситуации наиболее эффективен?
Варианты ответов:
- Использовать покер планирования (Scrum Poker) для определения компромиссной оценки сложности задачи всей командой.
- Оценить сложность задачи в сторипоинтах (Story Points) на основе статистики предыдущих задач.
- Встать на сторону разработчика, поскольку он имеет больше игрового опыта и опыта разработки.
- Встать на сторону дизайнера уровней, поскольку он отвечает за разработку игровых уровней.
- Посоветоваться с заинтересованными сторонами для получения дополнительной экспертной оценки сложности задачи.
Обоснование:
Покер планирования — это эффективный инструмент Scrum для оценки сложности задачи. Он позволяет каждому члену команды высказать свое мнение, обсудить разные точки зрения и прийти к общему пониманию сложности.
Дизайнер и разработчик смогут аргументировать свои позиции.
Команда совместно примет решение, учитывая все аспекты задачи.
Такой подход способствует прозрачности и взаимопониманию, что важно для работы в Scrum.
Другие варианты менее предпочтительны:
- Оценка на основе статистики:может быть неточной, если задача имеет уникальные особенности.
- Сторона разработчика или дизайнера:игнорирует коллективное обсуждение и может вызвать недовольство в команде.
- Дополнительная экспертная оценка:затягивает процесс и выходит за рамки принципов самоорганизации команды.
Правильный ответ:
Использовать покер планирования (Scrum Poker) для определения компромиссной оценки сложности задачи всей командой.
Вопрос 10:
Ваша команда разрабатывает социальную сеть для делового нетворкинга. Сейчас вы анализируете возможные риски. Соотнесите проблему, с которой может столкнуться команда, и метрику производительности команды, отслеживание которой позволит избежать этой проблемы.
A — Задержка выполнения задачи по разработке прототипа интерфейса вследствие непонятных требований.
B — Перегрузка команды, разрабатывающей модели машинного обучения, во время реализации функции поиска.
C — Перегруженность команды задачами в последнем спринте перед большим релизом.
- Диаграмма сгорания работ (Burndown Chart)
- Время цикла (Cycle Time)
- Распределение рабочей нагрузки (Workload Distribution)
Варианты ответов:
Обоснование:
- A (Задержка выполнения задачи по разработке прототипа интерфейса вследствие непонятных требований) - 2 (Время цикла): Отслеживание времени цикла (Cycle Time) позволяет выявить, какие задачи занимают больше времени, чем ожидалось. Это может помочь команде понять, что причиной задержки являются нечеткие требования, и вовремя их уточнить.
- B (Перегрузка команды, разрабатывающей модели машинного обучения, во время реализации функции поиска) - 3 (Распределение рабочей нагрузки): Распределение рабочей нагрузки (Workload Distribution) помогает оценить равномерность распределения задач внутри команды. Это позволяет избежать перегрузки отдельных специалистов.
- C (Перегруженность команды задачами в последнем спринте перед большим релизом) - 1 (Диаграмма сгорания работ):Диаграмма сгорания (Burndown Chart) показывает общий прогресс выполнения задач. Если в начале спринта остается слишком много работы, это сигнализирует о необходимости перераспределения задач, чтобы избежать перегрузки в конце.
Правильный ответ:
A — 2, B — 3, C — 1
Вопрос 11:
Ниже — три задачи по управлению рисками проекта в Scrum-команде и три принципа Scrum-подхода. Соотнесите каждую задачу с принципом, который наиболее ее характеризует.
Задачи:
A — На каждой ретроспективе команда обсуждает, какие непредвиденные риски оказали наибольшее влияние на выполнение задач.
B — Владелец продукта поддерживает актуальность бэклога продукта, в котором отражены возможные глобальные и рыночные риски.
C — Scrum-мастер ежемесячно обновляет риск-матрицу проекта, чтобы идентифицировать новые риски и оценить их влияние на достижение целей.
Варианты ответов:
Обоснование:
- A (На каждой ретроспективе команда обсуждает, какие непредвиденные риски оказали наибольшее влияние на выполнение задач) - 2 (Принцип инспекции): Принцип инспекции предполагает регулярное обсуждение и анализ текущей ситуации, чтобы выявлять проблемы и возможности для улучшения. Ретроспектива как раз направлена на инспекцию прошедшего спринта и его рисков.
- B (Владелец продукта поддерживает актуальность бэклога продукта, в котором отражены возможные глобальные и рыночные риски) - 3 (Принцип эмпирического контроля процесса):Принцип эмпирического контроля процесса базируется на актуальной информации и непрерывном обновлении данных. В данном случае владелец продукта управляет бэклогом, основываясь на новых данных о возможных рисках.
- C (Scrum-мастер ежемесячно обновляет риск-матрицу проекта, чтобы идентифицировать новые риски и оценить их влияние на достижение целей) - 1 (Принцип прозрачности):Принцип прозрачности требует, чтобы информация о проекте была доступна и понятна всем участникам команды. Риск-матрица делает риски видимыми и понятными для команды и заинтересованных сторон.
Правильный ответ:
A - 2, B - 3, C - 1
Вопрос 12:
В команде разработчиков программ для автоматизации розничной торговли после роста до 40 человек перешли на новый, масштабируемый фреймворк управления проектами. Сейчас в команде один владелец продукта, один бэклог продукта и 5 команд — каждая отвечает за отдельную пользовательскую функцию (фиче-команды). Организованы как общие встречи по планированию и ревью результатов, так и внутри каждой команды. Других дополнительных ролей в команде не появилось.
Какой подход к масштабированию Scrum отражен в этом кейсе?
Варианты ответов:
Обоснование:
Large-Scale Scrum (LeSS) — это подход к масштабированию Scrum, который сохраняет ключевые принципы Scrum (один владелец продукта, один бэклог продукта) и минимально усложняет процесс. Он подходит для работы нескольких команд над одним продуктом. В этом кейсе:
- Есть один владелец продукта.
- Один общий бэклог.
- 5 команд работают над разными функциями, но взаимодействуют через общие встречи по планированию и ревю.
Почему не другие подходы?
- Nexus добавляет интеграционную команду для управления зависимостями, чего в данном случае не описано.
- Scrum@Scale предполагает более масштабную структуру, включая несколько владельцев продуктов и сложные управленческие роли.
- SAFe подразумевает множество дополнительных ролей, таких как менеджеры программы, архитекторы и т. д., что не упомянуто в описании.
- Spotify-модель базируется на автономных командах (сквадах), но в ней акцент делается на "главы" (chapters) и "племена" (tribes), что также не соответствует описанному кейсу.
Правильный ответ:
Large-Scale Scrum (LeSS)
Вопрос 13:
Владелец продукта в команде, с которой вы сейчас работаете, решает внедрить методики дизайн-мышления в этап проектирования продукта. Какая из следующих практик дизайн-мышления НЕ сочетается со Scrum-подходом?
Варианты ответов:
- Создавать инновации, ориентированные на человека — конечного потребителя продукта.
- Нужно экспериментировать, чтобы взглянуть на вещи под другим углом и находить лучшие продуктовые решения.
- Чем разнообразнее состав команды разработки продукта с точки зрения их навыков и опыта, тем продуктивнее.
- Единственно важное в определении требований к продукту — мнение и потребности потенциального клиента.
- Для улучшения продукта нужно полюбить неудачи и ошибки, научившись извлекать из них уроки.
Обоснование:
В Scrum важна работа с заинтересованными сторонами (stakeholders), которые включают не только конечных пользователей, но и бизнес-представителей, технических экспертов и других участников процесса. Полагаться исключительно на мнение и потребности потенциальных клиентов — узкий подход, который не учитывает бизнес-цели, технические ограничения и стратегические приоритеты.
Другие утверждения хорошо сочетаются со Scrum, так как они отражают принципы кросс-функциональности, экспериментов, обучения на ошибках и ориентации на потребителя.
Правильный ответ:
Единственно важное в определении требований к продукту — мнение и потребности потенциального клиента.
Вопрос 14:
Команда разработки сталкивается с нестабильными требованиями от одного из ключевых заинтересованных лиц в течение спринта. Какой из вариантов разрешения этой ситуации НЕ согласуется со Scrum-фреймворком?
Варианты ответов:
- Попросить владельца продукта уточнить требования и зафиксировать их в бэклоге продукта.
- Пригласить заинтересованное лицо на ежедневные стендапы, чтобы он отслеживал, что работа команды соответствует его требованиям.
- Пригласить заинтересованное лицо на ревью спринтов, чтобы получать от него регулярную обратную связь о соответствии продукта требованиям.
- Провести ретроспективу с командой разработки для обсуждения проблем в работе, возникающих из-за нестабильных требований.
- Пригласить заинтересованное лицо на планирование спринта, чтобы он мог повлиять на приоритеты разработки продукта в текущем спринте.
Обоснование:
Ежедневные стендапы (Daily Scrum) предназначены исключительно для команды разработки, чтобы синхронизировать свою работу и обсудить прогресс в достижении целей спринта. Привлечение заинтересованных лиц на эту встречу нарушает ее цель и может отвлечь команду от фокуса на выполнении задач.
Остальные варианты согласуются со Scrum:
- Уточнение требований с владельцем продукта и фиксация их в бэклоге продукта — стандартная практика Scrum.
- Обратная связь от заинтересованных лиц на ревю спринтов помогает улучшить продукт.
- Ретроспектива позволяет выявить проблемы и найти пути их решения.
- Участие заинтересованного лица в планировании спринта помогает учесть его мнение при формировании целей спринта.
Правильный ответ:
Пригласить заинтересованное лицо на ежедневные стендапы, чтобы он отслеживал, что работа команды соответствует его требованиям.
Вопрос 15:
Какое утверждение о роли Scrum-метрик ЛОЖНО?
Варианты ответов:
- Показатели Scrum позволяют измерить ценность конечного продукта для клиента или заказчика.
- С помощью метрик Scrum можно обнаружить, когда растет список незакрытых элементов бэклога продукта.
- Scrum-метриками можно оценить, когда бэклог продукта был недостаточно детализирован на конкретные задачи.
- С помощью показателей Scrum можно заметить, когда задачи становятся более сложными и требуют инновационных подходов.
- С помощью метрик Scrum можно обнаружить накопление технического долга в проекте.
Обоснование:
Scrum-метрики, такие как скорость команды (Velocity), время цикла (Cycle Time) или диаграммы сгорания (Burndown/Burnup Charts), предназначены для оценки прогресса, эффективности и управления задачами. Они могут выявить проблемы, такие как задержки или недостаток детализации задач, но они не измеряют сложность задач или необходимость инновационных подходов. Такие аспекты требуют качественного анализа и обсуждения в рамках встреч, например, на планировании или ретроспективе.
- Метрики помогают оценивать ценность продукта через обратную связь от клиента.
- Метрики показывают рост незакрытых задач.
- Недостаточная детализация задач может быть выявлена через анализ задержек и выполнения.
- Технический долг можно выявить через метрики, такие как растущее время выполнения задач.
Правильный ответ:
С помощью показателей Scrum можно заметить, когда задачи становятся более сложными и требуют инновационных подходов.
Вопрос 16:
Какое из действий при внедрении Scrum на производственном предприятии НАИМЕНЕЕ эффективно для процесса производства?
Варианты ответа:
- Вы разделили весь персонал на команды, каждая из которых разрабатывает один модуль конечного продукта.
- Одним из ключевых приоритетов вы определили автоматизацию интеграции отдельно разрабатываемых частей в единый продукт.
- Вы решили, что тестирование продукта и его модулей будет частью процесса разработки, а не идти после него.
- Вы хотите организовать процесс так, чтобы сотрудники чаще готовили прототипы и виртуальные модели разрабатываемого продукта.
- Вы хотите повысить кросс-функциональность команды, увеличив число работников широкого профиля вместо узкоспециализированных специалистов.
Обоснование:
Разделение персонала на команды, которые работают только над отдельными модулями, противоречит принципу кросс-функциональности в Scrum. Это создает зависимости между командами, усложняет координацию и замедляет процесс интеграции. Scrum предполагает, что команды являются кросс-функциональными и способны самостоятельно создавать инкременты, включающие все аспекты работы.
Остальные действия согласуются с принципами Scrum:
- Автоматизация интеграцииускоряет процесс поставки и минимизирует ошибки.
- Интеграция тестирования в разработкупозволяет выявлять проблемы раньше.
- Прототипы и виртуальные моделипомогают быстрее получать обратную связь и адаптироваться.
- Кросс-функциональность повышает гибкость команд и их способность решать разнообразные задачи.
Правильный ответ:
Вы разделили весь персонал на команды, каждая из которых разрабатывает один модуль конечного продукта.
Вопрос 17:
Какое утверждение о работе с пользовательскими историями ЛОЖНО?
Варианты ответа:
- Истории должны выполняться за один спринт.
- История выполнена, если пользователь может сделать то, о чем он просил.
- Во время работы с пользовательскими историями нужно определить, какие этапы необходимо пройти и кто несет ответственность за каждый из них.
- В процесс работы с пользовательскими историями входит написание документации о том, как использовать продукт.
- При наличии нескольких категорий пользователей необходимо написать несколько историй.
Обоснование:
Утверждение 4: Это ложное утверждение, так как Scrum не предусматривает обязательного написания документации по пользовательским историям. Документация может быть частью других процессов, но не является основным элементом работы с историями.
Правильный ответ:
В процесс работы с пользовательскими историями входит написание документации о том, как использовать продукт.
Заключение:
Внедрение и успешное использование Scrum требует глубокого понимания его принципов и подходов, включая масштабирование для работы с несколькими командами. При подготовке к тестированию на продвинутом уровне важно обратить внимание на правильное взаимодействие между командами, использование фреймворков, таких как Nexus и LeSS, и эффективное управление Scrum-командами.
Для тех, кто хочет углубить свои знания и подготовиться к следующим уровням тестирования, рекомендуем ознакомиться с нашими предыдущими статьями:
- Scrum - базовый уровень— введение в Scrum и основные принципы.
- Scrum - средний уровень— расширенные практики и углубленные темы о Scrum-командах и их взаимодействии.
Эти статьи помогут вам освоить все ключевые аспекты методологии и подготовиться к более сложным задачам в масштабировании Scrum.