Действия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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