Спонсор: Microsoft
Опубликован: 16.02.2010 | Доступ: свободный | Студентов: 1422 / 157 | Оценка: 4.21 / 4.00 | Длительность: 06:28:00
Лекция 3:

Действия

< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Аннотация: В этой лекции последовательно рассматриваются действия и соответствующие им операции, такие как: контроль итерации, планирование итерации, разработка архитектуры решения, формулирование концепции проекта, разработка требований к качеству.

Контроль итерации

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

Операции:
Мониторинг итерации Обзор приоритетов в описателе
Снижение риска Уменьшение вероятности риска
Выполнение ретроспективного анализа Организация ретроспективного анализа

Операция: Мониторинг итерации

Понимание текущего состояния итерации очень важно для ее успешного завершения. Один из важнейших моментов в оценке хода итерации - анализ описателей высокоприоритетных сценариев, требований к качеству и ошибок в данной итерации. Актуализируйте план итерации, чтобы увидеть незакрытые задачи, связанные с описателями перечисленных типов. Определите завершившиеся задачи и распределите приоритеты так, чтобы сначала заканчивались наиболее важные части итерации. Задача менеджера проекта состоит в том, чтобы распознать потенциальные проблемы, приводящие к остановке работы, а также распознать узкие места, снижающие темп выполнения работы, и обеспечить непрерывное выполнение проекта.

Обзор приоритетов в описателе Если в процессе итерации изменяются приоритеты описателей сценариев или требований к качеству, менеджер проекта отвечает за то, чтобы организовать короткое совещание с участием бизнес-аналитиков, архитекторов, разработчиков и тестировщиков для обсуждения изменений. Приоритеты могут меняться по многим причинам: из-за возникновения технических вопросов, изменения приоритетов заказчика или зависимостей
Решение проблем Ежедневно выполняйте запросы поиска проблем и проверяйте, не заблокированы ли те или иные задачи разработки или тестирования. При возникновении проблем привлекайте к их решению других участников команды

Операция: Снижение риска

Для снижения риска необходимо предпринять шаги с целью уменьшения его вероятности или смягчения его воздействия. Проактивное управление рисками эффективней реактивного. Чтобы проактивное управление рисками было рентабельным, в первую очередь нужно уделять внимание наиболее рискованным моментам, но тратить на их устранение не больше, чем они могут принести убытков.

Уменьшение вероятности Предложите варианты снижения вероятности возникновения неблагоприятных событий
Смягчение воздействия Если вероятность возникновения неблагоприятной ситуации остается высокой, предложите способы смягчения вредного воздействия
Выработка плана на случай чрезвычайных обстоятельств Если риск все же остается неприемлемо высоким, - пересмотрите все сделанные допущения и требования к качеству, особенно относящиеся к эксплуатационной среде, доступности и специальным возможностям
Применение решений Реализуйте выбранное решение, обеспечивающее уменьшение вероятности и смягчение воздействия неблагоприятных обстоятельств

Операция: Выполнение ретроспективного анализа

Обратная связь является важной составляющей любого гибкого процесса разработки ПО. Поскольку всякая проектная группа - как и каждая проблема, с которой она сталкивается - уникальна, создание среды, отвечающей всем потребностям ее участников, является ключевым фактором в увеличении производительности их труда. Ретроспектива позволяет команде разработчиков проанализировать свои правильные и ошибочные действия после завершения очередной итерации. Главное здесь - увидеть возможные пути совершенствования процесса и соответствующим образом перестроиться. Чтобы извлечь максимальную пользу от ретроспективы, соответствующее совещание должно длиться около двух часов. Однако если члены команды видят, что все идет гладко, встречу можно сократить. Последняя итерация заканчивается ретроспективным анализом проекта.

Организация совещания для ретроспективы Пригласите участников команды на совещание. Оно должно проводиться после завершения итерации с участием всех членов коллектива. Совещание должно быть относительно коротким, но достаточным для того, чтобы сделать необходимые выводы (обычно около двух часов). Окончательный ретроспективный анализ (в конце проекта) может занять больше времени, вплоть до нескольких дней для масштабных проектов. Это завершающее собрание целесообразно организовывать таким образом, чтобы оно не мешало повседневной деятельности
Проведение совещания Установите четкие правила участия сотрудников в совещаниях. Используйте список из двух столбцов: "плюсов" и "минусов" завершенной итерации
Учитывайте результаты анализа в следующих итерациях Там, где это возможно, используйте результаты проделанного ретроспективного анализа для корректировки планов следующих итераций

Планирование итерации

При планировании итерации важно заранее определить правильный баланс между сценариями, требованиями к качеству и ассигнованиями на исправление ошибок. За каждую итерацию можно выполнить ограниченный объем работы. В текущую итерацию попадают сценарии и требования к качеству, имеющие наибольшую практическую ценность. Первоначальный план итерации создается на основе элементов сценариев ( scenario entries ) и требований к качеству, имеющих пока приблизительные оценки. Затем элементы, попавшие в план итерации, передаются бизнес-аналитику для написания сценариев. После этого разработчики и тестировщики разбивают сценарии на задачи. Эти задачи распределяются между разработчиками, и делается более точная оценка затрат, которая используется для равномерного распределения нагрузки между разработчиками. Завершение выработки плана итерации происходит на собрании участвующих в итерации бизнес-аналитиков, менеджеров проекта и разработчиков.

Операции:
Определение продолжительности итерации При планировании отталкивайтесь от даты окончания проекта
Оценка сценария Определите подмножество из списка сценариев
Оценка требования к качеству Определите подмножество из списка требований к качеству
Планирование сценария Создайте набросок плана итерации
Планирование требования к качеству Создайте набросок плана итерации
Планирование ресурсов на исправление дефектов Зарезервируйте ресурсы на устранение дефектов
Разбиение сценария на задачи Соберите команду
Разбиение требования к качеству на задачи Соберите команду

Операция: Определение продолжительности итерации

Итерация - это набор задач, которые должны быть выполнены в течение фиксированного промежутка времени. Общее время, необходимое для завершения задач, называется продолжительностью итерации. График проекта разбит на последовательность итераций и задач, которые, в свою очередь, имеют свой график. Определение продолжительности итерации включает в себя рассмотрение всех ключевых факторов, включая дату поставки продукта (если она определена), размер сценариев и их общее время. Обычно продолжительность итерации определяется в неделях, однако возможны и меньшие единицы времени. Продолжительность итераций определяется в начале проекта, а затем на основе этих данных определяется общая продолжительность проекта.

Планирование от даты окончания Если для проекта задана дата поставки конечного результата проекта, то она определяет продолжительность итераций. Создайте план проекта или с помощью календаря выясните, сколько времени может быть отведено на разработку
Проверка размера сценария После окончания планирования первой итерации проверьте, не разбиваются ли сценарии на более мелкие из-за ее продолжительности. Увеличьте продолжительность итерации, если это необходимо, для того, чтобы она соответствовала размеру сценария
Проверка затрат на интеграцию Интеграция выполняется на протяжении всей итерации по окончании каждой задачи разработки. Учитываются все особые требования или затраты на интеграцию
Анализ продолжительности итерации Проводите анализ продолжительности итерации совместно с проектной группой. Оптимальная продолжительность позволяет выполнить небольшое количество сценариев или требований к качеству. Каждая итерация должна заканчиваться выпуском внутренней или внешней версии с новыми функциональными возможностями, исправленными ошибками, реализованными сценариями или требованиями к качеству

Операция: Оценка сценария

Оценка сценария выполняется для создания общей картины, которая помогает понять, сколько усилий потребуется для реализации сценария. Подобные оценки позволяют бизнес-аналитику расставлять приоритеты и регулировать внешние ожидания. Менеджер проекта совместно с разработчиками выполняет оценки для наиболее приоритетных сценариев из списка.

Определите подмножество из списка сценариев Откройте список сценариев на портале проекта. Для каждого сценария с максимальным приоритетом назначьте разработчика или группу разработчиков, которые смогут выполнить оценку
Оценка реализации Совместно с разработчиками оцените приблизительный порядок величины (rough order of magnitude, ROM) сложности каждого сценария. Для многих проектов может быть применено следующее правило. Если необходимо выполнить не более шести заданий, требующих 1-2 дня, в этом поле указывается значение 1. Если необходимо выполнить от 6 до 12 заданий, требующих 1-2 дня, в этом поле указывается значение 2. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения сценария на части. Важно соблюдать примерные соотношения оценок, т. е. сценарий с порядком сложности 2 должен быть приблизительно в два раза больше сценария с оценкой сложности 1
Определение особых требований Совместно с разработчиками определите риски, которые могут задержать или помешать успешному завершению работ по реализации сценария, такие как недостаток знаний или зависимость от приложений сторонних поставщиков. Создайте описатель для каждого выявленного риска

Операция: Оценка требований к качеству

Оценка требований к качеству служит для определения усилий, необходимых для их реализации. Подобные оценки позволяют бизнес-аналитику устанавливать приоритеты и регулировать внешние ожидания. Менеджер проекта совместно с разработчиками выбирает из списка наиболее приоритетные требования к качеству и выполняет для них оценки.

Выбор требований к качеству из списка Откройте список требований к качеству на портале проекта. Для каждого сценария с максимальным приоритетом назначьте разработчика или группу разработчиков, которые смогут выполнить оценку
Выполнение оценки реализации Совместно с разработчиками оцените приблизительный порядок величины сложности каждого требования к качеству. Для многих проектов может быть применено следующее правило. Если необходимо выполнить не более шести заданий, требующих 1-2 дня, в этом поле указывается значение 1. Если необходимо выполнить от 6 до 12 заданий, требующих 1-2 дня, в этом поле указывается значение 2. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения на части задачи реализации требования к качеству. Важно соблюдать примерные соотношения оценок, т. е. сценарий с порядком сложности 2 должен быть приблизительно в два раза больше сценария с оценкой сложности 1
Определение ограничений Совместно с разработчиками определите риски, которые могут помешать успешному и своевременному завершению работ по реализации требования, такие как недостаток знаний или зависимость от ПО сторонних поставщиков. Создайте описатель риска и прикрепите его к соответствующему требованию к качеству для отображения зависимости

Операция: Разбиение сценариев на задачи

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

Соберите команду Соберите архитекторов, разработчиков и тестировщиков, которые будут работать над сценарием, либо как-то влиять на него. Менеджер проекта организует короткое собрание или дискуссию по электронной почте и фиксирует задачи
Определение архитектуры и задач разработки Начиная с того места, где новый сценарий отличается от уже реализованных сценариев, проследите его до конца. Обращайте внимание на видимые пользователю элементы, изменения в инфраструктуре или структуре данных, а также на моменты, которые влияют на всю архитектуру. Определите изменения в компонентах системы, которые произойдут в результате реализации планируемого сценария
Выбор архитектуры и задач разработки Пусть архитекторы и разработчики сами выберут себе задачи
Назначение ответственного разработчика сценария Передайте сценарий одному из разработчиков, работающих над задачами сценария. Он будет отвечать за сквозное тестирование интеграции этих задач
Создание тестовых задач Отредактируйте документ, описывающий тестирование для данной итерации, указав в нем тестовые данные и заполнив другие разделы. Создайте задачи для разработки необходимых тестов проверки сценария
Выбор тестовых задач Пусть тестировщики сами выберут себе задачи

Операция: Разбиение требования к качеству на задачи

Перед реализацией каждое требование к качеству должно быть разбито на задачи. Такое разбиение позволяет точнее выполнить оценку сложности и способствует лучшему пониманию разработчиками предстоящей работы. В рамках реализации требований к качеству обычно нужно выполнить несколько задач. Ключевым моментом в успешном разбиении требования к качеству является подключение к этому процессу разработчиков и тестировщиков, а также поощрение их выбирать себе задачи для себя самостоятельно. Все задачи должны быть распределены.

Соберите команду Соберите архитекторов, разработчиков и специалистов по тестированию, которые будут работать над требованием к качеству, либо как-то влиять на него. Менеджер проекта организует короткое собрание или дискуссию по электронной почте и фиксирует задачи
Определение архитектуры и задач разработки По ссылкам найдите сценарии, имеющие отношение к требованию к качеству, и проведите их обзор. Требования к качеству различаются по области своего влияния. Часть из них влияет только на один сценарий, в то время как другие могут оказывать воздействие сразу на несколько сценариев. Если будут обнаружены сценарии, пропущенные бизнес-аналитиком, добавьте их к соответствующему требованию к качеству
Выбор архитектуры и задач разработки Доверьте архитекторам и разработчикам самим выбрать себе задачи
Назначение ответственного разработчика требования к качеству Передайте требование к качеству разработчику, которому принадлежат задачи по соответствующему сценарию. Он будет отвечать за сквозное тестирование интеграции этих задач
Создание тестовых задач Отредактируйте документ, описывающий тестирование для данной итерации, указав в нем тестовые данные и заполнив другие разделы. Создайте набор задач для разработки необходимых тестов
Выбор тестовых задач Пусть тестировщики сами выберут себе задачи

Операция: Планирование ресурсов на исправление дефектов

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

Планирование ассигнований на исправление дефектов Из общего бюджета разработки выделите часть, необходимую на исправление дефектов (единица измерения - абстрактный человеко-день). Если план итерации выполняется в Microsoft Excel, обозначьте эти ассигнования как резерв бюджета. Если план итерации выполняется в Microsoft Project, то ассигнования могут быть запланированы условно
Учет зависимостей и других факторов Если сценарии или требования к качеству спланированы с учетом ассигнований на исправление дефектов, убедитесь, что ключевые разработчики, имеющие большое количество неисправленных ошибок, обладают достаточным резервом времени для исправления ошибок с самым высоким приоритетом. Проверьте еще раз предстоящие задачи, чтобы убедиться в наличии резерва. Переназначьте задачи или дефекты для обеспечения исправления дефектов
Проведение собрания посвященного началу итерации Завершите разработку плана итерации проведением собрания, на котором будет изложена информация о предстоящей итерации. На собрании должны присутствовать все участники команды, чтобы еще раз проверить задачи итерации

Операция: Составление графика сценария

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

Создание плана начальной итерации Совместно с бизнес-аналитиком разработайте план начальной итерации
Уточнение плана начальной итерации Когда сценарий написан и задачи по разработ ке включены в план итерации, общее количество запланированных работ не должно превышать средние возможности команды разработчиков
Проведение совещания посвященного началу итерации Завершите разработку плана итерации проведением собрания, на котором будет изложена информация о предстоящей итерации. На собрании должны присутствовать все участники команды, чтобы еще раз проверить задачи итерации

Операция: Составление графика реализации требований к качеству

Для реализации требований к качеству должен быть составлен график работ. Требования к качеству описывают нефункциональные требования, такие как, например, уровень производительности. С некоторыми требованиями не связаны задачи. Однако требования могут быть связаны со сценариями, в которых они реализуются. Таким образом, требования к качеству должны быть запланированы одновременно с соответствующими сценариями, чтобы обеспечить выполнение задач, связанных с их описателями.

Создание плана начальной итерации Совместно с бизнес-аналитиком разработайте план начальной итерации. Получите последнюю версию списка требований к качеству с расставленными приоритетами и оцененными трудозатратами. Совместно с бизнес-аналитиком выберите те из требований, которые укладываются в план итерации с учетом средней производительности команды, показанной в предыдущей итерации, и количества сценариев и ассигнований на исправление дефектов, запланированных на данную итерацию
Уточнение плана начальной итерации Когда задачи по разработке будут включены в план итерации, убедитесь, что общее количество запланированных работ не превышает средние возможности команды разработчиков
Проведение собрания, посвященного началу итерации Завершите разработку плана итерации проведением собрания, на котором будет изложена информация о предстоящей итерации. На собрании должны присутствовать все участники команды, чтобы еще раз проверить задачи итерации
< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Сергей Пономарев
Сергей Пономарев
Россия, Воронеж, Воронежский Государственный Университет
Руслан Шарипов
Руслан Шарипов
Казахстан