Processo de desenvolvimento de software para um projeto em tempo parcial na Universidade para 1 desenvolvedor?

5

Eu estarei fazendo um projeto universitário em tempo parcial em breve e o prazo para isso será de cerca de 8 meses, com aproximadamente 10 a 15 horas semanais trabalhando nisso, com uma revisão por um tutor a cada trimestre.

Minha pergunta é qual processo de desenvolvimento de software você recomendaria usar quando o curso exigir que você trabalhe sozinho para gerenciar a si mesmo e ao projeto?

Eu queria usar uma abordagem iterativa semanal ou quinzenal ao meu trabalho, mas muitos dos processos parecem feitos sob medida para equipes de pessoas.

Estou vendo o XP (Extreme Programming) OU o Scrum como algo que é menos do que a norma para o trabalho na Universidade, mas novamente o Scrum, eu ainda não sei muito sobre isso, e uma pergunta que tenho é; você pode dizer que está fazendo XP sem programação de pares? porque meu tutor parece pensar que eu tenho que me ater a todas as práticas, caso contrário eu não posso fazer isso (não importa se eu estou trabalhando sozinho).

Também podemos ter entradas externas do usuário, mas devido a pequenas escalas de tempo com trabalho em meio período, pode ser mais benéfico para mim mesmo ser o usuário, o que não é o que eu prefiro considerando como posso me perder no design .

    
por Pricey 18.01.2011 / 14:35
fonte

3 respostas

4

O primeiro princípio do Manifesto Ágil é ter uma preferência pela colaboração da equipe sobre os processos. O que isto significa para você é não se envolver com XP ou Scrum ou algum outro processo chamado, mas fazer algo para suas necessidades específicas. Algumas abordagens que podem realmente ajudar:

  • Histórias de usuários para rastrear requisitos / recursos e estimativa (pontos da história). Ele fornece estrutura suficiente para descobrir o design de alto nível sem ficar muito atolado nos detalhes.
  • BDD ou TDD , o mais importante, porque você está trabalhando sozinho. Sem um testador dedicado, você tem dois chapéus para usar. Se você codificar seus testes, eles ajudarão você a descobrir quando você acidentalmente quebrar algo.
  • Controle de versão. Use-o, ele salvará sua pele - mesmo que você seja apenas uma pessoa. Melhor ainda, use uma solução hospedada externamente que tenha backups regulares. Há várias opções como o GitHub ou algum equivalente que permita ter repositórios privados. Nada pior do que o sentimento de afundamento antes do dia d (dia de entrega) e você acabou de perceber que você desceu um buraco de rabo que tinha um poço sem fundo. O repositório permitirá que você volte a uma versão sã e escolha uma rota diferente.
  • iterações curtas. Não mais do que uma vez por semana, mas não menos do que uma vez a cada duas semanas. Você precisa de feedback constante e a iteração semanal pode funcionar muito bem. Em cada iteração você deve ter algo que funcione, embora com mais recursos. Se você iterar com muita frequência, estará girando suas rodas e não estará fazendo o suficiente. Se você não repetir muitas vezes, será muito longo sem feedback (ou seja, seu ciclo de testes) e os problemas se tornarão mais difíceis de resolver.
por 18.01.2011 / 14:53
fonte
0

Não há nada que impeça você de usar um processo ágil com apenas um desenvolvedor, embora alguns, como o XP, precisem de programação em pares, portanto, você teria que usar uma metodologia diferente.

Argumentou-se que o XP é uma forma particularmente frágil de desenvolvimento Ágil. Em XP Refactored , os autores apontam que se você não adotar apenas um dos recursos do XP, a coisa toda pode falhar muito mal.

Você não pode fazer levantamentos diários - a menos que seu tutor / supervisor esteja disponível no mesmo horário todos os dias. Então você terá que escolher os recursos que você usa.

Os ciclos de iteração curtos ajudarão e você poderá usar seus tutoriais semanais (?) para discutir o progresso feito na última semana e o que você espera alcançar na próxima semana.

    
por 18.01.2011 / 14:44
fonte
0

Para meus projetos pessoais, eu uso Kanban Pessoal para a visualização geral do processo.

...Unlike other personal productivity tools, Personal Kanban is a pattern – it is not an edict. You can mold it into whatever shape or form works best for you at the time. Personal Kanban is also scalable – it can work with just you, or with your family, or even with work groups.

There are only two real rules with Personal Kanban:

  1. Visualize your work
  2. Limit your work-in-progress

It’s just that simple. After you’ve used this “introductory’ kanban for a little while, your understanding of the nature of your work will evolve. As it does, your kanban will likewise evolve...

http://personalkanban.com/wp-content/uploads/2009/08/whiteboards-050-300x225.jpg

    
por 18.01.2011 / 18:35
fonte