Qualquer um gostaria de compartilhar sua experiência usando o TFS para gerenciamento de ciclo de vida do aplicativo

Question

Estamos desenvolvendo o aplicativo Web Web Web e Mobile Healthcare para nossos clientes. Nosso produto está evoluindo rapidamente e estamos apoiando clientes existentes e indo apoiar novos clientes.

O fluxo de trabalho de desenvolvimento atual envolve o SVN para código -fonte, documentos de requisitos de rastreamento e manis para rastreamento de defeitos.

Estamos considerando o gerenciamento do ciclo de vida do aplicativo baseado no VS TFS 2010 para nossa organização. Esperamos que o VS TFS 2010 nos ajude a otimizar o seguinte

1) Gerenciamento de requisitos 2) Controle do código -fonte 3) Construir automação 4) Gerenciamento de testes

Apenas imaginar alguém tem experiência usando o VS TFS 2010 e gostaria de compartilhar suas experiências? Existe alguma alternativa que vale a pena ao VS Teamsystem?

Answer 1

Prefácio: Esta é uma opinião pessoal e não tenho vínculos com a Microsoft, além do que desenvolvo com suas ferramentas para a plataforma deles, mesmo que eu tenha encontrado como um amante da Microsoft nesta resposta. (que eu sou - eu amo o desenvolvimento .NET)

Não usei o TFS 2010, mas usei a suíte de equipe de 2005, incluindo o TFS e as versões do Visual Studio suportadas. Não avançamos para 2008 ou 1020 por causa de quão extraordinariamente difícil a versão de 2005 era instalar. No entanto, uma vez que o instalamos ... adorei. As ferramentas de gerenciamento de projetos eram intuitivas e funcionavam bem. A configuração de compilações foi uma brisa, e fazia tudo o que eu queria fazer de maneira simples e eficiente.

Desde então, no entanto, adotamos ferramentas de código aberto para fazer o mesmo tipo de coisa. Como eu disse, a instalação de 2005 foi um pesadelo e, embora a versão de 2010 do Team Foundation Server instale com muita facilidade (eu o testei e o demonsti para o pobre time que ajudou na versão de 2005 apenas para mostrar o quão melhor isso é), eu não consegui convencer minha equipe a dar uma segunda chance. Eles optaram por ficar com ferramentas que não precisavam ser atualizadas com tanta frequência, e que eram mais fáceis de atualizar quando precisavam ser feitas.

Se fosse apenas eu, eu estaria usando. Essa é uma daquelas coisas em que as coisas funcionam corretamente e trabalham juntas sem problemas. E a documentação disponível (MSDN, vídeos, etc) é exaustiva. Duvido que qualquer outro conjunto de ferramentas seja tão bem documentado.

É uma pena que a experiência com a versão mais antiga tenha sido tão ruim que ninguém mais aqui dê à versão mais nova um raio justo.

Quanto às alternativas - não é de código aberto, mas Atlassiano tem um bom conjunto de ferramentas. Eles funcionam bem para o Java e estamos usando alguns deles em nossa loja .NET. Estamos usando SVN para controle de origem. É a única coisa que eu mais gosto em nosso novo ambiente do que no sistema de equipes.

Answer 2

Comecei em uma nova empresa há 2 meses que usa exclusivamente o TFS 2010 (para controle de origem e rastreamento de problemas/tarefas), e não consegui me sentir confortável com isso. Anteriormente, eu usei principalmente o SVN para controle de origem e o OnTime (por Axosoft) ou Fogbugz (Joel Spolsky) e amei os dois.

Não sei se é a maneira como eles estão usando o TFS (ramificar não é nada tão bom quanto em SVN ... e eles têm itens de backlog do produto, itens de backlog de sprint, insetos, impedimentos e Deus sabe o que mais manter rastrear) Mas eu acho isso muito complicado.

Eu acho que as ferramentas que um desenvolvedor usa devem ajudar o Dev, não atrapalhar. Se eu tiver que parar e pensar em como ramificar o código ou atribuir um problema, algo está errado com minhas ferramentas (ou eu só preciso gastar mais tempo aprendendo -as ... o que também não faz sentido para mim).