Qualidade de Software | eXtreme Programing

Slides utilizados em aula na disciplina Qualidade de Software do Instituto de Ciências Exatas e Informática - Sistemas de Informação. Pontifícia Universidade Católica de Minas Gerais - Unidade Barreiro, 1º Semestre 2015.

1. Qualidade de Software Pontifícia Universidade Católica de Minas Gerais Unidade Barreiro — 1º Semestre 2015 Prof. Eduardo Miranda emiranda.puc@gmail.com
2. Modelo Incremental
4. Modelo Incremental No desenvolvimento incremental, você adicionar um pedaço da imagem completa a cada iteração. A imagem está pronta quando todas as iterações forem realizadas.
5. No desenvolvimento incremental, você adicionar um pedaço da imagem completa a cada iteração. A imagem está pronta quando todas as iterações forem realizadas. Modelo Incremental
6. No desenvolvimento incremental, você adicionar um pedaço da imagem completa a cada iteração. A imagem está pronta quando todas as iterações forem realizadas. Modelo Incremental
7. No desenvolvimento incremental, você adicionar um pedaço da imagem completa a cada iteração. A imagem está pronta quando todas as iterações forem realizadas. Modelo Incremental
8. No desenvolvimento incremental, você adicionar um pedaço da imagem completa a cada iteração. A imagem está pronta quando todas as iterações forem realizadas. Modelo Incremental
9. Modelo Iterativo
10. Modelo Iterativo No desenvolvimento iterativo, você entrega um quadro e então decide se você gostaria de continuar melhorando-o ou não.
11. Modelo Iterativo No desenvolvimento iterativo, você entrega um quadro e então decide se você gostaria de continuar melhorando-o ou não.
12. Modelo Iterativo No desenvolvimento iterativo, você entrega um quadro e então decide se você gostaria de continuar melhorando-o ou não.
13. Modelo Iterativo No desenvolvimento iterativo, você entrega um quadro e então decide se você gostaria de continuar melhorando-o ou não.
14. Modelo Iterativo No desenvolvimento iterativo, você entrega um quadro e então decide se você gostaria de continuar melhorando-o ou não.
15. EXTREME PROGRAMING
16. • É uma metedologia ágil centrada no desenvolvimento de software. • Enquanto o Scrum foca na priorização e feedback do trabalho de desenvolvimento no nível de gerenciamento de projetos, o XP foca nas melhores práticas de desenvolvimento de software. eXtreme Programing
17. O XP tem 5 core values 1. Simplicidade; 2. Comunicação; 3. Feedback; 4. Coragem; 5. Respeito. eXtreme Programing
18. Simplicidade Reduza complexidade, funcionalidades, escopo extra e perdas. Encontre o jeito mais fácil de fazer o trabalho.
19. simplicidade The Standish Group Study reported at XP2002 by Jim Johnson, Chairman. Gráfico de utilização das funcionalidades em um sistema de acordo com o estudo do Standish Group.
20. simplicidade The Standish Group Study reported at XP2002 by Jim Johnson, Chairman. Gráfico de utilização das funcionalidades em um sistema de acordo com o estudo do Standish Group.
21. Comunicação Tenha certeza de que o profissional sabe exatamente o que é esperado dele e saiba em que os outros membros do time estão trabalhando.
22. Feedback Tenha retorno o mais rápido possível, de preferência para que ainda haja tempo de corrigir ou incrementar uma entrega antes do release. Falhe rápido!
23. lei de Barry Boehm (1981)
24. a curva de Kent Beck Beck, K (1999) Extreme Programming Explained: Embrace Change, “Figure 3. The cost of change may not rise dramatically over time” (Addison Wesley 1st Ed. P 23)
25. custo mais realista para o desenvolvimento ágil
26. Coragem É preciso coragem para deixar seu trabalho 100% visível a todos. Na programação em par, os times sabem o que cada um fez e tem a liberdade e autonomia para corrigir e melhorar sempre.
27. Respeito Respeito é essencial para o sucesso de um projeto com XP, já que todos trabalham juntos e são responsáveis pelo sucesso ou fracasso do projeto.
28. modelo do XP Spike arquitetural Planejamento do release Iteração Teste de aceitação Pequenos releases Spike User Stories Próxima iteração Nova user story Velocidade do projeto bugs Cenários de teste Plano do release Última Versão Aprovação do cliente Estimativas incertas Estimativas confiantes
29. • No XP os requisitos são representados por , que são utilizadas no planejamento de releases e iterações; • As iterações tem normalmente 2 semanas de duração e os desenvolvedores trabalham em par durante as iterações; eXtreme Programing
30. • O software (produto) é submetido a testes rigorosos e frequentes; • Com a aprovação on-site do cliente, o software é entregue em pequenas partes, ao final de cada iteração. eXtreme Programing
31. As tem como propósito responder a três perguntas sobre um requisito: 1. Quem?; 2. O quê?; 3. Por quê? user stories
32. As possuem um formato padrão: user stories Como <papel>, eu gostaria de <desejo>, de modo que <benefício> As a <role>, I want <goal/desire> so that <benefit> De maneira a <receber o benefício> como <papel>, eu gostaria <benefício> In order to <receive benefit> as a <role>, I want <goal/desire> Proposta de um time da Connextra Proposta de Chris Matts
33. user stories Como comprador, eu gostaria de receber uma nota fiscal da compra no meu email, de modo que eu possa comprovar a compra. Como leitor, eu gostaria de poder marcar a página que parei de ler meu e-book, de modo que eu possa retornar do mesmo lugar quando voltar a ler. De maneira a apresentar melhor a matéria como professor, eu gostaria de poder exibir conteúdo áudio visual durante a aula.
34. são histórias utilizadas como forma de reduzir risco para a implementação de um requisito. • Pesquisa de um novo framework ou tecnologia; • Criação de protótipos que irão definir melhor os requisitos.
35. Os podem ser utilizados de duas formas: • Técnico: analisa uma determinada tecnologia ou arquitetura a ser implementada em uma determinada • Funcional: sempre utilizado quando há dúvidas em como o usuário irá interagir com o sistema, do ponto de vista de usabilidade e comportamento.
36. História: Como consumidor, eu gostaria de ver diariamente meu consumo de energia, para que eu possa avaliar o meu consumo do passado, presente e projetado. técnico: Pesquisar quanto leva para obter os dados de consumo de energia, quais são os possíveis canais de comunicação e banda necessária. funcional: Criar um protótipo de um histograma simulando um histórico de consumo e obter um feedback do usuário sobre usabilidade História complexa Funcional Técnico
37. práticas XP
38. práticas XP • Warm rooms;
39. • Warm rooms; práticas XP
40. práticas XP • Warm rooms; • O time inclui um cliente que representa o negócio; • O time é multi-disciplinar; • Um coach para assegurar as práticas e processos; • Um gestor para facilitar a comunicação externa; • Especialistas generalistas; ◦ Otimização dos recursos (pessoas).
41. Release planning : • Entrega em ambiente de produção; • Acontecem uma ou duas vezes por ano. Iteration planning : • Planejamento das iterações ( No Scrum → sprint); • Quebra de histórias em tarefas e estima-se o trabalho; • Comprometimento do time com a entrega.
42. práticas XP • Pequenas entregas são realizadas a todo momento; • O código é constantemente disponibilizado para testes; • A qualidade é garantida com testes rigorosos e constantes; ◦ Continuous integration.
43. práticas XP • O cliente define os critérios de aceitação; • Testes automatizados; • O cliente cria testes que comprovam uma determinada funcionalidade em execução: Exemplo: ◦ Após realizar uma compra, acesso minha caixa de entrada de emails e devo ter recebido uma mensagem com a nota fiscal eletrônica.
44. práticas XP • Todos são donos de tudo. Qualquer dupla pode avaliar e melhorar qualquer parte do código; • Aumenta a visibilidade e o conhecimento de todo o time sobre o código; • Aumenta a qualidade do código; • Minimiza o risco na saida de membros do time.
45. • Mesmo padrão de codificação; • Objetivo é parecer que o código foi escrito por uma única pessoa.
46. • O maior ritmo de produtividade é alcançado quando o time possui um ritmo sustentável; • Horas extras podem eventualmente ser necessárias, mas no XP é claro que longas horas de trabalho são improdutivas e devem ser evitadas.
47. Metáforas são utilizadas como uma forma simples de definir os requisitos. Exemplo: • A cada jogada o usuário pode ganhar ou perder pontos, criando um extrato parecido com uma conta corrente bancária.
48. práticas XP • É o ato de reunir e compilar todo o código (normalmente diariamente) para assegurar que ele compila. • Expõe problemas de maneira antecipada antes que mais código seja desenvolvido sob um código já falho.
49. práticas XP
50. práticas XP
51. práticas XP • O código é escrito em pares, duas pessoas escrevem o mesmo código simultaneamente. • Pode parecer improdutivo, mas o XP garante que que a produtividade aumenta uma vez que os defeitos são reduzidos e a comunicação entre os membros do time aumenta;
52. práticas XP • Testes são uma parte crítica do XP; • Os testes são escritos antes da codificação da funcionalidade; ◦ Na primeira vez que for executado o teste tem que falhar já que a funcionalidade ainda não foi implementada. O objetivo é fazer com que o teste tenha sucesso.
53. • Melhorar a qualidade de uma funcionalidade, sem mudança no comportamento externo dela. • Reduzir código duplicado, aumentar a coesão ou melhorar a performance.
54. Resumidamente é responder a pergunta: "Qual a maneira mais simples de resolver este problema?"