Ежедневная сборка

В реальных проектах приходиться собирать исполняемый модуль или модули из сотен или тысяч исходных файлов. Некоторые проектные группы практикуют ежедневную сборку приложения с последующей проверкой работоспособности исполняемого модуля. Такая проверка очень важна – без нее ежедневная сборка не имеет смысла. Ежедневная сборка имеет несколько важных достоинств:

1) минимизирует риски, связанные с интеграцией кода – при ежедневной сборке проблемы этого сорта выявляются на ранней стадии, что позволяет вовремя отладить модуль, вызвавший проблему, или изменить соответствующее проектное решение;

2) упрощает поиск причин проблемы – при таком подходе не только проще выявить некорректный код, но и выяснить, что и когда случается с продуктом, прежде чем он перестал работать;

3) снижает риск падения качества.

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

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

1. удачная компиляция всех файлов и компонентов;

2. удачная сборка всех модулей и компонентов;

3. отсутствие ошибок препятствующих запуску приложения;

4. прохождение теста на работоспособность.

Планирование “снизу-вверх”

Попросту говоря, работу должны планировать те, кто ее делает. Такой подход:

1. повышает точность оценок, поскольку в этом случае они основаны на опыте конкретного разработчика, уже решавшего подобные задачи, а не взяты “с потолка” руководителем;

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

Планирование – задача всей группы (таблица 1).

Таблица 1. Составление графика “снизу-вверх”

Планирование	Представитель проектной группы
Основной план	Менеджер программы
Промежуточные этапы	Руководитель группы
Процессы	Группа разработки
Задачи	Разработчик

Версии

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

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

Рекомендации по организации выпуска версий продукта:

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

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

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

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

5. Если версия не решает задач бизнеса или производства, прекратите работу над ней: всегда знайте, когда нужно остановиться. Если нет причин выпускать следующую версию, не выпускайте ее.

Цели разработки

В большинстве проектов цели разработки попадают в одну из следующих категорий:

1) Прототип: на стадии “Анализ” прототип служит удобным инструментом обмена мнениями и уточнения концепции. Прототип – это нефункциональная демонстрационная версия продукта, чаще всего лишь набор снимков с экрана или Web-страниц. Помните, что прототип лишь помогает проектной группе и заказчику достичь соглашения относительно концепции приложения и его пользовательского интерфейса

2) Доказательство корректности концепции: в отличие от демонстрационного прототипа, концептуальные системы, служащие для доказательства концепции, являются полнофункциональными приложениями, цель которых – доказать реализуемость концепции. Прототип нацелен на демонстрацию концепции и пользовательского интерфейса, а концепт-системы – архитектуры и технологии.

3) Альфа-, бета- и промежуточные версии: на стадии разработки проектная группа чаще всего создает две основных промежуточных версии – альфа и бета. Они демонстрируют постепенное слияние пользовательского интерфейса, продемонстрированного на прототипе, и технологий, проверенных концепт-системой. Альфа-версия отвечает на вопрос: “Вот так технология и интерфейс выглядят вместе. Есть ли какие-то серьезные проблемы?”. Бета-версия отвечает на вопрос: “Мы решили все основные проблемы и большинство мелких. Мы ничего не упустили?”. Эта фаза разработки завершается созданием “золотой” версии.

4) Золотая версия: на стадии “Стабилизация” именно эта версия передается ограниченному кругу пользователей для тестирования. По мере выявления и устранения ошибок и проблем, связанных с производительностью, следом за ней развертывают следующие выпуски. Окончательная “золотая” версия, которая появляется в конце стадии “Стабилизация”, сигнализирует о завершении проекта и передаче результатов заказчику.

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

Лекция 8. Предпроект

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

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

Результат фазы “Анализ” – предпроект – представляет собой документ, описывающий концепцию проекта. Он детализирует:

1. концепцию проекта,

2. рамки проекта,

3. исходную информацию,

4. требования бизнеса и производства,

5. проектные требования,

6. результаты,

7. риски.