Carregar apresentação
A apresentação está carregando. Por favor, espere
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 -
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.