XP EXTREME PROGRAMMING

Apresentação em tema: "XP EXTREME PROGRAMMING"— Transcrição da apresentação:

1 XP EXTREME 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 , 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 -