Главная /
Менеджмент /
Анализ и оценка методов разработки программного обеспечения (Agile)
Анализ и оценка методов разработки программного обеспечения (Agile) - ответы на тесты Интуит
Правильные ответы выделены зелёным цветом.
Все ответы: Курс посвящен быстрым методам разработки программных систем – методам agile.
Все ответы: Курс посвящен быстрым методам разработки программных систем – методам agile.
Смотрите также:
В программировании понятие "Agile" в разных контекстах означает:
(1) Гибкие методы разработки программных систем
(2) Совокупность ряда современных методов разработки программных систем и связанной с ними философии
(3) Современную программную среду разработки программного обеспечения
(4) Методы проектирования программных систем
(5) Новые методические и идеологические подходы в программной инженерии
Какие принципы характерны для Agile метода Lean – Экономного программирования:
(1) Улучшить обучение
(2) Поставлять как можно раньше
(3) Доверять решения команде
(4) Принимать решения как можно раньше
(5) Строить множество решений, каждое из которых покрывает некоторую потребность пользователя
В Agile отрицается необходимость этапа "предваряющего анализа". Какие аргументы приводятся в защиту этого тезиса:
(1) Требования к системе меняются на протяжении разработки и потому не могут быть сформулированы на начальном этапе
(2) Архитектура системы изменяется в ходе разработки и потому ее проектирование на начальном этапе не представляется разумным
(3) Сбор пользовательских историй заменяет задание формальных требований
(4) Создание работающей системы не требует проектирования ее архитектуры
Какие высказывания являются справедливыми по отношению к утверждению, носящему характер всеобщности:
(1) Пример может доказать утверждение
(2) Пример может опровергнуть утверждение
(3) Пример может подтвердить справедливость утверждения
(4) Пример не может ни подтвердить, ни опровергнуть справедливость утверждения
"Предваряющий анализ" - это:
(1) Анализ кода, предваряющий включение кода в работающую программную систему
(2) Анализ, предваряющий разработку каждого программного модуля
(3) Начальный этап проектирования программной системы, предваряющий разработку кода и заканчивающийся созданием "документа требований"
(4) Начальный этап проектирования программной системы, предваряющий разработку кода и заканчивающийся выработкой основных архитектурных решений
Какие утверждения справедливы по отношению к понятию "принцип" в программной инженерии:
(1) Принцип задает общее правило разработки ПО
(2) Правило, которое задает принцип, должно быть конкретным
(3) Правило, которое задает принцип, должно быть абстрактным, применимым во всех случаях
(4) Принцип должен быть нетривиальным. Это означает, что можно привести разумные доводы против применения принципа в тех или иных ситуациях
(5) Правило "Создавайте качественный продукт" является принципом
Agile выступает за самоорганизуемую команду, передавая команде традиционные обязанности менеджеров. Что, по мнению Agile, не должны делать менеджеры:
(1) Выбирать задачи для реализации
(2) Создавать комфортные условия работы программистов
(3) Распределять работы между программистами
(4) Обеспечивать требуемую техническую поддержку – компьютеры, сеть, интернет и прочее
Что понимается под практикой (practice) в программных разработках:
(1) Любая деятельность, выполняемая в процессе разработки
(2) Деятельность, выполняемая регулярно
(3) Требования регламента, задающие режим работы
(4) Ежедневные встречи в Scrum – это практика
(5) Консультации с экспертом в Scrum – это практика
Что такое сборка (Build) системы:
(1) Интеграция всех раздельно разрабатываемых компонентов системы с целью построения единой системы
(2) Процесс перестроения системы после внесения изменений в отдельные ее компоненты
(3) Объединение всех версий системы в одну универсальную систему
(4) Построение всех возможных вариантов системы и сохранение их в базовой библиотеке
В Agile основное внимание уделяется тому, что непосредственно поставляется пользователям системы. Какие утверждения считаются справедливыми:
(1) Работающий код является единственным продуктом разработки
(2) Работающий код является главным, но не единственным продуктом разработки
(3) Работающий код и набор тестов являются двумя основными продуктами разработки
Какие методы разработки программных систем относятся к Agile:
(1) экстремальное программирование (Extreme Programming)
(2) объектное программирование (Object-Oriented Programming)
(3) структурное программирование (Structure Programming)
(4) парное программирование (Pair Programming)
Важнейшим принципом Lean является принцип "исключения затрат". Что понимается под затратами в Lean:
(1) Переключение с задачи на задачу, когда программист одновременно работает над несколькими задачами
(2) Свойства, необходимые малому числу пользователей
(3) Итерации, на которых пользователю предоставляется работающая система
(4) Создание тестов, сопровождающих код
Пользовательские истории позволяют:
(1) Проверить полноту требований
(2) Задать законы проблемной области
(3) Задать потребности пользователей
(4) Заменить требования
Какие доводы приводит автор книги в пользу записи требований к программной системе:
(1) Устные договоренности забываются с течением времени
(2) Устные контакты затруднены для распределенных команд с участниками из разных стран
(3) Эмоциональность устного высказывания является причиной ложных утверждений
(4) Устное общение вредит принятию решения
Что понимается под термином "водопад":
(1) Непрерывный процесс разработки программного проекта
(2) Процесс разработки, завершающийся падением проекта с большой высоты
(3) Модель разработки, предложенную в учебных целях, включающую последовательность этапов разработки проекта, когда следующий этап начинается после завершения предыдущего этапа
(4) Модель этапов разработки проекта, не содержащая циклов
"Поддерживайте устойчивый темп" - важный принцип Agile. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:
(1) Передача команде важных полномочий по управлению проектом, обеспечение программистам необходимых условий для работы позволяет отказаться от "маршей смерти"
(2) Всем членам команды следует обеспечить "персональную безопасность"
(3) При планировании работ следует предусматривать Geek Week недели
(4) Членов команды, не выдерживающих нужные сроки выполнения работ, следует удалять из команды
Agile выступает за самоорганизуемую команду, передавая команде традиционные обязанности менеджеров. Что, по мнению Agile, должны делать менеджеры:
(1) Выносить поощрения и наказания программистам, оценивая результаты их работы
(2) Представлять интересы команды в общении с внешним окружением
(3) Распределять работы между членами команды
Какие утверждения справедливы для "ежедневных встреч" Scrum:
(1) Эти встречи называются "встречами сидя", чтобы участники в комфортной обстановке могли решать насущные проблемы
(2) Встречи короткие обычно не более 15 минут
(3) Вопросы, обсуждаемые на встречах, фиксированы
(4) На встречах могут подыматься любые вопросы, требующие решения
Какие утверждения справедливы по отношению к технике парного программирования:
(1) Парное программирование – это техника, применяемая в XP – Экстремальном программировании
(2) Все Agile методы настаивают на повсеместном применении парного программирования
(3) Преимущество парного программирования в том, что один участник пары разрабатывает алгоритм, в то время, когда второй работает за компьютером
(4) В парном программировании один участник набирает текст программы, комментируя свои действия, второй – контролирует действия партнера, указывая на возможные ошибки
Автор книги, отдавая должное "пользовательским историям", говорит о важности "дуального программирования". Какие утверждения справедливы по мнению автора книги:
(1) В начальной фазе проекта "пользовательские истории" играют важнейшую роль и необходимы для построения модели предметной области
(2) В начальной фазе проекта при построении модели предметной области "пользовательские истории" играют малую роль, здесь проектируются классы и отношения между ними
(3) В последующих фазах разработки "пользовательские истории" играют важную роль, задавая функциональность, востребованную пользователями
(4) При дуальном программировании два подхода можно применять только последовательно
(5) При дуальном программировании два подхода можно применять параллельно
В манифесте Agile утверждается:
(1) Люди и взаимодействие важнее процессов и инструментов
(2) Документация важнее системы тестов
(3) Следование плану важнее готовности к изменениям
(4) Сотрудничество с заказчиком важнее согласования условий контракта
Какова Большая идея Agile метода Scrum:
(1) Снижение затрат
(2) Добавление, затем Упрощение
(3) Закрытое окно – Замораживание требований на время выполнения итерации
(4) Осмотическая Коммуникация
Какие утверждения следует признать справедливыми:
(1) Самоорганизуемая команда всегда работает эффективнее команды, управляемой менеджером
(2) Самоорганизуемая команда всегда менее эффективна, чем команда, управляемая менеджером
(3) Лучшим способом управления командой является способ "скрытого управления"
(4) Нет однозначного ответа на вопрос о том, какой способ управления командой более эффективен – самоорганизуемая команда или команда, управляемая менеджером
Кто обходился устными контактами, не пользуясь записями:
(1) Разработчики космических аппаратов
(2) Пифагор
(3) Строители египетских пирамид
(4) Платон
Какие утверждения справедливы по отношению к документу требований:
(1) Целью документа является выявление требований, позволяющих определить, правильно ли работает программная система
(2) Целью документа является выявление требований, позволяющих определить, разрабатывается ли правильная программная система, отвечающая потребностям сопричастников системы
(3) При построении программной системы в конкретной проблемной области важнейшей задачей является выявление потребностей сопричастников, - всех тех, кто заинтересован в решении стоящих проблем. Эти потребности отражаются в документе требований
(4) Главной целью документа требований является формулировка требований к разработчикам программной системы
(5) Требования, описывающие свойства предметной области, остаются неизменными в отличие от требований к создаваемой "машине" - внутренних свойств программной системы
"Разрабатывайте минимальный продукт" - важный принцип Agile. Реализуя этот принцип, следует создавать продукт с минимальной функциональностью. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:
(1) Большинство программных систем страдает избыточностью
(2) Продукт должен содержать не более пяти различных функций
(3) Каждую функцию продукта должны использовать не менее 90 % пользователей
(4) Следуйте лозунгу YAGNI Экстремального программирования – "Тебе Это Не Понадобится"
(5) Если код сегодня не требуется, то помещать его в систему – расточительство
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие обязанности не возлагаются на Владельца продукта:
(1) Отвечает за бэклог продукта
(2) Отвечает за бэклог спринта
(3) Подводит итоги спринта
(4) Распределяет работы между членами команды
(5) Отвечает за реализацию проекта в соответствии с правилами Scrum
Какие утверждения справедливы относительно "игры в планирование":
(1) При игре в планирование всегда выигрывают потребители
(2) При игре в планирование всегда выигрывают разработчики
(3) При игре в планирование иногда выигрывают потребители, иногда разработчики
(4) При игре в планирование достигается компромисс между желанием потребителей и возможностями разработчиков
(5) Целью игры является максимизация функциональности и минимизация времени разработки с учетом состава и возможностей команды разработчиков
Какие приемы применяются при рефакторинге:
(1) Применение абстракции – создание абстрактного класса и его конкретных наследников
(2) Переименование
(3) Дублирование важного кода
(4) Устранение дублирования
Как измеряется "скорость" разработки в Agile проектах:
(1) Под скоростью разработки понимается отношение трудоемкости выполненных работ ко времени их выполнения
(2) Скорость разработки можно измерить только за период всей итерации
(3) Скорость разработки можно измерять ежедневно
(4) Скорость разработки итерации – это число баллов тех историй, которые выполнены во время итерации
Какие предпосылки лежат в основе идей Agile:
(1) Отказ от "Предваряющего анализа" - начальных этапов разработки
(2) Отказ от ежедневного тестирования
(3) Предпочтение собственным инструментам разработки
(4) Итеративная разработка
Какова Большая идея Agile метода Crystal:
(1) Снижение затрат
(2) Добавление, затем Упрощение
(3) Закрытое окно – Замораживание требований на время выполнения итерации
(4) Осмотическая Коммуникация
Какие утверждения следует признать справедливыми:
(1) Обобщением с целью повторного использования функций системы следует заниматься на начальных этапах разработки системы
(2) Обобщением с целью повторного использования функций системы не следует заниматься, поскольку это вредит основной цели
(3) Обобщением с целью повторного использования функций системы следует заниматься в процессе разработки системы
(4) Отказ от обобщений противоречит принципу "приятия изменений"
(5) Обобщения позволяют предусмотреть возможность будущих изменений системы
Одно из важных наблюдений состоит в том, что "запись высказывания придает высказыванию излишнюю убедительность, которой текст в действительности может не обладать". Какие следствия вытекают из этого наблюдения:
(1) Письменным текстам следует предпочесть вербальные контакты
(2) Письменным текстам на естественном языке следует предпочесть тексты на строго формализованном языке, позволяющем устранить неоднозначность письменного текста
(3) Письменным документам следует предпочесть вербальные контакты с последующим созданием итогового документа
Сторонники Agile отрицают необходимость создания документа требований. Какие доводы они приводят в защиту такого подхода:
(1) Сбор требований не является предваряющей фазой, создающей статический документ, это деятельность, проясняющая детали в тот самый момент, когда они становятся необходимыми в процессе разработки
(2) Разработка системы выполняется Agile командой. Это демократический процесс, не признающий ограничений, задаваемых требованиями
(3) Документ требований бесполезен при поставке продукта, поскольку он не является частью того, что передается клиентам
(4) Документ требований быстро устаревает
(5) Создание прототипа системы важнее документа требований
Какие утверждения справедливы относительно "роли документов":
(1) Пользователя мало волнуют расходные материалы. Поскольку документы относятся к расходным материалам, то создавать их не следует
(2) Важно не только то, что важно для пользователя, но и то, что важно для разработчика
(3) Критика "устаревания документов" справедлива, поскольку внесение изменений в код зачастую не сопровождается внесением изменений в документы
(4) Существуют современные инструментальные средства, позволяющие синхронизировать изменения кода и документов
(5) Если нет инструментария, синхронизирующего изменения кода и документов, то использовать документы нецелесообразно
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие обязанности возлагаются на Scrum Мастера:
(1) Отвечает за то, чтобы команда применяла практики Scrum и выполняла предписанные Scrum правила
(2) Устраняет любые препятствия, возникающие у членов команды при реализации задач во время спринта, как технические, так и организационные
(3) Распределяет задачи между членами команды
(4) Подводит итоги спринта
Какие утверждения справедливы относительно игры в "покер планирования":
(1) В эту игру играют только потребители
(2) В эту игру играют только разработчики
(3) В эту игру играют потребители и разработчики
(4) Цель игры совпадает с целью игры в планирование
(5) Цель игры отличается от цели игры в планирование
Что такое TDD:
(1) Способ разработки системы, пропагандируемый в Agile и называемый "Три Долгие Дороги", когда анализируются три варианта развития системы и выбирается наикратчайший путь реализации
(2) Разработка, при которой применяются все приемы тестирования –юнит-тестирование, нагрузочное тестирование, комплексное и приемное тестирование
(3) Разработка, управляемая тестами, способ разработки, предлагаемый в XP, при котором вначале пишется тест, а потом создается и отлаживается код, обеспечивающий прохождение всех ранее разработанных тестов, в том числе и теста, написанного перед непосредственным созданием кода
(4) Разработка, управляемая тестами, способ разработки, предлагаемый в XP, при котором вначале создается и отлаживается код, а потом пишется тест, добавляемый в набор тестов. Вновь созданный код должен обеспечить прохождение всех ранее разработанных тестов, в том числе и теста, написанного после создания очередной порции кода
Что такое "бэклог" итерации:
(1) Основу бэклога составляет совокупность пользовательских историй, отобранных для реализации на итерации
(2) Совокупность задач, сформулированных на основе отобранных пользовательских историй
(3) Совокупность задач, реализованных на итерации
(4) Совокупность задач, которые не удалось реализовать на итерации
(5) Бэклог итерации разделяется на три – четыре раздела: задачи, выбранные на реализацию, еще не выбранные, уже реализованные, проверенные
Какие принципы лежат в основе идей Agile:
(1) Разрешать самоорганизацию команды
(2) Сохранять устойчивый темп разработки
(3) Выбирать лидера программного проекта
(4) Коллективная разработка тестов
Какие приемы характерны для Agile метода XP – Экстремального программирования:
(1) Триадное программирование
(2) Парное программирование
(3) Длинные итерации
(4) Короткие итерации
(5) Непрерывная интеграция
Какие идеи Agile считаются автором книги излишне рекламируемыми, хотя и не вредными, но и не столь полезными:
(1) Минимальная функциональность
(2) Ежедневные встречи
(3) Отказ от повторного использования
(4) Коллективное владение кодом
(5) Кросс-функциональная команда
В ряде книг и статей по Agile в целях рекламы новых подходов разработки программных продуктов применяются недобросовестные риторические приемы. О каких подобных приемах предупреждает автор этой книги:
(1) Запугивание
(2) Обольщение
(3) Катастрофизм
(4) Все или ничего
Предваряющий анализ помимо создания документа требований включает этап проектирования, на котором принимаются базисные архитектурные решения. Какие утверждения по мнению автора книги справедливы относительно процесса проектирования:
(1) Решения, принятые на этапе предваряющего анализа, являются окончательными и должны строго выполняться
(2) Проектирование и реализация два тесно связанных процесса. Решения, принимаемые на этапе реализации, влияют на проектные решения
(3) Возможность изменений проектных решений в ходе реализации не означает, что следует отказаться от этапа проектирования при проведении предваряющего анализа
Практика Agile предполагает итеративную разработку с короткими временными сроками для итераций. Какие утверждения являются справедливыми:
(1) Срок итерации не должен превышать 2 – 4 недели
(2) Если функциональность, запланированная на итерации, не достигнута, то срок итерации расширяется
(3) Если функциональность, запланированная на итерации, не достигнута, то срок итерации не изменяется, а функциональность либо отклоняется, либо переносится на следующую итерацию
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие утверждения справедливы относительно Команды:
(1) Должна быть сертифицированной
(2) Чаще всего, должна быть кроссфункциональной, когда любой член команды может выполнять любую задачу
(3) Должна быть самоорганизуемой
(4) За выполнение задач спринта ответственна команда, а не отдельный исполнитель
Какие утверждения в Agile считаются справедливыми относительно организации офисного пространства:
(1) Каждому программисту следует предоставить отдельный кабинет
(2) Отдельные кабинки для программистов недопустимы
(3) Закрытые офисы недопустимы
(4) В рабочем пространстве должна царить тишина, чтобы каждый мог комфортно работать
Какие утверждения справедливы для TFD разработки:
(1) Тесты являются важнейшим инструментов разработки
(2) Нет кода без теста
(3) Вначале пишется код, затем создается тест
(4) Вначале тест, затем код
(5) Все тесты входят в набор регрессионных тестов
Какие утверждения справедливы относительно понятия "панель историй и задач". Панель задач:
(1) В динамике отражает ход разработки, что способствует стремлению команды работать более эффективно, ускоряя процесс разработки
(2) Позволяет визуализировать различные состояния, через которые проходит каждая задача итерации
(3) Показывает, над какой задачей в данный момент работает каждый член команды
(4) Содержит список задач, предписанных для выполнения каждому члену команды
(5) Задает сроки, отведенные на решение задачи
Какие ключевые роли предполагаются в Agile:
(1) Лидер команды
(2) Архитектор проекта
(3) Команда
(4) Scrum-Мастер
Какие утверждения справедливы для Agile метода Scrum – Схватка:
(1) Представленная модель итерации стала де факто стандартом индустрии ПО
(2) Scrum в отличие от XP больше внимания уделяет организационным аспектам, чем технологическим
(3) Scrum в отличие от XP больше внимания уделяет технологическим аспектам, чем организационным
(4) Диаграмма выполнения является инструментом Scrum, позволяющим осуществлять ежедневный мониторинг процесса разработки
Какие идеи Agile считаются автором книги отличными:
(1) Короткие итерации
(2) Жесткие временные рамки итераций
(3) Ежедневные встречи
(4) Рефакторинг
(5) Правило закрытого окна
(6) Визуализация мониторинга скорости процесса разработки
Укажите истинные высказывания:
(1) "Запугивание" - это прием, при котором всякого, кто не использует agile, называют консерватором и бюрократом
(2) "Подстелите соломку" - это прием, при котором Вас убеждают, что проект, не использующий agile, как правило, заканчивается неудачей
(3) "Все или ничего" - это прием, при котором agile метод должен применяться в полном объеме, рекомендуемом авторами
Какие утверждения справедливы для понятия "модель жизненного цикла":
(1) Модель жизненного цикла определяет и стандартизует последовательность этапов разработки программной системы
(2) Современные модели жизненного цикла носят итеративный характер
(3) При разработке программных систем Agile не использует модели жизненного цикла
(4) Модель жизненного цикла играет как декларативную (описательную) роль, так и дескриптивную (предписывающую) роль
В инженерии ПО тестирование является основным способом обеспечения качества проекта. Какие утверждения справедливы по отношению тестирования:
(1) Тестирование позволяет доказать наличие ошибки, но не может доказать их отсутствия
(2) Для Agile тесты представляют основной ресурс проекта
(3) Регрессионное тестирование отвергается в Agile как затратное
(4) Современный инструментарий позволяет автоматизировать систему прохождения тестов
В главе 5 приводится ![math]()
– диаграмма - упрощенная модель водопадного типа, описывающая процесс разработки и тестирования проекта. Какие утверждения справедливы относительно этой модели:
– диаграмма - упрощенная модель водопадного типа, описывающая процесс разработки и тестирования проекта. Какие утверждения справедливы относительно этой модели:
(1) Эта модель соответствует процессу разработки программных продуктов в Agile
(2) Подобные модели отвергаются в Agile, поскольку в Agile отвергается предваряющий анализ, включающий этапы разработки требований и проектирования
(3) Подобные модели отвергаются в Agile, поскольку в Agile тестирование ведется непрерывно. Более того, создание тестов предшествует созданию кода
(4) Этапы Юнит тестирования, интеграционного и приемочного тестирования в Agile четко разделяются
(5) Поскольку на каждой итерации в Agile создается работающая система, функциональность которой расширяется на последующих итерациях, то все три этапа тестирования выполняются на каждой итерации
В Agile большое внимание уделяется контактам внутри команды и контактам с клиентами. Какие регулярные встречи регламентированы в Scrum:
(1) Встреча в начале проекта с клиентами для выработки документа требований
(2) Встреча в начале итерации, посвященная планированию итерации
(3) Встреча в конце проекта с клиентами для подведения итогов разработки
(4) Встреча в конце итерации для подведения итогов итерации
(5) Ежедневные короткие встречи команды, где каждый член команды отвечает на три вопроса
(6) Встреча, называемая ретроспективой, проводимая после завершения очередной итерации, целью которой является анализ качества созданного проекта и возможностей его улучшения
Какие утверждения следует считать корректными:
(1) Разработка TDD – разработка, управляемая тестами, - это практика, ориентированная на процесс тестирования
(2) Разработка TDD – разработка, управляемая тестами, - это не метод тестирования, а полноценный метод разработки программных систем
(3) Правило TDD требует, чтобы никакое изменение в коде не принималось, пока не пройдут все тесты регрессионного набора
(4) Наличие тестов не означает, что нет необходимости в написании спецификаций
Нисходящая диаграмма выполнения:
(1) Отображает рост скорости разработки
(2) Отображает падение скорости разработки
(3) Ось ординат которой задает трудоемкость (в баллах) уже решенных задач
(4) Ось ординат которой задает трудоемкость (в баллах) еще не решенных задач
(5) Содержит график средней скорости разработки, позволяющей выполнить проект в заданные сроки
(6) Точки над прямой, задающую среднюю скорость, свидетельствуют об отставании от графика
(7) Точки над прямой, задающую среднюю скорость, свидетельствуют об опережении графика
Какие практики лежат в основе идей Agile:
(1) Скрытие кода
(2) Открытое тестирование
(3) Ежедневные встречи
(4) Разделяемое владение кодом
Какие принципы характерны для Agile метода Crystal – Кристалл:
(1) Осмотическая коммуникация
(2) Экстремальная коммуникация
(3) Экономная коммуникация
(4) Персональная безопасность
(5) Автоматизация тестирования, интегрирования, управления конфигурацией
Правило закрытого окна – эта идея:
(1) Прекрасная
(2) Ужасная
(3) Шумно рекламируемая
(4) Хорошая
Риторический прием "Катастрофизм" - это:
(1) Вас убеждают, что применяемые сегодня методы разработки ПО обязательно ведут к катастрофе (так что только agile методы могут спасти проект)
(2) Вам предлагают радикальные меры, а в сносках говорят о том, что они не всегда применимы, но никогда точно не говорят, когда эти меры могут использоваться, а когда нет
(3) Если вы не используете agile, то вы консерватор, реакционер или чудак
Какие утверждения справедливы по отношению к понятию "Модели зрелости":
(1) Понятие "Модель зрелости" является развитием понятия "Модель жизненного цикла"
(2) Интеграционная Модель Технологической Зрелости (CMMI) позволяет оценить профессиональный уровень разработки программных систем в конкретной организации
(3) Каждая организация, разрабатывающая программные продукты, сама определяет свой уровень зрелости
(4) Применяемые практики, цели и оценки в процессе разработки программного продукта определяют уровень зрелости CMMI
Одна из главных целей, провозглашаемых Agile – создание продукта, отвечающего потребностям пользователя. Какие практики применяются в Agile для достижения этой цели:
(1) Задается документ требований
(2) Задаются сценарии – варианты использования, описывающие варианты прохода по системе
(3) Задаются сценарии – пользовательские истории, описывающие некоторые ситуации в процессе работы системы
(4) Задаются формальные спецификации, строго описывающие требования пользователей
Зависимости между модулями:
(1) Мешают выбирать наиболее приоритетную задачу на реализацию
(2) Не существуют, если применять методы Agile
(3) Требуют для их управления специального инструментария, например диаграмм Ганта, критикуемых в Agile
(4) Требуют распределения работ, совместимого с ограничениями, накладываемыми зависимостями
Какие утверждения справедливы для закона Боема, подтвержденного экспериментальными исследованиями:
(1) Существует единственная объективная характеристика программного проекта – номинальная стоимость
(2) Существует единственная объективная характеристика программного проекта – номинальное время выполнения проекта
(3) Объективно существуют две независимые характеристики проекта - номинальная стоимость и номинальное время выполнения проекта
(4) Объективно существующие две характеристики проекта - номинальная стоимость и номинальное время выполнения проекта связаны между собой
(5) Изменение номинальной стоимости может повлечь изменение номинальной длительности, но лишь в ограниченных пределах
Парное прогаммирование – эта идея:
(1) Прекрасная
(2) Ужасная
(3) Шумно рекламируемая
(4) Хорошая
Какие утверждения справедливы в походах Agile относительно таких характеристик проекта, как функциональность и длительность:
(1) Методы Agile, в особенности Scrum, отдают четкое предпочтение функциональности по отношению к длительности
(2) Методы Agile, в особенности Scrum, отдают четкое предпочтение длительности по отношению к функциональности
(3) Методы Agile имеют инструменты, позволяющие обеспечить выполнение проекта с полностью запланированной функциональностью в заданные сроки
(4) Методы Agile ведут разработку проекта в соответствии с принципом "либо что, либо когда". По крайней мере, таково мнение автора книги
Какие методы разработки программных систем относятся к Agile:
(1) Уединенное программирование (Single)
(2) Экономное программирование(Lean)
(3) Схватка (Scrum)
(4) Функциональное программирование (Functional)
Какие принципы характерны для Agile метода Lean – Экономного программирования:
(1) Поставлять как можно позже
(2) Строить целостное решение
(3) Доверять решения потребителям или менеджеру проекта
(4) Исключить затраты
(5) Видеть целое
В Agile отрицается необходимость этапа "предваряющего анализа". Какие практики применяются в Agile в обоснование справедливости этого тезиса:
(1) Итеративная разработка
(2) Отказ от тестирования на итерациях
(3) Пользовательские истории, как замена формальных требований
(4) Рефакторинг
(5) Ранняя поставка работающих версий системы с ограниченным функционалом
(6) Поставка на начальном этапе работающей системы с полной реализацией запланированного функционала
Какие высказывания являются справедливыми:
(1) Множество примеров иногда может доказать справедливость утверждения
(2) Множество примеров всегда может доказать справедливость утверждения
(3) Множество примеров никогда не может доказать справедливость утверждения
(4) Множество примеров с большой долей вероятности может убедить в справедливости утверждения
(5) Письменных описаний недостаточно. Устное общение также необходимо
Какие доводы приводят сторонники Agile, критикуя "Предваряющий анализ":
(1) Принципиально невозможно сформулировать требования к еще не созданной системе
(2) Требования меняются в ходе разработки и потому "документ требований", создаваемый в начале работы, является бесполезным
(3) Следование первоначальному плану, который задается статическим документом требований, не соответствует изменяющимся запросам пользователей
(4) Архитектурные решения следует принимать в тот момент, когда появляется проблема, но не раньше
(5) Не следует слушать пользователей. Все решения принимают разработчики
Какие из официальных Agile принципов автор книги не считает принципами, поскольку они не обладают либо свойством абстрактности (являются практиками), либо свойством нетривиальности (являются бесспорными истинами):
(1) Над проектом должны работать мотивированные профессионалы
(2) Работающий продукт – основной показатель прогресса
(3) Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта
(4) Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
Agile выступает за самоорганизуемую команду, передавая команде традиционные обязанности менеджеров. Что, по мнению Agile, не должны делать менеджеры:
(1) Требовать отчеты о проделанной работе
(2) Представлять интересы команды в общении с руководством
(3) Принимать решения, какие функции следует реализовать
(4) Управлять ресурсами, включая поставщиков и партнеров по аутсорсингу
Разработка в Agile ведется итеративно. Итерации, следуя Scrum, называются спринтами. Какие утверждения справедливы:
(1) Длительность спринта фиксирована и не превышает месяца
(2) Если функциональность, запланированная для выполнения на итерации, не реализована, то продление длительности спринта возможно только по разрешению Владельца продукта или менеджера проекта
(3) Если функциональность, запланированная для выполнения на итерации, не реализована, то реализация функциональности переносится на следующий спринт, либо отклоняется
(4) Никто не вправе изменить продлить длительность спринта
Какие воззрения следует считать справедливыми относительно периодичности построения сборки (Build) системы:
(1) Сборка процесс трудоемкий, поэтому она должна выполняться не чаще одного раза в месяц
(2) Сборку следует проводить ежедневно
(3) Сборка должна проводиться всякий раз, когда в систему вносится изменение
(4) Справедлив лозунг: "Build должен работать"
Тесты в Agile являются одним из основных продуктов разработки. Сама разработка управляется тестами. Какие утверждения справедливы относительно тестов:
(1) Юнит-тест – это "юный" тест, создаваемый в начале разработки, в отличие от сложных, комплексных тестов
(2) Юнит-тест – это совокупность тестов для тестирования одного модуля (юнита)
(3) Юнит-тест – это отдельный тест для тестирования модуля
(4) Регрессионный тест – это тест, при прогоне которого система "рухнула" - не прошла тест
(5) Разработка TDD построена так, что каждый юнит-тест является регрессионным тестом
Какие принципы лежат в основе идей Agile:
(1) Рассматривать тесты, как ключевой ресурс
(2) Выражать требования через сценарии
(3) Поставить клиента в центр
(4) Рекламировать систему до ее выпуска
Одним из принципов Lean является принцип "видения целого", не сосредоточиваясь на малых ценностях. Что понимается под малыми ценностями в Lean:
(1) Мониторинг индивидуальной производительности
(2) Мониторинг командной производительности
(3) Выдерживание общих сроков выполнения проекта
(4) Соблюдение промежуточных контрольных сроков
(5) Соблюдение бизнес - контрактов
Пользовательские истории и требования, - какие утверждения следует считать справедливыми:
(1) Пользовательские истории представляют требования пользователей, выраженные в абстрактной форме
(2) Задание формализованных требований исключает необходимость задания пользовательских историй
(3) Пользовательские истории представляют способ проверки полноты требований
Кому принадлежит высказывание: "Мысль изреченная есть ложь":
(1) Автору книги
(2) Автору одной из книг по Agile
(3) Пушкину
(4) Тютчеву
Сторонники Agile отождествляют "прогнозируемый процесс" с "водопадом", поскольку:
(1) Модель "водопада" является "прогнозируемым процессом". Отождествляя прогнозируемый процесс с водопадом, можно приписать прогнозируемому процессу все недостатки, присущие модели водопада
(2) Модели "жизненного цикла" у водопада и прогнозируемого процесса совпадают
(3) В модели водопада и в прогнозируемом процессе начальным этапом является этап "предваряющего анализа", критикуемый в Agile
"Поставить клиента в центр" - важный принцип Agile. Как следствие этого принципа, в Agile представитель клиентов включается в команду разработчиков. Какие утверждения, связанные с этим принципом, следует считать справедливыми:
(1) Взаимодействие с клиентами должно осуществляться в течение всего проекта
(2) Взаимодействие с клиентами заменяет требования
(3) Сопричастники (разные группы пользователей проекта) имеют зачастую противоположные интересы. Единственный представитель клиентов в команде не может отразить все разнообразие интересов
(4) Представитель клиентов, включаемый в команду, является экспертом высокой квалификации и способен выразить интересы всех групп пользователей
Agile выступает за самоорганизуемую команду, передавая команде традиционные обязанности менеджеров. Что, по мнению Agile, должны делать менеджеры:
(1) Выбирать задачи для реализации
(2) Создавать комфортные условия работы программистов
(3) Распределять работы между программистами
(4) Обеспечивать требуемую техническую поддержку – компьютеры, сеть, интернет и прочее
Какие особенности "ежедневных встреч" Scrum имеют место для распределенных команд:
(1) Члены команды могут работать в различных временных зонах, что затрудняет организацию встреч. Поэтому ежедневные встречи заменяются встречами два три раза в неделю
(2) Длительность встреч и их ежедневный характер является незыблемым правилом Scrum, применяемым и для распределенных команд
(3) Длительность встреч увеличивается
(4) На встречах могут решаться и технические вопросы, чтобы не назначать трудно организуемые дополнительные встречи
Что понимается под парным программированием:
(1) Парное программирование – это техника программирования, в которой каждый программный модуль разрабатывается независимо двумя членами команды
(2) Техника программирования, при которой один участник создает программу, другой ее тестирует
(3) Техника, при которой программные элементы создаются парой, непосредственно работающей за одним столом и за одним компьютером
(4) При парном программировании оба члена пары работают за одним компьютером, периодически меняясь местами при наборе кода, вслух обсуждая детали создаваемого кода
Как оцениваются "пользовательские истории":
(1) Каждой истории приписывается равное количество баллов
(2) Трудоемкость историй выражается в "человеко-днях" и представляет абсолютную оценку
(3) Трудоемкость историй оценивается в баллах и представляет относительную оценку, где за единицу, например, принимается трудоемкость простейшей истории
(4) "Конус неопределенности" является доказательством того, что оценки трудоемкости историй обладают большой степенью неопределенности на протяжении всего проекта
(5) "Конус неопределенности" отражает тот факт, что оценки трудоемкости историй становятся все более точными в ходе развития проекта
Какие ключевые роли предполагаются в Agile:
(1) Потребитель продукта
(2) Владелец продукта
(3) Разработчик продукта
(4) Менеджер продукта
Какова Большая идея Agile метода XP:
(1) Снижение затрат
(2) Добавление, затем Упрощение
(3) Закрытое окно – Замораживание требований на время выполнения итерации
(4) Осмотическая Коммуникация
Какие утверждения справедливы относительно "зависимостей между функциями системы" и сложностью системы:
(1) Для систем с аддитивной сложностью анализ зависимостей прост и позволяет организовать последовательный выбор функций на реализацию
(2) Для систем с мультипликативной сложностью анализ зависимостей прост, что позволяет отказаться от инструментария управления зависимостями, подобного диаграммам Ганта
(3) Для систем с мультипликативной сложностью анализ зависимостей прост и позволяет организовать последовательный выбор функций на реализацию
(4) Для систем с аддитивной сложностью анализ зависимостей прост, что позволяет отказаться от инструментария управления зависимостями, подобного диаграммам Ганта
Кто обходился устными контактами, не пользуясь записями:
(1) Русские купцы при заключении договоров
(2) Сократ
(3) Разработчики первых операционных систем
(4) Разработчики атомных электростанций
Какие утверждения справедливы по отношению к документу требований:
(1) Ошибки в документе требований легко исправимы. Эти исправления могут быть сделаны на любом этапе работы над программной системой, что никак не отражается на самой системе
(2) Одним из основных приемов при создании документа требований является опрос сопричастников будущей системы
(3) Одним из основных приемов при создании документа требований является опрос программистов – разработчиков системы
(4) Одной из современных форм документа требований является документ, размещаемый в облаке, доступный для совместного редактирования
"Разрабатывайте минимальный продукт" - важный принцип Agile. Реализуя этот принцип, следует создавать только запрашиваемый продукт. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:
(1) Создавайте архитектуру, поддерживающую будущие расширения
(2) Создавайте программные элементы настолько общими, насколько это возможно
(3) Делайте простейшую вещь, которая может еще выполнять работу
(4) Заботьтесь только о том, что нужно здесь и сейчас
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие утверждения верны относительно Владельца продукта:
(1) Владелец продукта играет роль менеджера проекта
(2) Владелец продукта разрешает технические споры, возникающие в процессе реализации
(3) Владелец продукта понимает задачи бизнеса, для которого строится система и отвечает за определение функциональности проекта
(4) Владелец продукта определяет "что делать", но не определяет "как делать"
Какие утверждения справедливы относительно "игры в планирование":
(1) Потребители задают приоритеты множества функциональных элементов
(2) Разработчики задают приоритеты множества функциональных элементов
(3) Разработчики дают оценку трудоемкости каждого функционального элемента
(4) Происходит пересмотр оценок разработчиков и потребителей, пока разработчики не согласятся на реализацию всех функциональных элементов
(5) Происходит отбор тех элементов, которые обладая высоким приоритетом, позволяют уложиться в сроки, отведенные на разработку проекта
Какие утверждения справедливы относительно понятия "рефакторинг":
(1) Рефакторинг может изменить семантику модуля
(2) Рефакторинг не должен изменять семантику модуля
(3) Рефакторинг должен улучшить качество кода и его архитектуру
(4) Рефакторинг создает комментарии, проясняющие реализацию модуля
Понятие "сделано" для задачи, реализующей пользовательскую историю, должно быть строго сформулировано и однозначно трактоваться всеми членами команды. Каковы максимальные требования для этого понятия:
(1) Создан тест и написан код, на котором тест проходит
(2) Написан код, прошедший юнит-тестирование
(3) Написан код, прошедший приемное тестирование
(4) Написан код, прошедший все этапы тестирования, не имеющий технических долгов
Какие практики лежат в основе идей Agile:
(1) Игра в планирование
(2) Планирующий покер
(3) Динамическое тестирование;
(4) Рефакторинг
Осмотическая (естественная, всепроникающая) коммуникация – это Большая идея какого метода:
(1) Lean
(2) XP
(3) Scrum
(4) Crystal
Какие утверждения следует считать корректными относительно роли потребителя в команде:
(1) Владелец продукта - отличная роль в командах Scrum
(2) В любую команду следует включать потребителя, оценивающего качество создаваемого кода
(3) В любую команду следует включать потребителя, отвечающего на все вопросы, связанные со спецификой проблемной области
(4) Связь с потребителями в процессе разработки системы играет важную роль, но не обязательно включать потребителей в состав команды
Одно из важных наблюдений состоит в том, что "запись высказывания придает высказыванию излишнюю убедительность, которой текст в действительности может не обладать". Какие уроки вытекают из этого наблюдения:
(1) Записи требований к проекту недостаточно. Запись требований не гарантирует ни их точности, ни их корректности
(2) Запись требований представляется излишней тратой усилий
(3) Запись требований необходима, но недостаточна. Необходимы также вербальные контакты между участниками проекта
Сторонники Agile отрицают необходимость создания документа требований по причине затратности и изменчивости этого документа. Какие аргументы приводит автор книги, оспаривая тезис "затратности":
(1) Пусть в документ требований включена некоторая функция ![math]()
, в ходе работы над системой может выясниться, что функция ![math]()
не требуется в системе и может быть удалена. Включение и удаление ![math]()
требует определенных затрат. При построении прототипа системы, включающего реализацию ![math]()
, также потребуются затраты, которые могут превзойти затраты в сравнении с подходом, предлагаемым документом требований
, в ходе работы над системой может выясниться, что функция не требуется в системе и может быть удалена. Включение и удаление требует определенных затрат. При построении прототипа системы, включающего реализацию , также потребуются затраты, которые могут превзойти затраты в сравнении с подходом, предлагаемым документом требований
(2) Документ требований и построение прототипа системы являются дополняющими подходами
(3) Документ требований и построение прототипа системы являются альтернативными подходами, исключающими друг друга
Какие утверждения, связанные со сложностью проекта, справедливы:
(1) Последовательное добавление новой функциональности в проект возможно для проектов с аддитивной сложностью
(2) Последовательное добавление новой функциональности в проект возможно для проектов с мультипликативной сложностью
(3) Любой проект с мультипликативной сложностью можно преобразовать в проект с аддитивной сложностью
(4) Простой итеративный подход, начинающийся с базовой функционирующей системы, в которую последовательно добавляется новый функционал, может привести к краху системы
(5) Для систем с мультипликативной сложностью необходимо "дальнее предвидение"
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие обязанности не возлагаются на Scrum Мастера:
(1) Отвечает за то, чтобы команда применяла практики Scrum и выполняла предписанные Scrum правила
(2) Устраняет любые препятствия, возникающие у членов команды при реализации задач во время спринта, как технические, так и организационные
(3) Распределяет задачи между членами команды
(4) Подводит итоги спринта
Какие утверждения справедливы относительно игры в "покер планирования":
(1) Каждой пользовательской истории члены команды выставляют оценку трудоемкости по своему усмотрению
(2) Окончательной оценкой трудоемкости истории признается максимальная оценка, выставленная одним из членов команды
(3) Окончательной оценкой трудоемкости истории признается минимальная оценка, выставленная одним из членов команды
(4) После показа оценок начинается обсуждение, в результате которого члены команды на очередной итерации могут изменить свои оценки
(5) Окончательной оценкой является оценка, достигнутая в результате компромисса
(6) Компромиссная оценка всегда достигается в сеансе игры
Какие этапы характерны для Разработки, управляемой тестами, в XP:
(1) Вначале создается код
(2) Вначале создается тест
(3) До написания кода запускается набор тестов, на котором все тесты должны проходить за исключением последнего добавленного теста
(4) До написания кода запускается набор тестов, на котором все тесты должны проходить
(5) Пишется код, после которого все тесты из набора тестов должны проходить
(6) Выполняется рефакторинг системы
Что отличает "бэклог" итерации от бэклога продукта:
(1) Бэклог продукта содержит варианты использования, а бэклог итерации – пользовательские истории
(2) В Бэклог продукта входят только ключевые истории, а в бэклог итерации – все истории
(3) Бэклог продукта содержит полную коллекцию пользовательских историй, а бэклог итерации – только те истории, которые выбраны для реализации на данной итерации
(4) Как правило, бэклог итерации содержит не сами истории, а задачи, сформированные на основе историй, отобранных для реализации. Бэклог продукта содержит только истории
Какие инструменты используются в Agile:
(1) Ревизские сказки
(2) Карты историй
(3) Панель историй
(4) Повести историй
Какие приемы характерны для Agile метода XP – Экстремального программирования:
(1) Рефакторинг
(2) Балансировка
(3) Коллективное владение кодом
(4) Разработка, управляемая тестами
(5) Введение Владельца продукта
(6) Пользовательские истории
Какие идеи Agile считаются автором книги излишне рекламируемыми, хотя и не вредными, но и не столь полезными:
(1) Сохранение устойчивого темпа
(2) Игра в планирование
(3) Деление команды на членов и наблюдателей
(4) Отказ от предваряющего анализа
(5) Правило закрытого окна
В ряде книг и статей по Agile в целях рекламы новых подходов разработки программных продуктов применяются недобросовестные риторические приемы. О каких подобных приемах предупреждает автор этой книги:
(1) Убеждение
(2) Доказательство, основанное на примере
(3) Неверифицируемые утверждения
(4) Сострадание
Сторонники Agileотрицают необходимость предваряющего анализа, включающего этап первоначального проектирования. Каковы их доводы:
(1) Деятельность по проектированию должна применяться на уровне индивидуальной итерации системы, чередуясь с фазой реализации
(2) Основным способом улучшения архитектуры системы является рефакторинг, который следует выполнять, когда действующая архитектура перестает удовлетворять потребностям системы
(3) Перед выполнением каждой итерации следует пересматривать архитектурные решения
(4) Проблемы нужно решать не тогда, когда они проявляются, а заранее, прогнозируя их появление
Разработка программного продукта в Agile является итеративной. Какие утверждения справедливы по отношению к характеру этой разработки:
(1) Итеративная разработка Agile является "вертикальной" разработкой, когда проектируется вначале базовый слой, а затем последующие слои, использующие уже построенные компоненты
(2) Итеративная разработка Agile является "горизонтальной" разработкой, когда проектируется полностью функционирующая система с минимальной функциональностью, а затем последовательно расширяется функциональность системы
(3) Итеративный стиль разработки Agile хорошо подходит для систем с аддитивной сложностью
(4) Итеративный стиль разработки Agile хорошо подходит для систем с мультипликативной сложностью
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие обязанности не возлагаются на команду:
(1) Распределять задачи между членами команды
(2) Подводить итоги спринта
(3) Давать оценку работы каждого члена команды
(4) Устранять препятствия технические и организационные, возникающие в ходе работы
Какие утверждения в Agile считаются справедливыми относительно организации офисного пространства:
(1) Рабочее пространство должно быть открытым
(2) Разработчики должны располагаться в большой комнате
(3) Столы разработчиков должны располагаться по кругу или должен быть единый круглый стол
(4) Контакты и обсуждение проблем группой разработчиков непременное условие эффективности процесса разработки
(5) Все технические обсуждения должны вестись в едином рабочем пространстве
Что отличает TFD разработку от TDD разработки:
(1) Всякая TFD разработка включает TDD разработку
(2) Всякая TDD разработка включает TFD разработку
(3) Рефакторинг является частью процесса TFD разработки
(4) Разработка TFD являясь подмножеством TDD, предъявляет менее строгие требования, что может приводить к снижению качества создаваемой системы
Панель задач, предназначенная для визуализации процесса разработки, позволяет:
(1) Каждому освободившемуся члену команды взять на реализацию задачу из списка еще не выбранных задач
(2) Выбирать для реализации каждый раз наиболее важную задачу из вершины списка, упорядоченного по приоритету (числа баллов, назначенных задаче)
(3) Отмечать наиболее успешных членов команды
(4) Отмечать наименее успешных членов команды
(5) Поднимать боевой дух команды
Общие предпосылки Agile философии базируются на следующих доктринах:
(1) переопределение ролей разработчиков, менеджеров и потребителей
(2) отказ от "Предваряющего анализа"
(3) отказ от итеративной разработки
(4) ограниченная функциональность, основанная на договоренностях
Какие приемы характерны для Agile метода Scrum – Схватка:
(1) Ежедневные встречи
(2) Правило "закрытого окна"
(3) Принятие важных изменений на всем протяжении процесса разработки
(4) Мониторинг процесса разработки – панель задач, диаграммы выполнения
(5) Мониторинг индивидуальной скорости разработки каждого члена команды
(6) Введение роли сертифицированного Мастера команды
Какие идеи Agile автор книги считает хорошими:
(1) Рефакторинг
(2) Планирующий покер
(3) Ежедневные встречи
(4) Правило закрытого окна
(5) Борьба с помехами и затратами
(6) Важность коммуникаций
Укажите истинные высказывания:
(1) "Катастрофизм" - это прием, при котором всякого, кто не использует agile, называют консерватором и бюрократом
(2) "Неверифицируемые заявления" - это прием, при котором Вас убеждают, что проект, не использующий agile, как правило, заканчивается неудачей
(3) "Все или ничего" - это прием, при котором agile метод должен применяться в полном объеме, рекомендуемом авторами. Неполнота использования приводит к неудаче
Какие этапы характерны для моделей жизненного цикла:
(1) Анализ требований
(2) Проектирование
(3) Реализация
(4) Ранжирование
(5) Чистка
(6) Верификация и проверка правильности
Какие стратегии разработки проекта приносят успех в большинстве ситуаций по мнению автора книги:
(1) Поставлять на каждой итерации работающую систему
(2) Вначале следует построить ядро системы, наращивая его до построения полнофункциональной работающей системы
(3) Применять стратегию "дуальной разработки"
(4) На ранних стадиях проекта следует заниматься трудными базисными проблемами
(5) Когда основная инфраструктура построена, следует сосредоточиться на построении работающих версий системы, постепенно наращивая их функциональность
В Agile потребители ставятся во главу угла. Потребители, так или иначе, участвуют в проекте, но их наблюдательная роль отлична от роли разработчиков проекта. Какие утверждения верны относительно наблюдателей и разработчиков, составляющих ядро команды:
(1) В Scrum Владелец продукта является представителем потребителей
(2) В XP представитель потребителей включается непосредственно в команду
(3) В жаргоне программистов наблюдателей называют "свинками" (pigs)
(4) В жаргоне программистов "свинками" (pigs) называют программистов
(5) Наблюдатели могут высказываться, но не имеют права решающего голоса при принятии решений
Какие цели ставятся на регламентируемых встречах Agile команд:
(1) На ежедневных встречах выясняется, что сделано за прошедший день, что будет сделано в текущий день, какие возникают проблемы, мешающие работе
(2) На встрече планирования итерации создается бэклог итерации
(3) На встрече планирования итерации происходит распределение задач между членами команды
(4) На итоговой встрече, завершающей итерацию, оценивается архитектура и качество созданного кода
Какие утверждения следует считать корректными:
(1) Рефакторинг – это процесс, направленный на устранение ошибок в созданном коде
(2) Рефакторинг не означает поиск и устранение ошибок
(3) Постоянное улучшение архитектуры проекта в процессе рефакторинга делает бесполезным процесс "Предваряющего анализа"
(4) Рефакторинг хорошо работает, когда комбинируется с "Предваряющим анализом
Восходящая диаграмма выполнения:
(1) Отображает рост скорости разработки
(2) Отображает падение скорости разработки
(3) Ось ординат которой задает трудоемкость (в баллах) уже решенных задач
(4) Ось ординат которой задает трудоемкость (в баллах) еще не решенных задач
(5) Содержит график средней скорости разработки, позволяющей выполнить проект в заданные сроки
(6) Точки над прямой, задающую среднюю скорость, свидетельствуют об отставании от графика
(7) Точки над прямой, задающую среднюю скорость, свидетельствуют об опережении графика
Каковы главные вклады Agile в приемы программной инженерии:
(1) Расширение полномочий команды
(2) Замораживание требований на время итерации
(3) Парное программирование
(4) Приемы организации тестирования
Какие утверждения справедливы для Agile метода Crystal – Кристалл:
(1) Crystal – полноценный метод разработки, содержащий все необходимые детали
(2) Crystal не является полноценным методом разработки, но определяет важнейшие принципы разработки
(3) По определению является мультиметодом, содержащим 16 вариантов реализации
(4) По мнению автора книги, представляет основу создания третьего поколения Agile методов
Какие идеи Agile автор книги считает отличными:
(1) Непрерывная интеграция
(2) Роль "Владельца продукта"
(3) Планирующий покер
(4) Борьба с помехами
(5) Принцип "нет кода без теста"
(6) Визуализация мониторинга прогресса разработки
Риторический прием "Подстелите соломку" - это, когда:
(1) Вас убеждают, что применяемые сегодня методы разработки ПО обязательно ведут к катастрофе (так что только agile методы могут спасти проект)
(2) Вам предлагают радикальные меры, а в сносках говорят о том, что они не всегда применимы, но никогда точно не говорят, когда эти меры могут использоваться, а когда нет
(3) Вам говорят, что если вы не используете agile, то вы консерватор, реакционер или чудак
На каком из пяти уровней CMMI требуется, чтобы процессы разработки программной системы были строго определены соответствующими документами, процедурами и инструментарием:
(1) Начальный
(2) Управляемый
(3) Определенный
(4) Управляемый на основе количественных данных
(5) Оптимизируемый
В Agile тестирование является основным способом обеспечения качества проекта. Какие утверждения справедливы по отношению тестирования в Agile:
(1) Нет кода без теста
(2) Вначале тест, затем код
(3) Вначале код, затем тест
(4) Код и тест создаются параллельно
Технический долг – это:
(1) Техника, заимствованная на время выполнения проекта
(2) Корректно работающий фрагмент кода или часть архитектуры проекта, которую следует улучшить
(3) Некорректно работающий фрагмент кода
(4) Фрагмент кода или часть архитектуры, подлежащая рефакторингу, в целях улучшения качества работающего проекта
Какие утверждения справедливы для закона Боема, подтвержденного экспериментальными исследованиями:
(1) Увеличивая стоимость работ в 4 раза, можно вдвое уменьшить время выполнения проекта
(2) Никакое увеличение стоимости работ не позволяет уменьшить время выполнения проекта более чем на 25%
(3) Увеличивая время выполнения проекта т в 4 раза, можно вдвое уменьшить стоимость работ
(4) Никакое увеличение времени выполнения проекта не позволяет уменьшить стоимость работ более чем на 25%
Установление жестких временных рамок итераций – это идея:
(1) Прекрасная
(2) Ужасная
(3) Шумно рекламируемая
(4) Хорошая
Что означает принцип: "либо что, либо когда":
(1) Заказчик выбирает "что сделать", команда – "когда это будет сделано"
(2) Заказчик выбирает "когда нужно сделать", команда – что будет сделано"
(3) Заказчик выбирает одно из двух – либо "что сделать", либо "когда сделать", команда выбирает оставшуюся альтернативу
(4) Заказчик устанавливает "что сделать" и "когда сделать". Команда выполняет проект с заданной функциональностью в заданный срок
В манифесте Agile утверждается:
(1) Работающий продукт важнее исчерпывающей документации
(2) Сотрудничество с заказчиком важнее согласования условий контракта
(3) Инструменты важнее работающего кода
(4) Менеджеры важнее программистов
(5) Готовность к изменениям важнее следования первоначальному плану
Какие принципы не характерны для Agile метода Lean – Экономного программирования:
(1) Постоянный анализ кода
(2) Исключение затрат
(3) Доверять решения команде
(4) Ежедневные встречи
(5) Строить целостное решение
Какие утверждения, связанные с "предваряющим анализом" следует считать справедливыми:
(1) Итеративная разработка позволяет отказаться от предваряющего проектирования
(2) Итеративная разработка полезная практика, но она не должна заменять предваряющее проектирование
(3) Рефакторинг позволяет отказаться от предваряющего проектирования архитектуры
(4) Рефакторинг – один из важнейших вкладов Agile, но он не должен заменять предваряющее проектирование архитектуры
(5) Пользовательские истории позволяют обойтись без предваряющего этапа формализации требований
Пример элемента ![math]()
со свойством ![math]()
доказывает справедливость утверждения:
со свойством 
доказывает справедливость утверждения:
(1) Все ![math]()
обладают свойством ![math]()
обладают свойством
(2) Существует элемент ![math]()
, обладающий свойством ![math]()
, обладающий свойством
(3) Не все элементы ![math]()
обладают свойством ![math]()
обладают свойством
(4) Не существует элемент ![math]()
, не обладающий свойством ![math]()
, не обладающий свойством
(5) Не существует элемент ![math]()
, обладающий свойством ![math]()
, обладающий свойством Какие доводы приводит автор книги, настаивая на необходимости проведения "Предваряющего анализа":
(1) Архитектурные ошибки являются самыми дорогостоящими ошибками. Если такая ошибка обнаруживается на поздних этапах, то приходится переделывать большую часть уже выполненной работы. Поэтому основные решения следует тщательно готовить на этапе предваряющего анализа
(2) Документ требований не является догмой, это динамический документ, являющийся частью проекта и изменяющийся в ходе выполнения проекта
(3) Документ требований должен быть всеобъемлющим, учитывающим все возможные ситуации, возникающие в ходе выполнения проекта
(4) Архитектура проекта должна быть полностью спроектирована до начала работы над кодом
(5) Инженерии программ следует учитывать опыт инженерной деятельности, при которой ни одна серьезная разработка не начинается без проведения этапа проектирования
Автор книги вводит собственную классификацию принципов Agile, отличную от официальной. Какие принципы введены автором?
(1) Простота – искусство минимизации лишней работы – крайне необходима
(2) Разрабатывать минимально необходимое ПО
(3) Сохранять устойчивый темп разработки
(4) Наивысшим приоритетом для нас является удовлетворение потребностей клиента
Agile выступает за самоорганизуемую команду, передавая команде традиционные обязанности менеджеров. Что, по мнению Agile, не должны делать менеджеры:
(1) Выносить поощрения и наказания программистам, оценивая результаты их работы
(2) Представлять интересы команды в общении с внешним окружением
(3) Распределять работы между членами команды
В Agile приветствуются изменения. Какие утверждения справедливы относительно стратегии управления изменениями:
(1) Изменения, предлагаемые клиентами, принимаются безоговорочно на всем протяжении разработки
(2) Изменения, предлагаемые разработчиками, принимаются на всем протяжении разработки при условии их утверждения командой
(3) Изменения принимаются только в процессе выполнения очередной итерации
(4) Изменения принимаются только после окончания очередной итерации и до начала следующей итерации
(5) Правилом "закрытого окна" называется правило, запрещающее вносить какие-либо изменения во время выполнения итерации
Какие утверждения справедливы относительно понятия "сборка" (Build) системы:
(1) Сборка признается успешной, если все компоненты сборки принадлежат одной версии
(2) Сборка признается успешной, если при интеграции компонентов системы не возникло ошибок
(3) Сборка признается успешной, если интеграция компонентов произошла без ошибок, и прогон всех тестов не выявил ошибок
(4) Современный инструментарий позволяет автоматизировать как сборку нужных компонентов системы, так и прогон всех требуемых тестов
Тесты в Agile являются одним из основных продуктов разработки. Сама разработка управляется тестами. Какие утверждения справедливы относительно процесса тестирования:
(1) Авторы методов Agile внесли большой вклад в разработку инструментария, автоматизирующего процесс тестирования, в частности, в разработку инструментария XUnit
(2) В инструментарий XUnit включается компонент, называемый "оракулом", предсказывающий упадет ли система на тесте или нет
(3) В инструментарий XUnit включается компонент, называемый "оракулом", определяющий условия успешного прохождения теста
(4) Регрессионный набор тестов является "возрастающим" продуктом, расширяемым в ходе разработки
Какие инструменты (артефакты) разработаны в Agile:
(1) виртуальные (пользовательские истории, график ликвидации нереализованных элементов и задач)
(2) материальные (карточки историй, панель историй, открытая комната)
(3) личностные (отображающие график участия каждого исполнителя)
(4) организационные (календарь совместных заседаний заказчиков и исполнителей)
Какие утверждения справедливы относительно Agile метода Lean – Экономного программирования:
(1) Метод представляет полноценный метод разработки
(2) Метод устанавливает ряд принципов, декларирующих что важно, а что не имеет особой ценности в процессе разработки
(3) Основная идея "экономичности" заимствована у методов индустриального производства, в частности, производства автомобилей фирмы Тойота
(4) Принципы, принесшие успех Тойоте, полностью применимы и к производству программных систем
Пользовательские истории и требования, - какие утверждения следует считать некорректными:
(1) Для задания свойств проблемной области следует использовать пользовательские истории, а не формальные требования
(2) Для задания свойств проблемной области следует использовать формальные требования, а не пользовательские истории
(3) Пользовательские истории не являются заменой выработки системных требований, определяющих ключевые абстракции
(4) Пользовательские истории являются заменой выработки системных требований, определяющих ключевые абстракции
Какие высказывания являются справедливыми:
(1) Вербальные контакты всегда лучше письменных
(2) Письменные контакты всегда лучше вербальных
(3) Вербальные контакты иногда лучше письменных
(4) Письменные контакты иногда лучше вербальных
(5) Предпочтение следует отдавать вербальным контактам, закрепленным письменным документом
(6) Если требования записаны, то это является свидетельством их точности и корректности
Автор книги считает, что прогнозируемый процесс не является водопадом, поскольку:
(1) Модель "водопада" является "прогнозируемым процессом", но отсюда не следует обратное утверждение. Отождествлять прогнозируемый процесс с водопадом некорректно
(2) У прогнозируемого процесса и водопада этапы разработки различаются
(3) Прогнозируемый процесс является моделью "жизненного цикла" с циклическим повторением этапов разработки, в отличие от классического водопада, не предусматривающего циклов
"Разрешать самоорганизацию команды" - важный принцип Agile. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:
(1) Необходимо поставить менеджмент на положенное ему место. На первом месте должны быть люди, фактически делающие работу
(2) Самоорганизуемой команде может требоваться тренер и наставник, но не требуется контроль и приказы
(3) Большинство проектов нуждается в менеджере, исповедующем стиль "Командуй и контролируй"
(4) Успехи команды Стива Джобса связаны с тем, что команда была саморганизуемой
(5) Традиционные для менеджера обязанности, такие как распределение задач, могут быть переданы команде
Agile выступает за самоорганизуемую команду, передавая команде традиционные обязанности менеджеров. Что, по мнению Agile, должны делать менеджеры:
(1) Требовать отчеты о проделанной работе
(2) Представлять интересы команды в общении с руководством
(3) Принимать решения, какие функции следует реализовать
(4) Управлять ресурсами, включая поставщиков и партнеров по аутсорсингу
Какие вопросы обсуждаются на "ежедневных встречах" Scrum:
(1) Что сделал каждый участник за предыдущий день
(2) Что не сделал каждый участник за предыдущий день
(3) Что предполагает сделать каждый участник в следующий день
(4) Какие препятствия мешают работе
(5) Кто виноват, что работа не выполнена вовремя
Как создаются пары в парном программировании:
(1) Пары создаются случайным образом по жребию
(2) Пары создаются на основе личных привязанностей и не меняются на протяжении всего проекта
(3) Строгих правил создания пар не существует
(4) Принято, что пары достаточно часто следует менять, чтобы все участники команды могли поработать в парах
(5) Пары подбираются так, чтобы один из членов пары мог выступать в роли ментора, другой – в роли ученика
Пользовательские истории и варианты использования. Какие утверждения считаются справедливыми в Agile для этих понятий:
(1) Пользовательская история представляет описание некоторой конкретной функциональности так, как ее видят пользователи
(2) Вариант использования – это описание вариантов одной и той же пользовательской истории
(3) Вариант использования задает один из сценариев всего процесса взаимодействия пользователя с системой
(4) При описании пользовательской истории требуется описать тройку – роль пользователя, его цель и преимущество истории
(5) При описании варианта использования требуется описать тройку – роль пользователя, его цель и преимущество истории
Ключевую роль в проектах Agile играют:
(1) Менеджер проекта
(2) Владелец проекта
(3) Архитектор проекта
(4) Потребитель (Customer – заказчик, пользователь)
(5) Ведущий программист
Какова Большая идея Agile метода Lean:
(1) Снижение затрат
(2) Добавление, затем Упрощение
(3) Закрытое окно – Замораживание требований на время выполнения итерации
(4) Осмотическая Коммуникация
Какие утверждения справедливы относительно "зависимостей между функциями системы":
(1) Agile разработка системы гарантирует отсутствие зависимостей
(2) Наличие зависимостей не мешает процессу независимой разработки функций
(3) Зависимости, возникающие между функциями, могут быть причиной мультипликативной сложности
(4) Последовательная итеративная схема выбора функций на реализацию неприемлема при наличии зависимостей между функциями
Какие доводы приводит автор книги в пользу записи требований к программной системе:
(1) Устная речь в большей степени неоднозначна в сравнении с неоднозначностью записи
(2) Письменная форма требований однозначна, устная форма неоднозначна
(3) В результате устного общения для принятия окончательного решения рекомендуется записать решение в письменной форме
(4) Устное общение способствует принятию решения, не требуя его записи
Какие утверждения справедливы по отношению к документу требований:
(1) Документ требований позволяет построить правильную систему
(2) Формы представления документа требований могут быть различными – текстовый документ, документ Вики, совместно редактируемый документ, размещаемый в облаке
(3) Документ требований после его создания и утверждения замораживается и не может быть изменен в ходе работы над проектом
(4) Одной из форм создания документа является семинар сопричастников проекта
"Разрабатывайте минимальный продукт" - важный принцип Agile. Реализуя этот принцип, следует создавать только код и тесты. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:
(1) Документы, диаграммы, модели являются расходными материалами, не являясь частью финального продукта. Необходимость каждого расходного материала должна быть предметом тщательного анализа
(2) Архитекторы проекта должны построить общую архитектуру проекта, представляющую важную часть продукта
(3) Тесты представляют важную часть продукта
(4) Для финального продукта только код и тесты имеют ценность
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие обязанности возлагаются на Владельца продукта:
(1) Отвечает за определение и сопровождение бэклога продукта – списка заказанных функций
(2) В начале каждого спринта выбирает пользовательские истории для их реализации в течение спринта
(3) Распределяет задачи между членами команды
(4) В конце спринта оценивает результаты спринта
Какие утверждения справедливы относительно "игры в планирование":
(1) Разработчики никогда не меняют своей оценки трудоемкости элементов
(2) Потребители никогда не меняют своей оценки приоритета элемента
(3) Для достижения компромисса потребители и разработчики на каждой итерации меняют оценки, стараясь достичь компромисса
(4) Игра в планирование является антагонистической игрой
(5) Игра в планирование является игрой, целью которой является достижение компромисса между различными критериями
Что такое "рефакторинг":
(1) Процесс факторизации системы
(2) Процесс, выявляющий и устраняющий неблагоприятные факторы, мешающие разработке системы
(3) Процесс улучшения качества уже созданного кода с возможным изменением его архитектуры
(4) Процесс, направленный на улучшение архитектуры кода, который предстоит разработать на последующих этапах развития системы
Какие утверждения справедливы относительно понятия "рабочее пространство":
(1) Вся команда должна иметь возможность работать в одном открытом пространстве
(2) Наряду с открытым рабочим пространством должны быть индивидуальные кабины
(3) Загородки и индивидуальные кабины не допустимы
(4) Каждый член команды доступен в открытом пространстве
(5) Каждый член команды доступен в индивидуальной кабине
Организационные практики, применяемые в Agile:
(1) Ежедневные встречи (Daily meeting)
(2) Непрерывная интеграция (Continuous integration)
(3) Разделяемое владение кодом (Shared code ownership).
(4) Недопущение ретроспективы (No Retrospective)
Закрытое окно – это Большая идея какого метода:
(1) Lean
(2) XP
(3) Scrum
(4) Crystal
Тесты и код. Какие утверждения справедливы:
(1) С каждым кодом, представляющим реализацию некоторого функционала, должен быть связан тест (набор тестов), проверяющим этот код
(2) Обязательное требование всякой разработки – вначале следует писать тест, затем код, на котором тест должен проходить
(3) Обязательное требование всякой разработки – вначале следует писать код, затем тест, позволяющий отладить код
(4) Разработка TDD требует дополнительного рассмотрения высокоуровневой перспективы, рассмотрения всей системы в целом
Одно из важных наблюдений состоит в том, что "запись высказывания придает высказыванию излишнюю убедительность, которой текст в действительности может не обладать". Какие уроки вытекают из этого наблюдения:
(1) Коммуникация важный, но сложный процесс, требующий применения разных форм коммуникации
(2) Число разработчиков следует минимизировать, уменьшая неоднозначность понимания текста
(3) Следует избегать письменной формы записи документов
Сторонники Agile отрицают необходимость создания документа требований по причине затратности и изменчивости этого документа. Какие аргументы приводит автор книги, оспаривая тезис "изменчивости":
(1) Для построения системы необходим план, которому необходимо строго следовать
(2) Никто в программной инженерии не требует замораживания требований, выработанных в начале проекта
(3) Требования являются частью программного проекта и могут изменяться подобно остальным компонентам проекта
(4) Наблюдение Agile об изменчивости требований является ошибочным. Требования остаются неизменными
"Простота" - один из принципов Agile. Но понимание этого принципа в Agile не всегда совпадает с пониманием "простоты" в классической программной инженерии. Какие высказывания о простоте согласуются с Agile видением:
(1) Простота в ясном концептуальном базисе и хорошо продуманной структуре системы
(2) Наиболее сложный аспект проектирования системы состоит в декомпозиции на модули
(3) Избегайте работы, которая не является необходимой
(4) Откладывайте решения настолько, насколько это возможно
(5) Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять
(6) Достижение простоты – это добавление работы и иногда существенное
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие утверждения справедливы относительно Scrum Мастера:
(1) Должен быть сертифицированным
(2) Может играть роль тренера
(3) Является ведущим разработчиком – главным программистом
(4) Управляет выполнением задач
Какие утверждения справедливы относительно игры в "покер планирования":
(1) Владелец продукта описывает функциональность элемента
(2) Члены команды дают свою оценку функциональности
(3) Члены команды дают оценку трудоемкости элемента
(4) Оценки трудоемкости выбираются из некоторого фиксированного множества
(5) Если процесс не сходится, то дискуссия прерывается до получения дополнительной информации
Какие утверждения считаются справедливыми в XP относительно TDD – разработки, управляемой тестами:
(1) После каждого добавления кода запускается набор тестов. Код отлаживается, пока все тесты не будут проходить на добавленном коде
(2) Вначале пишется тест, затем создается код
(3) Добавление кода сопровождается рефакторингом системы
(4) Все тесты входят в регрессионный набор тестов
(5) Прохождение тестов гарантирует корректную работу системы
Что такое "бэклог" продукта:
(1) Совокупность задач, сформулированных на основе отобранных пользовательских историй
(2) Совокупность реализованных задач
(3) Совокупность всех пользовательских историй, подлежащих реализации
(4) Совокупность сценариев – вариантов использования
Какие предпосылки лежат в основе идей Agile:
(1) Вера в разумность пользователя
(2) Фокусирование на качестве, достижимом в процессе тестирования
(3) Фокусирование на "Предваряющем анализе" - начальном этапе разработки
(4) Итеративная разработка
Какие утверждения справедливы для Agile метода XP – Экстремального программирования:
(1) Необходима постоянная интеграция разрабатываемого кода
(2) Нельзя создавать код, не создав предварительно тесты, проверяющие функциональность кода
(3) Снижение затрат – главная цель разработки программной системы
(4) Выполнение рефакторинга обязательное условие каждой итерации
(5) Изменения следует принимать в течение всего процесса разработки
Какие идеи Agile считаются автором книги излишне рекламируемыми, хотя и не вредными, но и не столь полезными:
(1) Парное программирование
(2) Отказ от предваряющего анализа
(3) Рефакторинг
(4) Открытое рабочее пространство
(5) Самоорганизуемая команда
В ряде книг и статей по Agile в целях рекламы новых подходов разработки программных продуктов применяются недобросовестные риторические приемы. О каких подобных приемах предупреждает автор этой книги:
(1) Подстелите соломку
(2) Катастрофизм
(3) Все или ничего
(4) Клевета по ассоциации
(5) Слепая вера
(6) Восхождение
На этапе предваряющего анализа не следует делать "слишком много". Какие решения следует принимать на этом этапе:
(1) Проектирование абстракций - абстрактных классов в терминах ООП
(2) Выбор образцов проектирования (паттернов) для решения ключевых проблем
(3) Проектирование спецификаций интерфейса (взаимодействия) между модулями
(4) Проектирование таксономии – семейств классов, связанных отношениями наследования и вложенности
(5) Проектирование и реализация динамических библиотек классов, допускающих повторное использование
Манифест Agile приветствует возможность внесения изменений в системе, идя навстречу пожеланиям пользователей. Однако не все принципы и практики Agile способствуют реализации этой цели. Укажите, какие из утверждений, принимаемых в Agile, затрудняют расширяемость системы:
(1) Построение системы тестов, связанных с каждой функциональностью
(2) Следование принципу YAGNI – "Это Тебе Не Понадобится"
(3) Применение практики "Закрытого окна", когда внесение изменений запрещается в ходе выполнения очередной итерации
(4) Если код сегодня не требуется, то помещать его в систему – расточительство
В Scrum предполагаются всего три роли для участников проекта – Владелец продукта, Мастер, Команда. Какие обязанности возлагаются на команду:
(1) Реализовать задачи, создавая код проекта
(2) Создавать тесты для каждой задачи
(3) Распределять задачи между членами команды
(4) Подводить итоги спринта
(5) Оценивать качество работы членов команды
Какие утверждения в Agile считаются справедливыми относительно организации офисного пространства:
(1) Зона тишины и уединения необходима также как и открытое рабочее пространство
(2) Программист, предпочитающий решать свои проблемы самостоятельно, может быть членом Agile команды
(3) Парное программирование – наиболее эффективный способ разработки
(4) Парное программирование - неприемлемый способ разработки
Что такое TFD:
(1) Разработка системы, получившая название True False Development, требующая на каждой итерации проверки корректности системы
(2) Разработка системы, получившая название Test First Development, требующая создание теста, перед каждой разработкой нового фрагмента кода
(3) Разработка, требующая проведение рефакторинга
Какие утверждения справедливы относительно карт историй:
(1) Карта истории формализована как по размеру, так и по содержанию
(2) Карта истории свободна как по форме, так и по содержанию
(3) Бумажный вариант карт истории теперь не применяется, будучи заменен электронным вариантом
(4) Бумажные карты, размещаемые на панели, способствую лучшей визуализации прогресса разработки
Какие высказывания характерны для Agile:
(1) От документа требований, определяющего цели проекта, зависит успех проекта
(2) Документ требований является бесполезным, поскольку требования меняются в ходе разработки
(3) Основные обязанности менеджеров следует передать команде разработчиков
(4) Роль менеджера проекта чрезвычайно важна
Какие приемы характерны для Agile метода Scrum – Схватка:
(1) Пользовательские истории, трансформируемые в задачи:
(2) TDD – разработка, управляемая тестами
(3) Правило "открытого окна"
(4) Планирование спринта в начале итерации
(5) Обзор спринта по завершении итерации
(6) Рефакторинг
Какие идеи Agile автор книги считает отличными:
(1) Парное программирование
(2) Рефакторинг
(3) Короткие итерации
(4) Принцип закрытого окна
Укажите истинные высказывания:
(1) "Клевета по ассоциации" - это прием, при котором всякого, кто не использует agile, называют консерватором и бюрократом
(2) "Катастрофизм" - это прием, при котором Вас убеждают, что проект, не использующий agile, как правило, заканчивается неудачей
(3) "Все или ничего" - это прием, при котором agile метод должен применяться в полном объеме, рекомендуемом авторами. Неполнота использования приводит к неудаче
Какие практики характерны для модели жизненного цикла RUP (Рациональный Унифицированный Процесс):
(1) Итеративная разработка
(2) Визуализация архитектуры
(3) Анализ проектных ошибок
(4) Непрерывная проверка качества
(5) Непрерывный анализ требований
Одна из практик, применяемых при реализации проекта, связана с выбором задач. Какая стратегия выбора критикуется в Agile:
(1) Важнейшую по Значимости – Первой
(2) Простейшую – Первой, Самую Трудную – Второй
(3) Самую Трудную – Первой
(4) Простейшую – Первой
Какие утверждения следует считать справедливыми:
(1) Кросс функциональная команда – это команда равных, где каждый может выполнять работу любой сложности
(2) Команда "главного программиста" - это команда специалистов, возглавляемых специалистом высокого уровня, выполняющего наиболее ответственную часть работы и отвечающего в первую очередь за успех проделанной работы. Аналогия с хирургической бригадой, выполняющей сложную операцию, где есть хирург и ассистирующие ему специалисты разного уровня
(3) Команда "главного программиста" лучше выполняет работу, чем кросс функциональная команда
(4) Кросс функциональная команда лучше выполняет работу, чем команда "главного программиста"
Какие утверждения справедливы при разработке больших проектов:
(1) Независимо от величины проекта должна быть единая Agile команда, выполняющая этот проект
(2) Большой проект может выполняться несколькими командами, каждая из которых может быть Agile командой, согласовывающая свои действия с другими командами
(3) Принципы Agile не применимы для больших проектов, выполняемых несколькими командами
(4) Для больших проектов, выполняемых несколькими командами, Scrum предлагает подход, называемый Скрум скрумов
Какие утверждения следует считать корректными:
(1) Идея парного программирования в полной мере реализуется, когда пару составляют "равные" личности
(2) Парное программирование применяется во всех Agile подходах
(3) Команда Agile должна следовать строгим стандартам написания кода
(4) Команда Agile свободна в своих действиях и не должна следовать строгим стандартам написания кода
Какие утверждения справедливы относительно понятия "диаграмма выполнения". Эта диаграмма:
(1) Задает среднюю скорость выполнения работ, обеспечивающую завершение проекта в заданные сроки
(2) Задает максимальное и минимальное время выполнения проекта
(3) Отражает текущее состояние работ
(4) Может быть возрастающей или убывающей
(5) Показывает, идет ли процесс с отставанием от графика или его опережением
Каковы главные вклады Agile в приемы программной инженерии:
(1) Центральная роль кода для программного проекта
(2) Центральная роль команды для эффективности процесса разработки проекта
(3) Короткие итерации с временными рамками для устойчивого развития проекта
(4) Избавление от программистов, срывающих график работы, для завершения проекта к заданному сроку .
Какие принципы характерны для Agile метода Crystal – Кристалл:
(1) Короткие итерации
(2) Рефлексивные улучшения
(3) Ежедневные встречи
(4) Принцип "закрытого окна"
(5) Персональная безопасность
Какие идеи Agile автор книги считает вредными:
(1) Ежедневные встречи
(2) Непрерывная интеграция
(3) Отказ от предваряющего анализа
(4) Отказ от средств анализа зависимостей
(5) Планирующий покер
Риторический прием "Клевета по ассоциации" - это, когда:
(1) Вас убеждают, что применяемые сегодня методы разработки обязательно ведут к катастрофе (так что только agile методы могут спасти проект)
(2) Вам предлагают радикальные меры, а в сносках говорят о том, что они не всегда применимы, но никогда точно не говорят, когда эти меры могут использоваться, а когда нет
(3) Вам говорят, что если вы не используете agile, то вы консерватор, реакционер или чудак
(4) Идея, которую автор собирается критиковать, ассоциируется с идеей, которую все критикуют
Методы Agile имеют собственную трехуровневую шкалу зрелости – Shu – Ha – Ri. Что должна делать команда, достигшая высшего уровня зрелости:
(1) Применять стандартные рецепты
(2) Комбинировать существующие рецепты и правила
(3) Уметь превзойти достигнутое
(4) Создавать собственные правила и рецепты
Что представляет собой набор регрессионных тестов в Agile:
(1) В этот набор включаются тесты, на которых система успешно завершает выполнение
(2) В этот набор включаются тесты, при выполнении которых система ломается
(3) Согласно стратегии Agile "вначале тест, затем код" в набор регрессионных тестов попадают все создаваемые тесты
(4) В набор попадают тщательно отобранные тесты, соответствующие значимым сценариям работы системы
Что с точки зрения Agile относится к непроизводительным затратам:
(1) Проведение рефакторинга
(2) Проведение предваряющего анализа
(3) Разработка спецификаций
(4) Построение диаграмм Ганта
(5) Создание тестов
Какие утверждения справедливы для характеристик закона Боема:
(1) Номинальная стоимость проекта – это стоимость проекта, утвержденная заказчиком
(2) Номинальная стоимость проекта – это стоимость проекта, за которую команда готова выполнить проект
(3) Номинальная стоимость – это усредненная оценка стоимости выполнения проекта командой среднего уровня за время, соответствующее номинальной длительности
(4) Номинальная длительность – это усредненная оценка длительности выполнения проекта командой среднего уровня за время, соответствующее номинальной стоимости
(5) Команда первоклассных специалистов может выполнить проект за время, меньшее номинальной длительности, и стоимость проекта может быть существенно ниже номинальной стоимости
Правило закрытого окна – эта идея:
(1) Прекрасная
(2) Ужасная
(3) Шумно рекламируемая
(4) Хорошая
Как в Agile рассматривают такие характеристики проекта как функциональность и длительность:
(1) На итерациях предпочтение отдается длительности. Время итерации фиксировано, функциональность может остаться частично не реализованной
(2) Не гарантируется реализация всей запланированной функциональности в фиксированное время
(3) Методы Agile гарантируют выполнение всей запланированной функциональности в фиксированное запланированное время
(4) На итерациях предпочтение отдается функциональности. Время итерации не фиксируется, но запланированная функциональность должна быть реализованной