Uma metodologia inovadora… Extreme Programming Uma metodologia inovadora…

Agenda Introdução Definição de XP Papéis da equipa Ciclo de vida Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Agenda Introdução Definição de XP Papéis da equipa Ciclo de vida Quando utilizar ou não? Conclusão

Introdução Metodologia de desenvolvimento Surgiu por Kent Beck Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Introdução Metodologia de desenvolvimento Surgiu por Kent Beck Chrysler Comprehensive Compensation (C3) project Valores, práticas, princípios e actividades Produzir código de qualidade, que possa ser executado e actualizado, de forma rápida, eficiente e simples Trabalho de equipa – clientes e equipa de desenvolvimento Surgiu nos anos 90, por Kent Beck, quando foi convidado a participar no projecto C3, numa reacção contra os métodos altamente regulado e cheios de burocracias que atrasavam e iam contra o modo de trabalho dos engenheiros de software - prático e eficiente.

Definição de XP Consiste em quatro partes: Valores Princípios Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Consiste em quatro partes: Valores Princípios Actividades Práticas Podemos ver o extreme programming como uma sinergia de quatro componentes Existe uma base de Valores sobre os quais assentam princípios e práticas, que nos indicam o modo como as actividades são executadas

Definição de XP Valores Simplicidade Comunicação Feedback Coragem Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Valores Simplicidade Comunicação Feedback Coragem O XP é composto por uma série de valores partilhados pelos membros da equipa Simplicidade – Esta consiste em fazer o mais simples que funciona. Há que resolver os problemas de hoje com simplicidade e esperar que os de amanhã também assim sejam. Ao contrario de outras metodologias em que é necessário prever o funcionamento futuro do sistema – o que por vezes o torna impossível de alterar já que as necessidades do momento podem não ter sido previstos. O XP baseia-se simplesmente no que o cliente necessita agora e não no que pode vir a necessitar. Comunicação – Todos os métodos tem processos de comunicação. No XP a comunicação baseia-se na oralidade, não há relatórios, nem documentos, nem planificações. Feedback – O feedback é vital para o sucesso de qualquer projecto de desenvolvimento de software. Como este está sempre em continuo estado de design o produto é validado por teste e erro. Para que isto seja verdade a equipa tem de desenvolver o código rapidamente e depois enviar pequenas versões de demonstração para o cliente. Este testa e dá a sua apreciação. Como este mecanismo é continuo o código está sempre actual e a qualidade e actualidade é assim garantida Coragem – Esta é a confiança de trabalhar rapidamente e caso exista a necessidade de redesenhar faze-lo sem hesitação. O XP tem uma forte cultura de testes, faz-se teste antes de fazer o código a ser testado. Tem de existir coragem ao codificar uma funcionalidade que já existe teste para esta. Há que ter em conta que os valores tem de estar todos presentes. Ex.: De que adianta coragem para refazer algo se a nova solução é complicada e confusa.

Definição de XP Princípios Rapid feedback Assumir simplicidade Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Princípios Rapid feedback Assumir simplicidade Mudança incremental Aceitar mudança Trabalho de qualidade Sobre os valores assentam os seguintes princípios: Rapid feedback – quem desenvolve deve ter um rápido ciclo de feedback para saber se as alterações que estão a ser feitas são de acordo com o que o cliente necessita. Assumir a simplicidade – Trabalhar o problema de uma forma simples tendo em conta apenas a iteração actual. Não tentar usar uma bola de cristal para prever o que vai ser necessário no futuro. Mudança incremental – resolver o problema num conjunto de pequena alterações. Isto aplica-se de igual forma ao planeamento, design e desenvolvimento. Aceitar a mudança – adoptar a estratégia de ter sempre varias opções para resolver um problema Trabalho de qualidade – A qualidade não pode ser deixada de parte nunca. O xp aumenta a qualidade através da sua base de testes. Programar testes antes de programar uma funcionalidade.

Definição de XP Actividades Escutar Testar Escrever código Designing Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Actividades Escutar Testar Escrever código Designing Escutar – O XP baseia-se na comunicação entre os membros da equipa. Para que a comunicação chegue a todos é necessário saber escutar. Testar – Testes não é algo que se faz antes de entregar a solução final ao cliente, mas sim um passo de integração dentro de todo o processo. Não são só testes limitados à exactidão e controlo de erros, mas também à performance e conformidade. Escrever código – O XP está assente na codificação através de praticas de como programação em pares, refactoring e revisão de código. Designing – Uma das ideias mais radicais do XP é a de que o design evolui e aumenta durante o projecto. O design não é estático nem atribuído a um só elemento, mas sim baseado em toda a equipa.

Definição de XP Práticas Planning game Pequenas versões Metáforas Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Práticas Planning game Pequenas versões Metáforas Design simples Testar Como devemos executar actividades num projecto em XP: Planning Game – Este processo permite ao cliente definir a caracteristica desejada usando as estimativas de custos que os programadores lhes dá. Escolhendo assim o que fica por fazer e o que fazer. Pequenas versões (releases) – o ciclo consiste em frequentes versões que aumentam o valor do negocio Metáforas – É uma visão comum de termos e linguagem no projecto. Ex: Imagine-se um projecto de desenvolvimento de um software jurídico. A percepção dos termos técnicos é diferente num programados e num jurista. Por isso é necessario definir uma “linguagem comum”. Design Simples – Design que permita ao codigo ser simples e que possa funcionar. Testar – O coração do XP são os testes automáticos. Os testes são desenvolvidos primeiro e implementados numa zona de testes autónomos.

Definição de XP Práticas Refactoring Programação em pares Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Práticas Refactoring Programação em pares Propriedade colectiva Integração contínua Refactoring – Melhorar o código sempre que se seja possível. O objectivo é refinar o codigo existente para que este fique melhor, mais eficiente e mais simples. Programação em pares – Dois programadores estão sempre no mesmo computados, e trocam de tarefa a cada duas horas. Propriedade colectiva – O código pertence à equipa. Assim qualquer membro pode sempre melhorar o código. Integração continua – os componentes são criados e integrados varias vezes por dia.

Definição de XP Práticas Semana de 40 horas Cliente no local Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Definição de XP Práticas Semana de 40 horas Cliente no local Padrões de código Semana de 40 horas – a performance não se pode manter se as equipas forem sobrecarregadas em termos de carga horária. O horário deve ser regular para assegura a qualidade. Cliente no local – Está sempre um representante do cliente no local e faz parte da equipa. Padrões de código – Conjunto de regras de codificação que a equipa aceitar para a uniformização de código.

Papeis da equipa Cliente Treinador (Coach) Programador Tester Tracker Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Papeis da equipa Cliente Treinador (Coach) Programador Tester Tracker Gerente Cliente – Define o que é o projecto e como deve ser desenvolvido, o termo de cliente pode não estar associado a uma pessoa individual, mas sim a um conjunto de pessoas que : -> Define e dá prioridade as “user stories” -> Define requisitos do projecto -> Descreve os testes que cada fase de desenvolvimento tem de passar antes de se passar à fase seguinte -> Poderá ser o utilizador final da aplicação Treinador – Orienta a equipa, tentado garantir que esta mantêm-se fiel à metodologia XP, para tal deve possuir os seguintes atributos -> Grande compreensão da metodologia XP -> Sentido de liderança -> Possuir grande conhecimento de programação orientada a objectos e de linguagens de programação -> O seu papel diminui à medida que a equipa evolui Programador – São considerados o coração dos projectos XP, e estão presentes em todas as fases do desenvolvimento com a metodologia XP -> Em conjunto com o cliente cria as User Stories -> Desenvolve código e testes -> Participa nas reuniões diárias e de planeamento Tester – Tem como objectivo realizar testes funcionais do projecto em desenvolvimento, podendo esses testes serem efectuados junto do cliente, se o desenvolvimento foi efectuado correctamente existem poucas hipóteses de chegarem “bugs” graves a esta fase, pois o código já se encontra testado a priori pelos programadores à medida que o vão escrevendo. Tracker – Cria estimativas de tempo sobre as User Stories e tarefas, verifica se o tempo gasto nas tarefas completas coincide com o previsto inicialmente, e vai actualizado o tempo total previsto para a duração do projecto. Tem ainda a responsabilidade de guardar um histórico dos testes funcionais criando um registo dos problemas encontrados, assim como o número de classes métodos e linhas de código geradas. Gerente – É a pessoa que lidera o projecto internamente e com o consumidor, e protege a equipa de interferências exteriores.

Ciclo de vida Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Ciclo de vida Exploration Phase – Procura-se definir as User Stories e a Achitectural Spike do projecto, para o lançamento da primeira versão. User Stories – Fornece a base para a execução e tomada de decisões do projecto, contém a descrição dos produtos e serviços a serem entregues, os objectivos do projecto e a definição de como este irá ser gerido. Deve ser seguido de forma ao produto final ter alta qualidade e se encontrar dentro do orçamento e prazos estabelecidos. Achitectural Spike – Conjunto de código considerado mínimo para o funcionamento inicial do projecto Planning Phase – Fase onde são implementadas descritivamente as User Stories mais importantes do projecto, podendo ser descritas através de modelos ou de texto, de forma a eliminar todas as duvidas que possam haver sobre os conteúdos pedidos pelo cliente. Iterations Phase – É onde é efectuado grande parte do esforço de desenvolvimento, pois são efectuadas modelações, programação e testes à User Storie em desenvolvimento em determinada iteração. Durante o desenvolvimento de determinada iteração irão aparecer novas User Stories que não tinham sido previstas anteriormente, sendo necessário voltar à fase anterior com essa User Storie. Productionizing Phase – Chega-se a esta fase quando uma funcionalidade se encontra a funcionar de acordo com os requisitos do cliente e se encontra livre de bugs, significando que se encontra pronto para produção, sendo agora necessário preparar o lançamento da aplicação para isso importante realizar testes de sistema e de instalação assim como a criação de documentação, podendo esta ser para os programadores, de forma a facilitar possíveis alterações e/ou melhorias, de operações, para indicar as dependencias do sistema, de suporte, para indicar a resolução de determinador problemas e de utilizador, de forma a integra-lo no sistema desenvolvido através de um guia ou manual de utilizador.

Quando utilizar? Em projectos pequenos e médios Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Quando utilizar? Em projectos pequenos e médios Equipa até 10 programadores Em projectos com requisitos em constante mudança durante o desenvolvimento Quando é possível contar com a colaboração do cliente Dúvidas, alterações e prioridades

Quando não utilizar? Equipas de grande dimensão Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão Quando não utilizar? Equipas de grande dimensão Separadas geograficamente Feedback demorado Em projectos não iniciados com XP Quando o prazo é apertado

XP – Conclusão É rápida e eficaz… Redução de custos Simples e flexível Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão XP – Conclusão É rápida e eficaz… Redução de custos Simples e flexível Menos permeável a erros

XP – Conclusão Falta de planeamento Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão XP – Conclusão Falta de planeamento Estimativa de tempo Antecipação do risco Falta de práticas e documentação no desenho do sistema Projecto de grande escala Reutilização para outros projectos

XP – Conclusão Migração… A participação do cliente… Aplica-se…? Agenda Introdução Ciclo de vida Definição de XP Quando utilizar ou não? Papéis da equipa Conclusão XP – Conclusão Migração… A participação do cliente… Aplica-se…?

Referências Links Bibliografia http://www.extremeprogramming.org http://www.xprogramming.com http://www.xispe.com.br http://www.unisinos.br Bibliografia Sams Teach Yourself Extreme Programming in 24 Hours (0-672-32441-5) Extreme Programming Explained : Embrace Change (2nd Edition) (ISBN 0321278658)

António Trindade - nº 3060 Avelino Cavaco - nº 3294 Filipe Inácio - nº 3046