Действия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка архитектуры решения

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

Операция: Разделение системы на подсистемы

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

Для создания гибкой архитектуры в MSF применяется создание временного прототипа ( shadowing ). Приложение-прототип ( shadow ) позволяет применить принцип нисходящего проектирования в любой итерации. В начале итерации, когда существует лишь проект, прототип опережает рабочий программный код. В этот период проектные конструкции не синхронизованы с кодом. В рамках прототипа выполняются все изменения архитектуры или дизайна, которые необходимы для предохранения основного кода от превращения его в "дымоход", "спагетти-код" и прочих проблем, связанных с плохим проектированием. По мере реализации элементов начального предваряющего прототипа ( leading shadow ), архитектура все больше соответствует рабочему коду. Те части системы, которые были спроектированы, но не были реализованы, теперь становятся действительными. Когда архитектура соответствует рабочему коду, прототип называется завершающим ( trailing shadow ). Это сумма конструкций из всех предыдущих итераций.

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

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

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

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

Операция: Разработка модели угроз

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

Операция: Разработка модели производительности

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

Операция: Создание архитектурной модели

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

Операция: Создание архитектуры инфраструктуры

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

Формулирование концепции проекта

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

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

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

Операция: Определение собирательных образов

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

Операция: Уточнение собирательных образов

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

Разработка требований к качеству

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

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

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

Операция: Создание моментальных снимков деятельности

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

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

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

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

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

Операция: Определение требований безопасности

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