Práticas ágeis

Apresentação sobre sugestões de práticas ágeis a serem aplicadas ao Centro de Qualidade e Testes de Software.

Transcript

1. PRÁTICAS ÁGEIS
3. 1950 ­ Toyota Production System ­Taiichi Ohno 1986 ­ The New New Product Development Game – Takeuchi e Nonaka 1992 ­ Crystal Clear Method – Alistair Cockburn 1993 ­ Scrum ­ Jeff Shuterland, Ken Schwaber e Mike Beedle 1994 ­ Analysis Patterns, UML Distilled, Planning XP – Martin Fowler 1996 ­ XP ­ Kent Beck, Ward Cunningham e Ron Jeffries 1997 ­ DSDM (Dynamic Syst. Dev. Method) – Arie van Bennekum e outros 1997 ­ FDD ­ Feature­Driven Development – Jeff De Luca e Peter Coad 1997 ­ ASD ­ Adaptive SW Develop. – Jim Highsmith e Alistair Cockburn 1999 ­ The Pragmatic Programmer – Andrew Hunt e Dave Thomas HISTÓRIA
4. 1950 ­ Toyota Production System ­Taiichi Ohno 1986 ­ The New New Product Development Game – Takeuchi e Nonaka 1992 ­ Crystal Clear Method – Alistair Cockburn 1993 ­ Scrum ­ Jeff Shuterland, Ken Schwaber e Mike Beedle 1994 ­ Analysis Patterns, UML Distilled, Planning XP – Martin Fowler 1996 ­ XP ­ Kent Beck, Ward Cunningham e Ron Jeffries 1997 ­ DSDM (Dynamic Syst. Dev. Method) – Arie van Bennekum e outros 1997 ­ FDD ­ Feature­Driven Development – Jeff De Luca e Peter Coad 1997 ­ ASD ­ Adaptive SW Develop. – Jim Highsmith e Alistair Cockburn 1999 ­ The Pragmatic Programmer – Andrew Hunt e Dave Thomas EM 2001...
6. Estamos descobrindo maneiras melhores de desenvolver software, fazendo­o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
7. Indivíduos e interações mais que processos e ferramentas
8. Software em funcionamento mais que documentação abrangente
9. Colaboração com o cliente Mais que negociação de contratos
10. Mais que seguir um plano Responder a mudanças
11. AGILE MÉTODOS PRÁTICAS AUP XP SCRUM LEAN KANBAN TDD Pair Programming CI Refactoring Stand­ups
12. PRINCÍPIOS E PRÁTICAS Inception Elaboration Construction Transition Model Implementation Test Deployment Configuration Management Project Management Environment Active Stakeholder Participation Apply Modeling Standards Apply Patterns Gently Apply the Right Artifact(s) Collective Ownership Create Several Models in Parallel Create Simple Content Depict Models Simply Discard Temporary Models Display Models Publicly Formalize Contract Models Iterate to Another Artifact Model in Small Increments Model With Others Prove it With Code Reuse Existing Resources Single Source Information Update Only When it Hurts Use the Simplest Tools AUP XP Coding Standards Collective Ownership Continuous Integration On­Site Customer Pair Programming Planning Game Refactoring Short Releases Simple Design Sustainable Pace System Metaphor Test­Driven Development SCRUM Product owner Scrum master Team Product backlog Sprint backlog Sprint burn down Sprint planning Daily scrum Sprint reviews print retrospective LEAN Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole KANBAN Visualize workflow Limit Work in progress Measure flow
15. TDD 1. Escreva o teste. Leve em conta todos os possíveis inputs, outputs e erros; 2. Rode o teste, ele deve falhar; 3. Escreva as funcionalidades planejadas; 4. Quando o código passar nos testes, deve­se refatorar o que for possível; 5. Rode os testes novamente, os testes devem passar; 6. Volte ao passo 1.
16. TDD Um exemplo simples: CALCULADORA!
17. TDD Um exemplo simples: CALCULADORA! ADD: soma de dois números
18. TDD 1. Escrever os testes:
19. TDD 2. Ver os testes falharem:
20. TDD 3. Codificar a funcionalidade:
21. TDD 4. Rodar os testes novamente:
22. TDD 4. Refatorar: ­ E se alguém mandar strings como parâmetro?
23. TDD 1. Escrever os testes:
24. TDD 2. Ver os testes falharem:
25. TDD 3. Codificar as funcionalidades:
26. TDD 4. Rodar os testes novamente:
27. Por que é melhor? ­ Já sentiu que foi tempo perdido escrever testes após uma pequena mudança? ­ Ficou com preguiça de testart tudo novamente? ­ Você não teve tempo o suficiente porque a deadline estava próxima? ­ Você disse que faria os testes “amanhã”? ­ Você teve que escolher entre escrever os testes e assistir o último episódio de GoT?
28. KANBAN BOARD
29. KANBAN BOARD ­ Ajuda a organizar três pontos de vista: time, tarefas e tempo; ­ Todo o time entende o status atual do projeto; ­ Incentiva a proatividade; ­ Limita a quantidade de “work in progress” e evidencia os limites da equipe.
30. KANBAN BOARD TASK KANBAN BOARD
31. KANBAN BOARD TASK KANBAN BOARD
32. KANBAN BOARD FEATURE KANBAN BOARD
33. KANBAN BOARD SMILEY CALENDAR
35. STAND­UPS MEETINGS ­ Todos os dias os membros do time se encontram para reuniões que são feitas de pé; ­ Cada membro do time descreve brevemente as contribuições que foram feitas e os obstáculos que surgiram; ­ A reunião é geralmente feita em frente ao quadro de tarefas; ­ Tem duração máxima de 15 minutos; ­ Todos os pontos que podem gerar discussões são anotados para posterior análise.
36. STAND­UPS MEETINGS ­ As reuniões fazem com que as informações importantes sejam compartilhadas; ­ Contribui para a coesão do time; ­ São curtas e mais prazerosas do que reuniões regulares.
37. PAIR PROGRAMMING
38. PAIR PROGRAMMING ­ Aumenta a qualidade do código, programando “out and loud” ajuda a entender os detalhes das tarefas de codificação; ­ Transferência de conhecimento sobre o código entre os membros do time; ­ Transferência de conhecimento técnico entre os membros do time;
39. PAIR PROGRAMMING QUADRO DE PAREAMENTO
41. INTEGRAÇÃO CONTÍNUA
42. INTEGRAÇÃO CONTÍNUA Z
43. INTEGRAÇÃO CONTÍNUA ­ Builds quebradas são anunciadas a todo o time que concentra seus esforços no “conserto” da build; ­ Minimiza os esforços e a duração de cada integração; ­ É possível entregar uma release a qualquer momento.
45. Keep it Simple, Stupid Princípio de design adotado pela Marinha dos EUA em 1960 A maioria dos sistemas funciona melhor quando mantidos simples A simplicidade deve ser um princípio chave das atividades de design complexidade desnecessária deve ser evitada
46. DESIGN SIMPLES 1. Todos os testes passam; 2. Não contem duplicações (DRY); 3. Expressa as ideias por trás das funcionalidades; 4. Tem classes e métodos pequenos.
47. The Zen of Python
48. O Zen do Python, port Tim Peters ­ Bonito é melhor que feio. ­ Explícito é melhor que implícito. ­ Simples é melhor que complexo. ­ Complexo é melhor que complicado. ­ Linear é melhor do que aninhado. ­ Esparso é melhor que denso. ­ Legibilidade conta. ­ Casos especiais não são especiais o bastante para quebrar as regras. ­ Ainda que praticidade vença a pureza. ­ Erros nunca devem passar silenciosamente. ­ A menos que sejam explicitamente silenciados. ­ Diante da ambigüidade, recuse a tentação de adivinhar. ­ Deveria haver um — e preferencialmente só um — modo óbvio para fazer algo. ­ Embora esse modo possa não ser óbvio a princípio, a menos que você seja holandês. ­ Agora é melhor que nunca. ­ Embora nunca freqüentemente seja melhor que *já*. ­ Se a implementação é difícil de explicar, é uma má idéia. ­ Se a implementação é fácil de explicar, pode ser uma boa idéia. ­ Namespaces são uma grande idéia — vamos ter mais dessas!
49. PADRÕES DE CODIFICAÇÃO
50. PADRÕES DE CODIFICAÇÃO ­ Facilita os processos de desenvolvimento, retirada de bugs, atividades de validação e manutenção.; ­ Aumenta a produtividade num projeto, uma vez que a comunicação dentro da equipe de desenvolvimento fica mais fácil; ­ Facilita a manutenção de código legado.
51. PROPRIEDADE COLETIVA
52. PROPRIEDADE COLETIVA ­ Reduz os riscos da falta de um dos desenvolvedores do time; ­ Os módulos pertencem ao time, não a indivíduos; ­ Todos têm o direito de verificar ou modificar o código; ­ Todos os programadores estão familiarizados ao código; ­ Encoraja cada desenvolvedor a se sentir responsável pela qualidade geral.
53. OBRIGADA!