SharePoint 2010: Preparar sua equipe
Selecionando e criando a estrutura de equipe de desenvolvimento adequada é fundamental para sucesso desenvolvimento de soluções do SharePoint.
Steve Wright e Corey Erkes
Adaptado de "Governança Pro SharePoint 2010" (Apress, 2012)
Um dos aspectos mais flexíveis do SharePoint como uma plataforma de colaboração é a capacidade de preparar e implantar aplicativos de negócios personalizado. Isso pode ser um processo complexo. Há muitas opiniões diferentes sobre o tamanho e estrutura de sua equipe de desenvolvimento de solução do SharePoint mais eficiente e eficaz.
Os defensores do desenvolvimento ágil solução preferem equipes menores porque regular comunicação individual é considerada um aspecto essencial do processo. Para projetos de desenvolvimento, um único time de menor não pode fornecer capacidade suficiente para satisfazer a necessidade de novas funcionalidades. Neste caso, a atribuição de várias equipes pequenas é geralmente mais eficaz do que uma única equipe de cada vez maior.
Planejamento e atribuindo uma divisão de trabalho entre várias equipes torna-se essencial. Há três maneiras principais para estruturar várias equipes para o desenvolvimento de soluções do SharePoint:
- Estrutura de equipe paralela
- Estrutura de equipe linear
- Estrutura de equipe baseado em componentes
Lembre-se que no SharePoint, um pacote de solução é a unidade de implantação. Enquanto suas equipes e você podem criar um pacote de solução única enorme para um aplicativo grande, é geralmente preferível para dividi-lo em vários pacotes relacionados que você pode testar e versão individualmente.
Estrutura de equipe paralela
A primeira estrutura de equipe é aquele em que equipes diferentes trabalham em paralelo para criar um conjunto de pacotes de soluções que compõem a versão final. Cada equipe é responsável por um ou mais pacotes de solução. Características dentro desses pacotes podem depender um do outro, mas eles não devem depender de pacotes produzidos por outra equipe.
Uma estrutura paralela funciona melhor quando você pode quebrar a funcionalidade do aplicativo em subaplicativos mais ou menos independentes. Cada equipe cria e testa seus próprios componentes de unidade e verifica-los no controle de fonte. O automatizada compilação processo então combina os pacotes de várias equipes em um único lançamento. Este processo permite que as equipes trabalham independentemente uma da outra na maioria das vezes, com um mínimo de coordenação necessária entre as equipes durante o desenvolvimento.
Estrutura de equipe linear
A estrutura próxima, que você pode considerar é uma estrutura linear, ou em camadas, equipe. Neste caso, cada equipe é responsável pelo desenvolvimento de funcionalidade em uma camada do aplicativo. Por exemplo, você pode ter três equipes desenvolvendo pacotes de solução que vão ser em camadas juntas. Equipe 1 cria a camada de quadro inferior e verifica-lo no controle de fonte. Equipe 2 recupera as soluções da equipe 1 e usa-los como um quadro ou conjunto de ferramentas para construir a próxima camada da pilha. Equipe 2 passa a segunda camada de componentes para equipe 3.
Uma estrutura linear é o mais adequada para situações onde um aplicativo é construído em camadas de abstração ou quadros. SharePoint-se é um bom exemplo deste tipo de projeto. As características que compõem o Windows SharePoint Services criam uma camada de ferramentas que podem usar outros aplicativos baseados no SharePoint.
Um exemplo de um aplicativo criado usando este kit de ferramentas é o SharePoint Server 2010. O produto de servidor é realmente apenas um conjunto de componentes, construído sobre a base fornecida pelo Windows SharePoint Services. Microsoft Project Server e Microsoft CRM são outros exemplos de soluções criadas com este processo de desenvolvimento.
Ao desenvolver soluções em camadas, cada camada geralmente será dependente de recursos fornecidos em níveis inferiores na pilha. Essas dependências podem ser declaradas em soluções e recursos que são desenvolvidos para assegurar que todos os pré-requisitos forem atendidos pela ativacao um recurso em um site do SharePoint.
Estrutura de equipe baseado em componentes
Considerando que as abordagens paralelas e lineares separam desenvolvimento atribuindo pacotes de soluções para equipes diferentes, há casos onde isso simplesmente não é possível. Nesse caso, você e suas equipes talvez precise tomar uma abordagem baseada em componente. Este tipo de estrutura atribui componentes como Web Parts, formulários, fluxos de trabalho e afins para várias equipes. Estas são independentemente testadas e verificadas no controle de fonte. Só então são os componentes embalados para entrega.
Este tipo de estrutura é muito flexível, porque você pode mover componentes de uma equipe para outro conforme necessário sem afetar o empacotamento do aplicativo. Infelizmente, isso também torna as várias equipes interdependentes.
Equipes de trabalho sobre os mesmos pacotes de solução precisam ter certeza de que quaisquer alterações que possam afetar componentes desenvolvidos por outras equipes são claramente comunicadas. Teste de integração com base em execução os pacotes finais é fundamental neste tipo de ambiente. A fonte mais provável de bugs em qualquer sistema é em cada limite entre componentes desenvolvidos por diferentes equipes.
Estratégia de desenvolvimento de equipe
Há várias outras considerações a ter em mente quando se estabelecessem em sua estratégia de desenvolvimento de equipe:
- Cada equipe terá uma agenda separada de compilação automatizada?
- Cada equipe terá um farm de teste de integração separada, ou serão todos compartilham um único farm?
- Como você vai planejar lançamentos para permitir que cada componente seja concluída na ordem necessária por outras equipes que dependem dela?
- Quanto a comunicação é necessária dentro e entre as equipes?
- Todas as equipes será no mesmo local físico?
- Quem é responsável pela integração de testes a versão final antes da entrega para teste de aceitação?
Naturalmente, como aplicativos se tornam maiores e mais complexos, é provável que nenhuma estrutura única equipe será suficiente. Uma abordagem híbrida, usando uma combinação de paralelo, lineares e baseada em componentes de equipes vão se tornar a norma em grandes organizações.
A equipe de governança deve garantir que todas as equipes compreendem suas responsabilidades atribuídas. Eles devem garantir que as equipes realizar testes rigorosos sobre as soluções antes de implantá-los no SharePoint.
.jpg)
Steve Wright é gerente sênior de gestão de inteligência empresarial para Sogeti USA LLC em Omaha, Nebraska Ao longo dos anos 20-última Plus, Wright trabalhou no controle de tráfego aéreo, financeiro, seguros e uma infinidade de outros tipos de sistemas. Ele tem o autor e realizadas avaliações técnicas para muitos títulos anteriores cobrindo produtos Microsoft, incluindo Windows, SharePoint, SQL Server e BizTalk.
.jpg)
Corey Erkes é Consultor Gerente Sogeti USA LLC em Omaha, NEB. Erkes trabalhou com uma vasta gama de empresas em diferentes pontos do ciclo de vida da suas implementações de SharePoint. Ele também é um dos membros fundadores do grupo de usuário do SharePoint de Omaha.
© 2012 Apress Inc. Todos os direitos reservados. Impresso com permissão da Apress. Copyright 2012. "Pro SharePoint 2012 governação" por Steve Wright e Corey Erkes. Para obter mais informações sobre este título e outros livros similares, por favor visite apress.com.