Ágil para o desenvolvedor solo

Como alguém implementaria os conceitos de processo Agile como desenvolvedor solo? O Agile parece útil para desenvolver aplicativos em um ritmo mais rápido, mas também parece muito orientado para a equipe ...

• Fazendo desenvolvimento orientado a teste
• Desenvolvendo em pequenos sprints
• Por ter muito contato com o cliente

Lembro-me de ler uma tese sobre o Cowboy Development, que é essencialmente ágil para desenvolvedores solo, mas não me lembro onde a encontrei.

Além da resposta de klez (todas as boas sugestões), sugiro o seguinte:

• Mantendo uma lista de pendências do produto
  Uma lista de pendências do produto é basicamente uma lista de todos os itens que você pretende concluir em algum momento deste produto.
• Mantendo um Burndown de Sprint e um Burndown de Produtos
  Um burndown de sprint começa com uma lista de todas as tarefas que você decidiu concluir neste sprint (um subconjunto do backlog do seu produto a ser concluído por um período de tempo definido - por exemplo, 2 semanas) junto com a estimativa do trabalho necessário. Ao marcar as coisas, você as marca como concluídas; reduzindo (ou queimando) o trabalho restante para esse sprint.
  Da mesma forma, a burndown de um produto controla o trabalho restante para todo o backlog do produto
• Adotando os conceitos de estimativa relativa e velocidade
  A estimativa relativa é uma técnica de estimativa que usa as outras tarefas (ou histórias) como guia. Por exemplo, se você souber que a tarefa A é mais fácil que a tarefa B e duas vezes mais complexa que a tarefa C, verifique se os "pontos" da tarefa A estão corretos em relação a essas expectativas.
  A ênfase não está em adivinhar corretamente a quantidade de trabalho necessária, mas em manter as estimativas consistentes entre si.
  Velocidade é uma medida de quantos "pontos" você faz em um sprint. Se sua estimativa relativa garantir consistência, essa velocidade poderá ser usada para estimar quais tarefas você provavelmente realizará nos próximos sprints. Observe que essa velocidade deve ser constantemente revisada.

• Limite o trabalho em andamento (além do time-boxing). Mesmo se você usar um método iterativo (em oposição ao Kanban), digamos que sua velocidade seja de 8 pontos por iteração. Não comece a trabalhar nos 8 ao mesmo tempo. Limitar o WIP pelo número de histórias ou pelos pontos da história é bom.
• Faça testes de aceitação automatizados para todas as suas histórias de usuários. Automatize o máximo que puder em geral.
• Erro ao tornar as histórias de usuário muito pequenas. Como regra geral, faça a proporção da maior para a menor história 3: 1 . Se você subestimar uma história no Scrum e ela for muito grande, vários desenvolvedores poderão enxameá-la para recuperá-la. Mas você não tem pessoas suficientes.
• Se, em um contexto de equipe de tamanho normal, você hesitaria em dividir um pico de uma história de usuário - no contexto de equipe pequena ou solo, faça o pico sem hesitação. Isso ajuda a manter as histórias menores e mais previsíveis.
• As retrospectivas são importantes no ágil em geral, portanto, o Kanban (que seria o Personal Kanban) obtém pontos extras aqui, porque seu processo retrospectivo é mais orientado a dados. É difícil jogar Triple Nickels quando você não tem pessoas suficientes.

Provavelmente, essas coisas se aplicam a situações individuais e de equipe pequena (2 ou 3 desenvolvedores).

ADICIONADO: algum tempo depois de escrever esta resposta, encontrei esta palestra na conferência e fiquei muito impressionado: Kanban pessoal: otimizando o codificador individual

• Trabalhe em sprints bem definidos ou escolha deliberadamente uma abordagem Kanban. Não acidentalmente acabe em Kanban
• Erros primeiro, recursos em segundo.
• Ainda mantenha o foco no valor versus o inchaço dos recursos. (YAGNI sobre revestimento de ouro)
• Retrospectivas são igualmente valiosas. E, igualmente importante, faça alterações no processo em pequenos pedaços. Não decida que hoje você começará a usar TDD, Mock e IoC de uma só vez, a menos que não tenha recursos externos para entregar ATM. Traga um de cada vez.

Por fim, defino o Agile realmente como "fazer o que faz sentido para sua equipe e cliente e não aderir às práticas antigas porque elas pareciam ter funcionado no passado".

O Agile funciona tão bem para os indivíduos quanto para as equipes. Trata-se de encontrar um processo que funcione para você e permitir que você se adapte às novas circunstâncias, uma vez que seu projeto já foi iniciado. Também se trata de agregar valor ao seu cliente regularmente, independentemente de o software estar ou não "finalizado".

Os processos ágeis são altamente iterativos. O trabalho é feito em curtos TimeBoxes / sprints / ciclos / iterações. Alguns trabalhos de design podem ser necessários antecipadamente, mas podem ser reformulados à medida que você aprende mais sobre o que é necessário que um sistema faça. O teste de unidade é a espinha dorsal de quase todos os métodos de desenvolvimento Agile, fornecendo uma indicação sobre se o seu software está funcionando e se as adições / alterações no software quebrarão a base de códigos existente.

Se você aderir ao BDD / TDD, permita que seus requisitos mudem com o vento e possa ajustar suas prioridades de recursos de acordo, se você construir todo o sistema e executar todos os testes com freqüência e se fornecer código de trabalho no final de cada sprint , você já é ágil.

Uau. Eu tentava manter um amigo no gancho que eu poderia ligar quando estivesse com problemas - e discutir o problema de codificação. Você sabe o que eu quero dizer ... apenas o ato de explicar um problema em voz alta traz uma solução para minha mente 90% do tempo.