Como você cria um processo de software para um projeto?

Como já escrevi em outras perguntas aqui, o projeto no qual estou trabalhando agora não tem processo de software. Isso significa que não há documentação (incluindo especificações ou requisitos de cópia impressa) , nenhum controle de origem , nenhum banco de dados de bugs, bugs são "corrigidos" (espero) e um novo código é adicionado ao mesmo tempo, e não há testadores formais - falharíamos no teste Joel tão ruim, não é nem engraçado.

Ontem, meu gerente me pediu para escrever um documento sobre como começar a corrigir essas deficiências. Note que eu sou apenas um estagiário, aqui por 6 meses. Vou sair no dia de Ação de Graças em novembro para voltar à escola. No entanto, acho que talvez consiga colocar esse projeto na direção certa, mas não sei por onde começar. Atualmente, estou usando o CiteSeer e a Wikipedia para tentar encontrar alguns documentos que descrevam processos de software e implementá-los, mas qualquer conselho, experiência pessoal ou link para blogs, documentos, artigos wiki ou qualquer outra coisa seria muito apreciado.

Eu sugeriria que você analisasse a programação Agile.

Existem muitas variantes, mas elas tendem a ter algumas coisas em comum:

• Revisão regular e priorização de recursos.
• Integração contínua e testes de unidade automatizados.
• Concentre-se na comunicação sobre a documentação (na prática, isso significa documentação no estilo wiki, enquanto você examina enormes especificações inflexíveis escritas com antecedência).
• Estimativas flexíveis, resultando em gráficos de queima e métricas de velocidade.
• Protótipos regulares revisados ​​em mais de 200 especificações de página com assinaturas.
• Qualidade na fonte ou o mais próximo possível.
• Revisão regular das partes interessadas - uma extensão da compreensão de seus clientes.
• Coloque o software no mercado (e ganhe dinheiro) o mais rápido possível.
• Comunicação direta, tanto quanto possível.

Um bom lugar para começar seria MSF Agile ou Scrum .

Dada a situação, você estará ausente em seis meses e a equipe não iniciará nenhum processo, limitaria o escopo do que você apresenta a uma ou duas coisas que podem ser razoavelmente implementadas e se sustentam no tempo que você está lá. Se fosse eu, eu daria uma olhada em uma ferramenta de controle de origem e em um rastreador de erros.

A razão pela qual eu começaria lá é porque a instalação dessas ferramentas o ajudará a estabelecer uma linha de base para o desempenho atual das equipes e, possivelmente, identificar problemas recorrentes. As alterações do processo são boas, mas esses são os itens básicos básicos que devem ser implementados primeiro.

Usamos o Prince2 para os processos de gerenciamento de projetos e funciona muito bem. Eu sugeriria que pareceria tortuoso para uma empresa sem gerenciamento de projetos, no entanto!

Adaptamos o pipeline de desenvolvimento descrito neste vídeo às nossas próprias necessidades, usando o TeamCity como nosso servidor de IC.

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

O TC é o único sistema de CI que eu conheço que faz um push ao repositório em vez de um pull, o que significa (teoricamente) que não há mais compilações quebradas!

Apenas para ecoar os sentimentos de alguns dos itens acima, as equipes que não têm estrutura se encaixam melhor com uma estrutura ágil. Obtenha o controle da fonte hoje mesmo, basta começar a colocar suas alterações no SVN e mostrar a alguns de seus desenvolvedores um diferencial quando você estiver procurando por bugs. Comece a adicionar logs de revisão. Se eles não conseguem ver os benefícios e a facilidade de uso do SVN, estão condenados.

Confira estes artigos sobre integração contínua para programação .NET usando MSBuild, CruiseControl.NET, FxCop, NUnit, NCover e Subversion ...

Das trincheiras de desenvolvimento de software