Учебник. Московский финансовопромышленный университет Синергия Кафедра Системного программирования
 Скачать 3.83 Mb.
|
|
Тема 2. Роли Вопросы темы: 1 Бизнес-аналитик. 2 Менеджер проекта. 3 Архитектор. 4 Разработчик. 5 Тестировщик. 6 Релиз-менеджер. 7 Администратор баз данных. 8 Разработчик баз данных. Вопрос 1. Бизнес-аналитик. В рамках командной модели MSF (MSF Team Model) бизнес- аналитик участвует в управлении продуктом. Основная задача бизнес- аналитика – разобраться в возможностях системы, относящихся к бизнесу, и раскрыть их команде. Он работает с пользователями и другими заинтересованными лицами, чтобы понимать их потребности и задачи, трансформировать их в конкретные определения, сценарии и требования к качеству, которые команда разработчиков будет использовать для построения приложения. Кроме того, бизнес-аналитик определяет ожидания от функциональных возможностей системы и управляет ими. В проекте он представляет пользователей и участвует в управлении продуктом в том смысле, что постоянно отслеживает интересы пользователей и заказчиков проекта. И наконец, бизнес- аналитикиотвечают за обеспечение взаимодействия между разработчиками и пользователями. Человек, назначенный на эту роль, 18 должен быть добавлен в группу доступа «Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, например такие, как создание и изменение документов, описателей и конечных продуктов. Действия и операции роли Действия: формулировка концепции проекта; разработка требований к качеству; создание сценария; планирование итерации. Операции: написание концепции; определение собирательных образов; уточнение собирательных образов; определение требований к качеству путем «мозгового штурма»; создание моментальных снимков деятельности; определение приоритетов в списке требований к качеству; написание требований к качеству; определение требований безопасности; работа над сценариями методом «мозгового штурма»; определение приоритетов в списке сценариев; оценка задачи по разработке базы данных; выполнение ретроспективного анализа; оценка сценария; оценка требования к качеству; составление графика сценария; составление графика реализации требований к качеству; обзор целей. Вопрос 2. Менеджер проекта. В рамках командной модели MSF менеджер проекта участвует в управлении продуктом. Основная задача менеджера проекта – добиваться выполнения поставленных перед командой задач в соответствии с графиком и в рамках бюджета. На менеджере проекта лежат обязательства по планированию и составлению графика работ, включающие разработку проекта и планов итераций, отслеживание состояния дел и составление отчетов, а также обязательства по определению рисков и выработке мер по их уменьшению. Менеджер проекта также проводит консультации с бизнес-аналитиками по 19 планированию сценариев и выработке требований к качеству для каждой итерации, консультируется с архитекторами и разработчиками для оценки объемов работ, советуется с тестировщиками, чтобы спланировать тестирование, и, кроме того, содействует взаимодействию участников команды. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Администратор проекта» (Project Administrator). Это позволит ему выполнять такие функции, как создание нового проекта, формирование новой команды и добавление в нее участников. Действия и операции роли Действия: контроль итерации; планирование итерации; ведение проекта. Операции: оценка задачи по разработке базы данных; мониторинг итерации; снижение риска; выполнение ретроспективного анализа; определение продолжительности итерации; оценка сценария; оценка требования к качеству; разбиение сценариев на задачи; разбиение требования к качеству на задачи; составление графика сценария; составление графика реализации требований к качеству; оценка хода выполнения; оценка пороговых значений показателей тестов; определение риска; обзор целей; классификация дефектов. Вопрос 3. Архитектор. В рамках командной модели MSF архитектор отвечает за архитектуру проекта. Его основная задача– обеспечить успех проекта путем разработки основных принципов приложения, которые включают в себя как организационную конфигурацию системы, так и физическую структуру ее развертывания. При этом архитектор должен стремиться к снижению сложности путем разделения системы на 20 понятные и простые части. Архитектура приложения чрезвычайно важна, поскольку она не просто устанавливает этапы построения системы, а определяет, будет ли приложение обладать свойствами, присущими успешным проектам. К ним относятся: удобство использования, надежность, практичность сопровождения, производительность и безопасность, а также возможности модификации в случае изменения требований. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, такие как создание и изменение документов, описателей и конечных продуктов. Действия и операции роли Действия: разработка архитектуры решения; планирование итерации. Операции: разделение системы на подсистемы; определение интерфейсов; разработка модели угроз; разработка модели производительности; создание архитектурной модели; создание архитектуры инфраструктуры; определение требований безопасности; разбиение сценариев на задачи; разбиение требования к качеству на задачи. Вопрос 4. Разработчик. В рамках командной модели MSF разработчик выполняет разработку приложения. Его основная задача – реализовать приложение согласно спецификациям и в установленные сроки. Разработчик также помогает уточнять физический дизайн, оценивать время и усилия для выполнения конкретных элементов, выполняет реализацию функций или руководит ею, подготавливает продукт к внедрению и является экспертом команды в технологических областях. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, такие как создание и изменение документов, описателей и конечных продуктов. 21 Действия и операции роли Действия: сборка продукта; устранение дефекта; реализация задачи по разработке; планирование итерации. Операции: разделение системы на подсистемы; определение интерфейсов; разработка модели производительности; запуск сборки; проверка выпуска; исправление сборки; приемка сборки; воспроизведение дефекта; определение причины возникновения дефекта; переназначение дефекта; выбор стратегии устранения дефекта; создание или изменение теста модуля; выполнение теста модуля; рефакторинг кода; обзор кода; интеграция изменений; оценка задачи по разработке; кодирование; анализ кода; оценка задачи по разработке базы данных; выполнение ретроспективного анализа; определение продолжительности итерации; оценка сценария; оценка требования к качеству; разбиение сценариев на задачи; разбиение требования к качеству на задачи; создание заметок о выпуске; развертывание продукта. 22 Вопрос 5. Тестировщик. В рамках командной модели MSF тестировщик выполняет задачи тестирования продукта. Основной задачей тестировщика является выявление проблем в продукте, которые могут неблагоприятно повлиять на его качество. Тестировщик обязан понимать контекст проекта и помогать остальным членам команды понимать решения, основанные на этом контексте. Ключевая цель тестировщика – поиск серьезных дефектов в продукте путем его тестирования и последующее их описание. Каждый найденный дефект тестировщик должен сопроводить точным описанием вредного воздействия и предложить способ обойти дефект, чтобы уменьшить это воздействие. Он должен как можно проще описать дефект и последовательность, в которой его можно воспроизвести. Тестировщик участвует в деятельности команды по определению стандартов качества продукта. Цель тестирования – убедиться, что известные функции работают правильно, и выявить возможные проблемы продукта. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, такие как создание и изменение документов, описателей и конечных продуктов. Действия и операции роли Действия: планирование итерации; закрытие дефекта; тестирование требования к качеству; проверка сценария. Операции: выполнение ретроспективного анализа; разбиение сценариев на задачи; разбиение требования к качеству на задачи; проверка исправления; закрытие дефекта; определение подхода к тестированию; создание теста производительности; создание теста безопасности; создание стрессового теста; создание нагрузочного теста; выбор и запуск тестового задания; 23 документирование дефекта; оценка пороговых значений показателей тестов. Вопрос 6. Релиз-менеджер. В рамках командной модели MSF релиз-менеджер отвечает за операции по выпуску продукта. Основная цель релиз-менеджера – обеспечение выпуска готового продукта. Он координирует выпуск продукта со специалистами по эксплуатации, создает план выпуска продукта и сертифицирует подготовленные к выпуску версии для поставки или развертывания. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Администратор проекта» (Project Administrator). Это позволит ему выполнять такие свои функции, как создание нового проекта, формирование новой команды и добавление в нее участников. Действия и операции роли Действия: выпуск продукта. Операции: исполнение плана выпуска; создание заметок о выпуске; развертывание продукта. Вопрос 7. Администратор баз данных. Основная задача администратора баз данных в контексте разработки базы данных – поддержка создания проектов баз данных, а также внесение изменений проекта в рабочую базу данных. В дополнение к этому он должен выполнять традиционные задачи, такие как ежедневное администрирование и поддержка серверов баз данных. Действия и операции роли Действия: создание проекта базы данных; развертывание проекта базы данных. Операции: создание проекта базы данных; импорт существующей базы данных; установка параметров сборки и развертывания; 24 изменение сгенерированных сценариев; проверка проекта базы данных; размещение проекта базы данных в службе управления исходным кодом; синхронизация проекта базы данных; проверка сборки; выполнение тестирования модулей базы данных; анализ изменений; создание резервной копии рабочей базы данных; установка базы данных на тестовом сервере; установка базы данных. Вопрос 8. Разработчик баз данных. Основная задача разработчика баз данных – выполнение комплекса задач по разработке базы данных в установленные сроки. Кроме того, он отвечает за оценку стоимости, контроль над реализацией функций и помощь остальным участникам команды по вопросам, связанным с базами данных. Разработчик баз данных совместно с администратором баз данных и прикладными разработчиками участвует в итеративном жизненном цикле разработки базы данных. Действия и операции роли Действия: реализация задачи по разработке базы данных; планирование итерации. Операции: оценка задачи по разработке базы данных; обновление локальной среды проекта; выполнение теста модуля базы данных; рефакторинг базы данных; определение продолжительности итерации; оценка сценария; оценка требования к качеству; разбиение сценариев на задачи; разбиение требования к качеству на задачи. 25 Тема 3. Действия Вопросы темы: 1 Контроль итерации. 2 Планирование итерации. 3 Разработка архитектуры решения. 4 Формулирование концепции проекта. 5 Разработка требований к качеству. Вопрос 1. Контроль итерации. Все выполняющиеся итерации необходимо контролировать. Время, затрачиваемое на решение проблем, влияет на общий темп проекта. При выдаче запросов поиска проблем зарегистрировать заблокированные описатели позволяет флаг «Issue». Запросы поиска проблем должны выполняться хотя бы один раз в начале рабочего дня. По завершении итерации необходим анализ сделанного для определения путей совершенствования процесса и рабочей среды. Если итерация начинается с собрания, на котором она планируется, заканчиваться она должна собранием, закрывающим итерацию, на котором проводится ретроспективный анализ проделанной работы. Операции: Мониторинг итерации. Обзор приоритетов в описателе. Снижение риска. Выполнение ретроспективного анализа. Операция: Мониторинг итерации Понимание текущего состояния итерации очень важно для ее успешного завершения. Один из важнейших моментов в оценке хода итерации – анализ описателей высокоприоритетных сценариев, требований к качеству и ошибок в данной итерации. Актуализируйте план итерации, чтобы увидеть незакрытые задачи, связанные с описателями перечисленных типов. Определите завершившиеся задачи и распределите приоритеты так, чтобы сначала заканчивались наиболее важные части итерации. Задача менеджера проекта состоит в том, чтобы распознать потенциальные проблемы, приводящие к остановке работы, а также распознать узкие места, снижающие темп выполнения работы, и обеспечить непрерывное выполнение проекта. 26 Операция: Обзор приоритетов в описателе Если в процессе итерации изменяются приоритеты описателей сценариев или требований к качеству, менеджер проекта отвечает за то, чтобы организовать короткое совещание с участием бизнес-аналитиков, архитекторов, разработчиков и тестировщиков для обсуждения изменений. Приоритеты могут меняться по многим причинам: из-за возникновения технических вопросов, изменения приоритетов заказчика или зависимостей. Решение проблем. Ежедневно выполняйте запросы поиска проблем и проверяйте, не заблокированы ли те или иные задачи разработки или тестирования. При возникновении проблем привлекайте к их решению других участников команды. Операция: Снижение риска Для снижения риска необходимо предпринять шаги с целью уменьшения его вероятности или смягчения его воздействия. Проактивное управление рисками эффективней реактивного. Чтобы проактивное управление рисками было рентабельным, в первую очередь нужно уделять внимание наиболее рискованным моментам, но тратить на их устранение не больше, чем они могут принести убытков. Уменьшение вероятности риска. Предложите варианты снижения вероятности возникновения неблагоприятных событий. Смягчение воздействия. Если вероятность возникновения неблагоприятной ситуации остается высокой, предложите способы смягчения вредного воздействия. Выработка плана на случай чрезвычайных обстоятельств. Если риск все же остается неприемлемо высоким – пересмотрите все сделанные допущения и требования к качеству, особенно относящиеся к эксплуатационной среде, доступности и специальным возможностям. Применение решений. Реализуйте выбранное решение, обеспечивающее уменьшение вероятности и смягчение воздействия неблагоприятных обстоятельств. Операция: Выполнение ретроспективного анализа Обратная связь является важной составляющей любого гибкого процесса разработки ПО. Поскольку всякая проектная группа – как и каждая проблема, с которой она сталкивается, – уникальна, создание среды, отвечающей всем потребностям ее участников, является ключевым фактором в увеличении производительности их труда. Ретроспектива позволяет команде разработчиков проанализировать свои правильные и ошибочные действия после завершения очередной 27 итерации. Главное здесь – увидеть возможные пути совершенствования процесса и соответствующим образом перестроиться. Чтобы извлечь максимальную пользу от ретроспективы, соответствующее совещание должно длиться около двух часов. Однако если члены команды видят, что все идет гладко, встречу можно сократить. Последняя итерация заканчивается ретроспективным анализом проекта. Организация совещания для ретроспективы. Пригласите участников команды на совещание. Оно должно проводиться после завершения итерации с участием всех членов коллектива. Совещание должно быть относительно коротким, но достаточным для того, чтобы сделать необходимые выводы (обычно около двух часов). Окончательный ретроспективный анализ (в конце проекта) может занять больше времени – вплоть до нескольких дней для масштабных проектов. Это завершающее собрание целесообразно организовывать таким образом, чтобы оно не мешало повседневной деятельности. Проведение совещания. Установите четкие правила участия сотрудников в совещаниях. Используйте список из двух столбцов: «плюсов» и «минусов» завершенной итерации. Учитывайте результаты анализа в следующих итерациях. Там, где это возможно, используйте результаты проделанного ретроспективного анализа для корректировки планов следующих итераций. Вопрос 2. Планирование итерации. При планировании итерации важно заранее определить правильный баланс между сценариями, требованиями к качеству и ассигнованиями на исправление ошибок. За каждую итерацию можно выполнить ограниченный объем работы. В текущую итерацию попадают сценарии и требования к качеству, имеющие наибольшую практическую ценность. Первоначальный план итерации создается на основе элементов сценариев (scenario entries) и требований к качеству, имеющих пока приблизительные оценки. Затем элементы, попавшие в план итерации, передаются бизнес-аналитику для написания сценариев. После этого разработчики и тестировщики разбивают сценарии на задачи. Эти задачи распределяются между разработчиками, и делается более точная оценка затрат, которая используется для равномерного распределения нагрузки между разработчиками. Завершение выработки плана итерации происходит на собрании участвующих в итерации бизнес-аналитиков, менеджеров проекта и разработчиков. |