SharePoint 2010: Подготовьте свои группы

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

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

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

• параллельная структура групп;
• линейная структура групп;
• структура групп, основанная на компонентах.

Вспомним, что в SharePoint единицей развертывания является пакет решения (solution package). Хотя вы и ваши группы можете создать для крупного приложения один большой пакет решения, как правило, предпочтительнее разбить решение на несколько взаимосвязанных пакетов, которые тестировать их и выпускать их версии по отдельности.

Параллельная структура групп

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

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

Линейная структура групп

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

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

Один из примеров приложения, созданного с использованием этого инструментария, — SharePoint Server 2010. Серверный продукт, по сути, — просто набор компонентов, основанных на базовом функционале, предоставляемом SharePoint Foundation. Microsoft Project Server и Microsoft CRM — еще два примера решений, разработанных по такой методике.

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

Структура групп, основанная на компонентах

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

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

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

Стратегия групповой разработки

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

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

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

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