SharePoint 2010: Vorbereiten des Teams
Auswählen und Erstellen der richtigen Entwicklung Team-Struktur ist entscheidend für die erfolgreiche Entwicklung von SharePoint-Lösungen.
Steve Wright und Corey Erkes
Adaptiert von "Pro SharePoint 2010 Governance" (Apress, 2012)
Ein flexibler Aspekt von SharePoint als Plattform für eine Zusammenarbeit ist die Fähigkeit, vorbereiten und Bereitstellen von benutzerdefinierten Geschäftsanwendungen. Dies ist ein komplexer Prozess. Es gibt viele unterschiedliche Meinungen über die effizientesten und effektivsten Größe und Struktur des Entwicklungsteams Ihrer SharePoint-Lösung.
Befürworter der agilen Lösungsentwicklung lieber kleinere Teams, da regelmäßige persönliche Kommunikation einen wesentlichen Aspekt des Prozesses betrachtet wird. Für große Entwicklungsprojekte ermöglichen ein kleineres Team möglicherweise nicht genügend Kapazität, um die Notwendigkeit für neue Funktionen zu erfüllen. In diesem Fall ist das Zuweisen von mehreren kleinen Teams in der Regel effektiver als ein zunehmend großes Team.
Für Planung und eine Arbeitsteilung zwischen mehreren Teams zuweisen wird notwendig. Es gibt drei grundlegende Möglichkeiten zur Strukturierung von mehreren Teams für die Entwicklung von SharePoint-Lösungen:
- Parallele Teamstruktur
- Lineare Teamstruktur
- Komponentenbasierte Teamstruktur
Beachten Sie, dass in SharePoint ein Lösungspaket die Einheit der Bereitstellung ist. Während Sie und Ihre Teams eine einzelne massive Lösungspaket für umfangreiche Anwendungen erstellen können, ist es in der Regel vorzuziehen, es oben zu brechen in mehrere verwandte Pakete, die Sie testen können und Version einzeln.
Parallele Teamstruktur
Die erste Teamstruktur ist eine in der Arbeit der verschiedenen Teams parallel um einen Satz von Lösungspaketen zu erstellen, aus denen sich die endgültige Version. Jedes Team ist verantwortlich für eine oder mehrere Lösungspakete. Funktionen innerhalb dieser Pakete können von einander abhängen, aber sie sollten nicht abhängen, Pakete, die von einem anderen Team produziert.
Eine parallele Struktur funktioniert am besten, wenn Sie die Funktionalität der Anwendung in mehr oder weniger unabhängigen Teilanwendungen unterbrechen können. Jedes Team erstellt und testet ihre eigenen Komponenten und prüft sie in die Quellcodeverwaltung. Der automatisierten build-Prozess dann kombiniert die Pakete aus verschiedenen Teams in eine single-Auskopplung. Auf diese Weise kann Ihre Teams unabhängig voneinander die meiste Zeit mit einem Minimum an Koordination zwischen den Teams während der Entwicklung arbeiten.
Lineare Teamstruktur
Die nächste Struktur mögliche Methode ist eine lineare oder geschichteten, Teamstruktur. In diesem Fall ist jedes Team verantwortlich für die Entwicklung der Funktionalität auf einer Ebene der Anwendung. Angenommen, haben Sie drei Teams an der Entwicklung der Lösungspakete, die zusammen gelegt werden werden. Team 1 die unteren Rahmen Ebene erstellt und in die Quellcodeverwaltung eingecheckt. Team 2 Ruft die Lösungen von Team 1 und nutzt sie als Rahmen oder Toolkit für den Aufbau der nächsten Schicht oben im Stapel. Team 2 übergibt dann die zweite Schicht der Komponenten an Team 3.
Eine lineare Struktur eignet sich für Situationen, wo eine Anwendung in Schichten der Abstraktion oder Frameworks gebaut wird. SharePoint selbst ist ein gutes Beispiel für diese Art von Design. Die Features, die SharePoint Foundation bilden, erstellen Sie eine Ebene über Tools, die anderen SharePoint-basierten Anwendungen verwenden können.
Ein Beispiel für eine Anwendung mit Hilfe dieses Toolkit ist SharePoint Server 2010. Das Produkt ist wirklich nur ein Satz von Komponenten, die auf der SharePoint-Stiftung Stiftung aufbauen. Microsoft Project Server und Microsoft CRM sind weitere Beispiele für Lösungen, die mit diesem Entwicklungsprozess.
Bei der Entwicklung von Lösungen in Schichten wird jede Schicht in der Regel auf den unteren Ebenen im Stapel bereitgestellten Features abhängig sein. Diese Abhängigkeiten können deklariert werden, in der Lösungen und Features, die entwickelt werden, um sicherzustellen, dass alle Voraussetzungen erfüllt sind, wenn eine Funktion in einer SharePoint-Website zu aktivieren.
Komponentenbasierte Teamstruktur
Während die Ansätze parallel und lineare Entwicklung durch Zuweisen von Lösungspaketen zu verschiedenen Teams zu trennen, gibt es Fälle, wo dies einfach nicht möglich. In diesem Fall müssen Sie und Ihre Teams einen komponentenbasierten Ansatz. Diese Art von Struktur weist Komponenten wie Webparts, Formularen, Workflows und dergleichen zu verschiedenen Teams. Diese sind unabhängig getestet und in die Quellcodeverwaltung eingecheckt. Erst dann werden die Komponenten für Lieferung gepackt.
Diese Art von Struktur ist sehr flexibel, da Sie Komponenten von einem Team verschieben können ohne Auswirkung auf die Verpackung des Antrags Bedarf. Leider macht dies auch die verschiedenen Teams voneinander abhängig.
Teams arbeiten auf die gleiche Lösungspakete müssen sicher sein, dass alle Änderungen, die von anderen Teams entwickelte Komponenten beeinflussen können klar kommuniziert werden. Integrationstests basierend auf laufen die letzten Pakete ist in dieser Art von Umgebung entscheidend. Die wahrscheinlichste Quelle von Fehlern in jedem System ist an jeder Grenze zwischen Komponenten von verschiedenen Teams entwickelt.
Team-Entwicklungsstrategie
Es gibt mehrere andere Überlegungen im Auge zu behalten, beim Zuordnen von Ihrem Team Entwicklungsstrategie:
- Muss jedes Team einen eigenen automatisierten Build Zeitplan?
- Haben jedes Team eine separate Integration Testfarm, oder Teilen sie alle einer einzelnen Farm?
- Wie planen Sie Versionen erlauben jede Komponente in der Reihenfolge, die von anderen Teams, die davon abhängen erforderlich abgeschlossen werden?
- Wie viel Kommunikation innerhalb und zwischen den Teams erforderlich ist?
- Werden alle Teams in der gleichen physischen Standort?
- Wer ist verantwortlich für Integrationstests die Endversion vor Auslieferung für Akzeptanztests?
Natürlich Anwendungen größer und komplexer werden, ist es wahrscheinlich, dass keine einzelne Teamstruktur ausreichen wird. Ein Hybridansatz mit einer Kombination aus Parallel, werden lineare und komponentenbasierte Teams die Norm in großen Organisationen.
Das Regieren-Team sorgen dafür, dass alle Teams ihre zugewiesenen Verantwortung verstehen. Sie müssen sicherstellen, dass die Teams strenge Tests führen vor der Bereitstellung von ihnen auf SharePoint-Lösungen.
.jpg)
Steve Wright ist senior Manager im Bereich Business Intelligence Management für Sogeti USA LLC in Omaha, Neb. In den Jahren zuletzt formte hat Wright an Flugsicherung, Finanz-, Versicherungs- und zahlreiche andere Arten von Systemen gearbeitet. Er verfasste und technische Rezensionen für viele vorherige Titel für Microsoft Produkte wie Windows, SharePoint, SQL Server und BizTalk durchgeführt.
.jpg)
Corey Erkes ist ein Manager-Berater für Sogeti USA LLC in Omaha, Neb. Erkes arbeitete mit einer Vielzahl von Firmen zu verschiedenen Zeitpunkten der Lebenszyklen ihrer SharePoint-Implementierungen. Er ist auch einer der Gründungsmitglieder der Omaha SharePoint User Group.
© 2012 Apress Inc. Alle Rechte vorbehalten. Gedruckt mit Genehmigung von Apress. Copyright 2012. "Pro SharePoint 2012 Governance" von Steve Wright und Corey Erkes. Für weitere Informationen zu diesem Titel und andere ähnliche Bücher, besuchen Sie bitte apress.com.