ALM & EPM - Integrando TFS e Project Server e extraindo o melhor dos mundos

ALM & EPM - Integrando TFS e Project Server e extraindo o melhor dos mundos

Nesse artigo iremos ver situações onde se torna interessante a utilização de ferramentas e técnicas formais de gestão de projetos e como podemos realizar a integração da plataforma do Team Foundation Server com o Project Server, para podermos assim gerar informações para todos os níveis de gestão de uma organização e extrair o melhor dos dois mundos.

Introdução

No dia-a-dia dos times de desenvolvimento nos deparamos diversas vezes com cenários em que as equipes de desenvolvimento trabalham com técnicas e conceitos ágeis e utilizam exclusivamente ferramentas para a gestão de engenharia de software para gerir seus artefatos e processos , porém precisam gerar informações formais para seu board executivo (gerentes, diretores, presidência, etc) que estão fortemente acostumados com conceitos formais ou que estão acostumados com práticas de gerenciamento de projetos mais tradicionais - vale lembrar que o intuito desse artigo não é colocar em check essas culturas, uma vez que cada uma tem sua aplicabilidade, estou citando essa composição apenas para poder formular um cenário,  OK ?  - Ou ainda necessitam de uma gestão mais formal devido a alguma obrigatoriedade. Dado esse cenário muitas vezes precisamos extrair indicadores para esses executivos que não competem as ferramentas de engenharia, com por exemplo valor financeiro dos projetos, gestão de recursos, índices de aplicabilidade de um portfólio de projetos, etc. Nosso intuito hoje é mostrar como podemos utilizar de maneira integrada o TFS para as demandas de engenharia de software integradas ao Project Server para a gestão desses pontos. Não iremos abordar durante o artigo as instalações do Team Foundation Server nem do Project Server, uma vez que, não há nenhuma configuração necessária nessas etapas, e também o nosso problema simula um cenário em que ambas as ferramentas já estão em produção.

O Cenário problema - conceitual

Vamos imaginar um time de desenvolvimento que trabalhe com Team Foundation Server para os processos de engenharia de software – com seus process templates customizados, seus workflows de build e deploy, seus cenários de teste altamente automatizados, etc -  e a organização onde esse time trabalha utiliza como plataforma de gestão de projetos EPM da Microsoft (Project Server + Sharepoint). Todos os executivos da empresa, a alta direção e o PMO estão acostumados com o uso do Project para gerir os projetos. Em certo momento o time de PMO da empresa passa a integrar os projetos de desenvolvimento e solicita que os dados sejam alimentados no EPM de maneira síncrona com a plataforma de engenharia para que em uma possível auditoria ou quando solicitado os dados estejam íntegros, além de passar pelos menos critérios de aprovação de tarefas dos outros projetos. Então somos questionados sobre dois pontos: como garantir que a equipe de desenvolvimento continuará seus trabalhos da forma mais produtiva possível e que esses indicadores ou esses boards sejam alimentados constantemente? E como fazer tudo isso gerando o menor impacto possível para os times?

Teremos para esse cenário uma série de soluções possíveis, desde as mais simples como orientar o time de desenvolvimento a alimentar também a ferramenta de EPM até soluções mais custosas como por exemplo possuir uma pessoa ou um time para fazer a transição das informações do TFS para o Project. Todas são saídas funcionam (lembrando que a melhor solução depende de mais fatores além dos citados) porém infringem diretamente uma premissa que temos: gerar o menor impacto possível para os times. Como podemos solucionar essa situação?

Para resolver essa situação iremos utilizar a integração que o Team Foundation Server fornece para com o Project Server. Essa integração é feita realizando-se alguns passos que veremos mais adiante, mas antes é interessante fazermos planejamento junto com o time para que seja elencado quais tipos de artefatos do time de engenharia (work itens) serão refletidos na plataforma do EPM. Algumas perguntas devem ser respondidas nesse ponto: o que queremos gerenciar? Como iremos gerenciar? Para que iremos gerenciar? Com essas respostas em mãos teremos condições de organizar as tarefas técnicas da integração.

Outro ponto é: qual é o ciclo básico das demandas. Onde nasce uma nova demanda de desenvolvimento? Por quem? Como ela é disparada para o líder técnico de desenvolvimento?

Essas perguntas serviram como embasamento para uma possível definição fina do processo de desenvolvimento já que, uma vez que temos uma integração os dados não podem simplesmente surgir, eles precisam seguir um fluxo, por mais simples que seja.

O Cenário problema – técnico

Nosso cenário problema é composto de um time de desenvolvimento que trabalha em vários team projects diferentes, dentro de uma única Team Project Collection. Essa Collection possuí N process templates diferentes que atendem a demandas pontuais de melhoria de processo – mas que nunca foram unificadas. Em termos de gestão de projetos, cada team Project representa um cronograma, e não necessariamente é gerido por um único Gerente de Projetos.

Após as nossas conversas, chegou-se a um consenso onde entende-se que os work itens a serem integrados serão: Task, Requirement e Bug. E temos um ponto muito importante levantado também, os GPs entendem necessário ter em mãos o state atual do work item para uma gestão mais efetiva das tarefas.

Com esses dados em mãos vamos iniciar os procedimentos técnicos de integração.

O passo-a-passo da integração

Temos alguns pontos que precisamos adiantar em termos de infraestrutura antes de iniciarmos nossa integração. Primeiramente o usuário que é utilizado para a execução dos serviços do TFS é o responsável por fazer a movimentação dos dados, por isso precisamos que o mesmo tenha privilégios administrativos na nossa plataforma de EPM. Segundo, precisamos que a equipe de infra disponibilize no servidor que executa a instancia do PWA (Project Web App) a mídia de instalação do TFS na mesma versão e update da versão do TFS que estamos executando.

Com isso em mãos o primeiro passo é realizarmos a instalação da extensão do TFS responsável por fazer a comunicação entre as plataformas. Para isso basta acessarmos a mídia de instalação do TFS e localizarmos o diretório Project Server Extensions.

Imagem 1 – Diretório de instalação do Project Server Extensions.

 

Após isso basta executarmos a instalação que é bem simples e rápida e não exige nenhuma configuração – não irei incluir os prints por não exigir nenhuma interação. Feito isso vamos passar a execução dos procedimentos de mapeamento.

Obs: todo o procedimento será executado via prompt de comando em modo administrador no servidor do TFS.

No nosso cenário teremos um Team Project chamado TeamProjectIntegracao que deverá ser refletido em um projeto do EPM chamado CronogramaIntegracao.

O primeiro passo é acessarmos o diretório de instalação do TFS para podermos prosseguir. Para isso basta executarmos o comando abaixo (nesse caso uma instalação padrão).

cd %programfiles(x86)%\Microsoft Visual Studio 12.0\Common7\IDE

O procedimento de mapeamento é dividido em quatro partes:

  1. O mapeamento entre servidores
  2. O mapeamento collection x instancia do PWA
  3. O upload do mapa de campos (explicarei mais a frente)
  4. O mapeamento dos projetos com os team projects.

Desses apenas o passo 4 terá necessidade de ser executado N vezes (para cada projeto que queiramos integrar) os outros uma vez executado estarão disponíveis para todos os projetos.

Vamos agora mapear os servidores (passo 1) para que eles se enxerguem. O executável responsável por essa integração – e todos os outros daqui para frente - é o TfsAdmin.exe. Para isso basta executarmos o comando abaixo.

TfsAdmin ProjectServer /RegisterPWA /pwa:http://servidorepm /PWA /tfs:http://servidortfs:8080/tfs

 

Após executado o comando basta aguardar até a confirmação do mapeamento no prompt. Um ponto a ser observado é que o mapeamento leva um tempo para ser propagado, então após executado o comando de mapeamento de servidores é necessário que aguardemos cerca de 5 minutos para que o mapeamento seja efetivado. Feito isso agora iremos referenciar a collection com o nosso PWA (passo 2). Para isso executaremos o comando abaixo.

TfsAdmin ProjectServer /MapPWAToCollection /pwa:http://servidorepm/PWA /collection:http://servidortfs:8080/tfs/KoniaCollection

 

O próximo passo é fazermos o upload do mapa de campos. O mapa de campos é um de-para que associa os campos utilizados pelo TFS para os campos utilizados pelo Project. Por exemplo, no TFS temos um campo chamado Completed Work, utilizado para indicar o quanto de esforço daquela tarefa já foi executado. No Project temos um campo que indica o total de horas trabalhados na atividade, para que os campos sejam sincronizados e os dados de uma sejam refletidos no outro precisam utilizar esse mapa.

Porém antes de realizarmos o upload do mapa de campos, vamos nos atentar a um ponto que foi citado no nosso problema.

“[...] um ponto muito importante levantado também, os GPs entendem necessário ter em mãos o state atual do work item para uma gestão mais efetiva dos projetos.”

Por padrão os campos que são sincronizados são campos de esforço, título, do responsável e algumas data, sendo assim no Project não teremos nenhuma referência para o State. Para isso precisaremos criar um campo customizado no PWA para que possamos referencia-lo. Para incluir o campo primeiramente precisamos acessar as configurações do PWA, conforme mostra a figura abaixo.

Imagem 2 – Acesso as configurações do PWA

 

Agora acessaremos o menu “Enterprise Custom Fields and Loockup Tables”

Imagem 3 – Acesso ao menu de criação de campos customizados

 

O próximo passo é criarmos um Loockup Table que servirá como provedor de dados para o nosso campo customizado. Lembrando que o campo State deverá conter todos os states dos work itens que serão sincronizados. Para isso basta acessarmos o menu “New Loockup Table”.

Imagem 4 – Criação do novo Loockup Table

 

No novo loockup table iremos informar um nome, o tipo de dados e os valores possíveis, conforme mostra a figura abaixo.

Imagem 5 – Preenchimento do novo loockup table

 

Depois de salvo iremos criar um novo campo. Para isso basta acessarmos a opção “New Field”.

   

Imagem 6 – Criando um novo campo

 

No novo campo iremos informar o nome, uma descrição, para qual tipo de entidade dentro do Project ele cera disponibilizado e qual a fonte de dados que ele consumira (o loockup table criado).

Imagem 7 – Valores para o novo campo

 

Após isso o nosso campo estará disponível para o Project utilizar (não apenas para a integração).

Agora temos condição que realizar o upload do nosso mapa de campos, porém como faremos a inclusão de um novo campo, antes vamos editar o mapa de campos, conforme o exemplo no link abaixo.

Download do exemplo do mapa de campos.

Para não ficar em branco a explicação do que foi feito no mapa de campos, fizemos a inclusão do novo campo do Project mapeando-o com o TFS, conforme podemos ver abaixo.

Imagem 8 – Alteração do mapa de campos.

Pronto agora podemos executar o comando abaixo para realizarmos o upload do mapa de campos (passo 3).

TfsAdmin ProjectServer /UploadFieldMappings /collection:http://localhost:8080/tfs/DefaultCollection /filePath:"C:\TFSMapping.txt" /force

Com o nosso ambiente pronto, agora basta selecionarmos quais os team projects serão sincronizados e um-a-um fazer o mapeamento com seus respectivos cronogramas. Para isso basta executarmos o comando abaixo (passo 4). Nesse exemplo ele está preparado para executar o mapeamento entre o team Project e o projeto citados anteriormente.

TfsAdmin ProjectServer 

/MapPlanToTeamProject

/collection:http://localhost:8080/tfs/DefaultCollection  /enterpriseproject:CronogramaIntegracao

/teamproject:TeamProjectIntegracao

/workitemtypes:"Bug, Task, Requirement"

Agora a m����gica está feita. Vamos valida-la?

Para validarmos basta criarmos um work item no TFS assinalando-o para ser integrado no Project e aguardar a sincronização.

Obs: os work itens apenas serão integrados uma vez que seja explicitamente informada a opção de sincronização. Essa opção não necessariamente deverá ser assinada na criação do work item, por isso no início do artigo deixei algumas questões a serem investigadas, para que seja definido um fluxo básico de informações justamente para decidir quando será necessário que o work item vire uma linha de cronograma.

Da mesma forma o caminho contrário é valido, basta criarmos um item no cronograma do Project, marca-lo para ser sincronizado e aguardar a sincronização.

Abaixo temos um exemplo de uma task criada no TFS e sincronizada no Project.

Imagem 9 – Task criada e sincronizada

Jeá na figura abaixo temos a visualização da mesma task sincronizada no cronograma do projeto.

Imagem 10 – Task vista pelo PWA

Conclusão

Com esse cenário podemos aproveitar o máximo das duas ferramentas, garantindo que não vamos atribuir responsabilidade desnecessárias a uma ou sub-utilizar a outra, o TFS é uma ferramenta de engenharia de software e não compete a ele gerir recursos e cronogramas por exemplo, o Project Server não trabalha com version control, builds, changesets, etc, mas podemos associar os dois e com isso, adotar as melhoras práticas e processos para obter o máximo de performance para os times. E com isso podemos ver também que podemos dentro de um time ágil ter a participação de um time formal de PMO por exemplo, para que possamos atingir objetivos organizacionais sem perder a performance e as vantagens de cada abordagem.

Referências

http://blogs.msdn.com/b/briankel/archive/2013/04/12/team-foundation-server-2012-and-project-server-2013-integration-virtual-machine-and-hands-on-labs-demo-scripts.aspx

https://msdn.microsoft.com/en-us/library/gg455680.aspx

Classificar por: Data da Publicação | Mais Recente | Mais Úteis
Comentários
  • Ed (DareDevil57) edited Revision 1. Comment: corrected spacing.Removed white space at the end of the post.Added in Tag

Página 1 de 1 (1 itens)