Implantação de ALM

Várias pessoas já me abordaram falando que querem implantar uma plataforma de ALM, querem começar a utilizar o TFS, mas são muitos recursos disponíveis, que é complicado ter tempo de capacitar a equipe inteira e até de assimilar muitas coisas novas de uma vez só

É importante entender que apesar de termos muitos recursos no Visual Studio ALM (sendo o TFS o coração dessa plataforma), não é necessário implantar todos os recursos de uma vez só.
Outro ponto importante para entender é que ALM está muito ligado ao negócio e à cultura da empresa, por isso não existe uma receita universal para implantação dos recursos, cada organização, cada equipe é um caso diferente.

Uma coisa legal de se fazer é rodar uma avaliação de como está a maturidade da empresa quanto a ALM, é algo que ajuda muito a decidir por onde começar a implantação. Uma ferramenta legal para isso é um Application Platform Optimization Assessment criado pela Microsoft especifico para ALM: https://bit.ly/q5jKPD . Trata-se de um questionário em várias áreas, como, por exemplo: arquitetura, gerenciamento de requisitos, gerenciamento de projetos, qualidade, entre outros. O resultado vai mostrar quais são as áreas mais frágeis, isso pode dar uma ajuda na hora de planejar quais recursos implantar primeiro.

Além disso posso compartilhar algumas coisas que já vi em implantações de TFS que foram legais. Vou fazer comentários sobre recursos do TFS e podemos explorar mais a fundo no futuro.

1. Comece com o Source Control: é legal começar com o Source Control, porque no fim das contas é dai que você vai gerar todo o resto. O Source Control do TFS é extremamente poderoso com várias recursos como Histórico de aterações, Branching, Merging, entre outros. É muito legal como é fácil de auditar o histórico de alterações, bem como ver graficamente a relação entre diferentes versões do código;
2. Use os work items para ter rastreabilidade e visibilidade: tendo o código-fonte no Source Control do TFS é muito importante começar a utilizar os work items. Os work items são extremamente importantes para você ter dois benefícios de utilizar o TFS: visibilidade e rastreabilidade. Os work items serão base para na sequencia você utilizar uma série de recursos, como por exemplo, os relatórios. Os work items dão visibilidade no seu projeto! Além de visibilidade eles fornecem rastreabilidade, por exemplo, o código-fonte que nós começamos a controlar no primeiro passo pode ser vinculado aos work items. Isso gera um benefício muito grande porque através dessa ligação fica fácil responder algumas perguntas que aparecem durante os projetos, como, por exemplo: "Porque esse trecho de código foi alterado?". Tendo o código ligado com o work item pode facilitar nisso, além de outros benefícios que teremos na sequencia;
3. Melhore o processo de build, testes e deploy com Team Build:  Usando o Source Control e os Work Items o próximo passo é utilizar o Team Build. O Team Build é o serviço de Build disponível no Team Foundation Server. É impressionante como muitos times ainda não trabalham com processo de build automatizado. Com build automatizado temos muitos benefícios, como, por exemplo, facilitar o processo de deploy da aplicação, fazer validações de qualidade do código que está indo para o servidor, executar testes unitários, e muitos outros. Uma coisa muito legal de utilizar quando temos um processo de build automatizado é Integração Contínua. A ideia é: "Integre cedo, integre sempre". O que isso quer dizer é você ter um processo automatizado que sempre verifique se o código que está subindo para o controle de versão funciona junto com o código todo. o Team Build tem recursos muito legais para ajudar nisso. Nesse ponto é interessante ver como as coisas estão integradas - quando você utiliza o Source Control e liga os check-ins com os work items você terá no relatório do Build todos os changesets e work items que entraram nesse build, isso ajuda muito a ter visibilidade sobre o que está entrando naquele build.
4. Aumente a qualidade com teste unitário: Teste unitário é uma técnica de engenharia de software que já se mostrou extremamente eficaz há muito tempo. Com teste unitário o desenvolvedor consegue ter muito mais certeza sobre a confiabilidade do código desenvolvimento, além de facilitar muito a manutenção de um aplicativo. Com certeza muita gente já passou pela situação de precisar dar manutenção em um aplicativo que já está em produção, mas não sabe ao certo o impacto que aquela alteração vai causar. É interessante lembrar que o teste unitário pode ser executado também no servidor de Build. Isso é uma maneira muito boa de automatizar e ter visibilidade sobre o resultado dos testes de uma aplicação. Vale a pena ressalvar que a implantação de testes unitários já pode ser feita desde o começo, aqui são apenas dicas em ordem sequencial, elas podem ser feitas paralelamente.
5. Teste a sua aplicação: o Visual Studio 2010 trouxe melhorias gigantescas na parte de testes com o Test Manager e o Lab Management. Com o Test Manager você pode criar, gerenciar e executar casos de testes de maneira extremamente simples. Um dos grandes benefícios do Test Manager é ele trabalhar com o conceito de "Bugs Ricos". Isso quer dizer tentar eliminar o cenário "Funciona na minha máquina". O que acontece muito entre testadores e desenvolvedores é um atrito, pois o testador cria um bug, mas o desenvolvedor alega nunca conseguir reproduzir os bugs por falta de informação. A ideia de trabalhar com "bugs ricos" é que o test manager coleta dados automaticamente quando o testador está executando os testes, dentre todos os dados coletados o mais interessante de todos é o IntelliTrace, que fornece uma espécie de pilha de execução da aplicação, e o desenvolvedor consegue receber isso e verificar como a aplicação estava naquele momento do erro, bem como navegar entre os passos da pilha.
6. Organize o seu ambiente de testes com Lab Management: Um dos grandes desafios da área de testes é ter ambientes organizados para executar os testes. Muitas vezes uma aplicação vai rodar em diferentes ambientes, mas por falta de recurso os testadores acabam testando em somente um ou dois ambientes que ele tem disponível. Com o lab management é possível criar uma biblioteca de máquinas virtuais que serão utilizadas para executar os testes. Uma coisa muito legal é que o testador pode criar uma snapshot da máquina virtual no momento em que deu o erro, e o desenvolvedor recebe esse snapshot junto com o bug criado.
7. Automatize os seus testes: Usar testes unitários e testes manuais são um grande passo para um time. Uma coisa que vai ficar clara com o passar do tempo é que não é possível sempre testar a aplicação manualmente. O que vai acontecer é que a aplicação vai crescendo e junto com isso o volume de testes vai crescendo. Com o volume de caso de testes crescendo fica inviável executar os testes manuais em toda a aplicação. Para resolver isso temos o recurso de teste automatizado de interface de usuário, que é chamado Coded UI Test. Com o Coded UI Test você pode criar código que vai testar a interface de usuário de um aplicativo. Uma coisa muito legal é que você pode colocar a execução destes testes unitários junto com o Build, inclusive utilizando os ambientes virtuais do lab management.

Alguém pode perguntar: e os relatórios??? A partir do momento em que começamos a utilizar os work items já devemos começar a utilizar também os relatórios, e conforme os recursos de build, teste e outros são utilizados o número de relatórios populados vai aumentando.

O Visual Studio ALM tem muito mais coisas que devem ser utilizadas, mas esses primeiros passos já representam um passo grande em uma implantação de ALM.

Outros recursos que devem ser utilizados são: Integração com o Project Server, os recursos do Visual Studio Ultimate, customização de Process Templates, alertas de work item, análise estática de código...

O que acham? Alguém quer compartilhar alguma experiência de implantação de TFS?

É isso, tem muita coisa legal para utilizar, então, mãos à obra. :)

Daniel