Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Metodologias de desenvolvimento de software e Visual Studio Team System

Dos documentos à automação por Sanjay Narang

Publicado em: 23 de novembro de 2006

Aplicável a:

  • Microsoft Visual Studio Team System

  • Microsoft SQL Server 2005

Resumo:

Existem diversos conjuntos de metodologias para diferentes tipos de ciclos de vida de desenvolvimento de software. Para implementar essas metodologias com eficiência e consistência, é importante ter as ferramentas do ciclo de vida que automatizam os processos e artefatos das metodologias. O Visual Studio Team System (VSTS) fornece uma solução atraente para gerenciamento e automação de metodologia de desenvolvimento de software. (12 páginas impressas)

Nesta página

Introdução
Automatização de uma metodologia de ciclo de vida no VSTS
Definição de um novo modelo de processo
Análise de metodologias de ciclo de vida típicas
Criação de modelos de processo para metodologias de ciclo de vida
Limitações
Ajustes em relação aos projetos do Visual Studio. Em outras palavras, todo o desenvolvedor tem que instalar o Visual Studio Team Explorer, mesmo se ele estiver trabalhando em um projeto que não use o Visual Studio (por exemplo, projetos baseados em Java).
Conclusão
Sobre o autor

Introdução

As metodologias de ciclo de vida de desenvolvimento de software fornecem o que (processos e produtos), como (técnicas) e quem (funções) para cada função típica em um projeto de desenvolvimento de software, como arquitetos de solução, consultores comerciais e desenvolvedores. Com o passar dos anos, o mercado de software se tornou extenso em termos de uso de metodologias. Hoje, o mercado dispõe de um número razoável estabelecido e comprovado de metodologias de desenvolvimento de software que fornece diferentes tipos de ciclos de vida de projeto. MSF (Microsoft Solution Framework ), RUP (Rational Unified Process), em cascata, ágil, etc.

Para usar essas metodologias com eficiência, é importante seguir os processos definidos nas metodologias de maneira consistente em todos os projetos. Seguir os processos de desenvolvimento de software de maneira consistente e precisa é uma tarefa desafiadora, pois:

  • Os processos de desenvolvimento de software são complexos e envolvem muitos níveis de atividades interdependentes. A maioria dos processos e das metodologias está disponível apenas como documentos de referência. É difícil para os profissionais aprenderem os processos exatos que estão nas referências dos documentos e segui-los em seus projetos.

  • Os profissionais seguem os processos manualmente e enviam os dados necessários dentro de várias ferramentas de ciclo de vida que não têm muita integração com as ferramentas de engenharia. As ferramentas de ciclo de vida podem ser ferramentas isoladas para gerenciamento de projetos, gerenciamento de requisitos, rastreamento de bug ou gerenciamento de análises, enquanto as ferramentas de engenharia podem ser ferramentas separadas para atividades como design, codificação, teste ou IDE (ambiente de desenvolvimento integrado) como o Visual Studio. Esses diferentes conjuntos de ferramentas dificultam a obtenção de uma implementação metodológica consistente em vários projetos e geram dados e relatórios inconsistentes na organização.

  • Os profissionais seguem os processos manualmente e enviam os dados necessários dentro de várias ferramentas de ciclo de vida que não têm muita integração com as ferramentas de engenharia. As ferramentas de ciclo de vida podem ser ferramentas isoladas para gerenciamento de projetos, gerenciamento de requisitos, rastreamento de bug ou gerenciamento de análises, enquanto as ferramentas de engenharia podem ser ferramentas separadas para atividades como design, codificação, teste ou IDE (ambiente de desenvolvimento integrado) como o Visual Studio. Esses diferentes conjuntos de ferramentas dificultam a obtenção de uma implementação metodológica consistente em vários projetos e geram dados e relatórios inconsistentes na organização.

  • A inconsistência faz com que o processo de análise não seja confiável, tornando, assim, difícil a identificação dos aprimoramentos do processo. Além disso, como os processos são seguidos manualmente, o relatório e a coleta de dados se tornam tarefas manuais, que resulta em produção e eficiência de distribuição mais baixa.

    Esses problemas podem ser abordados em grande parte pela automatização da implementação das metodologias usando as ferramentas de ciclo de vida fornecidas por diferentes fornecedores como Microsoft Corporation e Borland. A Microsoft oferece o VSTS (Visual Studio Team System), um ambiente integrado que abrange a maioria das atividades envolvidas em um projeto de desenvolvimento de software, que inclui automação e gerenciamento de ciclo de vida.

    O VSTS implementa suas metodologias de ciclo de vida usando modelos de processos. (Este artigo não descreve a estrutura interna dos modelos de progresso. Caso você não esteja familiarizado com isso, recomendo que você consulte Process Template Plug-Ins (em inglês) no MSDN). Um modelo de processo é um conjunto de arquivos XML que fornece especificações para diferentes artefatos e processos de uma metodologia. Para automatizar a metodologia de um ciclo de vida adotada por uma organização usando o VSTS, é necessário definir o modelo de processo para essa metodologia.

    Este artigo fornece as diretrizes necessárias para automatizar suas metodologias estabelecidas de desenvolvimento de software usando o VSTS. Além disso, ele ilustra o processo interativo de criar um novo modelo de processo e descreve os componentes comuns que constituem a maioria das metodologias disponíveis. Finalmente, ele descreve os diferentes modos para implementação desses componentes usando elementos de modelo de processo.

Automatização de uma metodologia de ciclo de vida no VSTS

O VSTS usa um conceito lógico, link projeto de equipe, que representa um projeto de desenvolvimento de software configurado no Team Foundation Server ou TFS. (O VSTS usa o componente TFS para proporcionar um armazenamento centralizado de todos os projetos relacionados a dados e permitir a colaboração entre os integrantes da equipe do projeto. Esse aspecto do lado do servidor do VSTS integra vários conceitos-chave.) Para obter os benefícios fornecidos pelo VSTS, crie um projeto de equipe para cada projeto de desenvolvimento de software que você começar. Para aplicar uma metodologia específica ao projeto de desenvolvimento de software, configure o projeto de equipe e preencha-o com dados iniciais de acordo com essa metodologia. Essas configurações e esses dados iniciais podem ser especificados usando os modelos de processo.

Os modelos de processo, como mencionado anteriormente, são um conjunto de arquivos XML com um esquema e estrutura predefinida. O PCW (Project Creation Wizard), usado para criar projetos de equipe, entende esses arquivos XML e suas estruturas. Ao criar um projeto de equipe, o PCW lê os arquivos XML do modelo de processo, e configura e preenche o projeto de equipe apropriadamente. Após a criação do projeto de equipe, as ferramentas fornecidas no VSTS (como controle de itens de trabalho, controle de código fonte, etc.) cuidam automaticamente da execução do projeto de acordo com essa configuração e com esses dados. Portanto, para implementar uma metodologia de ciclo de vida personalizada no VSTS, a única coisa que se deve fazer é definir um modelo de processo para essa metodologia e usá-la para criar um projeto de equipe. A configuração, a execução, o monitoramento e o relatório são manipulados automaticamente pelas ferramentas do VSTS, conforme elas entendem os esquemas do modelo de processo.

Definição de um novo modelo de processo

Definir um novo modelo de processo é uma tarefa complexa. É necessário planejar com cuidado e executar uma análise abrangente dos processos existentes de sua organização e dos modelos de processo do VSTS. Você deve identificar os artefatos e os processos na metodologia existente e selecionar os elementos apropriados dos modelos de processo do VSTS que serão usados para implementar esses artefatos e processos. Um artefato ou processo pode ser implementado usando mais de um tipo de elemento de modelo de processo. Você deve escolher aquele que melhor se encaixa no contexto do processo existente. A criação de um novo modelo de processo é um processo interativo. Geralmente, você pode usar as etapas mostradas na Figura 1 para criar um modelo de processo que atenda aos requisitos. A Figura 1 descreve cada etapa detalhadamente.

Aa905317.SDMthVSTS01L(pt-br,MSDN.10).gif

Figura 1. Processo interativo para criar um novo modelo de processo (clique na imagem para ampliá-la)

Escolha o modelo de processo base

Você deve escolher um modelo de processo existente como seu ponto de base e personalizá-lo de acordo com suas necessidades, em vez de criar um modelo a partir do zero. Você pode escolher um dos dois modelos de processo pronto para uso:

  • MSF for Agile Software Development

  • MSF for Capability Maturity Model Integration (CMMI) Process Improvement

Como alternativa, você pode usar um modelo de processo que já tenha definido para outra metodologia. Para escolher o modelo de processo certo, você deve analisar a metodologia e dividi-la em processos e artefatos necessários. Selecione o modelo que forneça a maioria dos processos e artefatos necessários, para que a personalização possa ser mantida em um mínimo.

Por exemplo, se sua metodologia exige um processo de revisão, é melhor usar o modelo MSF for CMMI Process Improvement, pois ele possui um WIT (Work Item Type) de revisão. Como outro exemplo, ambos os modelos têm um WIT de bug, mas se você precisar apenas de um processo bem simples de rastreamento de bugs, poderá escolher o modelo MSF for Agile Software Development, que tem um WIT de bug mais simples.

Personalizar

Depois de ter selecionado o modelo de processo base, será necessário personalizá-lo para se adequar a sua metodologia. Para fazer isso, você deve entender cada artefato de sua metodologia e criar um elemento correspondente no modelo de processo, seja mudando um arquivo XML existente ou criando um novo.

Na primeira vez que personalizar o modelo de processo, faça apenas uma pequena alteração. Se você tentar fazer muitas alterações, poderá cometer vários erros que serão difíceis de depurar. Planeje sua modificação e atualize o XML adequado para implementá-la.

Carregamento

Você deve carregar um modelo de processo antes de ele poder ser selecionado para a criação de novos projetos de equipe. Carregue o modelo de processo personalizado para um TFS usando o Process Template Manager fornecido no Team Explorer. Recomenda-se que você use um TFS que não esteja sendo usado por outras equipes, pois carregar um modelo de processo causa muitas alterações nos dados e no esquema do Team Foundation que não são facilmente reversíveis, por exemplo, novas definições de campo e seus correspondentes adicionais no depósito de relatório. Você deve carregar um modelo de processo para um TFS de produção somente quando tiver testado o modelo minuciosamente e não tiver planos de fazer nenhuma alteração futura nele.

Certifique-se de que o nome do modelo de processo não exista no TFS; não é possível carregar dois modelos de processo com o mesmo nome. Caso queira usar um nome já existente no TFS, será necessário excluir o modelo existente.

O processo de carregamento executa uma verificação para assegurar que o XML é válido, de acordo com os esquemas definidos no TFS. Se os arquivos XML do seu modelo de processo não forem válidos ou compatíveis com o esquema TFS, você encontrará erros e o processo de carregamento falhará. Neste caso, localize as alterações feitas e identifique aquela que está causando o erro. Recomenda-se que você não faça muitas alterações em uma única interação, pois isso dificultará a localização dos problemas.

Criar um projeto de equipe

Após carregar o modelo de processo, crie um novo projeto de equipe usando o PCW e utilize o novo modelo de processo para verificar as alterações. Se a criação de seu projeto falhar devido a erros, consulte o arquivo de log de criação do projeto (a última página do PCW tem um link para esse arquivo). Ele contém listas de tarefas executadas e detalhes de erros. Você pode mapear as tarefas que falharam nos arquivos XML e determinar a causa dos erros.

Mesmo quando um modelo de processo for carregado com êxito, será possível que ele provoque erros durante a criação do projeto. O processo de carregamento executa apenas uma verificação do esquema, enquanto o processo de criação lida com vários outros sistemas: bancos de dados do SQL Server, controle de origem, Windows SharePoint Services, SQL Server Reporting Services, etc. Caso haja uma alteração que não seja compatível com os esquemas de dados ou com as regras desses sistemas externos, ou caso esses sistemas não estejam acessíveis por algum motivo, você obterá um erro durante a criação do projeto.

Além disso, você não precisará criar um novo projeto de equipe para testar as mudanças nos WITs. Você pode usar o utilitário de linha de comando witimport para carregar um WIT atualizado em um projeto de equipe existente e testar as alterações nesse mesmo projeto. Para obter mais informações, consulte a referência sobre o comando witimport no MSDN do Windows.

Verificação de alterações

Após o projeto de equipe ter sido criado com êxito, verifique se sua alteração aparece no projeto de equipe corretamente abrindo o projeto no Team Explorer. Caso você tenha adicionado um tipo de item de trabalho, certifique-se que ele apareça no menu Add New Work Item. Caso você tenha removido um arquivo RDL, certifique-se de que o relatório correspondente não esteja mais disponível. Você deve executar uma verificação para cada plug-in.

Análise de metodologias de ciclo de vida típicas

Como explicado na seção anterior, a primeira etapa para a criação de um modelo de processo é entender os vários componentes e artefatos da metodologia a ser implementada. Existem várias metodologias disponíveis que representam diversos ciclos de vida de desenvolvimento de software. Estas metodologias geralmente têm os seguintes artefatos:

  • Fases, interações ou estágios. Por exemplo, a metodologia em cascata define fases como Requirement Engineering, Design, Coding e Unit Testing, etc.

  • Processos contínuos comuns a todas as fases ou interações desse ciclo de vida, por exemplo, gerenciamento de alterações, gerenciamento de risco, etc.

  • Métricas e relatórios.

  • Documentos de suporte (descrições de processo, modelos, listas de verificação e exemplos).

Uma fase típica é descrita pelos seguintes artefatos:

  • Atividades – funções e fluxos de trabalho, processos

  • Entradas – critérios de entrada

  • Saída – critérios de saída

Criação de modelos de processo para metodologias de ciclo de vida

Vamos analisar cada um dos principais artefatos das metodologias típicas, para entender suas implementações nos modelos de processo. Observe que um artefato pode ser implementado de mais de uma maneira usando diferentes elementos de um modelo de processo e qualquer pessoa pode escolher diferentes abordagens para implementar o mesmo processo ou artefato.

Para implementar um artefato, você deve modificar um dos arquivos XML existentes ou criar um novo, pois os modelos de processo são um conjunto de arquivos XML. Descrever a sintaxe do XML exato para uma implementação de artefato está além do escopo deste artigo. Contudo, o artigo descreveria como identificar os elementos de modelo de processo adequados e como utilizá-los na implementação de um artefato. Para encontrar a sintaxe necessária do XML exato, consulte a documentação modelos de processo (em inglês) disponível no MSDN.

Fases/estágios e atividades

Muitos ciclos de vida mantêm uma hierarquia de três níveis, em que o ciclo de vida é dividido em fases contendo atividades que representam os tipos de tarefas a serem executadas e em que as atividades contêm as tarefas atuais. Os ciclos de vida também necessitam que vários relatórios sejam gerados no fim de cada fase. Esses requisitos podem ser mais bem alcançados por meio de representação de fases e atividades usando a hierarquia de interação no VSTS Classifications Plug-in. As hierarquias do VSTS oferecem suporte a diversos níveis. Você pode manter quantos níveis forem necessários na metodologia que estiver implementando. Por exemplo, para um relacionamento de tarefa de atividades de fase, você pode manter dois níveis. O primeiro nível é para fases e o segundo é para atividades.

Todos os tipos de item de trabalho têm campos para selecionar o nível de hierarquias de classificação a que eles pertencem. Por meio da representação de fases e atividades usando a hierarquia de interação, qualquer tarefa (ou item de trabalho) pode ser associada a uma atividade (e a fase que a contém) escolhendo essa atividade no campo de interação do item de trabalho.

A Figura 2 mostra uma tarefa sendo associada a uma atividade e a uma fase (para um ciclo de vida de cascata) pelo Microsoft Project.

Aa905317.SDMthVSTS02L(pt-br,MSDN.10).gif

Figura 2. Associação de uma tarefa a uma atividade e a uma fase (clique na imagem para ampliá-la)

Além disso, é muito fácil gerar relatórios com base em fases ou atividades, pois essas hierarquias são dimensões predefinidas no data warehouse do VSTS.

A solução anterior será suficiente desde que você precise apenas do “nome” da fase e de seus itens de trabalho associados. Contudo, você terá que, em geral, armazenar atributos adicionais sobre a fase, como o dia de início, o dia de término, o estado, etc. As hierarquias de classificação, contudo, não oferecem suporte a qualquer atributo que não seja o nome. Neste caso, é melhor definir um tipo de item de trabalho “fase”, que possa armazenar todos os atributos necessários. Você teria que definir um item de trabalho (além da hierarquia de interação) para cada uma das fases desse projeto. Isso pode ser feito facilmente tendo um item de trabalho predefinido para cada fase nos arquivos de plug-in do item de trabalho do modelo de processo.

Para associar um item de trabalho a uma hierarquia, você pode criar apenas um WIT, “fase”, para uma determinada fase e definir o caminho de interação do item de trabalho para o nó de hierarquia correspondente a essa fase. Entretanto, não existe uma solução bem projetada para restringir os usuários do Team Foundation de criar mais de um item de trabalho de um determinado tipo, pois todos os tipos de item de trabalho são exibidos no menu Add New Work Item. A melhor solução possível é ensinar os usuários a não criar itens de trabalho adicionais desse tipo. Para ajudar os usuários, você pode nomear o item de trabalho de tal forma que eles entendam que não devem criar itens desse tipo. Por exemplo, você pode nomear um tipo de item de trabalho para a fase como “Fase [Para uso interno]” ou “Fase [Não criar]”. Além disso, pode personalizar o WIT de tal forma que ninguém tenha permissão para criar o item de trabalho, exceto os usuários de uma função em particular. Você pode fazer isso restringindo as permissões para a transição de estado para o estado inicial nessa função em particular. Por exemplo, a instrução a seguir permite apenas que os “administradores TFS” alterem o estado para “New”.

			<TRANSITION from="" to="New" for="TFS Administrators"></TRANSITION>
			

Formulários, fluxos de trabalho e processos

As atividades estão geralmente relacionadas às funções. Por exemplo, os desenvolvedores escrevem os códigos e executam revisões, enquanto os testadores realizam testes e encontram bugs. Essas atividades podem envolver um ou mais processos que devem ser seguidos para executar essas atividades. Por exemplo, a revisão pode ser executada usando um simples processo Peer Review ou um processo Fagan Inspection. Cada um desses processos pode ter o seguinte:

  • Campos e regras que administrem seus possíveis valores. Por exemplo, um processo Peer Review requer campos como Work Product Being Reviewed, Reviewer, Work Product Size, etc.

  • Estados de fluxo de trabalho. Por exemplo, um processo de rastreamento de bug necessita que o bug tenha estados como New, Active, Resolved ou Closed.

  • Transições de fluxo de trabalho possíveis. Por exemplo, o estado de um bug pode ser alterado de Active para Resolved ou o inverso, mas não pode ser alterado de Closed para Active.

  • Regras e ações de transições de fluxo de trabalho. Por exemplo, poderia haver uma regra em que quando um bug estivesse no estado Closed, ele não poderia ser atribuído a ninguém, ou quando um bug fosse encerrado por alguém, os campos Closed Date e Closed By seriam preenchidos automaticamente.

  • Layout de formulário que define a aparência e o posicionamento de vários campos desse processo.

Todos os requisitos mencionados anteriormente podem ser facilmente definidos criando um WIT para esse processo. Por exemplo, para definir o processo Peer Review , você criará um arquivo XML para o WIT Peer Review que se tornará parte de seu modelo de processo. Quando você cria um projeto de equipe baseado nesse modelo, é possível criar os itens de trabalho Peer Review com base naquele WIT, o que permite o cumprimento automático do processo Peer Review. A figura 3 mostra o item de trabalho Peer Review no ciclo de vida em cascata dentro de um Visual Studio baseado no cliente VSTS.

Aa905317.sdmthvsts03(pt-br,MSDN.10).gif

Figura 3. Interface do usuário do item de trabalho Peer Review

Existem também algumas coisas que você não pode fazer na estrutura do item de trabalho. Por exemplo, você não tem uma regra que especifique que o valor de um campo seja sempre mais ou menos o valor do outro campo (necessário nos campos Start Date e Finish Date). Além disso, não existe uma regra para especificar os valores mínimos ou máximos. Por exemplo, você pode querer restringir o campo Percentage entre 1 e 100. Além disso, não existe um método direto que especifique que um usuário pode escrever um tipo de item de trabalho e não outro tipo. Contudo, você pode encontrar soluções alternativas para a maioria dessas limitações.

Algumas vezes, as metodologias de ciclo de vida também fornecem artefatos predefinidos que todos os projetos que estiverem implementando essa metodologia devem ter. Por exemplo, tarefas como "Set Up the Development Environment" e "Create Traceability Matrix" são necessárias em todos os projetos de desenvolvimento. Do mesmo modo, produtos de trabalho como Design Document e System Test Plan também são necessários para a maioria dos projetos. A existência de tais artefatos ajuda muito os gerentes de projeto, pois eles não precisam definir as atividades ou tarefas comuns, pois essas derivam automaticamente da metodologia. Você também pode criar artefatos predefinidos para metodologias implementadas no VSTS. É possível fazer isso definindo as instâncias do item de trabalho no arquivo XML para o plug-in de rastreamento de item de trabalho.

Processos relacionados a controle de versão

O controle de versão é uma atividade fundamental para qualquer projeto de desenvolvimento de software. A maioria das organizações tem processos bem definidos para controle de versão de seus códigos-fonte e outros itens que necessitam de controle de versão como documentos, binários, etc. O VSTS fornece um novo sistema de controle de versão de nível empresarial no TFS. Você pode implementar seu processo de controle de versão existente usando um plug-in de controle de versão. Usando esse arquivo de plug-in, você pode especificar diferentes tipos de notas de check-in, diretivas gerais (por exemplo, se o check-out exclusivo é permitido ou não) e permissões (as atividades que as diferentes funções podem executar).

O VSTS também fornece diretivas de check-in que permitem a personalização de regras como All Unit Tests Should Pass Before Check-Ins. Contudo, existem diretivas específicas do cliente e não podem ser ativadas por modelos de processo.

Critérios de entrada e saída

Em geral, cada fase ou estágio tem alguns critérios de entrada e saída. Esses podem ser implementados de uma das seguintes maneiras:

  • Ter o campo Is Exit Criteria? em todos os tipos de item de trabalho que possam representar os critérios de saída. Se o valor do campo for “Yes” para um item de trabalho, isso significa que o item de trabalho é um dos critérios de saída para a fase a que o item de trabalho pertence. Por exemplo, se “Document SRS” for uma tarefa da fase Requirement Engineering e tiver o campo Is Exit Criteria? marcado como “Yes”, isso significa que essa tarefa será um dos critérios de saída para a fase Requirement Engineering.

  • Você pode salvar uma consulta a item de trabalho (usando o construtor de consultas do Team Explorer) para cada fase, que encontrará todos os itens de trabalho dessa fase com os critérios de saída “Yes”.

O mesmo se aplica aos critérios Entry. Os modelos prontos para uso no VSTS seguem essa abordagem:

  • Você pode definir um tipo especial de WIT que representa os critérios de saída. Geralmente, as metodologias têm um artefato distinto para produtos ou produtos de trabalho que também funcionam como critérios de saída. Tais artefatos podem ser mais bem representados por um WIT. Em tais casos, todos os itens de trabalho desse tipo se tornam critérios de saída para a fase a que estão associados.

  • Para fins de obrigatoriedade, caso você queira fazer distinção entre critérios de saída obrigatórios ou não, tenha um campo Is Mandatory no WIT.

Métricas e relatórios.

As metodologias de ciclo de vida definem métricas relacionadas a diferentes artefatos e aspectos do projeto, para ajudar a avaliar o desempenho do projeto e atender a padrões de qualidade estabelecidos. Essas métricas devem ser acompanhadas e fornecidas como relatórios para ajudá-lo na tomada de decisão. Existem duas etapas envolvidas na obtenção de um relatório para uma métrica em particular:

  1. Certifique-se de que todos os dados necessários para o relatório estejam disponíveis no banco de dados de relatórios.

  2. Crie um relatório que faça os cálculos necessários e formate os dados, conforme necessário.

O VSTS mantém o SQL Server 2005 baseado no data warehouse OLAP para manter os dados de todos os seus relatórios. Os dados de diferentes subsistemas do VSTS (como classificações e rastreamento de item de trabalho) atualizam os cubos e as dimensões nesse data warehouse de relatórios em intervalos regulares. Você pode então escrever relatórios com o SQL Server 2005 Reporting Services, que são implantados no projeto de equipe criado.

Os WITs lhe oferecem a possibilidade de especificar os dados que devem ir para o warehouse de relatórios. Você pode adicionar um atributo "reportable" aos campos de WITs. Todos os campos marcados como "reportable" são levados para o warehouse como dimensão ou medida, de acordo com o que você tenha especificado na definição de campo. Depois de ter os dados necessários no warehouse, você poderá definir os relatórios para uma metodologia criando arquivos RDL e adicionando-os ao plug-in de relatório do modelo de processo.

Documentos de suporte: Descrições de processo, modelos, listas de verificação e exemplos.

Geralmente, os processos e documentos relacionados (modelos, listas de verificação, exemplos, etc.) estão disponíveis no site de qualidade da organização. Como o site contém muitos processos e documentos, torna-se muito difícil para um desenvolvedor procurar algo específico. Você pode usar o VSTS de duas maneiras para simplificar isso:

  1. Especificar todos os documentos relacionados à metodologia nos arquivos XML para o plug-in WSS. Quando um projeto de equipe é criado com essa metodologia, todos esses documentos são adicionados à biblioteca de documentos especificada no site do WSS. Você pode acessar esses documentos pelo site do WSS ou do Team Explorer. O Team Explorer permite que você acesse todas as bibliotecas de documentos do projeto de equipe associado.

  2. Criar páginas de orientação do processo (usado pelo plug-in do WSS) para sua metodologia que resultaria em páginas da Web muito intuitivas e conectadas para os desenvolvedores procurarem e entenderem os diferentes processos e atividades.

Artefatos adicionais

Os modelos de processo do VSTS fornecem seis plug-ins prontos para usar que podem atender a maioria dos requisitos de suas metodologias. Contudo, pode haver alguns momentos em que esses seis plug-ins não atendam a suas necessidades. Por exemplo, o departamento de qualidade de sua organização pode manter um banco de dados centralizado que contenha as metas da empresa ou limites de várias métricas (como variação de esforço e adiamento de tarefas) que devem ser alcançados por todos os projetos. Você pode implementar isso buscando os valores de meta desse banco de dados centralizado na hora da criação do projeto e preenchê-los em tipos de item de trabalho personalizados no VSTS. No momento, nenhum dos plug-ins disponíveis atende a essas exigências. Em tais casos, você deve escrever seu próprio plug-in usando a API de extensibilidade.

Nas seções anteriores, nós abordamos a maioria dos artefatos de uma metodologia de ciclo de vida. Os mapeamentos entre os artefatos de metodologia e os modelos de processo do VSTS são resumidos na Tabela 1.

Tabela 1. Mapeamento dos artefatos do Hewlett-Packard GM e elementos de modelo de processo do VSTS

Artefatos de metodologia

Elementos de modelo de processo do VSTS

Fases e atividades

Nós do primeiro nível e do segundo nível, respectivamente, em interação hierárquica dos Classifications Plug-in

Funções e permissões

Plug-in de grupos e permissões

Fluxos de trabalho e processos (tarefas, bugs, revisões, problemas, riscos, solicitações de alteração)

Tipos de item de trabalho do plug-in de rastreamento de item de trabalho

Artefatos predefinidos (tarefas, etapas)

Itens de trabalho predefinidos no plug-in de rastreamento de item de trabalho

Regras e permissões relacionadas a controle de versão

Plug-in de controle de versão

Critérios de entrada e saída (entradas e saídas)

Tipos de item de trabalho com um campo para especificar se um determinado item de trabalho é de critério de entrada ou de saída e consultas a item de trabalho para obtenção desses itens.

Medidas e métricas (para relatórios)

Campos marcados como reportáveis nos tipos de item de trabalho relacionados

Documentos de suporte

Lista de todos os documentos necessários no plug-in WSS

Limitações

Existem algumas limitações para o sistema de gerenciamento de metodologia VSTS. As duas principais são:

  1. Nenhuma agregação através dos projetos de equipe. Isso significa que você não poderá obter relatórios que mostrem dados dos projetos em modo de busca detalhada.

  2. Ajustes em relação aos projetos do Visual Studio. Em outras palavras, todo o desenvolvedor tem que instalar o Visual Studio Team Explorer, mesmo se ele estiver trabalhando em um projeto que não use o Visual Studio (por exemplo, projetos baseados em Java).

Ajustes em relação aos projetos do Visual Studio. Em outras palavras, todo o desenvolvedor tem que instalar o Visual Studio Team Explorer, mesmo se ele estiver trabalhando em um projeto que não use o Visual Studio (por exemplo, projetos baseados em Java).

Para grandes organizações que já dispõem de processos e ciclos de vida bem estabelecidos e também são compatíveis com os padrões de qualidade como o CMMI, os recursos prontos para usar do VSTS podem ser insuficientes para atender a todos os requisitos. Tais organizações precisam de uma solução completa para gerenciar seus projetos e processos que possam servir para todos os tipos de projetos, não apenas para aqueles baseados no Visual Studio. De forma muito interessante, os recursos de extensibilidade do VSTS o tornam um bom candidato para ser usado como plataforma na criação dessa solução

A Hewlett-Packard desenvolveu essa solução – denominada APPRISE – criada sobre o VSTS Team Foundation Server e oferece muitos recursos adicionais, como cliente baseado na Web, suporte de estrutura da organização, implementação das metodologias HP Global Methods (GM), imposições de processo, serviço de rastreamento de programação e métricas e relatórios agregados. Para obter mais detalhes sobre APPRISE, consulte o estudo de caso (em inglês).

Conclusão

Resumo: Existem diversos conjuntos de metodologias para diferentes tipos de ciclos de vida de desenvolvimento de software. Para implementar essas metodologias com eficiência e consistência, é importante ter as ferramentas do ciclo de vida que automatizam os processos e artefatos das metodologias. O Microsoft VSTS é um desses sistemas e fornece uma solução atraente para automação e gerenciamento de metodologia.

O VSTS implementa uma metodologia usando modelos de processos. Você pode "personalizar" modelos de processo prontos para atender a seus requisitos de metodologia. Contudo, existem algumas funcionalidades, como agregação de relatório, que você não obtém apenas com a "personalização". Para obter isso, você pode "estender" o VSTS usando pontos extensíveis.

Sobre o autor

Sanjay Narang é consultor sênior de tecnologia na GDIC (Global Delivery India Center) da Hewlett-Packard. Ele está em Bangalore, Índia, e tem aproximadamente oito anos de experiência em TI. Sanjay obteve um PGDIT (diploma de pós-graduação) em TI e possui MCSD para certificações em .NET Framework e SCJP. Esteve por muito tempo envolvido na criação e no desenvolvimento de soluções baseadas em tecnologias Microsoft. Além disso, trabalhou em várias soluções e produtos relacionados à automatização do processo de software e padrões de qualidade do software, como SEI-CMMi.

Além da automatização de processos de software e VSTS, Sanjay trabalha nos projetos relacionados a SOA envolvidos com as tecnologias Microsoft e interoperabilidade com outras tecnologias. Ele publicou artigos sobre IPv6, VSTS, SOA e serviços da Web, e escreve extensivamente sobre o VSTS em seu blog . (em inglês) Sanjay pode ser contatado pelo sanjay.narang@yahoo.com.

Mostrar:
© 2014 Microsoft