Trabalho de Fundamentos da Engenharia de Software

1. Trabalho de Fundamentos da Engenharia de Software 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 eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima Escalfoni 100134931 Rafael de S. Tenório Cavalcanti 104120277

2. Introdu₤₧o 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 m₫dio porte de desenvolvimento de software, que precisam lidar com problemas que estejam em mudan₤as constantes, principalmente causados pela dificuldade do levantamento de requisitos iniciais.

3. Introdu₤₧o eXtreme Programming Nos modelos tradicionais o custo de mudan₤as ₫ alto. (tem que fazer ajustes na fase inicial do projeto) A eXtreme Programming já trabalha pensando que mudan₤as ir₧o ocorrer, o que diminui o custo para uma altera₤₧o.

4. Introdu₤₧o eXtreme Programming Recomendada para equipes de 2 à 12 membros, devido a necessidade de comunica₤₧o e simplicidade. Para implementar em grandes empresas, basta fazer uma divis₧o em várias equipes. A eXtreme Programming ₫ baseada em quatro valores: Comunica₤₧o, Simplicidade, Feedback e Coragem, que s₧o responsáveis pela melhoria do custo de uma altera₤₧o de requisitos durante o ciclo de vida do projeto.

5. Introdu₤₧o eXtreme Programming A eXtreme Programming se baseia em uma s₫ria de práticas, que podem ser utilizadas individualmente, mas que obt₫m melhores resultados quando utilizadas em conjunto. Muitas práticas da eXtreme Programming s₧o apenas de bom senso e as pessaos já as utilizam mesmo sem saber. O nome “eXtreme Programming” vem da aplica₤₧o dessas praticas a níveis extremos.

6. Introdu₤₧o eXtreme Programming Se ₫ bom fazer revis₧o de código, ent₧o o código será sempre revisado (Pair Programming). Se ₫ bom fazer testes, todos v₧o testar o código o tempo todo (Unit Testing), at₫ mesmo o cliente (Functional Testing). Se fazer projetos ₫ bom, ent₧o 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).

7. Valores eXtreme Programming Baseada em 4 valores: Comunica₤₧o, Simplicidade, Feedback e Coragem. Comunica₤₧o: Principal valor da XP, grande parte das práticas est₧o baseadas nela. Se n₧o 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. Valores eXtreme Programming Simplicidade: É muito difícil n₧o 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 mudan₤as. 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. Valores eXtreme Programming 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 produ₤₧o, 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 produ₤₧o assim que ele tenha valor para o cliente, fazer apenas o que se precisa para o momento e adiar o processo de análise n₧o ₫ nada facil.

10. Práticas eXtreme Programming A XP ₫ baseada em um conjunto de 12 práticas fundamentais, que podem ser aplicadas individualmente, mas que funcionam melhor em conjunto. 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 12. 40 Hour Week

11. Práticas eXtreme Programming 1. The Customer is Always Available: O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma itera₤₧o 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 aceita₤₧o e orientar os desenvolvedores durante o processo de programa₤₧o. Esse prática encontra alguma resist₨ncia por que as empresas acham muito caro destinar um funcionário para ficar acompanhando o processo. Como solu₤₧o ou pode-se nomear um membro da equipe para representar ou cliente, ou se fazer reuniões semanais.

12. Práticas eXtreme Programming 2. Planning Game: Os jogadores do jogo do planejamento s₧o o cliente e os t₫cnicos. O objetivo: colocar em produ₤₧o 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.

13. Práticas eXtreme Programming 2. Planning Game (continua₤₧o) 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 fa₤a estimativas de prazo de entrega. Para a realiza₤₧o 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. Práticas eXtreme Programming 2. Planning Game (continua₤₧o) Se n₧o 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 rela₤₧o entre as funcionalidades entregues e as solicitadas pelo cliente a cada itera₤₧o ₫ chamada de Velocity.

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

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

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

18. Práticas eXtreme Programming 4. Acceptance Tests: (continua₤₧o) 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 cria₤₧o 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. Práticas eXtreme Programming 5. Test First Design: Define que qualquer m₫todo 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 s₧o fundamentais para a XP, uma vez que d₧o suporte a outras t₫cnicas da metodologia, como o Refactoring e o Collective Code Ownership

20. Práticas eXtreme Programming 6. Continuous Integration: A t₫cnica 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 integra₤₧o ocorrem por haver muita diferen₤a entre os códigos desenvolvidos, pois muito trabalho foi feito por cada membro da equipe entre cada integra₤₧o Com a integra₤₧o 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 rec₫m integrado foi o responsável por inserir este erro no sistema.

21. Práticas eXtreme Programming 7. Simple Design: Deve-se projetar apenas "a coisa mais simples que possa funcionar". Esta ent₧o ₫ a aposta da XP, que n₧o deve ser desenvolvido nada que n₧o seja necessário para a itera₤₧o na qual se está trabalhando agora, "resistindo à tenta₤₧o" 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 n₧o precisando de todas as funcionalidades e flexibilidade que se coloca em um código que poderia ser implementado de forma simples.

22. Práticas eXtreme Programming 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 s₧o: código duplicado, m₫todos de classes muito longos, m₫todos cujos nomes n₧o indicam claramente o que fazem e excesso de comentário no código. Com o refactoring se consegue Simple Design e os Testes automatizados d₧o seguran₤a ao processo, assim vemos como as práticas do XP se complementam.

23. Práticas eXtreme Programming 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 implementa₤₧o, ficando responsável pela digita₤₧o do código, o outro deve tentar ter uma vis₧o 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. Práticas eXtreme Programming 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 v₧o surgindo no decorrer do processo. Geralmente trabalha-se com releases mais curtas, já que quanto menor o tempo entre cada vers₧o, mais facil fica corrigir eventuais problemas.

25. Práticas eXtreme Programming 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 padr₧o de desenvolvimento. O ideal ₫ que, com o passar do tempo, algu₫m que olhe o código n₧o 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. Práticas eXtreme Programming 12. 40 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 sugest₧o, cada pessoa tem sua própria capacidade de trabalho, este tempo poderia ser de 35 ou 45 hora.

27. Variáveis eXtreme Programming Na Extreme Programming, s₧o consideradas quatro variáveis que est₧o 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. Variáveis eXtreme Programming Custo: poucos recursos para um projeto podem trazer s₫rios prejuízos para as demais variáveis, pois com um or₤amento muito apertado normalmente n₧o se consegue contar com a equipe que se gostaria, e isto pode trazer problemas para a efetiva resolu₤₧o 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 aplica₤₧o.

29. Variáveis eXtreme Programming 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 tomar₧o tempo para serem corrigidos. Escopo: um escopo menor pode melhorar a qualidade, pois se tem menos tarefas para serem desenvolvidas, e tamb₫m reduz o prazo e o custo.

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

31. M₫tricas eXtreme Programming O Release Plan ₫ o plano de desenvolvimento gerado a partir das sessões de planning game. Neste plano est₧o definidas quais as stories far₧o parte de cada itera₤₧o 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 rela₤₧o entre funcionalidades entregues e as funcionalidades planejadas por cada desenvolvedor e deve ser medida a cada itera₤₧o.

32. M₫tricas eXtreme Programming Toda metodologia de desenvolvimento deve fornecer ao seu gerente condi₤ões para avaliar o andamento do projeto, atrav₫s de medi₤ões de qualidade (tanto do produto quanto do processo de desenvolvimento) e prazos. Estas medi₤ões s₧o conhecidas no desenvolvimento de sistemas como m₫tricas. As m₫tricas mais importantes na XP s₧o: 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. M₫tricas eXtreme Programming Test Coverage of the Code: Quantidade de Unit Tests por classe, tamb₫m ₫ uma m₫trica de qualidade interna de trabalho, pois serve para medir o qu₧o testado está um sistema. Acceptance Test Coverage: Quantidade de testes de aceita₤₧o do projeto como um todo. Acceptance Test Pass: Percentual de testes de aceita₤₧o aprovados para cada itera₤₧o enviada, em rela₤₧o ao total de testes de aceita₤₧o 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. M₫tricas eXtreme Programming Estas m₫tricas s₧o possíveis gra₤as ao caráter dinâmico da XP, onde o cliente pode fornecer feedback sobre o desenvolvimento durante o mesmo, e n₧o apenas após ter o produto final em suas m₧os. Por este aspecto, e tamb₫m por suas características de ser fortemente baseado em testes, tanto unitários quanto de aceita₤₧o, que a ger₨ncia de projetos em XP difere tanto da ger₨ncia tradicional.

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

36. Casos bem sucedidos eXtreme Programming

37. Casos bem sucedidos eXtreme Programming

38. Casos bem sucedidos eXtreme Programming

39. Programas que utilizam eXtreme Programming Iterate: ₫ uma ferramenta comercial desenvolvida pela empresa Diamond Sky e foca exclusivamente no controle das user stories e no planning game. http://www.diamond-sky.com/products/iterate

40. Programas que utilizam eXtreme Programming XpPlanit: ₫ uma ferramenta comercial on-line para gerenciamento de projetos XP, tamb₫m baseada no planejamento de itera₤ões e na medi₤₧o 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. http://www.xpplanit.com/

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, tamb₫m gera estatísticas sobre a medi₤₧o da velocity da equipe. http://www.versionone.net/

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 rela₤₧o às ferramentas anteriores a possibilidade de exportar dados para o MS-project. http://www.selectbs.com/products/scope.htm

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 n₧o ₫ uma ferramenta, mas sim uma esp₫cie de linguagem de script para a interface citada acima, que possibilita o controle de stories e a medi₤₧o da velocity. http://twiki.org/cgi-bin/view/Plugins/XpTrackerPlugin

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

45. Conclusões eXtreme Programming 1) Indivíduos e itera₤ões ao inv₫s de processos e ferramentas. 2) Software em funcionamento ao inv₫s de documenta₤₧o compreensível. 3) Colabora₤₧o do cliente ao inv₫s de negocia₤₧o de contrato. 4) Responder às mudan₤as ao inv₫s de seguir o plano.

46. Conclusões eXtreme Programming Sendo as duas principais diferen₤as entre as metodologias ágeis e as tradicionais: 1) Elas s₧o adaptativas, ao inv₫s de previsivas: as metodologias tradicionais tentam planejar uma grande parte do software em muitos detalhes com bastante anteced₨ncia. Por isto elas s₧o resistentes à mudan₤a. Já nas metodologias ágeis, as mudan₤as de requisitos durante o desenvolvimento s₧o bem-vindas. Elas tendem a ajustar o desenvolvimento do software às mudan₤as de requisitos, sendo mais flexíveis neste ponto. 2) Elas s₧o orientadas às pessoas, n₧o 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 s₧o hoje uma realidade, uma vez que est₧o ficando cada vez mais populares entre os desenvolvedores. Estas metodologias t₨m em comum um foco maior na comunica₤₧o e na codifica₤₧o, ao inv₫s de focar no processo, como as metodologias tradicionais. Uma destas metodologias ₫ a Extreme Programming, baseada em um conjunto de t₫cnicas 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 documenta₤₧o e prega que qualquer t₫cnica 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 produ₤₧o do software.

48. Conclusões eXtreme Programming A ger₨ncia de projetos XP, ent₧o, deve ser o mais "leve" possível, n₧o gerando documenta₤₧o desnecessária e n₧o pertinente ao desenvolvimento. Para tanto, as t₫cnicas 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 n₧o ₫ pertinente à metodologia, mas que pode ser obtida pelos mesmos lan₤amentos efetuados para o tracking do projeto.

49. Conclusões eXtreme Programming Verificamos tamb₫m 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 utiliza₤₧o, já que este assunto ₫ muito subjetivo. Algumas consequencias da implementa₤₧o do eXtreme Programming como a diminui₤₧o da documenta₤₧o e a necessidade de mais pessoas nas equipes, podem ser vistas como vantagens para algumas pessoas e como desvantagens para outras, ent₧o tentamos nos manter objetivos, e apenas explicar as consequencias da sua utiliza₤₧o, e deixar o leitor decidir por si próprio se considera cada consquencia uma vantagem ou uma desvantagem.

50. Bibliografia eXtreme Programming eXtreme Programming Refactored - The case against XP Matt Stephens. eXtreme Programming for Web ProjectsDoug Wallace. IsobelRagget. eXtreme Programming Applied - Playing to WinTravis Griggs. eXtreme Programming ExplainedKent Beck. Questioning eXtreme ProgrammingPete McBreen. Extreme Programming Vinicius Teles.