Metodologias Ágeis: XP, Scrum e RAD

Metodologias Ágeis

Trabalham com uma abordagem iterativa para especificação, desenvolvimento e entrega do software. Foram criadas para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Destinam-se à entrega rápida do software para o cliente. Exemplos: XP, Scrum, Crystal.

Princípios das Metodologias Ágeis

• Envolvimento do cliente
• Entrega incremental: feito em incrementos, o cliente especifica os requisitos a serem incluídos
• Pessoas: habilidades da equipe reconhecidas e exploradas
• Aceitar mudanças: projete o sistema para acomodá-las
• Manter a simplicidade: programas menos complexos

RAD (Rapid Application Development)

Usadas para o desenvolvimento de aplicações orientadas a dados. Atualmente, apoia o desenvolvimento de interfaces de banco de dados baseados em navegadores web, permitindo acesso via internet.

Prototipação

• Engenharia de requisitos: ajuda na descoberta e validação dos requisitos do sistema.
• Projeto do sistema: usado para explorar soluções específicas de software e apoiar o processo de interface com o usuário.
• Teste: usado para realizar testes completos com o sistema que será entregue para o cliente.

Vantagens da prototipação: maior adequação do sistema às necessidades do usuário, qualidade do projeto aprimorada, facilidade de manutenção aprimorada, esforço de desenvolvimento reduzido.

XP (Extreme Programming) - 1996, Kent Beck

• Satisfação do cliente
• Entregar o software que o cliente precisa quando é preciso
• Dar poder a quem desenvolve o software
• Dar importância ao trabalho de equipe
• Comunicação, Simplicidade, Feedback, Coragem

Quando usar XP: projetos pequenos, equipes pequenas (não funciona com equipes grandes), funcionalidade do sistema pode ter que mudar com o tempo, quando existe um grande risco no desenvolvimento.

Planning Game

(O cliente escreve o que quer em um cartão curto, programadores estimam o custo, cliente decide a duração do próximo ciclo, com base nas estimativas o cliente decide o que será feito e o que será adiado, garante mais retorno ao cliente em cada ciclo).

Releases Frequentes

Recursos investidos, versão curtas para ver o custo e tem que encaixar na anterior, passa por desenvolvimento e teste, mais urgentes são feitos primeiro.

Metáfora do Sistema: (Cliente fala e a equipe não entende, equipe pede uma demonstração).

O mais simples que possa funcionar: menor complexidade diminui riscos, software cresce e se torna mais complexo (mais riscos de quebras), cortar os sonhos e mostrar o que pode ser feito.

Testar antes: escritos antes de codificar a função do produto, funciona como documentação (não substitui), obriga a pensar como será usado antes de codificá-lo, componente só fica pronto depois de passar dos testes. Unit-testing (teste que o programador faz, quando ele termina só faz os pequenos, os grandes deixa para os testadores).

Refatoração: você tem que mudar algo e já aproveita e transforma em uma nova tecnologia, ideias brilhantes parecem estúpidas depois de uma semana, não acrescenta, apenas "limpa" a existente, recomendável fazer antes de acrescentar alguma função.

Pair-Programming: duas pessoas pensam melhor que uma, uma obriga a outra a pensar no problema, colega deve entender todo o código, desejável os dois terem experiências com níveis diferentes, menos distração.

Propriedade coletiva do código: algo complexo demais, quebrado ou que podia ser melhorado deve ser corrigido, todos devem saber arrumar, não pode haver especialista em uma área, isso evita dependência.

Integração contínua: fazer tudo a partir de uma base que você tenha baseado nela ou no release anterior.

Semana de 40 horas: horas extras são sinal de alerta e viradas de noite produzem baixa qualidade, programadores devem ter uma vida própria, e nunca superestimar os prazos.

Cliente sempre presente: responde dúvidas mais rapidamente, comunicação pessoal é mais eficiente que escrita, programadores não devem tomar decisões para as quais não estão preparados.

Padrões de codificação: todos os programadores devem saber editar e entender o código, legível para a “posteridade”, com o tempo - custo de manutenção. Os padrões não precisam ser arbitrários ou impostos com uso de violência – é desejável que sejam consensuais.

Dificuldades

Cliente ausente: procure um substituto "gerente" quando o cliente for bem ocupado.

Mais de um cliente: procure um único representante.

Privacidade, ambiente hostil, ferramentas estranhas: quando resistirem ao pair-programming crie um espaço para isso, máquinas dedicadas a isso com editores e OSs que os programadores prefiram.

Custo do pair-programming: é caro à primeira vista, porém os programadores vão dispersar menos e o código será de maior qualidade, algumas equipes até planejam soluções e programam separadamente.

Algumas duplas não funcionam: rearranje sempre as duplas, algumas combinações vão funcionar melhor que outras, fator técnico e cultural influenciam.

Sistemas legados: mais fácil começar com XP do que mudar depois, procure fazer a transição em algum momento.

Propriedade do código: programadores não podem ter ciúmes de suas crias, encoraje o uso das mesmas linguagens.

Dificuldade para testar: testar componentes quanto à função, separar conteúdo e apresentação ajuda, componentes de interface podem ser testados separadamente.

Internet-time: pressões induzem a reverter às práticas menos adequadas, ciclos podem se tornar curtos demais para a função, tendência a abandonar testes.