SharePoint 2010 : préparez votre équipe

Sélection et création de la structure de l'équipe de bon développement sont crucial pour le développement réussi de la solution SharePoint.

Steve Wright et Corey Erkes

Adapté de « Gouvernance SharePoint Pro 2010 » (Apress, 2012)

Un des aspects plus souples de SharePoint comme une plate-forme de collaboration est la capacité à préparer et déployer des applications métier personnalisées. Cela peut être un processus complexe. Il y a beaucoup d'opinions divergentes sur la taille et la structure de votre équipe de développement de solution SharePoint plus efficient et efficace.

Les promoteurs du développement de solutions agiles préfèrent petites équipes parce que des communications individuelles sont considérée comme un aspect essentiel du processus. Pour les grands projets de développement, une seule équipe plus petite ne fournit pas une capacité suffisante pour satisfaire le besoin de nouvelles fonctionnalités. Dans ce cas, assigner plusieurs petites équipes est généralement plus efficace qu'une seule équipe de plus en plus grande.

Planification et affectation d'une division du travail entre plusieurs équipes devient essentielle. Il existe trois méthodes principales pour structurer des équipes de développement de solution SharePoint :

  • Structure de l'équipe Parallel
  • Structure de l'équipe linéaire
  • Structure de l'équipe de base de composants

N'oubliez pas que dans SharePoint, un package de solution est l'unité de déploiement. Alors que vous et votre équipe pouvez créer un package de solution massive unique pour une application volumineuse, il est généralement préférable de le casser vers le haut en plusieurs paquets liés, que vous pouvez tester et version individuellement.

Structure de l'équipe Parallel

La structure de l'équipe première est un dans lequel travaillent les équipes différentes en parallèle afin de créer un ensemble de packages de solutions qui composent la version finale. Chaque équipe est responsable d'un ou plusieurs packages de solution. Fonctions au sein de ces paquets peuvent dépendre de l'autre, mais ils ne devrait pas dépendre de produits par une autre équipe.

Une structure parallèle fonctionne mieux lorsque vous pouvez scinder les fonctions de l'application en sous-applications plus ou moins indépendantes. Chaque équipe crée et teste ses propres composants et les contrôles dans le contrôle source. L'automatisé processus de génération, puis combine les paquets provenant de différentes équipes en une seule version. Ce processus permet à vos équipes travaillent indépendamment les uns des autres la plupart du temps avec un minimum de coordination nécessaire entre les équipes au cours du développement.

Structure de l'équipe linéaire

La structure suivante, que vous pourriez envisager est une structure linéaire, ou en couches, de l'équipe. Dans ce cas, chaque équipe est responsable du développement des fonctionnalités à une seule couche de l'application. Par exemple, vous disposez de trois équipes de développement de packages de solution qui vont contenir un ensemble. Équipe 1 crée le calque du cadre inférieur et vérifie dans le contrôle source. Équipe 2 récupère les solutions d'équipe 1 et les utilise comme un cadre ou une trousse d'outils pour la construction de la couche suivante dans la pile. Équipe 2 passe ensuite la deuxième couche de composants à l'équipe 3.

Une structure linéaire convient mieux aux situations où une application est générée dans les couches d'abstraction ou de cadres. SharePoint lui-même est un bon exemple de ce type de conception. Les fonctionnalités qui composent SharePoint Foundation créent une couche d'outils utilisables par les autres applications basées sur SharePoint.

SharePoint Server 2010 en est un exemple d'une application générée à l'aide de cette boîte à outils. Le produit serveur est vraiment juste un ensemble de composants construits sur la base fournie par SharePoint Foundation. Microsoft Project Server et Microsoft CRM sont d'autres exemples de solutions créées avec ce processus de développement.

Lorsque vous développez des solutions en couches, chaque couche sera généralement dépendent des fonctionnalités offertes à des niveaux inférieurs dans la pile. Ces dépendances peuvent être déclarés dans les solutions et les fonctionnalités qui sont élaborées pour s'assurer que toutes les conditions sont réunies lors de l'activation d'une fonctionnalité à un site SharePoint.

Structure de l'équipe de base de composants

Alors que les approches linéaires et parallèles séparent développement en assignant des packages de solutions à différentes équipes, il y a des cas où ce n'est juste pas possible. Dans ce cas, vos équipes et vous devrez peut-être d'adopter une approche basée sur des composants. Ce type de structure affecte les composants tels que les composants WebPart, formulaires, flux de travail et autres à diverses équipes. Ceux-ci sont indépendamment testés et archivés dans le contrôle de code source. Alors seulement, les composants sont emballés pour la livraison.

Ce type de structure est très flexible car vous pouvez déplacer éléments d'une équipe à l'autre selon les besoins sans affecter l'emballage de la demande. Malheureusement, cela rend également les diverses équipes interdépendantes.

Les équipes travaillant sur les mêmes packages de solution doivent s'assurer que toutes les modifications qui peuvent affecter les composants développés par d'autres équipes sont clairement communiquées. Tests d'intégration basé sur exécute les packages finales est essentiel dans ce type d'environnement. La source la plus probable des bogues dans n'importe quel système est à chaque limite entre composants développés par des équipes différentes.

Stratégie de développement d'équipe

Il y a plusieurs autres considérations à prendre en considération lors de l'élaboration de la stratégie de développement de votre équipe :

  • Chaque équipe aura un calendrier distinct de génération automatisé ?
  • Chaque équipe aura une batterie de test intégration séparé, ou seront ils partagent tous une seule ferme ?
  • Comment allez vous planifier communiqués pour permettre chaque composant doit être remplie dans l'ordre requis par d'autres équipes qui en dépendent ?
  • Il faut combien de communication au sein et entre les équipes ?
  • Toutes les équipes seront dans le même emplacement physique ?
  • Qui est responsable de l'intégration, test de la version finale avant la livraison pour le test d'acceptation ?

Bien sûr, que les applications deviennent plus grandes et plus complexes, il est probable qu'aucune structure de l'équipe unique ne suffira. Une approche hybride en utilisant une combinaison de parallèle, linéaires et par composant les équipes deviendront la norme dans les grandes organisations.

L'équipe de gestion devrait s'assurer que toutes les équipes comprennent leurs responsabilités. Ils doivent s'assurer que les équipes procèdent à des tests rigoureux sur les solutions avant de les déployer sur SharePoint.

Steve Wright

Steve Wright est un cadre supérieur en gestion d'entreprise intelligence pour Sogeti USA LLC à Omaha, au Nebraska. Au cours des dernière plus de 20 ans, Wright a travaillé sur le contrôle du trafic aérien, financier, d'assurance et une multitude d'autres types de systèmes. Il a écrit et réalise des examens techniques pour de nombreux titres précédents portant sur les produits Microsoft, notamment Windows, SharePoint, SQL Server et BizTalk.

Corey Erkes

Corey Erkes est consultant manager Sogeti USA LLC à Omaha, au Nebraska. Erkes a travaillé avec un large éventail de sociétés à différents points du cycle de vie de leurs implémentations de SharePoint. Il est également l'un des membres fondateurs du groupe d'utilisateurs SharePoint Omaha.

© 2012 Apress Inc. Tous droits réservés. Imprimé avec la permission de Apress. Copyright 2012. « Pro SharePoint 2012 gouvernance » par Steve Wright et Corey Erkes. Pour plus d'informations sur ce titre et autres ouvrages semblables, s'il vous plaît visitez apress.com.

Contenu associé