Реферат: Комплексная автоматизация проектов разработки ПО в условиях кризиса

Применительно к проектам разработки ПО одним из недостатков популярных систем календарного планирования и управления (типа MS Project) является отсутствие возможности связывать задачи с другими проектными активностями и устанавливать зависимость между элементами их жизненных циклов.

Для решения данной проблемы все чаще используются системы с возможностью отслеживать состояние проектных активностей (issue tracking).

Трекер (от англ. track, что значит «след») – специальная система для отслеживания состояния проектных активностей (задач, требований, дефектов). Подобные системы появились в конце 1990-х гг. для обнаружения ошибок в коде при проведении тестирования в проектах разработки ПО. Впоследствии выяснилось, что можно успешно применять эти системы для отслеживания и других проектных активностей. Обычно в трекере для каждой проектной активности установлен определенный жизненный цикл, однако во многих представленных на рынке системах предусмотрена возможность гибкой настройки жизненного цикла в зависимости от требований проекта.

В LUXproject применяется трекер JIRA компании Atlassian. Благодаря гибкой архитектуре трекера можно создавать разнообразные жизненные циклы с учетом проектных требований.

Например, в компании используются несколько методологий ведения проектов разработки ПО:

 agile-практики;

 методологии, основанные на RUP-подобных процессах;

 проекты, связанные с поддержкой пользователей.

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

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

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

2. Интеграция и единый пользовательский интерфейс

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

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

Следует отметить, что интеграция wikiдвижка, трекера, версионного репозитория и инструментов разработки в едином визуальном интерфейсе (рис. 2) имеет существенные достоинства, такие как возможность создавать прямые ссылки между различными функциональными модулями и наличие прозрачных переходов из одного функционального модуля в другой.

Например, в LUXproject интегрирован wikiдвижок Confluence компании Atlassian, который позволяет выводить на страницу информацию из других систем, формируя ее расположение и параметры отображения путем простейших конфигурационных настроек, благодаря чему можно быстро адаптировать проект к конкретным требованиям внутренней и внешней среды.

3. Проектные коммуникации

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

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

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

4. Управление рисками

В современных условиях, когда на проект оказывает влияние как внутренняя, так и внешняя среда, управление рисками становится обязательным компонентом любого проекта независимо от отрасли.

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

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

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

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

5. Проектные шаблоны

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

Для минимизации времени настройки систем существуют так называемые проектные шаблоны.