1. Разработку сложных продуктов (не обязательно программных)

1. Разработку программного обеспечения

1. Разработку и внедрение программного обеспечения

1. Разработку и поддержку сложных продуктов (не обязательно программных)

Руководство по Скрам (Scrum guide) поощряет любые изменения в ролях, артефактах правилах и событиях Скрама, поскольку, согласно Agile-манифесту "люди и взаимодействие важнее процессов и инструментов“

Руководство по Скрам (Scrum guide) поощряет любые изменения в ролях, артефактах правилах, кроме тех что противоречат Agile-манифесту и основной идее Скрам

1. Руководство по Скрам (Scrum guide) явно запрещает любые изменения в ролях, артефактах правилах

Главная задача Скрам - удовлетворение заказчика результатом, помимо нее нет никаких ограничений и запретов в применении и модификации подхода

1. Можно дополнять тем что не противоречит уже написанному

Нельзя ни дополнять ни в каких случаях

Можно менять как угодно, ведь Скрам-фремворк это Agie-подход

1. Нельзя дополнять, но можно отказываться от того что не подходит именно вашей команде

Есть список "хотелок", они реализуются командой непрерывно в виде "потока работ" и могут передаваться заказчику по мере готовности

1. Есть список "фич" (ожиданий от содержания) от руководителя продукта, фичи из этого списка (обычно по несколько штук) реализуются командой в рамках "спринтов" (одинаковых отрезков времени), результаты передаются по завершении спринта

Есть жесткие рамки, которые фиксируются в уставе проекта, внутри которых планы, которые можно уточнять по необходимости

1. Есть жесткое, раз и навсегда фиксированное техническое задание и такой же жесткий план работ, которым руководствуется команда и по которому передает результаты заказчику

Менеджер, который распределяет задачи внутри команды

Эксперт, основная ответственность которого понять что именно лучше добавить в список задач на разработку - бэклог продукта

1. Спонсор проекта, обеспечивающий команду всеми необходимыми ресурсами

1. Все перечисленное неверно

1. Может быть членом команды разработки

1. Самостоятельная роль, он всегда является внешним по отношению к команде (отделен от команды разработки)

1. Не обязательная роль, если уже определен владелец продукта

1. Все перечисленное неверно

1. От 1 до 9 человек

1. Не больше 40 человек

1. Может быть любого размера, ведь согласно Agile-подходу люди и их взаимодействие важнее процессов (а также любых условностей)

1. От 3 до 9 человек

Подчиняется указаниям скрам-мастера о том кому какую задачу взять

1. Включает в себя владельца продукта

Не должна иметь подкоманд

1. В отличие от других ролей - не обязательно существует

1. Владелец продукта НЕ может совмещать свою роль с работой в команде разработки, он должен быть строго от нее отделен решая вопрос "что делать", но не вмешиваясь в принятие решений "как"

Владелец продукта, в отличие от Скрам-мастера, может совмещать свою роль с работой в команде разработки и это желательно, ибо так он будет лучше понимать не только "что нужно сделать", но и "как это сделать"

Владелец продукта и команда разработки - взаимоисключающие роли, на проекте может быть либо владелец продукта, либо команда, но никогда не оба

Если владелец продукта совмещает свою роль с работой в команде разработки, он обязан взять на себя и роль Скрам-мастера

1. Пользовательские истории

1. Запросы на исправление дефектов

1. Запросы на устранение технического долга

1. Все перечисленное верно

Все разделы только сам исходя из собственного мнения (это его документ)

1. Разделы "элементы" сам, остальные - заполняет команда

1. Разделы "элементы" и "их ценность" - преимущественно сам, а раздел "сложность" с помощью команды

1. Не заполняет бэклог продукта, это документ над которым работает только команда за счет самоорганизации

Истории пользователей в бэклоге продукта должны быть по-возможности независимы (не иметь взаимосвязей)

Истории пользователей в бэклоге продукта должны быть описаны как можно подробнее, желательно большое количество деталей, схем

Истории пользователей в бэклоге продукта должны давать четкое представление о том как они будут реализованы технически, это должно входить в их описание

Все перечисленное неверно

Скрам-мастер
(Scrum master)

1. Команда разработки (development team)

Владелец продукта (Product owner)

1. Мастер потока
   (flow master)

1. Для того чтобы высший менеджмент не мог потребовать выполнения работы "в установленный срок«

1. Потому что членам команды трудно оценивать продолжительность (и гораздо легче - трудоемкость)

Для того чтобы заложить в оценку риски и чтобы ее легко можно было пересматривать в случае возникновения проблем

1. Потому в Скрам любят красивые термины, а по сути это синоним "человеко-часов"

1. Прогнозировать срок завершения работ (если скорость команды и состав задач в бэклог не изменятся)

1. Отслеживать взаимосвязи между работами

1. Анализировать корневые причины проблем на проекте

1. Обсуждать состав заинтересованных сторон проекта

Планирование спринта - ежедневный Скрам - ретроспектива спринта - обзор спринта

1. Планирование спринта - ежедневный Скрам - обзор спринта - ретроспектива спринта

1. Обзор спринта - планирование спринта - ежедневный Скрам - ретроспектива спринта

1. Обзор спринта - ежедневный Скрам - планирование спринта - ретроспектива спринта

1. Ежедневный Скрам

1. Ретроспектива спринта

1. Обзор спринта

1. Планирование спринта

1. Ответ на три вопроса (отвечает каждый член команды)

1. Ответ на три вопроса (отвечает владелец продукта)

1. Желающие высказываются о своих проблемах (число вопросов и тезисов не ограничено)

1. Желающие высказываются о своих проблемах, потом переходят к ответам на три вопроса (отвечают все участники ежедневного Скрам)

1. Проверка что цель спринта достигнута

1. Проверка что реализованы все элементы бэклога продукта, взятые в спринт

Анализ того эффективно ли работали все члены команды в ходе спринта

Все перечисленное - является задачей ревью спринта

Не может, так как для перехода к последующей фазе  необходимо принять результат предыдущей фазы

2. Может, но только при исключительной важности требований к

срокам проекта

Может, но это приводит к повышению риска повторения работ,  если последующая фаза начнѐтся прежде, чем будет получена  точная информация о результатах предыдущей фазы

Может, если результат предыдущей фазы не требуется  принимать до начала последующей фазы

1. Это требование нельзя удовлетворить в проекте

1. Мнение заказчика надо учесть и включить соответствующий  процесс в иерархическую структуру работ

Мнение заказчика надо учесть и добавить отдельную фазу в  жизненный цикл проекта

1. Проект по реализации этого требования можно рассматривать

как отдельный проект общей программы

1. Для определения их влияния на успех проекта

1. Для выявления их требований и определения влияния  на достижение целей проекта

1. Для определения способов их участия в работах на  различных стадиях проекта

Для определения способов взаимодействия с ними в  ходе проекта

На выполнении работ

1. На координации человеческих и других ресурсов

1. На ограничении влияния на проект третьих сторон

1. На поддержании ответственности за совершение ошибок

Теории трёх требований

Тройного ограничения

1. Трёх экспертов

1. Оценки по трём точкам

На влияние спонсора

2. На план коммуникаций

2. На "тройное ограничение"

2. На следующие задачи, связанные с этим изменением

Топ-менеджер разрабатывает план на основе данных

менеджера проекта

2. Функциональный менеджер разрабатывает план на основе  данных менеджера проекта

2. Менеджер проекта разрабатывает план на основе данных от

членов команды

4. Менеджер проекта разрабатывает план на основе данных от  топ-менеджера

Это делать не надо. Раз уж план составлен, то команда знает,  что ей делать

2. Ежемесячно

2. Непрерывно

2. Еженедельно

Не включать этого человека в список участников проекта

2. Попросить его руководителя найти возможность, чтобы  направить его активность на другие дела

2. Не обращать внимания на его предложения

2. Привлекать его к работам проекта, начиная с самых ранних

стадий и до конца проекта

Применить одну из мотивационных теорий для снятия

недовольства членов команды

2. Усилить контроль за изменением содержания

   (скоупа)

2. Обеспечить более строгий контроль над деятельностью  членов команды

2. Разработать систему поощрений и наказаний для обеспечения  выполнения работ в срок

Этого требует PMBOK

1. Это необходимо из-за наличия в проекте работ, выполняемых  по контрактам подрядчиками

1. Иерархическая структура работ - единственный путь для  идентификации рисков

1. Иерархическая структура работ позволит определить  результат каждой из работ или пакета работ

Работы каждого уровня должны входить как составляющая  часть в работу вышестоящего уровня

Верхний уровень содержит описания самых главных  продуктов проекта. Ниже лежащие уровни связаны с  детализацией этих описаний

Работы должны располагаться в соответствии с порядком  выполнения, обеспечивающим достижение результата

2. Работы должны располагаться и объединяться на  соответствующем уровне в соответствии с их  функциональным назначением

Указать программисту на недопустимость таких действий и

потребовать удалить сделанное

2. Добавить эту разработку в план проекта, поскольку она не затрагивает расписания проекта и его стоимости

2. Составить документ о сделанном изменении и дать на  подпись заказчику, поскольку изменение уже произведено

2. Проанализировать возможные риски, связанные с этим  изменением и после этого принять решение

Возразить спонсору, что критический путь не позволит

сделать этого

Сообщить, что вы согласны, если можно не выполнять  работы, которые лежат на критическом пути

2. Сообщить, что вы согласны, если можно не выполнять

работы, которые не находятся на критическом пути

На совещании команды проверить, можно ли операции,  лежащие на критическом пути, сжать или сократить методом  быстрого прохода

Спонсор проекта

2. Руководитель проекта

2. Инженер по качеству

2. Любой член команды проекта

Степень, в которой проект удовлетворяет целям заказчика

2. Степень, в которой проект удовлетворяет требованиям

2. Результат правильного выбора нужных дополнительных  возможностей, которые сделают заказчика счастливым

2. Удовлетворение ожиданий заказчика как явно  сформулированных, так и тех, о которых заказчик даже не  догадывался

Расходы на гарантийное обслуживание

2. Брак

2. Переделка

2. Обучение членов команды проекта управлению

качеством

1. Компромисс

1. Сглаживание

1. Давление

1. Уклонение

Компромисс

2. Сглаживание

2. Давление

2. Уклонение

Принять меры к его дополнительному обучению и курировать  его действия в течение оставшегося времени

2. Потребовать от функционального менеджера, чтобы он

организовал надлежащее обучение этого сотрудника

Пересмотреть расписание проекта с учетом отставания в  выполнении работы данным членом команды

Заменить этого сотрудника на другого, более  квалифицированного

Увеличение частоты совещаний с командой и отчётов о  статусе проекта

Учреждение специальной награды для лучшего сотрудника  команды проекта

Усиление давления на каждого сотрудника с целью  завершения проекта в срок

2. Повышение чувства доверия и сплочённости в коллективе

1. Формирование

1. Возмущение

1. Делегирование

1. Стабилизация

Чтобы заслушать информацию об исполнении работ членами

команды

Чтобы обменяться взаимной информацией по исполнению  проекта

2. Чтобы уточнить и подтвердить стоимость выполненных работ

2. Чтобы довести до сведения членов команды информацию о  последних изменениях

90%

75%

50%

25%

1. Контакт с глазами собеседника

1. Уточняющие вопросы

1. Прерывание собеседника
   (при необходимости)

Переспрашивание

1. Для соблюдения порядка следования фаз проекта

1. Разрешение спорных вопросов

1. Идентификация участников проекта

1. Оценка значимости каждого участника проекта

1. Умение планировать работы проекта

Умение вести переговоры

1. Умение анализировать ситуацию

1. Умение документировать полученную информацию