SharePoint 2010: Preparazione del team
Selezionando e creando la struttura del team di sviluppo corretto è fondamentale per il successo nello sviluppo di soluzione di SharePoint.
Steve Wright e Corey Erkes
Adattato da "Pro SharePoint 2010 Governance" (Apress, 2012)
Uno degli aspetti più flessibili di SharePoint come piattaforma di collaborazione è la possibilità di preparare e distribuire applicazioni business personalizzato. Questo può essere un processo complesso. Ci sono molte opinioni discordanti sulla dimensione e struttura del vostro team di sviluppo di SharePoint soluzione più efficiente ed efficace.
I fautori dello sviluppo Agile soluzione preferiscono squadre minori perché regolare comunicazione One to One è considerato un aspetto essenziale del processo. Grandi progetti di sviluppo, un unico team minori non può fornire una capacità sufficiente per soddisfare la necessità di nuove funzionalità. In questo caso, l'assegnazione di più piccole squadre è solitamente più efficacia di un unico team sempre più grandi.
Pianificazione e l'assegnazione di una divisione del lavoro tra più squadre diventa essenziale. Ci sono tre modi primari per formare più squadre per lo sviluppo di soluzione di SharePoint:
- Struttura del team parallelo
- Struttura lineare team
- Struttura del team basato su componenti
Ricordate che in SharePoint, un pacchetto della soluzione è l'unità di distribuzione. Mentre tu e il tuo team può creare un pacchetto di unica soluzione massiccia per un'applicazione di grandi dimensioni, è generalmente preferibile suddividerla in diversi pacchetti correlati che è possibile testare e versione individualmente.
Struttura del team parallelo
La prima struttura di squadra è uno in cui lavoro di diverse squadre in parallelo per creare un set di pacchetti di soluzioni che compongono la release finale. Ogni team è responsabile di uno o più pacchetti di soluzione. Caratteristiche all'interno di questi pacchetti possono dipendere da uno altro, ma non dovrebbe dipendere da pacchetti prodotti da un'altra squadra.
Una struttura parallela funziona al meglio quando le funzionalità dell'applicazione può essere suddivisa in più o meno indipendenti sottoapplicazioni. Ogni squadra crea e unit test i propri componenti e controlli li nel controllo del codice sorgente. Processo di compilazione automatica quindi combina i pacchetti da varie squadre in un singolo. Questo processo permette il vostro team lavorare indipendentemente uno da altro maggior parte del tempo con un importo minimo di coordinamento necessaria tra squadre durante lo sviluppo.
Struttura lineare team
La struttura successiva che si potrebbe considerare è una struttura lineare, o a strati, team. In questo caso, ogni team è responsabile per lo sviluppo di funzionalità ad uno strato di applicazione. Ad esempio, si potrebbero avere tre squadre sviluppando pacchetti della soluzione che verranno strati insieme. Squadra 1 crea lo strato di fondo quadro e archivia nel controllo del codice sorgente. Squadra 2 recupera le soluzioni da 1 Team e li usa come un quadro o un toolkit per la creazione del livello successivo nello stack. Squadra 2 passa poi il secondo strato di componenti al Team 3.
Una struttura lineare è più adatta a situazioni dove un'applicazione è costruita a strati di astrazione o di quadri. SharePoint si è un buon esempio di questo tipo di progettazione. Le caratteristiche che fanno di SharePoint Foundation creano uno strato di strumenti che è possono utilizzare altre applicazioni basate su SharePoint.
Un esempio di un'applicazione costruita utilizzando questo toolkit è SharePoint Server 2010. Il prodotto server è davvero solo un set di componenti costruito sulla cima della Fondazione fornita da SharePoint Foundation. Microsoft Project Server e Microsoft CRM sono altri esempi di soluzioni costruite con questo processo di sviluppo.
Quando si sviluppano soluzioni in strati, ogni strato sarà solitamente dipendono dalla funzionalità fornite ai livelli più bassi dello stack. Queste dipendenze possono essere dichiarate nelle soluzioni e caratteristiche che sono stati sviluppati per garantire che tutti i prerequisiti sono soddisfatti quando si attiva una funzionalità di un sito di SharePoint.
Struttura del team basato su componenti
Considerando che gli approcci paralleli e lineari separano lo sviluppo assegnando pacchetti soluzione a diverse squadre, ci sono casi dove questo non appena è possibile. In questo caso, voi e il vostro team potrebbe essere necessario adottare un approccio basato su componenti. Questo tipo di struttura assegna componenti come Web part, moduli, flussi di lavoro e simili alle varie squadre. Questi sono indipendentemente testati e controllati in controllo del codice sorgente. Solo allora i componenti sono confezionati per la consegna.
Questo tipo di struttura è molto flessibile perché è possibile spostare componenti da una squadra a altra in base alle esigenze senza alterare il packaging dell'applicazione. Purtroppo, questo rende anche le varie squadre interdipendenti.
Squadre lavorando sugli stessi pacchetti soluzione necessario assicurarsi che eventuali modifiche che potrebbero intaccare i componenti sviluppati da altre squadre sono chiaramente comunicati. Test di integrazione basati sull'esecuzione dei pacchetti finali è fondamentale in questo tipo di ambiente. La più probabile fonte di bug in qualsiasi sistema è a ogni confine tra componenti sviluppati da team diversi.
Strategia di sviluppo del team
Ci sono parecchie altre considerazioni da tenere a mente quando tracciare la strategia di sviluppo del team:
- Ogni squadra avrà un programma separato automated build?
- Ogni squadra avrà una farm di testing integrazione separata, o si condividono una singola farm?
- Come pensate comunicati per consentire ogni componente per essere completato nell'ordine necessario da altre squadre che dipendono da esso?
- Quanto la comunicazione è necessaria all'interno e tra le squadre?
- Tutte le squadre saranno nella stessa posizione fisica?
- Chi è responsabile per l'integrazione di test la versione finale prima della consegna per test di accettazione?
Naturalmente, come le applicazioni diventano più grandi e più complessi, è probabile che nessuna struttura singola squadra sarà sufficiente. Un approccio ibrido, utilizzando una combinazione di parallelo, lineare e componente-ha basato le squadre diventerà la norma in organizzazioni di grandi dimensioni.
La squadra di governo dovrebbe garantire che tutte le squadre di comprendano la loro responsabilità assegnate. Essi devono garantire che le squadre eseguano test rigorosi sulle soluzioni prima della loro distribuzione su SharePoint.
.jpg)
Steve Wright è un senior manager nella gestione di business intelligence per Sogeti USA LLC in Omaha, Neb Nel corso degli anni ultimi coltivano, Wright ha lavorato sul controllo del traffico aereo, finanziaria, assicurazioni e una moltitudine di altri tipi di sistemi. Ha creato ed eseguito valutazioni tecniche per molti titoli precedenti riguardanti prodotti Microsoft, tra cui Windows, SharePoint, SQL Server e BizTalk.
.jpg)
Corey Erkes è un consulente di gestione per Sogeti USA LLC in Omaha, Neb Erkes ha lavorato con una vasta gamma di aziende in diversi punti del ciclo di vita delle loro implementazioni SharePoint. Egli è anche uno dei membri fondatori del gruppo di utenti SharePoint Omaha.
© 2012 Apress Inc. Tutti i diritti riservati. Stampato con il permesso da Apress. Copyright 2012. "Pro 2012 Governance di SharePoint" da Steve Wright e Corey Erkes. Per ulteriori informazioni su questo titolo e altri libri simili, si prega di visitare apress.com.