Metodologias do ciclo de vida de software para equipes de um homem [fechado]

Estou construindo um sistema de software para o meu projeto de mestrado e estava procurando conselhos sobre metodologias específicas que se adequariam a uma "equipe de um homem só" ...

Eu vivo como uma "pistola de aluguel de software", que trabalha principalmente em casa, então estou louca para ouvir o que as outras pessoas têm a dizer sobre isso.

Aqui estão algumas coisas que eu achei importantes:

• Como Denis diz, o controle da fonte é vital - mas o SVN não é a única opção. Eu uso principalmente o Perforce, e o git é uma boa alternativa. Eu gosto de um modelo de desenvolvimento "principal"; isso me permite fazer experimentos em ramificações de código, mesclá-los na linha principal quando eles funcionam e junk-los se não o fizerem.
• Eu uso um caderno para anotações e um programa para rastrear tarefas. Atualmente eu uso o Redmine para o último; antes disso, eu usei o Fogbugz. Também gosto do Redmine porque ele tem um wiki interno muito bom, que eu posso usar para anotações persistentes e links para sites importantes.
• Também é vital rastrear o que estou fazendo e definir limites razoáveis ​​para que eu possa fazer o suficiente sem queimar - veja abaixo.

Minhas outras técnicas evoluíram ao longo dos anos, e eu as ajusto dependendo do projeto e do cliente. As pessoas me pagam pelo código de trabalho, não brincando com o processo, então tento manter o processo leve e fora dos rostos dos meus clientes. Mas acho que algumas técnicas ágeis funcionam muito bem para mim:

• Um dos meus clientes atuais tende a soltar grandes recursos para implementar e não me incomoda até que estejam prontos. Então, acho que trabalhar naqueles em sprints Scrum é ótimo. Meu palpite é que isso pode funcionar para um projeto de mestrado, a menos que seu orientador de pesquisa seja um maníaco por controle.
• Meu outro cliente atual tende a ter mais emergências do tipo "pare de trabalhar nisso e corrija esse". Eu tentei fazer isso com Scrum e desisti depois de um sprint. Então, eu estou fazendo isso usando o Kanban, e funciona muito melhor.

A outra maneira de trabalhar por conta própria é que você não tem ninguém para lhe dizer o que fazer ou quando, ou se você está fazendo o suficiente, ou quando parar de trabalhar, porque você já fez o suficiente - então você tem que fazer isso por si mesmo. Pessoalmente, prefiro o Scrum porque posso acompanhar o meu desempenho em relação aos meus objetivos de sprint. Para projetos Kanban, posso acompanhar quanto tempo estou dedicando, mas não gosto disso e algo mais baseado em objetivos.

Alguns amigos juram por Pomodoro como uma maneira de mantê-los focados nas tarefas e rastrear a eficiência pessoal, e estou pensando em experimentar.

Eu também tenho um processo formal para liberar código para meus clientes para garantir que o que eles estão recebendo seja "correto", mas isso provavelmente está fora do escopo do que você está perguntando.

Use o SVN acima, versão tudo. Para rastreamento, o notebook serve para projetos mais simples, se necessário, você tem muitos aplicativos gratuitos de rastreamento de tarefas / bugs (o Redmine é legal). Agile / XP / Continuous Integration / outros seria um pouco exagerado na minha opinião.

Além do processo de software pessoal , não descobri muito sobre modelos de processo formais projetados para uso por um único desenvolvedor. O PSP é bastante pesado em documentação e papelada (na sua forma bruta, de qualquer maneira), sem muito a dizer sobre técnicas específicas de execução de trabalho (em vez disso, o PSP se concentra na coleta de dados para encontrar áreas para melhoria), mas é um ponto de partida ponto para o desenvolvimento de um processo pessoal que você pode usar em projetos de pequeno a médio porte.

Penso que o melhor curso de ação seria simplesmente seguir algumas das melhores práticas amplamente aceitas, escolhidas adequadamente (com base em suas necessidades e no projeto), de vários modelos de processos. Dê uma olhada nos métodos para rastrear o trabalho realizado / restante, gerenciando requisitos, controle de versão, testes (principalmente testes de unidade e aceitação), integração contínua, padrões de codificação, Você não precisará disso, e assim por diante. Caso contrário, sugiro ler Code Complete e The Pragmatic Programmer e praticar suas dicas.

A maior coisa sobre o trabalho individual é que, além de quaisquer restrições impostas a você por forças externas, tudo depende de você. Você não precisa acomodar mais ninguém trabalhando ao seu lado, por isso é mais fácil escolher técnicas que lhe permitam trabalhar da maneira mais eficiente possível. Ao longo dos anos, você provavelmente descobriu como funciona melhor, de modo que seria um bom ponto de partida. Em seguida, aplique as "melhores práticas" conhecidas para aprimorar suas habilidades e técnicas.

O cara está perguntando sobre metodologias específicas e as pessoas estão respondendo "use o software X / Y". NÃO é uma questão de ferramentas, na verdade existem muitas metodologias e parece que ainda não há um relatório de validação para elas: Agile, Iterative, Spiral, Waterfall, XP, V-Model, TDD.