Um freelancer pode usar desenvolvimento ágil?

Quero melhorar a maneira como desenvolvo software. Eu quero desenvolver mais rápido e um ótimo código! Hoje eu uso o método waterfall como freelancer, escrevendo coisas na web (sites, sistemas, etc.). Existe uma maneira de usar o desenvolvimento ágil (XP, SCRUM, etc) trabalhando dessa maneira? Não sei nada sobre desenvolvimento ágil, por onde devo começar? Muito obrigado.

... Além da programação em pares, com certeza. ;-)

Sério, também sou freelancer e uso técnicas ágeis o máximo que posso. Isso funciona muito bem para mim. Eu uso muito o TDD,

Ninguém em qualquer lugar usa 100% do XP ou Scrum, mas todo mundo usa partes dele, tentando adotar o máximo que funciona para eles. Na minha opinião, quanto mais você adota, melhor fica.

O que mais sinto falta é a programação em pares. A maneira como você supera isso é

1. Vá a muitas reuniões de grupos de usuários.
2. Encontre algumas pessoas que você respeita como desenvolvedores.
3. Peça que eles o encontrem tomando café ou algo para escrever um código. Dê a eles parte do seu salário por hora, ocasionalmente, se achar necessário ou apenas responder em espécie ao trabalhar no código deles.
4. Participe ou crie um Hack Club como este: http://www.DallasHackClub.org .

Aqui estão alguns recursos que eu uso:

• Programação extrema - um guia online rápido, mas completo, através do XP.
• Uma ótima visão geral do Scrum .
• Livro fantástico e curto . Perfeito para você!

Então, eu diria que há três "pontos impressionantes" principais no uso do Agile como freelancer:

1. Para clientes maiores, Trabalho / cobrança em iterações. No final da iteração, o cliente pode continuar trabalhando no projeto ou finalizá-lo (ou seja: alcançou seu objetivo). Eu sei (por experiência) que não posso estimar bem mais do que algumas semanas antes, e o pagamento por iteração também mantém o fluxo de caixa entrando. Não é divertido estar no sexto mês de um projeto de três meses e aguardar para finalizar o projeto para que você possa bil ...

2. Ágil significa que a mudança acontece. Fiz vários projetos de lances fixos (o que você acha que pode fazer com o Waterfall) que me perderam dinheiro por causa de uma solicitação do cliente no meio do ciclo. A mudança acontece: o cliente pode desvalorizar um ticket para realizar outro trabalho mais rapidamente, ou talvez você tenha denunciado errado e não tenha feito tanto quanto esperava.

3. Boas ferramentas de colaboração do cliente. Minha estimativa padrão (para algo menor que o valor de uma iteração de trabalho) é na verdade uma série de etapas do Behavior Driven Development derivadas das expectativas do cliente. Eu envio isso ao cliente e digo "Isso está correto?". Isso garante que todos estejam na mesma página.

4. A coisa mais simples que poderia funcionar. É algo a ter em mente enquanto você trabalha: não tenha medo de voltar ao cliente e dizer: "Isso seria muito mais simples (ou mais poderoso, ou o que for) se o fizéssemos dessa maneira ... "

5. Scrum é importante. Gosto de enviar um email para meus clientes todos os dias em que trabalho no projeto deles. É como o meu scrum para eles: "no que trabalhei hoje", "no que / quando vou trabalhar no próximo projeto?", "Existe algo no meu caminho?" E "No geral, como vai o progresso ? "

6. O desenvolvimento orientado a testes também é realmente útil, mesmo como um único programador. Minhas "estimativas com histórias de BDD nelas" me ajudam a alimentar esse processo.

Uma ótima maneira de começar sua jornada Agile é configurar seu fluxo de trabalho usando um sistema KANBAN.

Simplesmente temos 3 raias:

1. Nossas tarefas pendentes ou pendências
2. Em que estamos trabalhando ou EM PROGRESSO
3. Coisas que concluímos ou FAZEMOS.

Esse fluxo de trabalho simples do Agile é uma ótima maneira de começar.

Em termos de codificação, eu recomendaria o uso do TDD ( Test-driven Development ). Incluímos muitos ótimos links que descrevem o TDD em nosso artigo, mas os copiaremos novamente aqui:

Para mais informações, consulte os seguintes recursos:

• AgileData.org - Um ótimo recurso para desenvolvimento orientado a testes.
• JamesShore.com - Outra grande avaria para TDD
• Net Tuts - Uma introdução divertida ao TDD que eu gosto!
• Artima - Entrevista com Martin Fowler
• Games From Within - Um bom estudo de caso de TDD
• DaniWeb - Introdução ao TDD para desenvolvedores
• Mark Levison - Artigo sobre TDD

Como você é um indivíduo, é melhor você abordar metodologias ágeis como algo que está lá para ajudá-lo a descobrir o que funciona melhor para você . Eles estão lá para ajudá-lo a alcançar o platô "não há colher", mas como exatamente isso vai acontecer depende inteiramente de você e o que você criar no final se sobreporá bastante a algumas metodologias em vários níveis, ainda será algo completamente seu.

Como você está tentando encontrar seu próprio caminho para melhorar sua eficácia geral, aqui estão algumas dicas que podem ajudá-lo a pelo menos não cometer os mesmos erros que cometi:

Desista de todas as soluções de software voltadas exclusivamente para metodologias ágeis, pelo tempo que puder.

O fato de serem mais adequados para facilitar a colaboração em equipe não vem ao caso. Resistir a tentação. Você não se encaixa em uma maneira de fazer as coisas e depois espera que sua adoção funcione da melhor maneira possível. Não, apenas frustra você. Você primeiro encontra sua maneira de fazer as coisas e, em seguida, procura uma solução de software adequada. Acabei usando quadros brancos (iniciados com um, mas agora tenho dois no meu quarto) para rastrear / desenvolver histórias e a técnica Pomodoro | Lista do To Do Today para rastrear minhas tarefas de desenvolvimento e o início de 2011. Siga o básico até obtermos algumas interfaces, como as de Iron Man 2 ou carros voadores, que começam a aparecer.

Reflexão, reflexão, reflexão

Isso foi o que eu entendi ser a parte mais importante de qualquer metodologia para um indivíduo. Trata-se de desenvolver esse fluxo de trabalho que fornece uma visão holística do seu projeto, para que você possa acompanhar o que precisa ser feito e quando de maneira fácil de gerenciar e onde as más decisões raramente são tomadas e se destacam para que possam ser rapidamente alteradas antes que causem algum dano ... mas você não pode simplesmente pegá-lo da prateleira. Comece de algum lugar, de qualquer lugar. Você fica com ela enquanto ele funciona. Invista no rastreamento dos bons, dos ruins e dos mais ou menos. Melhore suas suposições e ajuste a maneira de fazer as coisas adequadamente. Essa é a única maneira de melhorar.

Aprecie os prazos, concentre-se na rapidez com que você faz as coisas

Eu provavelmente era o próximo cara quando comecei, perseguindo datas. Gráficos de burnout? Eu costumava pensar neles como uma maneira de visualizar minha faixa de desenvolvimento em relação aos prazos. É um desempenho, não um modelo de estimativa. Há tempo para medir sua eficácia, refletindo sobre o trabalho que você fez dentro de um determinado período de tempo, e não apenas algum valor idiota para representar a distância antes de impedir os prazos. A realidade é que as coisas são feitas quando são feitas e sua metodologia deve explicar isso.

Desviar de acordo

No final, quem disse que você precisa usar histórias de usuários ou qualquer coisa que sabemos sobre esse assunto? Não pense assim. Se você se sente mais à vontade para pensar em recursos, desafie a comunidade global de desenvolvimento e faça do seu jeito, porque fazer as coisas é tudo o que importa no final do dia. Se você acaba sentindo que está fazendo algo errado, parabéns - você acabou de concluir que é hora de pular para outra coisa. É sobre o que é, não sobre os comos.

Eu responderia "como você deseja melhorar a maneira como desenvolve software?". Para o seu modelo de negócios, quais são os maiores problemas encontrados com a metodologia em cascata?

Seu objetivo é um desenvolvimento mais rápido, código mais robusto, maior reutilização, atendimento / adaptação às mudanças de requisitos, etc.? Existem diferentes metodologias para superar diferentes problemas.

É claro que adotar uma metodologia de design diferente da Waterfall pode ser muito útil no gerenciamento eficaz de um ciclo de vida de projetos, dependendo dos requisitos de negócios. Para o desenvolvimento ágil, há um grande número de recursos online. Eu procuraria no AUP (Agile Unified Process) que incorpora TDD (Test Driven Development). Isso pode ser extremamente útil ao criar / gerenciar grandes sistemas escalonáveis.

Não existe uma metodologia 'tamanho único' e esta é a principal razão para o grande número de abordagens diferentes. Gostaria de começar a pensar onde você acha que estão atualmente os gargalos no seu processo de desenvolvimento e depois tentar adotar uma nova metodologia para superar isso.

Por exemplo, você costuma não cumprir os prazos? Os novos recursos introduzem um grande número de bugs? Os novos requisitos causam uma grande reconstrução? A empresa exige a apresentação de sistemas de trabalho regulares? Confira: Introdução ágil , iterativa e ágil .