MSF for Agile 5 e TFS 2010 - Artigo .net Magazine 84

O mundo está cada vez mais ágil, e isto é um fato. Cartões de crédito, transações on-line, delivery dos mais diversos produtos, redes 3G e dispositivos portáteis conectados quase 100% do tempo, cursos a distância, GPS, e diversos outros recursos que nos dão rápido acesso a serviços e informações. Na prática, todos os serviços existentes ajudam as pessoas a serem mais produtivas, a um custo cada vez menor.

Nos projetos de software esta agilidade está cada vez mais em evidência, tornando-se cada vez mais um requisito obrigatório para que se consiga atingir a produtividade necessária para tornar equipes e empresas competitivas e viáveis economicamente.

Cada vez mais, entende-se que desenvolvimento de software não é uma ciência exata, pois a interferência humana é muito influenciadora do sucesso de um projeto. Surgem então os princípios práticos do Manifesto Ágil, aonde paradigmas são expostos como princípios para apoiar a produção de maneira a garantir a viabilidade econômica dos produtos.

Segundo o manifesto Ágil, a produtividade é focalizada através dos princípios:

“Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Bom, então nos perguntamos se deixamos itens adicionais de desenvolvimento de software de lado, como a Arquitetura e Testes por exemplo. Não, os métodos ágeis não vão contra as disciplinas de engenharia, eles apenas tendem a aplicar os princípios de engenharia de uma maneira mais prática e direta. O que muda na verdade é a maneira como se lida com estes itens. Por exemplo, a arquitetura tende a ser evolutiva, desenvolvida baseada em princípios, porém atualizada conforme a necessidade do produto. Os testes por sua vez são feitos antecipadamente, no processo chamado de “early testing”. Conforme o produto fica pronto, a comunicação e o trabalho em equipe passam a serem fatores críticos de sucesso – não que já não fosse em outros tipos de projeto, mas os métodos ágeis realmente os trazem como carro chefe do processo de desenvolvimento – uma abordagem inteligente, uma vez que muitas falhas em projetos começam por falhas de comunicação.

Falando em Processo de Desenvolvimento, as fases dos projetos também continuam ocorrendo, porém, existe a tendência de evitarmos os entregáveis desnecessários, focarmos nos entregáveis úteis e que realmente façam sentido. É muito importante o planejamento da entrega de releases menores, porém mais frequentes baseados em versões “funcionando” deste produto. Neste processo de releases diversos, os clientes são trazidos para avaliar o produto, e obtém-se previsibilidade de que o projeto está ou não caminhando na direção certa, sendo possível agir em tempo hábil de corrigir o rumo do mesmo. É impressionante, pois os métodos ágeis acabam protegendo o ROI (Return On Investment, ou “retorno sobre investimento”), uma vez que o cliente pode ter em seu ambiente, uma versão inicial e funcionando do produto que foi adquirido.

Estes princípios de produtividade, qualidade e de previsibilidade são esclarecidos em diversas outras metodologias que empregam a execução ágil de produção de software, como XP (Extreming Programming), DAS (Desenvolvimento Adaptativo de Software), DSDM (Método de desenvolvimento Dinâmico de Sistemas), Crystal, FDD (Desenvolvimento Guiado por Características), AM (Modelagem Ágil), Scrum e MSF for Agile. O conceito principal de agilidade é o mesmo, pois se baseia no mesmo princípio fundamental do manifesto Ágil.

Neste artigo serão abordados alguns princípios ágeis tomando como referência o MSF for Agile como modelo de processo, e vamos avaliar as funcionalidades do TFS 2010 para suporte a metodologias ágeis. Para o MSF for Agile existe um process template (ou template de processo) que está disponível junto com o TFS 2010 e também há ampla documentação no site do MSDN. O MSF for Agile é baseado no framework Scrum e nas experiências da própria Microsoft, portanto constantemente observamos referências diretas ao Scrum.

O processo de desenvolvimento segundo o MSF for Agile

Durante a edição deste artigo a Microsoft liberou o Visual Studio Scrum 1.0. Isto pode levar à pergunta: Porque a Microsoft iria criar um novo modelo de processo para Agile, se já existe o MSF for Agile? Na verdade, os modelos de processo são um pouco diferentes, pois no Microsoft Scrum 1.0 há alguns recursos que visam suprir necessidades do framework Scrum.

Segundo o MSF for Agile 5.0, o projeto é constituído de fases e atividades, organizadas com o objetivo de agrupar e sequenciar atividades relacionadas, e assim aperfeiçoar cada uma delas. O projeto é então dividido pelos seguintes grupos de atividades, ou fases: