Гибкость метода

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

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

Коллективная работа

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

Компонентный подход

Традиционно прикладные сервисы создавались с помощью интерфейсов прикладного программирования (Application Programming Interface, API), изучение которых весьма трудно.

Еще один популярный метод — объектно-ориентированные системы, но и он требует от программистов достаточно высокого мастерства. Кроме того, объектно-ориентированные системы, как правило, ограничены рамками одного языка программирования.

Компоненты — стандартная модель объединения сервисов, чтобы предоставить их услуги приложениям. Компоненты являются своего рода “черными ящиками”, скрывающими подробности реализации.

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

Периодическая демонстрация продукта заказчику

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

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

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

Понимание целей проекта

Успех проекта основан на понимании членами проектной группы его целей и задач. Все должны уяснить их, согласиться с ними и сказать: “Мы все сделаем, и точка!” Кроме того, разработчики и заказчики должны выработать общий взгляд на проект, то есть четко определить его задачи. Часто у членов проектной группы и заказчиков есть сформировавшиеся представления о ходе проекта и графике его выполнения. Чтобы снизить возможность конфликта, проектная группа и заказчики должны согласовать представления о проекте. В конечном счете и та, и другая сторона заинтересованы в выпуске требуемого продукта в установленные сроки.

Управление изменениями

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

Управление рисками - слагаемые успешного проекта

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

Рассмотрим этапы процесса управления рисками:

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

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

Зависимость продукта от ожиданий пользователей

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

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

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