XP E X TREME P ROGRAMMING

1. XPEXTREME PROGRAMMING Fábio Carvalho nº 3838 Cláudio Custódio nº 3768

2. EXTREME PROGRAMMING Nesta apresentação vamos abordar: • O que é XP? • Seus valores • Práticas • Papeis ( roles)

3. XP, o que é? (1) É uma forma de desenvolver software eficiente, de baixo risco, flexível, previsível, cientifica, e divertidamente. Esta metodologia distingue-se das outras por: • avaliação concreta e continuada de ciclos curtos desde o inicio. • abordagem incremental do planeamento, que surge rapidamente com um plano da evolução do projecto ao longo da sua vida. • capacidade de agendar de forma flexível a implementação de funcionalidades, conforme as necessidades comerciais. • confiança em testes escritos sumariamente por programadores e clientes para monitorizar o progresso de desenvolvimento, para permitir a evolução do sistema, e detectar os defeitos prematuramente.

4. XP, o que é? (2) • confiança na comunicação oral, testes e código fonte para comunicar a estrutura e intenção do sistema. • confiança no processo de desenho evolucionário que dura tanto como o sistema irá durar. • confiança na estreita colaboração de programadores vulgares. • confiança em práticas que funcionam tanto com os instintos a curto prazo dos programadores como com os interesses a longo prazo do projecto.

5. XP, o que é? (3) XP é feito para se aplicar em projectos que podem ser concebidos por equipas de dois a dez programadores, que não estarão constrangidos pelo ambiente de computação existente, e onde a razoável tarefa de executar testes se pode executar na fracção de um dia.

6. Valores (1) • Simplicidade: Um código simples permite reagir às mudanças com maior agilidade que um código complexo, e também está menos sujeito a falhas quando for modificado. Mas simplificar um código complexo é um trabalho duro. • O valor da comunicação: XP prima a comunicação nas trocas de impressão breves e concisas e na programação a dois. Preferindo sempre chat a eMail, telefonemas a chat, conversar pessoalmente a telefonemas, trabalhar na mesma sala a ter salas isoladas, trabalhar em conjunto a analisar o produto final.

7. Valores (2) • Coragem: É preciso coragem para: apontar um problema no projecto, parar quando está cansado, pedir ajuda quando necessário, simplificar código que já está a funcionar, dizer ao cliente que não será possível implementar um requisito no prazo estimado, fazer alterações no processo de desenvolvimento. Ou seja, seguir o procedimento mais correcto mesmo que este tenha menos aceitação por parte da equipa. • Feedback (avaliação): o feedback é como um “tratamento” para o perigo do optimismo na programação. O feedback trabalha em diferentes escalas temporais. Com os testes efectuados ao sistema pelos programadores está-se a receber feedback acerca do estado do sistema. O feedback provem tanto dos clientes como da equipa de desenvolvimento do sistema.

8. Valores (3)Feedback

9. Práticas (1) • O jogo do planeamento: determinar rapidamente o âmbito do novo lançamento combinando as prioridades do negócio e as estimativas técnicas. Manter o plano actual. • Lançamentos pequenos: lançar um programa simples em pouco tempo, e depois lançar pequenas novas versões ciclicamente. • Metáfora: conduzir todo o desenvolvimento com a partilha de uma simples “história” sobre como todo o sistema funciona. • Projecção simples: deve-se manter o sistema o mais simples possível. • Testes: os programadores escrevem testes continuamente, que devem correr sem problemas para continuar. Os clientes escrevem testes para demonstrar que certas funcionalidades estão prontas.

10. Práticas (2) • Refactoring: os programadores reestruturam o sistema sem alterar o seu comportamento para tirar duplicações, melhorar a comunicação, simplificar ou adicionar flexibilidade. • Programação aos pares: todo o código é escrito com duas pessoas numa máquina. • Propriedade colectiva: qualquer um pode mudar qualquer código em qualquer lugar no sistema e em qualquer altura. • Integração continua: integrar e construir o sistema muitas vezes por dia, cada vez que uma tarefa é terminada. • Semana de 40 horas: nunca trabalhar mais de 40 horas por semana.

11. Práticas (3) • Cliente “local”: incluir um utilizador do sistema na equipa, disponível em qualquer altura para tirar duvidas. • Escrever código segundo padrões: escrever todo o código segundo padrões de modo a haver uma melhor comunicação através do código.

12. Papéis das pessoas ( Roles) • Programador: é quem implementa o código. • Cliente: o cliente sabe o que pretende da aplicação, é ele que tem de influenciar o desenvolvimento do projecto sem o “controlar”. • Testador: está focado no cliente, vai ajudá-lo a escolher e escrever testes funcionais. • Tracker: localiza os sinais vitais do projecto (metas) uma ou duas vezes por semana e garante que todos estejam bem cientes dos mesmos. • Coach: tem que notar quando as pessoas se estão a desviar do processo de equipa e traze-los de volta á atenção da equipa. • Consultor: fornece sabedoria técnica quando a equipa precisa. • Manager: deve transmitir coragem á equipa, confiança, e ocasionalmente alguma insistência para que façam aquilo a que se propuseram.

13. Coclusão Todas a metodologias se baseiam no medo, o medo do projecto falhar devido a vários factores, e XP não é excepção, apenas ajuda a evitar essas falhas.

14. Bibliografia: - Extreme Programing explained Beck, Kent - www.xispe.com.br