VSTS - Visão Geral
por Fábio Câmara e Marcus Garcia
Desde a década passada diversas pesquisas nos apresentam como resultados altos percentuais de fracasso em projetos de software. Acreditamos que somente com uma proposta realmente diferente poderemos mudar este negativo histórico dos últimos 10 anos. Esta proposta chama-se Visual Studio Team System!
Uma reflexão cabe nesta informação introduzida: Se uma informação histórica de insucesso persiste por muito tempo em nossa realidade é sinal que ela representa a normalidade. Em outras palavras, pelo tempo que os projetos fracassam podemos considerar que todo novo projeto está mais inclinado a fracassar do que a ser bem sucedido. Responsabilizados pela semântica que introduzimos e pela necessidade quase que desesperada de "plantar sementes" que proporcionem resultados diferentes nas pesquisas comentadas, propomos duas fases bem divididas para este artigo técnico: Na primeira fase apresentaremos conceitos técnicos importantes para compreender a ferramenta e na segunda mostraremos na prática como funcionam alguns destes conceitos.
Conceitos principais
Todo o mecanismo de funcionamento do conjunto de ferramentas que compõe o Visual Studio Team System, dividido primeiramente pelo lado servidor por uma ferramenta chamada Team Foundation Server e pelos "clientes" especializados conforme papel de colaboradores previamente definidos no projeto chamado de Visual Studio Team Editions, funciona tomando como base um "template"de processos.
Neste momento de lançamento recente da ferramenta, o TFS fornece somente dois templates de processos, ambos derivações evoluídas do MSF - Microsoft Solutions Framework. São eles: MSF for Agile Software Development e MSF for CMMI Process Improvement. Para estudar estes processos fornecidos pela metodologia e automatizados pela ferramenta você deve ler o Process Guidance, guia que é disponibilizado pelo VSTS por padrão e pode ser visualizado na janela Team Explorer (ver mais adiante na demonstração prática).
Por trás destes processos, existem conceitos importantes de serem compreendidos para o pleno funcionamento das propostas de controle, gestão e automação de informações sobre o projeto em desenvolvimento. Muitos destes conceitos que apresentaremos agora são válidos para as duas metodologias, contudo ressaltamos que nos baseamos no MSF for Agile Software Development. Na medida do possível traduziremos todos os termos para português. Raras exceções serão mantidas visando não definir uma "tradução" inadequada ao termo em nossa língua.
| • | Papéis: São responsabilidades pré-estabelecidas e com foco especialista que colaboradores do time do projeto assumem ao início do mesmo. Um colaborador pode ter mais de um papel e a lista de papéis sugerida é: Gerente de Programa, Gerente de Produto, Gerente de Versão, Arquiteto, Desenvolvedor, Analista de Testes e Representante de Usuários.
| ||||||||
| • | Grupo de Atividades e Atividades: Papéis realizam alguma atividade, que são agrupadas em grupos de atividades. As atividades produzem produtos e possuem uma classificação de estado. Uma atividade pode conter um ou mais itens de trabalho. Os resultados das atividades são chamados de produtos ou "work products". Work products são tipicamente documentos, códigos fontes, planos de projetos e qualquer outro tipo de resultado que agrega valor ao projeto. Resumidamente podemos hierarquizar como:
| ||||||||
| • | Usuários e grupo de usuários: Colaboradores do projeto precisam fazer login em sua estação de trabalho como um usuário válido e definido no Team Explorer do Visual Studio Team System. É conforme o papel deste usuário que determinadas funcionalidades e permissões de uso estarão liberadas para que o mesmo utilize-as. Aplicar o conceito de grupo de usuários é um facilitador que incrementa a segurança e a administração do projeto, permitindo a implementação de regras associadas ao grupo. Imagine cadastrar uma série de políticas e ter que aplicar uma a uma para cada usuário, seria no mínimo improdutivo - concorda? | ||||||||
| • | Work Item Database e Metric Warehouse: Todas as informações planejadas ou inseridas no Team Project são gerenciadas dentro de um banco de dados SQL Server 2005. Estes registros são chamados de work items e podem trilhar os estados das atividades ou tarefas dentro deles. Existe uma série de consultas ao banco de dados preparadas que fornecem relatórios e gráficos em tempo real permitindo a visualização de como "anda a saúde" de seu projeto.
| ||||||||
| • | Source Control: O Team Foundation Version Control é em nosso ponto de vista a primeira e mais fácil justificativa para você adotar o VSTS em seu time de projeto. Suas diferenças positivas em comparação com o Visual SourceSafe e outras ferramentas concorrentes de mercado são tão significativas que seria o mesmo que comparar, fazendo uma analogia, uma prancha de surf com um jet ski. Os work products como código fonte e arquivos de textos são armazenados nele. Os demais work products como planilhas, documentos binários e etc são armazenados e gerenciados pelo project portal, que tem por trás dele as funcionalidades do WSS - Windows SharePoint Services. | ||||||||
| • | Project Portal: Através de um site automaticamente disponibilizado pelo Visual Studio Team System, gerentes de projeto, gerentes de produto, usuários e quaisquer papéis que possamos classificar como "stakeholder" podem ter acesso a informações importantes e atualizadas sobre o projeto como, por exemplo, índices de produtividade e qualidade do mesmo. Outro ponto positivo é que o portal aplica o conceito "user friendly" possibilitando usuários "comuns" visualizarem estas informações. | ||||||||
| • | Ciclos e iterações: A integração do MSF com o VSTS permite a aplicação rápida de técnicas de desenvolvimento baseadas em ciclos e iterações. Um cenário típico de utilização é ter ciclos curtos que compreendem iterações com focos específicos. Iterações curtas possibilitam a redução da margem de erro em suas estimativas, pois proporcionam rápido retorno comparativo entre o planejado e o realizado dentro do seu projeto. Pelo conceito do MSF, cada iteração deveria resultar em um pedaço estável do "todo", propiciando a evolução perceptível dos resultados do projeto.
| ||||||||
| • | Mindset ou em nossa tradução livre, "atitude": A comunhão entre MSF e VSTS defende uma série de atitudes que devem ser incorporadas pelo time de projeto para o máximo proveito da automação fornecida pela ferramenta. Estas atitudes são amplamente explicadas na documentação que acompanha a metodologia escolhida na hora de utilizar a ferramenta. Algumas destas atitudes são subjetivas como por exemplo "incentive a comunicação aberta" e outras são bem objetivas como por exemplo "promova entregáveis com freqüência". |
Visualizando a prática
Através de uma proposta de explicação passo-a-passo, mostraremos como se cria um time de projeto, como se define um time de projeto, exemplificaremos o cadastro de itens de trabalho e sua respectiva visualização no Project Portal.
Time de projeto
A criação de um time de projeto no Visual Studio Team System ou abreviadamente VSTS, pode ser feita facilmente. Antes isso, precisamos lembrar que, o VSTS na sua versão atual, não pode ser instalado no mesmo servidor que possui o AD (Active Directory) de seu DC (Domain Controller). Na prática, isso quer dizer que para montar times no VSTS antes você precisa criá-los no DC da empresa. (Figuras 1 e 2)
Figura 1 - Acessando o Active Directory para criar os usuários do time
Figura 2 - Entendendo o Gerenciador de domínio
Após abrir o Gerenciador do AD (Active Directory), note que existe um domínio (Item 1 da figura 2), esse é o domínio do seu servidor considerado o DC (Domain Controller) de sua rede local. Mais abaixo você encontra os grupos do domínio, entre eles o grupo Users local de criação de seus usuários (Item 2 da figura 2). Vale lembrar que os privilégios das contas dos usuários de seu time sobrepõe os privilégios definidos na administração do seu projeto no VSTS, ou seja, os privilégios do AD são mandatórios, portanto, é necessário ter muito cuidado na administração de contas.
Na DC de nosso exemplo estamos utilizando vários papéis, entre eles:
- 1 Admin
- 2 Arquitetos
- 2 Desenvolvedores
- 1 Tester
- 1 Gerente de Projeto
Cada um com seus respectivos privilégios de acesso ao domínio. Mais uma vez vale lembrar que para um administrador de rede todos os envolvidos acima tem praticamente os mesmos privilégios de acesso ao domínio.
Figura 3 - Entendendo o Gerenciador de domínio
E também vários grupos (Figura 3) com os quais é possível definir privilégios também. Dessa forma, podemos migrar um usuário que tem privilégio de desenvolvedor para arquiteto simplemente arrastando-o para o grupo em questão e dessa forma sendo atribuídos para ele os direitos do grupo escolhido.
Nota
Caso não exista um DC na sua rede local, será necessário ter um para a instalação do VSTS. Uma outra opção seria instalar o VSTS for Workgroups* onde a utilização do DC não é obrigatória.
* Acesse o site http://msdn.microsoft.com/vstudio/teamsystem/ e procure maiores informações.
Abra o Visual Studio 2005 e em seguida clique no menu View / Team Explorer ou digite as combinações de teclas CTLR + ] ou CTRL + M (Figura 4)
Figura 4 - Entendendo o Team Explorer
O Team Explorer como o próprio nome diz é o Gerenciador dos Projetos do VSTS, tem seu funcionamento idêntico ao Solution Explorer, porém, é totalmente voltado ao gerenciamento dos projetos.
Clique em Adicionar Projetos Existentes , escolha um projeto e em seguida clique com o botão direito do mouse sobre Team Project Settings. (Figura 5)
Figura 5 - Explorando o Team Explorer
Administração básica
Após a criação do projeto é preciso definir as permissões do mesmo (somente leitura, escrita, publicação, criação e execução de builds e etc.)
Vá para a guia Team Explorer, clique com o botão direito sobre o seu projeto. Escolha Team Project Settings e na seqüência um dos Itens:
- Groups
- Permissions
- Classifications
- Source Control
Groups
Nesse opção, podemos definir grupos, assim como fazem os Administradores de redes para o Active Directory os usuários que fazem parte de um determinado grupo herdar as permissões escolhidas para o mesmo.
Figura 6 - Explorando o Groups
Clicando em Properties (Figura 6), temos condições de adicionar os usuários do grupo escolhido. Note que esse usuário pode ser de sua rede local ou um outro Team Foundation Server Group.
Figura 7 - Explorando o Groups II
Permissions
As permissões podem ser dadas tanto a grupos como a usuários isolados. Entre essas permissões podemos encontrar:
- Administrar um build
- Apagar resultado de testes
- Apagar este projeto
- Editar status de builds
- Editar informações do projeto
- Publicar resultado de testes
- Iniciar / terminar um build
- Visualizar informações do projeto
- Escrever Builds
Figura 8 - Explorando Permissions
Classifications
Defina o modelo Hierárquico do projeto e quem tem acesso e a quais partes.
Figura 9 - Explorando o Classifications
Source Control
Multiplos Checkouts? Já vem por padrão habilitado. Defina regras para Chekin como Análise de código, Testes, Work itens e etc. Defina-os como requeridos ou não, crie suas próprias regras. No policy Editor é possível você definir regras para todo o projeto
Figura 10 - Explorando o Source Control
Work Items (Itens de trabalho)
Toda e qualquer ação envolvida em um projeto é considerada um Work Item, portanto, o Work Item é vital ao andamento de um projeto. Mostraremos a seguir como gerenciar esse grande recurso do VSTS.
Para cadastrar um Work Item, abra o Team Explorer e depois abra o projeto escolhido. Clique com o botão direito sobre Work Itens e depois clique em Add Work Item
Figura 11 - Explorando o Work Item
Escolha um tipo de Work Item. Por padrão, os tipos Bug, Quality of Service Requirement, Risk, Scenario e Task já estão criados. Escolha um deles clicando sobre o item desejado.
Em nosso exemplo estou utilizando o Work Item do tipo Task. Vamos analisar esse tipo:
Figura 12 - Criando um Work Item
1. | Nessa área digite o título de sua tarefa (Task) |
2. | Escolha a área ou departamente do seu time que ficará responsavel pela tarefa |
3. | Defina o Status da tarefa, inicialmente esta como Ativo, você pode criar novos Status se necessário. |
4. | Especifique, se necessário, qual pessoal específicamente será a responsável pela tarefa |
5. | Descreva detalhes, históricos, links, anexe arquivos e demais informações pertinentes a tarefa |
Classification - Trata-se de uma área específica do cadastro de item destinado a escolha da área do projeto , ou seja, posso criar uma tarefa específica para um item de sub-pasta por exemplo e também definar por qual Iteração essa classificação vai passar.
Após o preenchimento, clique em Salvar e depois feche o item. Vamos agora visualizar/administrar esse item em diversas visões diferentes.
Visualizando e administrando itens
Umas das formas de visualizar um Work Item é pelo próprio Visual Studio. Para isso, vá para o Team Explorer clique sobre Work Items e em seguida escolha Team Queries / All Tasks.(Figura 13)
Figura 13 - Visualizando um Work Item
O Team System traz por padrão várias queries de visualizações padrões. Você pode escolhar uma delas ou criar a sua própria clicando com o botão direito do mouse sobre Team Queries (figura14)
Figura 14 - Criando uma Querie de consulta
Ao escolher a opção All Tasks, clique com o botão direito do mouse sobre View Results você tem acesso a todas as tarefas que estão pendentes no sistema (Figura 15) além é claro, de poder fazer as devidas modificações no item.
Figura 15 - Criando uma Querie de consulta
E o Gerente de Projeto? Como administra?
Através de acesso via Microsoft Project e/ou Microsoft Excel é possível administrar um Work Item também. Para isso abra o Excel inicialmente, ou se preferir, escolha a opção Open in Microsoft Excel localizado no menu de All Tasks conforme Figura 15.
No Microsoft Excel
A administração via Excel é simples, bastando para isso apenas alguns passos que iremos descrever a seguir. Durante todo o exemplo poderá notar que é bem simples e por diversas vezes bem intuitivo.
Figura 16 - Criando uma Querie de consulta
Na parte superior (Figura16) temos a barra de trabalho do VSTS que pode ser adicionada a partir da instalação desse Add-On que acompanha o VSTF (Visual Studio Team Foundation). Nessa barra é possível:
Conectar em um projeto de time já existente
Figura 17 - Visualizando e Administrando Work Items via Excel
Escolha o projeto simplesmente clicando no item desejado, na sequencia é solicitado a escolha de uma query (Figura 18).
Figura 18 - Escolhendo uma Query em Microsoft Excel
Ao escolhar uma New List e uma Query automaticamente você tem a visualização dos Work Items (figura 16).
Publica alteração efetuadas no Item escolhido
Após efetuar as modificações no item, você pode simplesmente clicar em publicar e o VSTS atualiza a base de dados do Projeto (Figura 19).
Figura 19 - Atualizando a base de dados em Microsoft Excel
Ao clicar em Publish note que a barra de Status da planilha indica a atualização. Portanto, isso prova que a base de dados esta sendo alterada.
No Project
No Project o processo é bem similar ao executado no Excel, bastando apenas ter o Add-On do VSTF instalado no micro também. Porém, no Project é possível ter um ambiente bem mais amigavel ao Gerente de Projetos, podendo por exemplo, alterar prazos utilizando-se de recursos do tipo Drag and Drop (Figura 20)
Figura 20 - Administrando Work Items em Microsoft Project
Project Portal
Um dos recursos mais inovadores do VSTS é sem dúvida o Project Portal que nos mostra em ambiente web, utilizando-se para isso o Share Point Services, toda a situação do nosso projeto além de fornecer também toda a documentação default da metodologia de desenvolvimento escolhida para o projeto.
Figura 21 - Vizualizando o projeto pelo Project Portal
Entre as inúmeros opções podemos destacar os Reports, a área para adcionar notícias sobre o projeto Announcements, e também a Issues List que trás para nós os Work Items atuais (figura 22).
Figura 22 - Vizualizando Work Items pelo Project Portal
Conclusão
Apresentamos uma visão geral sobre uma proposta diferente, evolutiva e inédita.. A adição de atitudes novas com a automação de controles proporcionarão expectativas ímpares e apoiarão sua tomada de decisão direcionando corretamente o projeto nos momentos de dúvidas do time.
Acreditamos em muitos avanços que serão facilmente perceptíveis aos times que adotarem as atitudes e as funcionalidades disponibilizadas pela ferramenta. Ainda como acréscimo, as novidades do TFVC - Team Foundation Version Control também proporcionarão significativas melhorias de controle, segurança e compartilhamento de documentos do projeto.
Sucesso em seus projetos.
Fabio Camara (fabio.camara@vstsrocks.com.br) é Microsoft MVP (Most Valuable Professional) em VSTS, MCAD Charter, MCDBA, MCSE, MCSD.NET, MSF Practitioner e ITIL Foundations Certificated. É membro fundador do VSTS Rocks Brasil (http://www.vstsrocks.com.br) e ministra palestras e demonstrações práticas de VSTS desde sua versão Beta 2 - Utiliza VSTS em seus projetos e sonha com uma ferramenta como esta desde que começou a coordenar projetos de software com grupo de pessoas em 1998.
Marcus Garcia (marcusgarcia@teamsystem.com.br) é Microsoft MVP (Most Valuable Professional) em Visual Basic, Diretor da INETA BRASIL (International .NET Association), palestrante, escritor, e colunista em diversos sites. Estuda VSTS desde a versão Beta 1 e esta muito contente com a evolução da ferramenta para gerenciamento de projetos mais inovadora do mercado.