Como posso descobrir qual metodologia de programação (se houver) que estamos usando?

Question

O meu grupo está se movendo para o Team Foundation Server em breve.Na verdade, eu estou indo para o esforço.

Uma das coisas que você começa a decidir que metodologia você está usando - Agile, CMMI, etc.

Coisa que é - eu não tenho nenhuma idéia do que a metodologia que usamos.Por que eu quero dizer, nós não estamos usando ativamente um.E eu não estou familiarizado o suficiente com Ágil ou outros métodos para saber que, se qualquer, acontecer para aplicar a maneira que nós estamos fazendo.

Existe algum padrão de metodologia?Como, se passar alguns muito franco processo (get requisitos, código, teste, empurrar para o controle, ter o teste de QA, empurre para a produção) é que existe mesmo um nome para ele?

E como um bônus, com o TFS, qual é a penalidade para escolher a errada logo de início?Como é que é difícil mudar a marcha, mais tarde, se decidir ir Ágil ou algo assim?

Answer 1

Não há grande penalidade para a troca de métodos - você apenas escolhe um padrão quando instala e pode escolher o que você usará para qualquer projeto. De fato, isso só tem a ver com a forma como o TFS configura a página do projeto SharePoint inicialmente - você pode adicionar o que quiser à sua página depois de criar, por isso, se você decidir alterar a metodologia de um projeto, não é difícil de fazer.

Para os dois que o TFS fornece fora da caixa (ágil e SCCM/CATAFALHA), é realmente uma questão do seu processo - você libera "cedo e frequentemente", com lançamentos de pacotes menores à medida que os bugs entram ou você executa seus projetos Em grandes iterações, com um lançamento com muito mais frequência, mas com liberações óbvias de marco?

Uma pergunta a fazer (embora não seja exatamente precisa, mas sempre me ajuda): o produto tem números de versão que serão significativos para os usuários finais? Por exemplo, muitos sites são ágeis, pois estão constantemente lançando melhorias e patches, e geralmente não têm grandes melhorias/revisões, enquanto um produto como o MS Office tem um número de versão significativo (2003, 2007, etc.), que é É mais provável que o SCCM.

Se você não tem uma metodologia declarada, é um ótimo momento para desenvolver um - decida qual ciclo de lançamento faz sentido para você, criar um projeto em cada um e revisar o que o TFS configura para você automaticamente - faça os indicadores de progresso e as páginas do SharePoint Faça senso? Há algo óbvio faltando?

Answer 2

Se você não consegue discernir uma metodologia, então você estiver usando um ad-hoc metodologia.Ele pode ser similar a uma metodologia existente (por acidente).Note no entanto que seguir uma metodologia não é o mesmo que ser bem-sucedido.Eu tenho visto muitos metodologia pesado projetos que falharam, e a abundância de "assento das calças" projectos de ser um grande sucesso tanto (se talvez na necessidade de um pouco de refatoração quando a poeira baixou).

Alteração de metodologias depende de sua cultura, mais do que qualquer coisa.As instituições tendem a resistir à mudança, e fazer alguns indivíduos.No entanto, é novamente a situação de dependente:se a situação existente é, obviamente, quebrado, uma instituição pode, por vezes, fazer snap alterações que toda a gente de surpresa.

Algumas metodologias são "mais pesado" do que outros:esses são mais difíceis de alterar para ou de.Mesmo Desenvolvimento Orientado a testes é "pesado", em que a adota-lo após o fato significa a adição de um monte de testes para o código antigo.A maioria mundo real transições basta adicionar o teste de como os arquivos são editados por outras razões.Da mesma forma, movendo-se a partir de TDD para alguns cachoeira estilo exigiria um monte do código a ser documentado em grande abandonadas ligantes.

Answer 3

O método mais básico tende a ser seu método iterativo ou "em cascata", porque você simplesmente passa de passo a passo. No entanto, não parece mais ser muito popular.