1 / 14

XP E X TREME P ROGRAMMING

XP E X TREME P ROGRAMMING. Fábio Carvalho nº 3838 Cláudio Custódio nº 3768. E X TREME P ROGRAMMING. Nesta apresentação vamos abordar: O que é XP? Seus valores Práticas Papeis ( roles). XP, o que é? (1).

Télécharger la présentation

XP E X TREME P ROGRAMMING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related