TFS modelo de orientação do processo lock-in?

Question

A minha equipa está olhando para migrar muitas de nossas ferramentas (SCM, bug-tracking, constrói, testando) para TFS. Estamos pensando em mudar cada sistema em etapas. Por exemplo, o controle de origem movimento primeiro, bug / recurso de rastreamento seguinte, etc ...

Uma vez que temos de escolher um modelo de processo de controle de origem uso (ou qualquer coisa no TFS) como trancado em que estamos com a decisão? Eu estou olhando para evitar ter de criar outro projeto mais tarde ( ou é que não é tão ruim quanto eu acho que seria?).

eu sei que posso em tudo teoria personaliza as configura modelo de processo após o fato (certo?), Mas como viável é isso na prática?

Aqui está como eu vejo as coisas acontecendo:

1. Nós migrar nosso código fonte. Nós escolher modelo CMMI, da Microsoft.
2. Nós criar um novo item de trabalho (ou o check-in nota) que é um simples link para o nosso legado sistema de rastreamento de bugs.
3. Eu trabalho por algum tempo.
4. Vamos esperar até os poderes constituídos (nós somos uma empresa de software decente médias) para elaborar um novo fluxo de trabalho de desenvolvimento TFS. Esta pode ser uma simples recolha de novos itens de trabalho ou um modelo totalmente novo que configura todos os tipos de coisas.
5. Tentamos migrar nosso projeto TFS para este novo sistema sem perder nossa história.

Será que vamos ser lamentamos não apenas esperar até que todas estas decisões foram finalizadas antes de usar TFS?

Answer 1

Então, você está certo para pensar sobre o seu modelo de processo como há uma certa quantidade de "lock-in" no entanto, não é muito grave. É como se você está preso ao seu modelo de processo com mel em vez de super-cola.

Pessoalmente, gostaria de começar com o modelo MSF Agile. É muito peso mais leve e contém menos itens de trabalho -. Para que mais likley querer adicionar coisas a ele (muito fácil no TFS, muito bem apoiado), em vez de levá-los longe (mais complicado e não é totalmente satisfatório)

No entanto, se o poder é que se decidir ir por um processo de definição do processo uber e magicamente chegar a um novo modelo de processo em 12 meses o tempo que eles querem que você use, então não é completamente perdido. Se você achar que você deseja criar um projeto novo Team, contanto que é nesse servidor (ou coleção de projeto no TFS 2010), então você pode ramificar o código para o novo projeto de equipe (o que significa que a história é um pouco obscurecida nas versões atuais dos clientes TFS) ou você pode criar um novo projeto da equipe com uma pasta vazia para controle de origem e, em seguida, mover as pastas filho ao longo do projeto de equipe antigo para o novo. Isto irá preservar a história perfeitamente como TFS mantém história de movimentação na mesma instância TFS. Os itens de trabalho de antes da mudança vai ser preso lá no velho modelo de processo embora e você precisa decidir se você quer copiá-los ou deixá-los a ficar fechado para fora naturalmente.

Obviamente, usando efetivamente TFS para 12 meses em projetos reais, quando os poderes que vêm bater você também vai estar em uma posição muito melhor para saber o que você quer que seu novo modelo de processo brilhante para olhar como - e eu 've muitas vezes constatamos que este é um exercício que simplesmente nunca acontece ea maioria das pessoas são ajustes feliz torno das bordas do MSF Agile ou escolher algo mais prescritiva como Scrum para o Team System .

Espero que ajude,

Martin.