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

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

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

Иерархия проектов

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

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

Типичные ситуации:

• Программа проектов. Обычно под программой проектов понимают набор из нескольких проектов, объединенных общими целями, иногда, общим интересом со стороны одного заказчика. В каждом из проектов программы могут разрабатываться независимые приложения или решения, либо частично пересекающиеся и интегрируемые.
• Поддержка продуктов для одного заказчика. Цель проекта поддержки заключается в организации единой точки управления ожиданиями заказчика. Все пожелания внутри проекта поддержки дублируются в проектах соответствующих продуктов и тем самым отслеживается и контролируется решение запросов заказчика.
• Единая служба поддержки. При передаче реализованного продукта в поддержку, заказчику сообщается адрес единой службы поддержки, через которую осуществляется взаимодействие пользователей с разработчиками. Часть проблем могут решать специалисты службы поддержки, используя базу знаний или пользовательскую документацию дочерних проектов. Другую часть проблем они передают на анализ и решение непосредственно в дочерние проекты.
• Модульная разработка. Крупное решение часто делится на несколько относительно независимых модулей, либо компоненты, отличающиеся по технологии разработки: сервер приложения и база данных. В каждом модуле происходит уточнение исходных требований под специфику данного модуля.

Звезда (кастомизация решения)

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

Характерной чертой такой схемы является экспорт практически всех артефактов из центрального проекта во внешние проекты.

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

Сеть (технологический актив)

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

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

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

Теперь команда любого проекта, к которому подключен технологический проект имеет быстрый доступ к:

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

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

Еще интересные статьи на эту тему:

• Как объединить разработку и поддержку
• Учимся подбирать методологию к проекту
• Ставим процесс внедрения типовых решений
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Постоянные улучшения и ретроспективы в Agile