Codificar: A melhor forma de aprender sobre o projeto em que estamos trabalhando é usando o código fonte. No final das contas tudo roda em cima do código fonte, o sistema que o cliente vai usar na entrega, o aprendizado do time sobre o projeto é com o código fonte, enfim o código fonte é o maior valor integrável do projeto.

Testar: A melhor forma de saber se seu código fonte esta fazendo o que realmente deve fazer é testando. O teste mostra exatamente se o código está fazendo o que deve realmente fazer.

Ouvir: Na nossa profissão vemos vários colegas (ou nós mesmos) que acham que sabem tudo e só existe uma verdade: Desenvolvedor não sabe nada. Por mais que você acha que conhece a rotina de trabalho do seu cliente, procure ouvir sempre o que ele tem a dizer, o que ele tem a mostrar e aprenda com ele. Outro ponto importante é a parte de teste, como testar se você não sabe o que deve testar?

Logo testes devem ser feitos e acompanhados pelo seu cliente para que eles mostrem exatamente o que deve ser feito e testado.

Projetar: Podemos seguir a sequencia, ouvir, fazer um teste, codificar e executa-lo. Poderíamos ficar neste ciclo por algum tempo, mas sem projetar nada em algum momento ficaria impossível de continuar neste ciclo pois tudo estaria desorganizado. Mas e quando devemos projetar? Veremos nas praticas que projetamos todo o tempo.

Enfim estes são os pilares do trabalho de um time de desenvolvimento. Gosto muito de uma definição do Kent Beck:

“Então você codifica porque se você não codificar não terá nada. Você testa porque se você não testar você não saberá quando você terminou de codificar. Você ouve porque se você não ouvir você não saberá o que codificar ou o que testar. E você projeta para que você possa codificar, testar e ouvir indefinidamente. Isso é tudo. Estas são as atividades que devemos ajudar a estruturar.”

E para que estas atividades tenham o melhor resultado possível usamos as práticas da XP, mas vamos ver cada uma delas detalhadamente nos próximos post´s.

Abraços.

Leandro, tem como gerar um relatório no TFS que eu consiga rastrear todos os Work Items do meu projeto e sua relação?
Resposta: Eu nunca precisei usar e também nunca ninguém pediu, mas posso dar uma olhada para você!

Assim que o GP saiu, meu primeiro pensamento foi em usar a API do TFS, que já descrevi aqui como usar, porém seria um trabalhão!! Então fui fazer uma pesquisa rápida no pai dos burros (Google) e acabei encontrando o plugin para Visual Studio chamado Work Item Visualizer for TFS 2010, foi a solução para o pedido do gerente de projeto!

Este plugin realmente foi muito útil, assim que você digita o número de um WorkItem ele gera o rastreamento do mesmo.

Exemplo

Temos uma User Story Realizar Login, desse WI foi gerado mais 3 Tasks (1 para modelagem, 1 para execução, 1 para teste) e a partir do Teste Case foi gerado vários Bugs. Veja na imagem abaixo como isso funciona!

Também temos a opção de gerar uma Matriz de Rastreabilidade, dessa forma podemos saber se alterar o UC Realizar Login quais serão os impactos que poderão impactar no seu projeto

Sensacional!!!!

Quando fui mostrar isse plugin para o gerente, o bicho pulava de alegria!!! e o pessoal do CMMI chegou a chorar (exagero) hehehehe!!! e pagou pau novamente para o TFS!

Deixe seu comentário, opinião, crítica

Aquele abraço!

São eles:

Feedback Rápido: O feedback é muito importante, mas não podemos ter esse feedback muito tarde, pois assim não saberemos se o que esta sendo feito esta correto. E tendo o feedback a segunda parte é aplica-lo o mais rápido possível, assim teremos sempre um curto espaço de tempo entre o feedback dado pelo cliente e seu retorno ao mesmo. O aprendizado desta forma é muito mais concreto, diria até palpável, do que ter um feedback demorado ou mesmo ter um feedback rápido mas não coloca-lo em pratica.

Simplicidade presumida: Este é um dos princípios que os desenvolvedores tem mais dificuldade em assimilar, pois somos condicionados desde pequenos a planejar para o futuro. Mas na XP temos sempre que pensar no presente, no que estamos desenvolvendo agora, no problema que estamos resolvendo agora. Mesmo sabendo que mais para frente teremos mais itens a adicionar no software que esta sendo construído quem garante que realmente usaremos estes itens, que eles realmente serão necessários? Vamos manter a solução o mais simples possível para resolver simplesmente aquele problema, e vamos confiar em nossos conhecimentos técnicos para que quando outras alterações apareçam as façamos da melhor forma possível.

Mudanças incrementais: Mudanças grandes devem ser feitas em pequenos passos. Quanto menor o passo mais fácil de saber para onde ele esta levando. E quanto maior o problema, mais fácil resolve-lo dividindo em partes.

Aceitação de mudanças: Toda mudança no software é bem vinda, pois geralmente ela é um feedback mostrando qual o caminho que o desenvolvimento deve seguir.

Alta qualidade: Este é um dos principais princípios, pois dentro das quatro variáveis de desenvolvimento de projetos (escopo, custo, tempo, qualidade) ela é a única que não deveria ser uma variável, pois quando se trabalha sem qualidade não se tem orgulho do trabalho feito. Qualidade no seu trabalho leva a orgulho do produto final. Os únicos valores que a qualidade deve aceitar são “excelente” e “insanamente excelente”.

Estes são os princípios fundamentais, vamos falar sobre os princípios menos fundamentais:

Ensinar Aprendendo: Em vez de colocar uma cartilha com “Faça XYZ depois de WKX” ou “Faça 30 testes unitários” vamos mostrar como chegamos a nossos padrões, vamos ensinar como analisar o que deve ser feito, como saber se a quantidade de testes esta boa.

Investimento inicial pequeno: Este é um item controverso. Devemos tentar enxugar o máximo possível para começar a desenvolver, mas esse máximo pode ser um para mim e outro para você, então estes pontos tem que ser debatidos por clientes e desenvolvedores, para se chegar a um bom consenso.

Jogar para ganhar: Apesar de parecer um item relevante, ele mostra a sua importância em ver a diferença entre jogar para ganhar e jogar para não perder. A maioria dos times de desenvolvimento cerca-se de documentos para que no fim se der alguma coisa errada eles estejam “protegidos” pela documentação. Temos que ter consciência que estamos todos no mesmo time e jogamos todos do mesmo lado, então vamos dar o melhor de nós e fazer tudo da melhor forma possível.

Experimentação concreta: Cada vez se desenvolve alguma coisa no projeto e não se testa a probabilidade de que esteja errado é grande. E isso acontece também com requisitos. Todas as ações do projeto deveriam ser testadas, claro que usando sempre o bom senso.

Comunicação honesta e franca: Toda a equipe deve ter em mente que a comunicação é um dos itens mais importantes do projeto e no mesmo devemos ter liberdade para comunicar tudo o que esta ocorrendo de bom e ruim a todos sem ter medo de represarias, ironias ou preconceitos.

Trabalhar a favor dos instintos do pessoal e não contra ele: Pessoas gostam de ganhar, de trabalhar em um projeto que tenha qualidade, que seu trabalho seja reconhecido e a melhor forma de conseguir isso é deixando a equipe se auto gerenciar, sabendo que cada um vai fazer o que escolher, vai dar o seu melhor.

Aceitação de responsabilidade: A imposição de qualquer trabalho com o tempo vai tirando o animo das pessoas. Para resolver isso a pessoa deve aceitar a responsabilidade e não ser imposta. Com isso o time vai se auto gerenciando e todos estão sempre fazendo o que gostam e o que não gostam, mas sempre por escolha e não imposição. Isso não quer dizer que você sempre fará o que quiser, mas se existem varias tarefas para serem feitas alguém escolherá ela, seja às vezes você ou outro membro do time.

Adaptação Local: Não existe uma bala de prata para seus problemas. A XP vai te mostrar muitos caminhos e você deve experimentar todos e depois disso você vai começar a modificar e adaptar, mas sempre tendo em vista os valores da XP.

Viajar com pouca bagagem: Os membros de um time devem sempre ter em sua consciência que tudo pode mudar, a única coisa que temos de certeza em um projeto é o teste e o código. E quando o teste ou o código não atende mais eles também devem ser descartados sem peso na consciência. Mantenha sempre o necessário.

Métricas genuínas: Na XP adotamos métricas que podemos manter. Por exemplo, é muito mais pratico dizer “Este item cabe dentro de uma iteração de 2 semanas” do que dizer “Este item vai demorar 14.567 horas para ser feito”. Vamos manter métricas que podemos confiar.

No próximo artigo vamos falar das práticas da XP.

Abraços.

Esse artigo tem a finalidade de descrever como configurar o plugin Microsoft Visual Studio Team Explorer Everywhere no Eclipse e conectar no TFS 2010

Baixar o Plugin

Primeiro de tudo temos que baixar o plugin para o Eclipse que será responsável por conectar no TFS 2010 Microsoft Visual Studio Team Explorer Everywhere 2010

Instalando o Plugin

Agora vamos instalar o plugin, abra seu Eclipse entre na opção Help -> New Software

Clique na opção Add para adicionar o local onde o arquivo foi salvo

Adicione um nome TFS2010 e o local onde se encontra o arquivo ZIP

Veja que é listado o plugin, selecione e clique em next

Será exibido os detalhes da instalação, clique em next

Na próxima tela será exibida o termo de licença, clique em aceitar e depois em finish

Processo de instalação

Após a instalação será necessário reiniciar o Eclipse

Conectando no TFS 2010

Depois de reiniciado o Eclipse, temos que exibir a view do TFS, para isso clique em Window -> Show View -> Other

Selecione a opção Team Foundation Server -> Team Explorer e clique em OK

Agora temos que abrir o projeto que está no servidor do TFS, na view Team Explorer clique em Add Existing Team Project

A primeira vez será exibido o termo de licença, clique em accept

Na próxima tela temos que adicionar a chave do produto, ou usar a versão trial

Agora sim, que vamos configurar a conexão com o TFS

1. Server: Endereço do servidor TFS (não esqueça de colocar o /tfs no final)
2. Selecione o tipo da autenticação
3. Usuário
4. Domínio
5. Senha

Na próxima tela vamos selecionar a collection e o projeto que queremos conectar, e clique em Next

Depois vamos configurar o workspace que é a pasta local onde o projeto estará, e clique em OK

Você receberá uma mensagem perguntando se deseja baixar a última versão do projeto

Sincronizando o projeto com o workspace

Depois de conectado podemos ver toda a estrutua do TFS na view Team Explorer, veja que igual ao Visual Studio

Toda as opções que temos no VS também temos nesse plugin do Eclipse, podemos fazer Check-in/Check-out, fazer querys, acompanhar Work Items, etc.. veja abaixo alguma imagens

Check-in de arquivos pendentes

Opções do TFS para cada projeto

Listagem dos Work Itens

Detalhes do Work Item

Conclusão

Dessa forma podemos utilizar o TFS em projetos que utilizam outras linguagem como Java, PHP, C++, etc…

Qualquer dúvida, opinião, reclamação mande seu comentário!

Aquele Abraço!

A adaptação e o uso correto das disciplinas contidas nesta biblioteca garantem mais qualidade, confiabilidade e segurança a todos os processos relacionados, o que resulta em um ambiente muito
mais estável e uma equipe muito mais proativa. Esta metodologia surgiu no final da década de 1980 pela Agencia central de comunicações e telecomunicações, ou CCTA, ligada ao governo britânico, inicialmente com o intuito de comparar diversas propostas de diversos proponentes e prestadores de serviços de TI, isso devido ao grande número de operações de Outsourcing que estava ocorrendo no pais, por diversas áreas governamentais, o que resultava em uma grande ocorrência de subcontratações e, em conseqüência, perda de padronizações necessárias para garantir a fluidez dos processos de negócio. Ou seja, uma metodologia de trabalho seria necessária para botar esta bagunça em seu devido lugar. Mas o que faz do ITIL hoje, mais de vinte anos após sua criação e adoção
em diversos países do mundo, inclusive no Brasil, ser ainda uma metodologia altamente procurada por empresas que querem ter o seu gerenciamento de TI sob controle e com qualidade? Trata-se de uma peculiaridade que esta metodologia tem, que outras até podem ter, mas que, as vezes não demonstram: A sua versatilidade e adaptabilidade ao negócio da organização, ou seja, o ITIL não é
uma metodologia fechada, que temos que seguir exatamente “by the book”, ela é sim uma metodologia que, desde que sigamos seus princípios básicos e não a façamos perder sua identidade, ela pode ser perfeitamente adaptada ao seu ambiente de negócios e funcionar com perfeição. Em resumo, se alguém, chegar em sua empresa dizendo que quer “Implementar o ITIL” Fuja desta pessoa!!! O ITIL
não se implementa, se “Adota”, se “adapta”.

Obviamente, durante os anos, o ITIL sofreu uma serie de aperfeiçoamentos, visando justamente andar em paralelo ao desenvolvimento do gerenciamento de TI das organizações, que resultavam em novos barreiras e desafio para seus gestores, fazendo com que sua estrutura se alterasse e se adaptasse a esta nova realidade. Inicialmente, a sua biblioteca dispunha de quarenta livros e, anos
depois, fora feita uma grande reformulação, entre os anos de 2000 e 2002, surgindo assim a versão 2.0 do ITIL, onde os volumes foram baixados para oito.
Entre os anos de 2004 e 2006  fora feita uma outra reformulação, desta vez abrangendo seu escopo, tanto para o lado de TI como para o lado do negócio, dando então o surgimento da versão atual, ITL
3.0.

Obviamente, em apenas um post, não poderíamos aqui falar de toda a metodologia, então, resolvi dissertar um pouco sobre três disciplinas que, ao meu ver, são o cerne de toda a metodologia e onde também poderemos ver mais claramente as integrações com a metodologia ALM. São elas, Gestão de Incidentes, Gestão de problemas e Gestão de Mudanças.

Gestão de Incidentes

Para falarmos sobre esta disciplina, primeiro precisamos entender o que, especificamente, trata-se de um incidente:

Um incidente, falando a linguagem de um ambiente de produção d e TI, nada mais é que um evento não planejado que causa, ou leva a iminência de uma parada nos serviços, e que deve, de qualquer
forma, ser tratado e resolvido no menor tempo possível. E é ai que a gestão de incidentes entra, justamente para gerenciar este evento e, junto aos seus respectivos responsáveis, procurar o restabelecimento da produção, ou mesmo retirar o perigo da iminência de sua parada. A gestão de incidentes é, portanto, a linha de frente para defender o ambiente de produção, e suas principais atividades são:

• Classificação do Incidente e suporte Inicial;
• Investigação e diagnostico do incidente, junto aos responsáveis;
• Fechamento dos incidentes;
• Comunicação sobre os incidentes.

Entre os benefícios que podemos ter com o perfeito funcionamento desta disciplina, podemos ressaltar os seguintes:

• Redução significativa do impacto nos incidentes no negócio a organização, diretamente ligado ao incremento efetivo da identificação pró-ativa, bem como melhoras do processo;
• Correto mensuramento e, por conseguinte, cumprimento do SLA, permitindo um gerenciamento de TI mais focado no negócio;
• Eliminação / mitigação de perdas com uma identificação mais correta do incidente;
• Melhoria da satisfação do usuário.

 Bem como também podemos levantar aqui alguns problemas resultantes da não existência ou mesmo da não importância dada pela organização para com ela:

• O  impacto dos incidentes no ambiente pode se tornar mais severo do que o necessário, caso não haja um atendimento especializado;
• Solucionadores e especialistas podem ser acionados sem a real necessidade, o que resulta na diminuição da eficiência deste time;
• Usuários dispersos e sem informações a respeito do que esta ocorrendo;
• Recorrências requentes de incidentes cuja causa é amplamente conhecida;

Em resumo do que fora falado acima, podemos então classificar as responsabilidades de uma Gestão de Incidentes
da seguinte forma:

• Monitorar, direcionar e tratar incidentes relacionados ao ambiente de produção, no que diz respeito a sistemas e seus agregados (Páginas, componentes, dados, objetos de banco de dados), ou outros itens que possam impedir o funcionamento destas, resolvendo a seu nível, quando possível, bem como elevando o caso aos outros níveis, para tratamento da solução;
• Resolver, quando possível, ou fomentar, junto as áreas solucionadoras, os incidentes no ambiente produtivo, imediatamente ao conhecimento da ocorrência, resolvendo-a imediatamente, em caráter definitivo ou provisório, o mais rápido possível, com o intuito de restaurar a produção, elevando o mesmo a problema, quando necessário, e seguindo os critérios pré-estabelecidos para este processo.

 Agora, quando esta disciplina não consegue resolver, em seu nível o incidente, de forma definitiva, fazendo somente um paliativo para que a operação não pare de vez, entra em ação uma outra disciplina, que é a Gestão de Problemas, bem como sua co-irmã, que também atua diretamente com incidentes em determinados casos, a Gestão de Mudanças. Elas serão os assuntos do próximo post! Até lá!

O que é uma Branch?

Branch é uma forma de organizar seu código fonte para que possamos trabalhar em versões diferentes sem afetar um ao outro, em outras palavras, uma branch nada mais é do que uma cópia do seu projeto.

Existem várias abordagens para gerenciamento de branchs, a que estou usando atualmente é a apresentada na figura abaixo:

A branch Base é onde nosso sistema vai ter a versão que está estabilizada e que está em produção, a partir da Base criamos os nossos pacotes onde os desenvolvedores vão codificar novas funcionalidades, quando esses pacotes estiverem homologados pelo cliente realizamos o merge com a nossa Base e geramos um novo build para produção.

Como criar uma Branch?

Quando estamos usando o TFS 2010 é muito fácil criar uma branch, para isso entre no source control do seu projeto clique com o botão direito do mouse sobre a pasta Base, onde se encontra o nosso código fonte, e selecione a opção Branching and Merging -> Branch, conforme a figura abaixo

Agora vamos criar a nossa Branch baseado na última versão, adicione o nome de Pacote1 e na opção Branch from version selecione a opção Lasted Version

Status da criação da nossa nova Branch

Faça o mesmo processo para criar a branch Pacote2, depois de criado, em nosso sorce control deve estar conforme a figura abaixo

Exemplo

Abaixo vou fazer um pequeno exemplo adicionando arquivos no Pacote1 e no Pacote2 e depois realizar o merge desses pacote com a Base, veja a figura abaixo para comparar o conteúdo de cada Branch

Realizando o Merge com a Base

Agora vamos realizar o merge dos pacotes com a Branch Base, para isso clique como botão direito sobre a branch Pacote1 e selecione a opção Branching and Marging -> Merge conforme a imagem abaixo

Será aberto um wizard para realizar o merge, onde vamos configurar o Source (DE) e o Target (PARA) e clique em Next, veja a imagem abaixo

Agora selecionamos que queremos fazer o merge da última versão, e clique em Next

E para finalizar, clique em Finish

Depois de finalizado podemos observar que a nossa Branch encontra-se em processo de merge, veja a figura abaixo

O que temos que ver é se o merge gerou algum conflito, o que geralmente acontece, para isso na janela Pending Changes clique no último ícone para ver os conflitos

A melhor maneira de resolver os conflitos é manualmente usando a ferramenta de merge do próprio Visual Studio, para isso clique no arquivo que gerou conflito e clique em Merge Change In Merge Tool

Será aberta uma ferramenta onde podemos comparar e fazer o merge manualmente, do lado esquerdo é o arquivo que está no Pacote1, do lado direito o arquivo da Base e abaixo com o arquivo vai ficar como merge.

Veja que nesse primeiro conflito aconteceu porque na branch Pacote1 temos o aquivo Pacote1Controller.cs e na branch Base não temos esse arquivo, por isso temos que adicionar essa linha (em azul) para a branch Base, basta clicar em cima da linha para que ela seja adicionada na branch Base, veja na imagem abaixo

Depois clique em Next Change para verificar se possui novos conflitos, e veja que temos mais um conflito referente ao arquivo Pacote1/Index.cshtml, temos que seguir a mesma lógica, clicar na linha azul para resolver o conflito

Clique em Next Change até que todos os conflitos sejam resolvidos e depois clique e OK, uma mensagem de confirmação será exibida para salvar o arquivo

Veja que agora temos apenas um arquivo com conflito, clique em Merge Change In Merge Tool novamente para resolver os conflitos

Será aberta a mesma janela para resolver o conflito, nesse caso é o link do menu que temos que adicionar em nossa branch Base,

Resolva todos os conflitos e depois clique em OK, depois de todos os arquivos que tinham conflitos serem resolvidos a janela ficará vazia

Agora é só compilar o projeto e dar um Check-In

Faça esses mesmos passos para realizar o merge com a branch do Pacote2, no final a nossa branch Base deverá conforme a imagem abaixo

Conclusão

O processo de branch é muito simples e fácil, o que temos que tomar muito cuidado é na hora do merge, geralmente quando falamos de merge a primeira palavra que vem em nossa mente “isso vai dar merda!” e eu concordo com esse pensamento, se não perdermos tempo e atenção para gerenciar esse merge com certeza vai dar merda, essa é a etapa onde temos que ter um responsável pela essa atividade

Outra sugestão é usar ferramentas de merge para auxiliar esse procedimento, deixo uma dica de uma ferramenta muito boa chamada Araxis que se integra com o Visual Studio e com o TFS

Para mais informações sobre Branch, o time de ALM da Microsoft criou um guia para estudos que pode ser baixado aqui

Aquele abraço!

Ah! que fique bem claro de uma vez por todas que cronograma é diferente de projeto!

Neste artigo abordarei duas opções da caixa de diálogo “Informações do Projeto” que impactam a forma como o Project vai trabalhar: “Data de início” e  “Agendar a partir de”.

Vou utilizar o Microfot Project Professional 2010  para ilustrar os conceitos.

Imagine que o seu projeto vai começar daqui a um mês. Então você precisa informar ao Project a data de início do projeto antes de começar a inserir as tarefas. Para isso acesse a aba “Projeto”, depois escolha a opção “Informações do Projeto”.

Na opção “Data de início”, escolha a data ou digite no formato dia/mês/ano (com dois dígitos cada). Fazendo assim a primeira tarefa do seu cronograma vai começar na data que você definiu para o começo do seu projeto.

À medida que você for inserindo as tarefas, definindo as durações e sequenciando as atividades o Project vai calculando as datas de início e de término de cada tarefa automaticamente. Essa é a boa prática, pois o cronograma fica sem restrições de datas, possibilitando uma maior flexibilidade e melhor visualização do gráfico de Gantt para o planejador e para a equipe do projeto.

A segunda opção a ser considerada é o agendamento, pois ela causa maior impacto no seu cronograma e na forma de planejar. Você deverá dizer ao Project como pretende agendar o seu cronograma: se a partir da data de início ou se a partir da data de término do projeto.

Agendar a partir da data de início é a maneira mais comum e mais utilizada no mundo. Para isso acesse o menu “Projeto”, depois escolha a opção “Informações sobre o projeto”. Chegando lá escolha a opção “Agendar a partir de” e selecione “Data de início do projeto”.

Porém se você tiver uma restrição de data término para o seu projeto, no agendamento do cronograma você deverá escolher a opção “Data de término do projeto”.

Este tipo de agendamento é muito comum em projetos de construção civil ou em projetos onde a data de término é a principal restrição, caso contrário o produto ou serviço gerado pelo projeto não poderá prosseguir ou entrar em produção. Por exemplo, a reforma ou a construção de um estádio para uma Copa do Mundo de Futebol. Se o estádio não estiver pronto numa determinada data, por exemplo, dois meses antes da Abertura da Copa do Mundo, não será possível a realização de jogos neste estádio.
Ainda sobre o agendamento a partir da data de término do projeto vale a pena comentar que dependendo das durações e do sequenciamento das atividades ajustadas no cronograma, o Project avisará que tal operação vai alterar a data de término previamente configurada por você, aumentando o nível de manutenção e intervenções manuais no cronograma pelo planejador e equipe do projeto.
Como dica, nas fases iniciais do planejamento, mesmo que o seu projeto tenha uma data de restrição de término, comece o seu cronograma ajustando o agendamento a partir da data de início e verifique se o término do projeto coincide ou se aproxima com da sua data de restrição.

Para verificar a data de término do projeto antes e durante a elaboração do cronograma, escolha o menu “Arquivo”, selecione “Opções” e na guia/aba “Avançado” escolha em “Opções de exibição deste projeto” clique/ative “Mostrar tarefa de resumo do projeto”.

Definir a data de início do projeto e a forma de agendamento para o seu cronograma são ações essenciais para uma boa elaboração do seu cronograma e devem ser realizadas logo no início do seu planejamento.

Por Marconi Fábio Vieira
PMP, MVP em Project

Quando se fala em ALM, obviamente nos vem à cabeça, logo de cara, uma só coisa: Ciclo de desenvolvimento de aplicações e seu gerenciamento como um projeto, com base na analise de requisitos, controle constante de cada passo deste projeto, conseguindo maior previsibilidade, rastreamento, segurança e, por conseqüência destes de mais alguns fatores, a tão desejada qualidade, que tende a seguir o caminho da excelência no gerenciamento. Este conceito vale muito bem para qualquer tipo de projeto de desenvolvimento de software, que use metodologias como o SCRUM, ou se apóie em conceitos de CMMI, como em fabricas de software, e até os que utilizariam metodologias mais parrudas, como o PMI.

Porém, no meu caso, que sou, talvez, o ”peixe mais fora d’água” desta comunidade, já que sou uma pessoa de operações e de infra-estrutura e não sou um desenvolvedor, essa visão do que é ALM e o que ele pode oferecer tomou um rumo um tanto diferente, mas nada estranho, pois, a cada dia que eu aprendo mais sobre esta metodologia, mais eu percebo que ela é maleável e adaptativa, e podemos sim aplicá-la, e a seus conceitos, em outras aeras que não a de desenvolvimento de software apenas. Portanto, resolvi aqui escrever um pouco sobre estas minhas idéias, que acredito eu, sim, já devem ter sido pensadas por outros profissionais que tem o mesmo perfil que o meu, ou mesmo até por desenvolvedores que também possuem conhecimento de gerenciamento tático / operacional de serviços e processos de TI, resultado do constante processo de equalização de conhecimentos que a área de TI, às vezes, devido a sua também constante mutabilidade, quer seja por necessidade, ou mesmo por tendências naturais de mercado, nos oferece.
A diferença talvez seja que eu quero aqui compartilhar estas idéias com todos da comunidade.

Dado este panorama, farei estas explanações em uma serie de posts, para uma melhor assimilação, bem como, para ser bem sincero, por pura falta de tempo deste que vos escreve. Para isso, nesta primeira parte, darei uma breve introdução sobre gerenciamento de serviços de TI e, em seguida, na segunda parte, falarei um pouco da metodologia que usaremos para evidenciar este controle, a ITIL, para, ai sim, fazer uma abordagem em como o ALM pode ajudar a implementar tal visão.

Um pouco sobre Gerenciamento de Serviços de TI

Em primeiro lugar, vamos tentar conceitualizar um pouco o que vem a ser o gerenciamento de processos de TI. Ele se baseia, em sua totalidade, em processos que, por sua vez, são atividades que sempre são inter-relacionadas, em com o intuito de atingir a um objetivo comum, um resultado desejado, que fora previsto e planejado. Dependendo de alguns fatores, tais como o tipo e organização, seu nicho de mercado ou mesmo a criticidade de seu negócio, podem fazer com que estes processos sejam mais simples ou então extremamente complexos, fazendo com que, para cada um destes processos, exista um método de gerenciamento dos mesmos e, para certos casos, até um gerente designado para este fim. Algo que sempre temos que ter em mente é que um processo nunca deve ser visto de forma isolada dos demais. Lembre-se! Os processos são Inter-relacionados, isto é, dependem um dos outros e esta dependência sempre afeta o resultado final. E é exatamente ai, que o gerenciamento de serviços de TI entra, para promover a convivência correta entre eles, coordenando cada um deles, mas sempre visando o uníssono, sempre vendo como uma coisa só.

Existem alguns objetivos básicos de um processo de gerenciamento de TI. Entre eles podemos destacar os seguintes:

• Aumento exponencial, significativo e constante da qualidade dos serviços
• A previsibilidade do comportamento destes serviços deve também aumentar
• O custo alocado deve diminuir

Basicamente, os processos que suportam a estes serviços, são classificados em três novéis diferentes, e co-relacionados. São eles:

Nível Estratégico:

Nível onde existe o perfeito entendimento de qual é a missão a ser seguida pela organização, e onde é feito o alinhamento da área de TI com as necessidades do negócio, para então se traçar o plano de ação.

OBS:

Aqui vale uma ressalva importante para todos nós profissionais de TI: O Foco é, e sempre será, no negócio! A área de TI não existe por si só, não importa qual seja a organização, ela é sempre um meio para um fim, ou seja, um meio para se manter ou melhorar o que chamados de “Core Business” ou o negócio que a empresa trata. A área de TI será sempre uma ferramenta para auxiliar este negócio, fazendo-o mais ágil e lucrativo, por conseguinte.

Nível Tático:

Neste nível, existe a missão de fazer cumprir o que fora acordado em nível estratégico, ou seja, relacionar-se com o cliente, estabelecendo e fazendo-se cumprir todos os acordos, bem como monitorando o desempenho e a evolução dos mesmos por todo o seu ciclo, quer seja ele finito (um projeto fechado) ou indeterminado (uma operação de suporte), e, através de analises diversas, prever problemas ou novas necessidades, bem como corrigir erros de percurso.

Nível Operacional:

Literalmente, é quem põem a mão na massa, sendo orientado e corrigido, quando necessário, pelo nível estratégico, é quem faz acontecer o que fora previamente definido. Ou seja, é neste nível que acontece a manutenção destes serviços diversos.
Obviamente, como geralmente acontece em empresas, principalmente de médio e grande porte, existem muitos processos e serviços que são sim funcionais, mesmo sem a existência de um processo mais detalhado de gerenciamento de TI. Geralmente estes processos são passados por uma verificação, um estudo e, geralmente, parte deles, ou mesmo todos eles são reaproveitados pelo novo modelo, apenas sofrendo pequenas alterações de modo a se encaixarem melhor na nova visão. E é ai que entra a metodologia chamada Information Technology Infrastructure Library (Biblioteca de Tecnologia da Informação e Infra-estrutura) ou ITIL.

Mas este é assunto para o próximo Post… Até lá!

1) Configurando TFS Build

Se em seu projeto você tentar configurar um novo build e receber a mensagem abaixo, é porque o Build do TFS não está configurado no servidor.

A configuração do TFS Build segue o padrão Next, Next, Next, Finish, para configurar o build entre no Team Foundation Server Administration Console e selecione a opção Build Configuration -> Configure Installed Features.

Nessa tela tem uma descrição da configuração, Clique em Start Wizard.

Nessa tela é apenas de início, clique em Next.

Agora é apresentado a sua collection onde será configurado o Build, selecione a collection e clique em Next.

Vamos criar a quantidade de agentes, o padrão é 1, clique em Next.

Selecione a conta que vai executar o serviço de Build, e em qual porta ela vai ser executada, lembre que essa porta tem que estar liberada em seu Firewall, clique em Next.

Para confirmar as configurações, clique em Next.

O TFS vai verificar as configurações, clique em Configure.

Processo de instalação.

Mensagem de sucesso.

Veja que agora na opção Build Configuration aparace nosso Controller e nosso Agente.

2) Criando um novo Build

Agora vamos configurar o nosso projeto para usar o Build do TFS, abra seu projeto no TFS e clique com o botão direito sobre a opção Builds e selecione a opção New Build Definition.

Será aberta uma nova aba no Visual Studio para configurar o nosso Build, clique em General e adicione um nome e uma descrição.

Agora clique em Triger e vamos selecionar como nosso build será acionado.

Temos algumas opções para acionar nosso Build.

• Manual – Será executado manualmente por um usuário acessando o Visual Studio

• Continuous Integration -  Sempre que um Check-in é efetuado o build é executado, nesse caso é fácil descobrir quem quebrou o Build ( Who broke the build?)

• Rolling Builds -  É parecido com o Continuous Integration, porém ele reúne vários Check-ins  e executa o build, também podemos configurar para ser executado em um determinado intervalo

• Gated Check-In – Também é parecido com o Continuous Integration, porém quando o desenvolvedor realizar um Check-in uma janela irá aparecer conforme abaixo

Quando o desenvolvedor clicar em Build Changes o TFS cria uma Shelveset com os arquivos alterados o TFS Build faz um merge do código fonte, realiza o Build e se tudo ocorrer bem realizar o Check-in para o source control.

• Schedule – Podemos agendar para quando queremos o nosso build, todos os dias, todas quartas-feiras, em uma determinada hora, etc…

Agora clique em Workspace, onde vamos configurar qual source cntrol a ser executado o Build.

Agora clique em Build Defaults e configure o diretório para onde deve ser copiado o Build, deve ser um diretório compartilhado na rede.

Agora clique em Process e selecione os itens que vamos adicionar no build, que deve ser a nossa solution (.sln)

Clique em Add e selecione a solution do seu projeto.

Agora é só salvar o build.

3) Executando o Build

Como configuramos nosso build para ser iniciado Manualmente vamos executar nosso Build, clique no buil que acabamos de criar e selecione a opção Queue New Build

Na janela que abriu podemos configurar mais algumas opções, clique em Queue

Uma nova janela irá se abrir no Visual Studio como status do nosso build

Quando o build for concluído o status deve ficar conforme a imagem abaixo.

Para verificar os arquivos gerados temos que acessar a pasta compartilhada que configuramos anteriormente (\\tfs-2010\build) e acessar a pasta _PublishedWebsites

4) Erros Conhecidos

Alguns erros que ocorreram comigo durante a criação desse POST

Erro 1: MSB4019

Resolução

Copiar a pasta C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications da sua máquina local para o servidor de build

Erro 2: MSB3245

Resolução

Como meu projeto era é em ASP NET MVC 3 tive que instalar no servidor de Build

5) Boas Práticas

A Microsoft recomenda que o Build Service seja instalado em uma máquina separada da camada de aplicação do TFS, para melhor performance e também o servidor de Build deve possuir todos os assymblys referenciado em seu projeto

Qualquer dúvida, problema, sugestão deixe seu comentário!

Aquele Abraço!

Este artigo visa abordar considerações e práticas simples que devem ser observadas antes de elaborar um cronograma e faz parte de uma série de artigos que pretendo escrever sobre o assunto. Sugiro que visite constante este site para as novas publicações.

Introdução

Antes de por a mão na massa, ou seja, de abrir a sua ferramenta preferida de elaboração de cronogramas você deve, no mínimo, ter acesso aos seguintes documentos:

• Termo de Abertura do Projeto
• Documentos de Requisitos
• Declaração de Escopo do Projeto
• EAP do Projeto
• Listas e atributos das atividades
• Requisitos e calendários dos recursos
• Estimativas de durações das atividades

Estes documentos costumam ficar armazenados num diretório da sua rede, com as devidas permissões de acesso, ou em um site do projeto, facilmente implementado numa solução como o SharePoint Server integrado com o Project Server e o Project Web Access.

Termo de Abertura do Projeto

O Termo de Abertura do Projeto fornece a descrição em alto nível do projeto e das características do produto, e também contém os requisitos de aprovação do projeto.

Essas informações fornecem ao planejador uma visão geral do que o projeto se propõem a implementar e o cenário que levou a realização do projeto. Sem elas é impossível começar!

Documentos de Requisitos

Os Documentos de Requisitos descrevem como os requisitos individuais atendem às necessidades do negócio para o projeto. Alguns componentes desta comunicação são: a necessidade e os objetivos do negócio, os requisitos funcionais e não funcionais, requisitos de qualidade, critérios de aceitação, regras de negócio, impacto em outras áreas organizacionais, requisitos de treinamentos e suporte e premissas e restrições de requisitos.

Chamo atenção neste ponto para os requisitos de treinamentos, pois já foram definidos e documentados nos Documentos de Requisitos. Dependendo do porte do projeto, os treinamentos poderão possuir níveis (básico, intermediário ou avançado) e serem realizados em fases diferentes no decorrer do projeto, bem como personalizados para públicos diferentes como executivos, gerentes de projetos e equipe, operadores, etc. Então você deve considerar a inserção de tarefas no seu cronograma para contemplar estes treinamentos. Verifique quais tarefas precisam estar concluídas para que os treinamentos sejam iniciados.

Verifique os níveis de treinamentos e se possuem restrições de sequencia, ou seja, um treinamento de nível avançado só pode ser iniciado se um treinamento de nível intermediário ou básico tiver sido concluído. Isso você consegue ajustar facilmente através das ligações entre as tarefas, como por exemplo: TI (Término-a-Início), II (Início-a-Início), TT (Término-a-Término) e IT (Início-a-Término).

Outro aspecto muito importante a ser considerado pelo planejador é o envolvimento do setor de RH da empresa, pois é o responsável pelas políticas de treinamentos e deverá ser sempre envolvido para o agendamento e negociação de liberação de recursos humanos com os outros setores da empresa. Pessoas ou funções de RH deverão ser comunicados e incluídos na planilha de recursos do cronograma e alocados nas respectivas tarefas.

Declaração de Escopo

A Declaração de Escopo fornece uma descrição detalhada do projeto e do produto. É crítica para o sucesso do projeto e baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação do projeto.

Neste ponto quero chamar a sua atenção paras as restrições do cronograma. Alguns projetos contem restrições fortes como, por exemplo, devem terminar numa determinada data, caso contrário não será possível a utilização do produto ou do serviço do projeto. Por exemplo, a reforma ou construção de um estádio de futebol para utilização na Copa do Mundo. Se aquele estádio não ficar pronto na data programada (ou data de restrição) não será possível realizar os jogos no mesmo.

Existem basicamente dois tipos de restrições: de cronograma, conforme supracitada e de tarefa. Você terá uma flexibilidade maior no planejamento quando trabalhar com as restrições nas tarefas, pois são facilmente ajustadas através das ligações.

A restrição de cronograma “engessa” mais o planejador, pois, dependendo da “mexida” que ele fizer nas atividades no decorrer do projeto, principalmente nas colunas de durações e predecessoras, a ferramenta de elaboração de cronograma começará a apresentar mensagens, alertando-o que aquele movimento afetará a data de término do projeto, previamente definida no método de agendamento do projeto (se a partir do início ou do término do projeto).

Conhecer antecipadamente as restrições do projeto através da Declaração de Escopo o ajudará na elaboração do cronograma desde o início.

EAP (Estrutura Analítica do Projeto)

Procure ter acesso à EAP do Projeto, pois nela estão registradas as entregas de forma visual e dentro das respectivas fases. Aliás, a EAP do Projeto é uma das entradas principais para você começar a elaborar os eu cronograma.

As entregas serão inseridas como marcos no seu cronograma. Normalmente dependem de uma sequencia de tarefas a serem concluídas. As entregas possuem duração zero e devem refletir exatamente as informações da EAP do Projeto, porém agora com numa visão temporal. A maioria das ferramentas de elaboração de cronogramas possuem filtros e relatórios específicos para visualização as entregas no tempo, integradas inclusive com o gráfico de Gantt.

Listas e Atributos das Atividades

É uma lista abrangente que inclui todas as atividades necessárias para o projeto. Inclui um identificador e uma descrição do escopo do trabalho de cada atividade em detalhes suficientes para assegurar que os membros da equipe entendam qual trabalho precisa ser executado.

Os atributos das tarefas ampliam a descrição das atividades através da identificação dos múltiplos componentes associados a cada atividade. Ex: ID (identificador), o ID da EAP, atividades predecessoras e sucessoras, relações lógicas, antecipações e esperas, requisitos de recursos, datas impostas, restrições e premissas.

As listas e os atributos das atividades podem ser obtidos de projetos anteriores ou através de especialistas experientes no escopo do projeto.

Requisitos de Recursos das atividades e Recursos de calendários

Os requisitos de recursos das atividades identificam os tipos e as quantidades de recursos necessários para cada atividade do pacote de trabalho. Esses requisitos podem então ser agregados para determinar os recursos estimados para cada pacote de trabalho. A quantidade de detalhes e o nível de especificidade das descrições dos requisitos dos recursos podem variar com a sua área de aplicação.

Os calendários especificam quando e quanto tempo os recursos identificados estarão disponíveis durante o projeto. Inclui a consideração de atributos tais como experiência, nível de habilidade do recurso, assim como as várias localizações geográficas de onde vêm esses recursos e quando poderão estar disponíveis.

O planejador deverá obter ou buscar as informações dos calendários dos recursos logo no início do projeto. Com essas informações ele poderá configurar caso a caso na planilha de recursos do cronograma, o que refletirá diretamente nas datas de início e término das atividades.

Estimativas de duração das atividades

São avaliações quantitativas do número provável de períodos de trabalho que serão necessários para completar uma atividade.

O planejador deverá solicitar o apoio de uma ou mais especialistas de cada disciplina para estimar corretamente as durações e inseri-las no cronograma.

Trabalhei num projeto de construção de uma unidade de processo na indústria petroquímica, onde havia uma equipe multidisciplinar, como civil, elétrica, instrumentação, processo, mecânica e tubulação. Por mais que o planejador tenha experiência, ele precisa elaborar o cronograma a partir das informações fornecidas pelos especialistas de têm experiência e condições técnicas de mensurar com mais precisão as durações de tarefas de suas áreas. É um trabalho feito em conjunto!

Não se aventure nas estimativas se tiver à sua disposição uma equipe de especialistas! Eles estão lá para lhe ajudar!

Conclusão

Não é muito aconselhável começar a elaborar um cronograma sem ter acesso à estes importantes documentos e à essas informações! Tem gente que se arrisca!

O problema é o retrabalho e a necessidade de fazer revisões mais profundas nas fases posteriores do projeto, onde a “batata já está assando”, consumindo muito tempo e recursos.

Ler e principalmente estudar essas informações no início do projeto, antes de começar a arregaçar as mangas da sua ferramenta, vai deixar o seu cronograma mais consistente, refletindo exatamente os anseios dos documentos supracitados e da Organização que está executando o projeto, otimizando o seu tempo, energia e recursos durante as fases de execução e controle do projeto.

Próximo Artigo

No próximo artigo vou começar a analisar alguns detalhes básicos que devem constar nos cronogramas, para que estejam de acordo com as melhores práticas de planejamento.

Marconi Fábio Vieira

PMP, MVP em Project
MCP, CUE, CUA, CACP Storage Specialist