Ágil para o desenvolvedor solo

133

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 ...

kelleystar
fonte
77
Eu apenas tentei adotar a programação em pares como desenvolvedor solo e melhorou a qualidade do meu trabalho!
usar o seguinte comando

Respostas:

66
  • 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.

Federico klez Culloca
fonte
18
Eu discordo totalmente com a afirmação de que o desenvolvimento "Cowboy" é Agile, mesmo para um desenvolvedor de solo
Travis Christian
4
@TravisChristian - É mais Lone Ranger.
Jeffo
9
Aqui está um link para a tese , que @ a.brookshollar tentou deixar como uma edição.
Scott Whitlock
6
Aposto que nem Travis nem as 11 pessoas que votaram no seu comentário leram a tese em questão. O título completo é "Cowboy: uma metodologia de programação ágil para um programador solo" e, embora um pouco datado, vale a pena ler.
Brien Malone
2
O link para a tese está morto, mas existe um arquivo: web.archive.org/web/20150914220334/http://…
Tobias Kienzler
39

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.
Damovisa
fonte
Lista de pendências de produtos, burndown, estimativa relativa (pontos da história) e velocidade são práticas ágeis essenciais. Nenhum deles é específico para a situação do praticante solo.
precisa saber é o seguinte
4
... assim como TDD, sprints, e contato com o cliente ...
Damovisa
5
seria bom se você também dissesse o que significa todo esse jargão. Eu sou tão ignorante quanto era antes de ler esta resposta ..
Click Upvote
2
@ Damovisa: Eu não preciso de suas descrições ou de uma pesquisa na web, muito obrigado. Você descreve com bastante precisão algumas práticas comuns do Scrum. Esse é exatamente o ponto de partida da pergunta do OP. Sim, essas práticas existem, mas são orientadas para equipes, como as aplico na micro-escala? Não há nada em suas descrições que seja específico para a microescala.
azheglov
4
@azheglov Uau, não precisava ofender. Eu estava destacando quais partes do Scrum considero mais úteis em um cenário de desenvolvedor solo, em vez de como aplicá-las. Nenhuma dessas técnicas deve mudar para um time solo x equipe, para que sejam aplicadas exatamente da mesma maneira. Para espelhar suas palavras - não há nada nessas técnicas que seja específico da microescala.
Damovisa
21
  • 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

azheglov
fonte
9
  • 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".

MIA
fonte
3

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.

S.Robins
fonte
0

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.

codeyoung
fonte
8
Esse é o maior valor que recebo de algum lugar, como stackoverflow. Não sei dizer quantas perguntas eu digitei e depois não pressionei enviar.
Dan Ray
5
Relacionados: c2.com/cgi/wiki?RubberDucking
Jo Liss
2
O ducking de borracha é um ótimo conceito (discutido aqui em questões relevantes ), mas como isso responde à pergunta? "Como alguém implementaria os conceitos de processo Agile como desenvolvedor solo?"
Gnat 23/05