A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Trabalho de Fundamentos da Engenharia de Software eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima Escalfoni 100134931.

Apresentações semelhantes


Apresentação em tema: "Trabalho de Fundamentos da Engenharia de Software eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima Escalfoni 100134931."— Transcrição da apresentação:

1 Trabalho de Fundamentos da Engenharia de Software eXtreme Programming Daniel Fabio Domingues Posner Rafael Elias de Lima Escalfoni Rafael de S. Tenório Cavalcanti U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o

2 eXtreme Programming Criada em 1996 por Kent Beck e Ward Cunningham no desenvolvimento de um sistema de recursos humanos chamado C3 para a montadora de automóveis Chrysler. Metodologia ágil, voltada para equipes de pequeno e mdio porte de desenvolvimento de software, que precisam lidar com problemas que estejam em mudanas constantes, principalmente causados pela dificuldade do levantamento de requisitos iniciais. Introduo

3 eXtreme Programming Nos modelos tradicionais o custo de mudanas alto. (tem que fazer ajustes na fase inicial do projeto) A eXtreme Programming já trabalha pensando que mudanas iro ocorrer, o que diminui o custo para uma alterao. Introduo

4 eXtreme Programming Recomendada para equipes de 2 à 12 membros, devido a necessidade de comunicao e simplicidade. Para implementar em grandes empresas, basta fazer uma diviso em várias equipes. A eXtreme Programming baseada em quatro valores: Comunicao, Simplicidade, Feedback e Coragem, que so responsáveis pela melhoria do custo de uma alterao de requisitos durante o ciclo de vida do projeto. Introduo

5 eXtreme Programming A eXtreme Programming se baseia em uma sria de práticas, que podem ser utilizadas individualmente, mas que obtm melhores resultados quando utilizadas em conjunto. Muitas práticas da eXtreme Programming so apenas de bom senso e as pessaos já as utilizam mesmo sem saber. O nome eXtreme Programming vem da aplicao dessas praticas a níveis extremos. Introduo

6 eXtreme Programming Se bom fazer reviso de código, ento o código será sempre revisado (Pair Programming). Se bom fazer testes, todos vo testar o código o tempo todo (Unit Testing), at mesmo o cliente (Functional Testing). Se fazer projetos bom, ento será parte do dia-a-dia de todos (Refactoring). Se bom o projeto ser simples, o sistema será sempre na forma mais simples que suporte as necessidades requisitadas (The Simpliest Thing That Could Possibly Work). Introduo

7 eXtreme Programming Valores Baseada em 4 valores: Comunicao, Simplicidade, Feedback e Coragem. Comunicao: Principal valor da XP, grande parte das práticas esto baseadas nela. Se no for eficiente pode causar atrasos e problemas no projeto. Uma equipe deve ter meios de se comunicar de maneira rápida e eficiente com o cliente, com o gerente do projeto e com outros desenvolvedores envolvidos.

8 eXtreme Programming Valores Simplicidade: É muito difícil no olhar para frente, para os requisitos que precisam ser implementados amanh, na próxima semana e no próximo m s. Mas ficar compulsivamente pensando no futuro um dos problemas da curva do custo exponencial das mudanas. A XP aposta que melhor fazer algo simples e de desenvolvimento rápido hoje, e ter que gastar um pouco mais no futuro para remodelar um processo, do que implementar um grande projeto, que acabe tendo muitas funcionalidades que acabem nunca sendo necessárias.

9 eXtreme Programming Valores Feedback: O cliente deve receber o sistema o quanto antes, a fim de poder dar um feedback rápido, guiando assim o desenvolvedor do software. Quanto mais cedo o cliente colocar o sistema em produo, mais rápido podem ser feitos ajustes para que o mesmo fique de acordo com o que o cliente realmente quer. Coragem: É preciso coragem para mudar a maneira pela qual se desenvolve sistemas. Colocar um sistema em produo assim que ele tenha valor para o cliente, fazer apenas o que se precisa para o momento e adiar o processo de análise no nada facil.

10 eXtreme Programming A XP baseada em um conjunto de 12 práticas fundamentais, que podem ser aplicadas individualmente, mas que funcionam melhor em conjunto. Práticas 1. The Customer is Always Available 7. Simple Design 2. Planning Game 8. Refactoring 3. Collective Code Ownership 9. Pair Programming 4. Acceptance Tests 10. Small Releases 5. Test First Design 11.Coding Standards 6. Continuous Integration Hour Week

11 eXtreme Programming 1. The Customer is Always Available: O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iterao e definir prioridades. Na XP todas as decisões sobre o rumo do projeto devem ser tomadas pelo cliente. Ele deve priorizar as tarefas, ser responsável pelos testes de aceitao e orientar os desenvolvedores durante o processo de programao. Esse prática encontra alguma resist ncia por que as empresas acham muito caro destinar um funcionário para ficar acompanhando o processo. Como soluo ou pode-se nomear um membro da equipe para representar ou cliente, ou se fazer reuniões semanais. Práticas

12 eXtreme Programming 2. Planning Game: Os jogadores do jogo do planejamento so o cliente e os tcnicos. O objetivo: colocar em produo as funcionalidades de maior valor possível durante o decorrer do jogo. No planning game o software efetivamente planejado pela equipe de desenvolvimento e pela equipe do cliente. Nesta atividade, cada equipe tem o seu papel bem claro e definido: a equipe do cliente responsável por definir escopo e prioridades e a equipe de desenvolvimento por fornecer estimativas. Práticas

13 eXtreme Programming Práticas 2. Planning Game (continuao) Muitas vezes difícil manter as equipes focadas exclusivamente no seu papel. Por isto, cabe ao coach da equipe de desenvolvimento ficar alertando sobre possíveis desvios, evitando que os desenvolvedores escolham as tarefas e que o cliente faa estimativas de prazo de entrega. Para a realizao do Planning Game, o cliente já deve ter as User Stories definidas e baseado em conhecimentos anteriores os desenvolvedores devem fornecer estimativas para o desenvolvimento para cada Story.

14 eXtreme Programming Práticas 2. Planning Game (continuao) Se no for possível estimar uma Story, quer dizer que ela esta muito complexa e deve ser dividida em Stories menores, por outro lado, se esta for muito pequena, deve ser agregada a outras. Normalmente ela adequada quando pode ser desenvolvida em dois ou tr s dias. A relao entre as funcionalidades entregues e as solicitadas pelo cliente a cada iterao chamada de Velocity.

15 eXtreme Programming Práticas 2. Planning Game (continuao) De posse das User Stories e das estimativas feitas pela quipe de desenvolvimento, os clientes devem definir o escopo da próxima iterao, selecionando aquelas que ele deseja que sejam implementadas. Nas reuniões do Planning Game tambm so repassadas para o cliente as informaões sobre o andamento da release atual e informaões sobre eventuais atrasos.

16 eXtreme Programming Práticas 3. Collective Code Ownership: A equipe como um todo responsável por cada arquivo de código. No preciso pedir autorizao para alterar qualquer arquivo. O código deve ser de propriedade de todos e todos devem ter permisso para alterar o que for necessário para que seu trabalho possa ser desenvolvido. Todos so donos e responsáveis por todo o código. Para garantir o mínimo de problemas com esta tcnica, existem os testes automatizados e a Continuous Integration, que garante que as alteraões feitas vo ser anexadas rapidamente ao código principal, diminuindo muito a chance de duas duplas estarem trabalhando no mesmo código.

17 eXtreme Programming Práticas 4. Acceptance Tests: Os testes de aceitao so a melhor maneira pela qual o cliente pode fornecer feedback sobre o sistema. So eles que indicam para os desenvolvedores quando a story que eles esto desenvolvendo está pronta ou no. Os testes devem ser escritos pela equipe do cliente, fornecendo material para que os desenvolvedores do sistema possam avaliar o progresso da implementao, e ter certeza de que o que esto desenvolvendo está correto.

18 eXtreme Programming Práticas 4. Acceptance Tests: (continuao) Os testes devem ser escritos antes que inicie o desenvolvimento da Story, e devem ser automatizados para diminuir o tempo gasto com eles. Os testes sendo definidos pelo cliente, fazem com que o produto final fique mais de acordo com o que o cliente realmente precisa, uma vez que cada tarefa só vai será concluída depois de passar pelos testes que o próprio cliente definiu. Colocando a criao de testes como uma tarefa do cliente o obriga a participar de forma realmente efetiva do desenvolvimento do sistema e cria uma "cumplicidade" maior entre equipe de desenvolvimento e equipe do cliente.

19 eXtreme Programming Práticas 5. Test First Design: Define que qualquer mtodo de cada objeto que possa falhar deve ter um teste automatizado que garanta o seu funcionamento. Após os programadores receberem a Story a ser implementada, eles passam a escrever os testes unitários para ela. Os testes automatizados so fundamentais para a XP, uma vez que do suporte a outras tcnicas da metodologia, como o Refactoring e o Collective Code Ownership

20 eXtreme Programming 6. Continuous Integration: A tcnica de Continuous Integration diz que o código desenvolvido por cada par de desenvolvedores deve ser integrado ao código base constantemente. Geralmente os problemas de integrao ocorrem por haver muita diferena entre os códigos desenvolvidos, pois muito trabalho foi feito por cada membro da equipe entre cada integrao Com a integrao contínua, e os unit tests, estes problemas se reduzem bastante, pois cada vez que algum código integrado, todos os unit tests devem ser rodados, e se algum deles falhar, porque o código recm integrado foi o responsável por inserir este erro no sistema. Práticas

21 eXtreme Programming Práticas 7. Simple Design: Deve-se projetar apenas "a coisa mais simples que possa funcionar". Esta ento a aposta da XP, que no deve ser desenvolvido nada que no seja necessário para a iterao na qual se está trabalhando agora, "resistindo à tentao" de fazer uma rotina "mais completa". Este princípio conhecido na XP pela sigla YANGNI (you are not gonna need it), que diz que normalmente se acaba no precisando de todas as funcionalidades e flexibilidade que se coloca em um código que poderia ser implementado de forma simples.

22 eXtreme Programming Práticas 8. Refactoring: Deve-se reescrever o código, melhorando e simplificando o mesmo, sempre que for possível. Indícios de que um código precisa de refactoring so: código duplicado, mtodos de classes muito longos, mtodos cujos nomes no indicam claramente o que fazem e excesso de comentário no código. Com o refactoring se consegue Simple Design e os Testes automatizados do segurana ao processo, assim vemos como as práticas do XP se complementam.

23 eXtreme Programming Práticas 9. Pair Programming: Todo o código deve ser produzido por duas pessoas utilizando o mesmo computador. Enquanto um dos parceiros se preocupa com detalhes da implementao, ficando responsável pela digitao do código, o outro deve tentar ter uma viso mais ampla da rotina, revisando o código. Duas pessoas conseguem pensar em um número maior de testes automatizados, existe uma troca de experi ncias fazendo um nivelamento da equipe e garante que todos os membros da equipe já tenham trabalhado em todos os módulos dos sistema.

24 eXtreme Programming Práticas 10. Small Releases: Com pequenas releases possível existir um feedback constante do cliente, conseguindo dados para o Planning Game. Assim possível ajustar o desenvolvimento às necessidades que vo surgindo no decorrer do processo. Geralmente trabalha-se com releases mais curtas, já que quanto menor o tempo entre cada verso, mais facil fica corrigir eventuais problemas.

25 eXtreme Programming Práticas 11. Coding Standards: Para que todos possam ter acesso a qualquer parte do código e que as pessoas possam trabalhar em pares, importante que os desenvolvedores sigam um padro de desenvolvimento. O ideal que, com o passar do tempo, algum que olhe o código no saiba dizer por quem o mesmo foi escrito. Assim fica mais fácil conseguir um código simples, e muito mais ágil o processo no caso da necessidade de um Refactoring

26 eXtreme Programming Hour Week: Trabalhar por longos períodos contraproducente. Um programador cansado coloca mais erros no código e o tempo ganho em uma noite de hora extra muitas vezes perdido no dia seguinte, procurando por um bug dentro de uma rotina. O número 40 apenas uma sugesto, cada pessoa tem sua própria capacidade de trabalho, este tempo poderia ser de 35 ou 45 hora. Práticas

27 eXtreme Programming Variáveis Na Extreme Programming, so consideradas quatro variáveis que esto presentes no desenvolvimento de um projeto: custo, tempo, qualidade e escopo. Se o cliente decide, por exemplo, em ter um projeto com o menor custo, no menor prazo e com a qualidade máxima, a quarta variável, neste caso escopo, deve ser definida de acordo pela equipe de desenvolvimento, ficando neste exemplo bastante prejudicada.

28 eXtreme Programming Variáveis Custo: poucos recursos para um projeto podem trazer srios prejuízos para as demais variáveis, pois com um oramento muito apertado normalmente no se consegue contar com a equipe que se gostaria, e isto pode trazer problemas para a efetiva resoluo do problema do cliente. Tempo: um prazo maior para a entrega final do sistema aumenta a qualidade e o escopo do mesmo, dentro de um limite. Por outro lado, caso o prazo seja muito pequeno, prejudica-se o escopo da aplicao.

29 eXtreme Programming Variáveis Qualidade: Pode-se ter ganhos pequenos (dias ou semanas) se sacrificando a qualidade em alguns pontos do projeto, como por exemplo definindo-se um número menor de unit tests para uma classe. Contudo, mas este ganho tende a desaparecer na medida em que a baixa qualidade pode causar problemas que tomaro tempo para serem corrigidos. Escopo: um escopo menor pode melhorar a qualidade, pois se tem menos tarefas para serem desenvolvidas, e tambm reduz o prazo e o custo.

30 eXtreme Programming Variáveis As variáveis custo e tempo normalmente so deciso do cliente, pois dele a deciso sobre quando precisa do sistema implementado e qual o valor que está disposto a pagar por isto. A variável qualidade no deve ser sacrificada. Portanto, normalmente a variável sobre a qual a equipe de desenvolvimento acaba tendo o controle sobre o escopo.

31 eXtreme Programming Mtricas O Release Plan o plano de desenvolvimento gerado a partir das sessões de planning game. Neste plano esto definidas quais as stories faro parte de cada iterao dentro da release, qual o desenvolvedor responsável por cada story e a estimativa de prazo. Um termo importante dentro do planejamento de projetos XP velocity. A velocity a relao entre funcionalidades entregues e as funcionalidades planejadas por cada desenvolvedor e deve ser medida a cada iterao.

32 eXtreme Programming Mtricas Toda metodologia de desenvolvimento deve fornecer ao seu gerente condiões para avaliar o andamento do projeto, atravs de mediões de qualidade (tanto do produto quanto do processo de desenvolvimento) e prazos. Estas mediões so conhecidas no desenvolvimento de sistemas como mtricas. As mtricas mais importantes na XP so: Velocity: Número de funcionalidades entregues comparado ao número de funcionalidades prometidas. 40 Hour Week: Quantidade de horas trabalhadas por semana por desenvolvedor.

33 eXtreme Programming Mtricas Test Coverage of the Code: Quantidade de Unit Tests por classe, tambm uma mtrica de qualidade interna de trabalho, pois serve para medir o quo testado está um sistema. Acceptance Test Coverage: Quantidade de testes de aceitao do projeto como um todo. Acceptance Test Pass: Percentual de testes de aceitao aprovados para cada iterao enviada, em relao ao total de testes de aceitao da mesma. Relative Bug Density: Quantidade de erros encontrados pelo usuário para cada classe multiplicado pelo tempo que cada um levou para ser corrigido.

34 eXtreme Programming Mtricas Estas mtricas so possíveis graas ao caráter dinâmico da XP, onde o cliente pode fornecer feedback sobre o desenvolvimento durante o mesmo, e no apenas após ter o produto final em suas mos. Por este aspecto, e tambm por suas características de ser fortemente baseado em testes, tanto unitários quanto de aceitao, que a ger ncia de projetos em XP difere tanto da ger ncia tradicional.

35 eXtreme Programming Casos bem sucedidos Algumas empresas que utilizam eXtreme Programming:

36 eXtreme Programming Casos bem sucedidos

37 eXtreme Programming Casos bem sucedidos

38 eXtreme Programming Casos bem sucedidos

39 eXtreme Programming Programas que utilizam Iterate: uma ferramenta comercial desenvolvida pela empresa Diamond Sky e foca exclusivamente no controle das user stories e no planning game.

40 eXtreme Programming Programas que utilizam XpPlanit: uma ferramenta comercial on-line para gerenciamento de projetos XP, tambm baseada no planejamento de iteraões e na medio constante da velocity, com a característica de ter um repositório central de projetos que possam ser acessados pelos membros da equipe pela Web.

41 Programas que utilizam eXtreme Programming VersionOne: desenvolvido pela empresa VersionOne, mais uma ferramenta comercial de controle de iteraões baseada em user stories, que, a exemplo das anteriores, tambm gera estatísticas sobre a medio da velocity da equipe.

42 Programas que utilizam eXtreme Programming Select Scope Manager: uma ferramenta comercial, bastante completa, que permite o controle de iteraões e releases, e tem como diferencial em relao às ferramentas anteriores a possibilidade de exportar dados para o MS-project.

43 Programas que utilizam eXtreme Programming XP Tracker Plugin: O XP Tracker Plugin um plugin para a interface wik i, utilizada no desenvolvimento de páginas web colaborativas. Na verdade no uma ferramenta, mas sim uma espcie de linguagem de script para a interface citada acima, que possibilita o controle de stories e a medio da velocity.

44 eXtreme Programming Conclusões Como relao às metodologias tradicionais, consideradas muito pesadas para equipes pequenas, um novo grupo de metodologias surgiu nos últimos anos. Elas so chamadas de metodologias ágeis, entre as quais a XP se enquadra, e propõem uma diminuio na burocracia do desenvolvimento de software. Em um encontro em Utah, nos Estados Unidos, em fevereiro de 2001, os principais autores das ento chamadas metodologias leves se encontraram para discutir as semelhanas entre suas metodologias, e descobriram que elas t m muito em comum. Nesta ocasio foi criado o termo metodologias ágeis, e foi escrito o "manifesto ágil", que descreve as quatro principais diferenas entre as metodologias ágeis e as metodologias tradicionais:

45 eXtreme Programming 1) Indivíduos e iteraões ao invs de processos e ferramentas. 2) Software em funcionamento ao invs de documentao compreensível. 3) Colaborao do cliente ao invs de negociao de contrato. 4) Responder às mudanas ao invs de seguir o plano. Conclusões

46 eXtreme Programming Sendo as duas principais diferenas entre as metodologias ágeis e as tradicionais: 1) Elas so adaptativas, ao invs de previsivas: as metodologias tradicionais tentam planejar uma grande parte do software em muitos detalhes com bastante anteced ncia. Por isto elas so resistentes à mudana. Já nas metodologias ágeis, as mudanas de requisitos durante o desenvolvimento so bem-vindas. Elas tendem a ajustar o desenvolvimento do software às mudanas de requisitos, sendo mais flexíveis neste ponto. 2) Elas so orientadas às pessoas, no aos processos: a meta das metodologias de desenvolvimento desenvolver um processo que vai funcionar da mesma maneira, independente de quem o esteja utilizando. Metodologias ágeis levam mais em conta a habilidade da equipe de desenvolvimento, e tendem por isto a se ajustar à equipe.

47 Conclusões eXtreme Programming As metodologias ágeis so hoje uma realidade, uma vez que esto ficando cada vez mais populares entre os desenvolvedores. Estas metodologias t m em comum um foco maior na comunicao e na codificao, ao invs de focar no processo, como as metodologias tradicionais. Uma destas metodologias a Extreme Programming, baseada em um conjunto de tcnicas e valores rígidos, que devem ser observados durante todo o ciclo de vida do desenvolvimento. A XP, por seu caráter informal, gera pouca documentao e prega que qualquer tcnica de ger ncia de projetos que for empregada deve ser o menos burocrática possível, pois o foco da equipe de desenvolvimento deve se a produo do software.

48 eXtreme Programming Conclusões A ger ncia de projetos XP, ento, deve ser o mais "leve" possível, no gerando documentao desnecessária e no pertinente ao desenvolvimento. Para tanto, as tcnicas de ger ncia de projetos aplicadas a esta metodologia devem seguir as características da mesma, como o uso de user stories, o planejamento de releases e o acompanhamento das tarefas dos desenvolvedores. Por outro lado, necessário aos administradores do negócio um acompanhamento da rentabilidade dos projetos, característica que no pertinente à metodologia, mas que pode ser obtida pelos mesmos lanamentos efetuados para o tracking do projeto.

49 eXtreme Programming Conclusões Verificamos tambm que o eXtreme Programming uma metodologia bastante promissora, que pode ser bastante vantajosa se for bem utilizada. Encontramos uma grande dificuldade em definir vantagens e desvantagens na sua utilizao, já que este assunto muito subjetivo. Algumas consequencias da implementao do eXtreme Programming como a diminuio da documentao e a necessidade de mais pessoas nas equipes, podem ser vistas como vantagens para algumas pessoas e como desvantagens para outras, ento tentamos nos manter objetivos, e apenas explicar as consequencias da sua utilizao, e deixar o leitor decidir por si próprio se considera cada consquencia uma vantagem ou uma desvantagem.

50 eXtreme Programming Bibliografia eXtreme Programming Refactored - The case against XP Matt Stephens. eXtreme Programming for Web Projects Doug Wallace. IsobelRagget. eXtreme Programming Applied - Playing to Win Travis Griggs. eXtreme Programming Explained Kent Beck. Questioning eXtreme Programming Pete McBreen. Extreme Programming Vinicius Teles.


Carregar ppt "Trabalho de Fundamentos da Engenharia de Software eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima Escalfoni 100134931."

Apresentações semelhantes


Anúncios Google