A pergunta-título deste post é bastante recorrente – muitos de nossos clientes já a fizeram – e por isso sabia que mais cedo ou mais tarde deveria parar e escrever um post a respeito. A ideia seria mostrar os principais motivos (ou “justificativas”) para que alguém decida atualizar seu ambiente TFS existente.

Como recebi pelo Twitter a mesma pergunta de novo, ficou claro para mim que era hora de escrever este post.

Se você ainda está usando TFS 2005 ou 2008 a motivação é mais simples e óbvia: A nova versão do produto é *muito* mais rápida, *muito* mais estável e *muito* mais robusta (por exemplo, porque agora suporta Alta Disponibilidade). Isso, por si só já justificaria a atualização.

Já para aqueles que estão no 2010 (que introduziu a nova plataforma mais rápida e estável sobre a qual o 2012 foi construído) a motivação é menos óbvia. Fica fácil se questionar se o custo de uma migração compensaria os eventuais novos recursos. É para aqueles nesta situação que este post se destina.

Alguns dos recursos abaixo foram introduzidos como parte das duas atualizações trimestrais do TFS, conhecidas como “Visual Studio Quarterly Update” (a atualização do TFS é lançada junto com a do Visual Studio). Assim, quando você encontrar uma menção a VS2012.1 ou VS2012.2, estarei me referindo a uma das duas atualizações.

Veja abaixo mais detalhes sobre estes itens:

1. Novo Web Access
2. Gestão Ágil de Projetos
3. Suporte a Equipes (Times)
4. Workspaces Locais
5. Revisão de Código
6. Coleta de Feedback
7. Preemptive Analytics

Novo Web Access

O Team Web Access (interface web do TFS) foi totalmente reescrito na versão 2012. Com isso, problemas conhecidos de escalabilidade (versões anteriores não suportavam muitos usuários simultâneos) e desempenho foram resolvidos. Além disso, o time do TFS aproveitou a oportunidade para “limpar” a interface e torna-la mais eficiente e agradável. Claro que o “agradável” é subjetivo, mais a maioria dos usuários de TFS que conheço preferem a nova versão.

Do ponto de vista técnico, abandonou-se o ASP.NET WebForms em prol do ASP.NET MVC. Além disso, ainda que o novo Team Web Access não seja propriamente uma aplicação do tipo SPA, tira proveito de muitas das técnicas usadas numa SPA. A tendência é que o time do TFS adote cada vez mais o modelo SPA, em especial à medida que mais e mais partes da API do TFS forem expostas como endpoints REST.

Uma outra frente de investimento é na paridade de recursos com as ferramentas de cliente. Ou seja, coisas que só eram possíveis de se fazer através do Visual Studio ou do Test Manager estão sendo trazidas para a interface web:

• Gestão de Builds: agora é possível não apenas gerenciar os builds e consultar seu histórico, mas também podemos agendar builds diretamente na interface web:
  
• Gestão de Testes: agora é possível gerenciar suítes e casos de teste na interface web (VS2012.2), bem como executar testes manuais diretamente a partir do browser (VS2012.2)!
   

Gestão Ágil de Projetos no Web Access (Backlog, Taskboard, Kanban board, Tagging…)

Provavelmente a menina dos olhos da nova versão, agora temos poderosos recursos para a gestão ágil de projetos, tais como:

• Gestão de Backlog do Produto: Agora você pode facilmente cadastrar itens em seu backlog de produto. Mesmo que você não use Scrum, o conceito de backlog é tão simples e útil que acaba atendendo a qualquer processo de desenvolvimento. Priorize e reordene os itens da lista apenas arrastando e soltando. Gráficos de Velocidade e de Fluxo Cumulativo (VS2012.1) ajudam a ter uma visão de alto nível do ritmo do trabalho do time.
  
• Planejamento de Sprints: Em complemento à gestão do seu backlog, é possível também planejar e gerenciar suas sprints. Recursos como o balanceamento de carga e o cadastro de capacidade de trabalho (com detalhes como horas/dia de trabalho e ausências) permitem uma visualização efetiva de suas sprints – uma grande ajuda durante as sprint plannings!
  
• Quadro de Tarefas (Taskboard) da sprint: O taskboard é a ferramenta perfeita para o dia-a-dia do time. Como um substituto eletrônico para os tradicionais “quadros de post-its”, é possível visualizar e mover as tarefas entre seus diversos estados, além de atualizar facilmente o trabalho restante. Com duas visualizações diferentes (por PBI – product backlog item – e por membro do time) você pode consultar, a qualquer momento, qual a situação de uma sprint.
   
• Quadro Kanban (Kanban board) (VS2013.1): O suporte a Kanban no TFS 2012, introduzido no Update 1, visa a atender os times que preferem não usar Scrum ou que não querem, por exemplo, o overhead de fazer o breakdown de seus PBIs em tarefas. De maneira simplista, com o suporte a Kanban temos um quadro similar ao Taskboard mas que, ao invés de tarefas, mostra PBIs.
  
• Tags (VS2013.2): Tagging é um mecânico muito versátil de marcação de itens de trabalho que pode ser usado para muitas finalidades diferentes, tais como categorizar bugs para ajudar com a triagem ou sinalizar itens de trabalho para acompanhamento fora do escopo normal de desenvolvimento e teste.
  

Suporte a Equipes (Times)

Outra novidade muito benvinda é a possibilidade de criarmos times: grupos de pessoas que atuam no mesmo projeto e por isso compartilham um backlog.

Com o uso de times podemos simular a criação de “sub team projects”, como se estivéssemos efetivamente dividindo um team project em vários menores, organizados por equipe. Essa nova funcionalidade cristalizou de vez o uso de um único Team Project como uma boa prática. Aliás, Um Team Project vai ser assunto para um próximo post.

Workspaces Locais

Certamente poucas coisas irritam tanto os desenvolvedores que usam o TFS quanto ter que fazer checkout antes de editar um arquivo. Isso é especialmente verdade para aqueles que, antes do TFS, estavam acostumados com Subversion, Mercurial ou Git.

E por que o TFS se comporta de maneira diferente? Simples: A fim de melhorar o desempenho de grandes repositórios de código, o TFS mantinha no servidor a lista (e o status) dos arquivos baixados para os computadores dos desenvolvedores. Assim não era necessário trafegar essas informações pela rede o tempo todo. A contrapartida é a “inconveniência” de se fazer checkout toda hora, para “avisarmos” o servidor que estamos alterando um arquivo.

Por outro lado, a Microsoft entende que nem todo mundo tem repositórios de código do tamanho dos da Microsoft e que, para essas pessoas, o modelo de checkout é uma inconveniência maior do que um pequeno aumento no tráfego de rede.

Surge, assim, o espaço de trabalho local (local workspace): agora é possível trabalhar com o controle de versão sem fazer checkout primeiro. Basta sair alterando o conteúdo do seu diretório local e depois fazer checkin. O TFS se encarrega de identificar o que mudou e que deve ser atualizado no servidor.

Rápido e prático.

Revisão de Código

Muitos times têm a necessidade de suportar um processo formal de revisão de código – seja por uma questão regulatória e/ou processual, seja porque o time é distribuído e portanto tem menos oportunidades informais de peer-review.

Pensando nisso, agora o TFS tem um mecanismo nativo para a solicitação formal de revisão de código. Desenvolvedores podem juntar as alterações que devem ser revistar e encaminha-las a um revisor. Essa solicitação entra numa fila para que o revisor possa atende-la no momento mais conveniente. O feedback do revisor (incluindo comentários que ele pode ter feito a respeito de trechos de código) é enviado de volta ao desenvolvedor, que pode então incorpora-lo a seu código.

Coleta de Feedback

Você já precisou obter feedback dos seus usuários/clientes? Provavelmente sim – a menos que você goste de viver perigosamente, desenvolvendo um sistema sem envolver seu cliente.

Acho que todos concordamos que o melhor feedback é aquele obtido pessoalmente. Não há nada como a interação entre as pessoas para avaliar o que nossos usuários gostaram (ou não gostaram), ou mesmo para confirmar o entendimento dos requisitos e regras de negócio.

Num mundo perfeito sempre faríamos isso ao vivo. Mas como não vivemos num mundo perfeito, vez por outra precisamos pedir feedback a um usuário remoto. Nesses casos, o grande desafio é garantir que estamos capturando e armazenando o feedback da maneira mais efetiva, sem que ele se perca em e-mails ou outras ferramentas igualmente inadequadas.

Para melhorar essa interação com usuários remotos, o TFS oferece agora a possibilidade de solicitarmos feedback para usuários remotos. Através da interface web do TFS, podemos criar convites para nossos usuários, passando instruções dos cenários que gostaríamos que eles validassem.

Esse convite, enviado pelo TFS por email, contem também o link para instalação do Microsoft Feedback Client: uma ferramenta gratuita, baseada do Microsoft Test Manager, que facilita a navegação pelos cenários a serem tratados e permite uma captura mais rica de feedback, oferecendo até mesmo a possibilidade de gravar o áudio e o vídeo da webcam do usuário. O resultado dessa sessão de feedback é gravado automaticamente como um item de trabalho no TFS.

Preemptive Analytics

Preemptive Analytics Community Edition para Team Foundation Server é uma ferramenta de terceiros criada pela Preemptive (fabricante do Dotfuscator) que permite que receba informações sobre erros experimentados por seus clientes.

Colocando de outra forma: você já viu esta mensagem de erro abaixo no Windows?

Esse é um recurso do Windows que coleta informações sobre aplicativos que travaram em seu computador. A Microsoft posteriormente tem condições de analisar esses dados e assim corrigir eventuais problemas.

Agora, já pensou se você pudesse ter a mesma funcionalidade para suas próprias aplicações? Ou seja, já pensou se ao ocorrer um erro durante o uso de uma de suas aplicações, houvesse uma coleta de dados (detalhes da exceção, stack trace, configurações do sistema do cliente etc.) e esses dados fossem enviados através da internet diretamente para o seu TFS? É exatamente isso que o Preemptive Analytics se propõe a fazer.

Ao instrumentar seu aplicativo com o Preemptive Analytics, você será capaz de ver esses erros que ocorreram remotamente, em seus clientes, sendo inseridos diretamente no Visual Studio Team Foundation Server 2012. Com isso, você pode facilmente prioriza-los juntamente com outros bugs identificados internamente. Exceções são analisadas, correlacionadas e filtradas em um conjunto de “incidentes de produção”, com base em regras e limites operacionais que você especificar.

E o TFS 2013?

Com o TFS 2013 batendo à porta, este post já está (quase) obsoleto. Mas não se preocupe; pretendo fazer um follow-up cobrindo as novidades do 2013 em breve.

Conclusão

Este post não tem, de maneira alguma, a pretensão de ser uma lista completa do que há de novo no TFS 2012. Entretanto as novidades acima dão ideia dos principais benefícios da nova versão do produto e devem ajuda-lo a decidir se vale a pena investir na atualização.

Quer aprender mais sobre o TFS 2012? Um bom ponto de partida é a página do TFS no site MSDN. Outra excelente fonte de conhecimento é a “Máquina Virtual de TFS do Brian Keller” e seu conjunto de hands-on labs (exercícios práticos para serem feitos diretamente na máquina virtual).

E não se esqueça: se decidir atualizar seu TFS para 2012/2013 e quiser contar com ajuda especializada para isso, é só nos chamar!

Um abraço,
Igor

(Post originalmente publicado em http://tshooter.com.br/2013/08/30/por-que-atualizar-para-o-tfs-2012/)