Bom vamos às práticas:

Jogo do Planejamento: Tanto a equipe de Desenvolvimento quanto as pessoas da área de negócios precisam manter sua comunicação aberta para discutir aonde e como chegar. O pessoal de negócios deve decidir sobre:

Escopo: Quanto do problema deve ser resolvido para chegar a uma solução que retorne valor para o cliente

Prioridade: Qual dos itens é mais importante para o cliente? O que deve ser desenvolvido primeiro que dará ao cliente uma vantagem competitiva no mercado, ou que diminuirá seu trabalho?

Data de entrega: Sabemos sempre que o cliente quer tudo para ontem, mas do tudo que deve ser feito o que fara a diferença e quando fara a diferença?

Mas a área de negócios não pode tomar toda a decisão sozinha, o time deve ajudar com:

Estimativas: Quanto tempo levará para implementar uma determinada funcionalidade?

Consequências: O time deve sempre orientar o cliente e a área de negócios para as consequências das escolhas deles, como por exemplo, trabalhar com determinada linguagem ou SGDB pode ajudar ou atrapalhar dependendo do tipo do produto a ser desenvolvido.

Processos:: Como o time vai trabalhar, quais métricas vão usar?

Cronograma detalhado: O que será feito em cada história? Qual o item de maior risco do projeto? O time deve opinar junto à área de negócios sobre o que deve ser desenvolvido primeiro, atacando de preferencia os itens críticos logo de cara.

Entregas Frequentes: Cada entrega deve ter o menor tamanho possível que traga o maior valor possível para o negócio. E cada entrega deve fazer sentido, nada de fazer funções que não tenham sentido para mostrar que esta entregando alguma coisa, cada entrega deve sempre ter função definida e valor gerado.

Metáfora: Uma ou mais frases que mostrem qual o caminho do projeto, mostrando claramente o que o projeto faz, qual a sua utilidade. E uma metáfora pode mudar no meio do caminho, quando se descobre alguma coisa nova, ou há uma mudança nos rumos do projeto. A metáfora seria como uma descrição da visão panorâmica do projeto, e como uma visão ela deve nos mostrar o caminho a ser tomado.

Projeto Simples: Os pontos fundamentais para um projeto bem feito, com qualidade e simples são:

Ter e executar testes sem falhar.

Não ter código duplicado.

O código deve expressar o que ele deve fazer para os programadores.

Acrescente o que você precisa quando você realmente precisar.

Todos os pontos acima fazem você ser cuidadoso com seu código, e um grande ponto da simplicidade é: Desenvolva somente o necessário para resolver o problema. Geralmente somos condicionados a pensar no futuro, a tentar adivinhar o que vai ser necessário. Na XP você deve apenas resolver o problema, o futuro é incerto e provavelmente o que você teme não chegará a acontecer. E se acontecer seu sistema será simples o bastante para que ele seja resolvido sem dores de cabeça.

Teste: Seu programa deve ser testado continuamente, pois os testes além de dizerem que aquele trecho esta funcionando trazem segurança para futuras alterações. E quando falamos de teste não estamos só falando de teste de unidade, mas também de teste de funcionalidade que seus clientes devem fazer para terem a segurança que determinada funcionalidade atende o que eles desejam.

Refatoração: A refatoração do código é um dos itens mais importantes, pois o código deve sempre estar da melhor forma possível e nem sempre acertamos um código de primeira. A refatoração deve ser feita por todo o time em todo o código, sempre que você for trabalhar em alguma funcionalidade e ver que pode melhorar alguma coisa faça.

Programação em Par: Uma das práticas mais polemica da XP, a programação em par é a melhor ferramenta para a disseminação de conhecimento e nivelamento dentro de uma equipe. Apesar da XP pregar que todo o código deve ser produzido em par, em minha opinião existem casos em que não há necessidade da programação em par, como por exemplo, a realização de um CRUD (desde que você não tenha nenhum estagiário na sua equipe, senão até no CRUD é bom fazer pareamento com o estagiário para ele ganhar aprendizado e confiança). E aquela história de que eu poderia estar aproveitando dois programadores em funcionalidades diferentes em vez de dois em uma funcionalidade única é real? Na minha experiência e da do Kent Beck não (olha eu me igualando ao Kent rsrsrsr). O que ocorre quando realmente esta se programando em par é que você tem duas pessoas analisando um problema, logo uma esta programando e o parceiro pode ir analisando o código escrito e já ir pensando em testes, vendo se pode melhorar alguma coisa, enfim, os dois estão concentrados em resolver o mesmo problema e o velho ditado que duas cabeças pensam melhor que uma neste caso é a mais pura verdade. Mas ai você lendo este texto vai me falar “Denis, você ali em cima realmente, por quê?”. Eu disse o realmente porque se você não tiver uma equipe realmente comprometida à programação em par não vai funcionar, pois a pessoa que não esta com o teclado e mouse vai estar com o smartphone ou tablet navegando, olhando o twitter, vendo e-mail e nada de ajudar na solução do problema. Uma equipe motivada é tudo em qualquer metodologia, mas no XP é fundamental.

Propriedade Coletiva: Todo mundo é dono do código e ponto. Não deve existir nenhuma funcionalidade em que só exista uma pessoa no time que mexa. Todo mundo pode e deve trabalhar em todo o sistema, sem reservas. Isso da um senso de responsabilidade em todos de manter tudo em ordem.

Integração Continua: Não adianta eu ter iterações de duas semanas se cada programador só vai integrar o código que esta fazendo quando terminar o prazo. A integração deve ser feita sempre no termino de uma tarefa. E nessa integração o par que programou deve acompanhar os resultados dos testes para ver se não quebrou nada. E quanto menor for o código integrado mais fácil é de se fazer a analise caso de alguma coisa errada.

Semana de 40 Horas: O time não é uma maquina que faz trabalho sem parar e o projeto não é um projeto de chão de fabrica aonde as pessoas abaixam a cabeça e cada um faz seu trabalho sem pensar. Programar exige muito e quanto mais cansado estiver seu time menos ele vai render. Uma semana de hora extra pode ser bem aceito, mas duas semanas seguidas quer dizer que existe alguma coisa errada nas suas estimativas ou com seu time e que você deve analisar isso e não continuar forçando o time com uma carga horaria desmotivadora.

Cliente presente: Esta é outra pratica controversa, pois geralmente o cliente não vai ter alguém para disponibilizar a acompanhar a equipe enquanto é feita aquela funcionalidade, mas isso seria o ideal. Ter sempre uma pessoa do cliente para tirar dúvidas ali do seu lado, verificando sempre se esta tudo certo é o melhor dos mundos, mas caso isso não seja possível deve-se entrar em acordo com o cliente para que o time tenha acesso o mais rápido e fácil possível às pessoas da empresa para matar suas dúvidas.

Padrões de Codificação: Se temos o time trabalhando em tudo a todo o tempo devemos ter um padrão a ser seguido para que quando o programador A for alterar alguma coisa que o programador B fez, ele saiba como as coisas devem estar. Se não existe padrão um código pode estar bom para mim e ruim pra você. Com uma padronização saberemos quando o código esta ruim ou bom (na maioria das vezes).

No próximo post vamos falar de como todas essas práticas trabalham juntas apoiando umas as outras.

Abraços.

Abaixo vou descrever os passos necessários para fazer o TFS Build executar o Code Coverage

Configuração do Teste

Primeiramente temos que configurar o nosso projeto de teste para habilitar a opção de Code Coverage, para isso abra o arquivo Local.testsettings

Agora selecione Data and Diagnostics e depois habilitar a opção Code Coverage

Agora clique em Configure

Selecione a DLL que queremos verificar a cobertura de código e clique em OK

Configuração do Build

Agora temos que configurar o nosso Build, no item Process temos um campo TestSettings File

Selecione o arquivo de teste que configuramos anteriormente

Depois de todo esse processo, salvei o Build Configuration e mandei executar novamente, porém não me resolveu o problema ;(

Executei varias tentativas passando parâmetros para o MSBuild porém também sem sucesso

Solução

Encontrei esse post http://social.msdn.microsoft.com/Forums/pl/tfsbuild/thread/a7c8921b-808c-483b-a517-09f8ba35c149

Primeiramente achei meio estranho ter que instalar o VS Premium ou Ultimate no servidor de Build, porém eu instalei e no final deu certo

Conclusão

O grande problema dessa solução é, que estamos usando mais uma licença do Visual Studio e ainda por cima as versões mais caras

Aquele Abraço!

Segue os links para Download :
Team Foundation Server Beta

Visual Studio 11 Team Foundation Server Express Beta

Visual Studio 11 Team Explorer Beta

Visual Studio 11 Team Explorer Beta Language Pack

Visual Studio 11 Team Explorer Everywhere Beta  

Até mais.

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