Agile para o desenvolvedor Solo

• Fazendo desenvolvimento orientado por testes
• Desenvolvendo em pequenos sprints
• Por ter muito contato com o cliente

Eu me lembro de ter lido uma tese sobre o Cowboy Development, que é essencialmente ágil para desenvolvedores solo, mas não me lembro onde o encontrei.

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

• Mantendo um backlog de produto
  Um backlog de produto é basicamente uma lista de todos os itens que você pretende concluir em algum momento para este produto.
• Mantendo um Burndown de Sprint e um Burndown de Produto
  Um Burndown Sprint começa com uma lista de todas as tarefas que você decidiu concluir neste sprint (um subconjunto de seu backlog de produto a ser concluído durante um período de tempo definido - por exemplo, duas semanas), juntamente com a estimativa do trabalho necessário. Ao marcar as coisas, você as marca como feitas; reduzindo assim (ou queimando) o trabalho restante para esse sprint.
  Da mesma forma, uma burndown de um produto rastreia o trabalho restante para todo o backlog do produto
• Adotando os conceitos de estimativa relativa e velocidade
  Estimativa relativa é uma técnica de estimativa que usa as outras tarefas (ou histórias) como um guia. Por exemplo, se você souber que a tarefa A é mais fácil que a tarefa B e aproximadamente duas vezes mais complexa que a tarefa C, certifique-se de que os "pontos" da tarefa A estejam corretos em relação a essas expectativas. A ênfase não está em adivinhar corretamente a quantidade de trabalho necessário, mas manter as estimativas consistentes umas com as outras.
  A velocidade é uma medida de quantos "pontos" você faz em um sprint. Se a sua estimativa relativa é garantir a consistência, essa velocidade pode ser usada para estimar quais tarefas você provavelmente fará nas próximas etapas. Note, porém, que a 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 pontos da história é bom.
• Testes de aceitação automatizados para todas as suas histórias de usuário. Automatize o máximo que puder em geral.
• Erro ao tornar as histórias dos usuários muito pequenas. Como regra geral, faça a relação da maior para a menor história 3: 1 . Se você subestimar uma história no Scrum e for grande demais, vários desenvolvedores podem enxotá-la para recuperá-la. Mas você não tem pessoas suficientes.
• Se, em um contexto de equipe de tamanho regular, você hesitar em dividir um pico de uma história de usuário - no contexto de equipe individual ou pequena, faça o pico sem hesitação. Isso ajuda a manter as histórias menores e mais previsíveis.
• Retrospectivas são importantes em agile em geral, então Kanban (que seria Personal Kanban) pontua pontos extras aqui, porque seu processo retrospectivo é mais baseado em dados. É difícil jogar Triple Nickels quando você não tem pessoas suficientes.

Estas coisas provavelmente se aplicam a situações de equipe solo ou pequena equipe (2 ou 3 desenvolvedores).

ADICIONADO: em algum momento depois que eu escrevi esta resposta, encontrei esta palestra na conferência e fiquei muito impressionado: Kanban Pessoal: Otimizando o Codificador Individual

• Trabalhe com sprints bem definidos ou escolha deliberadamente uma abordagem kanban. Não acabe acidentalmente no Kanban
• Primeiro, os bugs aparecem em segundo lugar.
• Ainda mantenha o foco no valor vs. (YAGNI sobre Gold Plating)
• Retrospectivas são tão valiosas. E tão importante quanto, faça mudanças no processo em pequenos pedaços. Não decida que hoje você vai começar a usar o TDD, o Mock e o IoC de uma só vez, a menos que você realmente não tenha recursos externos para entregar o ATM. Traga um de cada vez.

O Agile funciona tão bem para indivíduos quanto para equipes. Trata-se de encontrar um processo que funcione para você e permitir que você se adapte às mudanças de circunstâncias, uma vez que seu projeto já tenha começado. Trata-se também de entregar valor ao seu cliente regularmente, independentemente de o software estar ou não "acabado".

Processos ágeis são altamente iterativos. O trabalho é feito em pequenos TimeBoxes / sprints / ciclos / iterações. Algum trabalho de design pode ser solicitado antecipadamente, mas pode ser refatorado conforme você aprende mais sobre o que é necessário para um sistema fazer. O teste unitário é a espinha dorsal de quase todos os métodos de desenvolvimento ágil, dando a você uma indicação de que seu software está funcionando e se adições / alterações em seu software irão quebrar a base de código existente.

Se você aderir ao BDD / TDD, permita que seus requisitos mudem com o vento e ajuste suas prioridades de acordo, se você construir todo o seu sistema e executar todos os testes com frequência e se entregar o código no final de cada sprint, você já é Agile.

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