Revisitando as Práticas de Engenharia Ágil
•
13 j'aime•1,718 vues
Slides da minha palestra na QCon SP 2013: Agile virou mainstream: hoje em dia é difícil encontrar um time que não esteja seguindo um processo ágil. No entanto os processos mais comuns focam mais nas práticas gerenciais e não tanto nas práticas de engenharia. Na minha experiência com Métodos Ágeis, a falta de disciplina técnica é um dos principais impedimentos para criar equipes altamente produtivas. Nesta palestra eu pretendo revisitar as práticas de engenharia ágil, desde as originalmente propostas por XP há mais de dez anos atrás - como TDD, refatoração ou programação em par - até ideias mais recentes - como DevOps, infraestrutura como código e pipelines de deployment. Ao invés de focar no "O que?" de cada prática, pretendo tomar uma abordar mais profunda, focando no "Por quê?", nos comportamentos e nos resultados esperados de uma equipe que aplica as práticas com sucesso.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Revisitando as Práticas de Engenharia Ágil
Similaire à Revisitando as Práticas de Engenharia Ágil (20)
Plus de Danilo Sato
Plus de Danilo Sato (14)
Revisitando as Práticas de Engenharia Ágil
- 1. Revisitando as práticas de engenharia ágil Danilo Sato @dtsato
- 2. Danilo Sato @dtsato - www.dtsato.com Desenvolvedor, Arquiteto, Coach, DevOps, Treinador
- 4. Fonte: VersionOne State of Agile (2012) Referência: http://www.versionone.com/state-of-agile-survey-results/
- 5. Fonte: VersionOne State of Agile (2012) Referência: http://www.versionone.com/state-of-agile-survey-results/ Scrum + Kanban = 72% ~ 75%
- 6. Fonte: VersionOne State of Agile (2012) Referência: http://www.versionone.com/state-of-agile-survey-results/ Scrum + Kanban = 72% ~ 75% 4% “Não Sei” ?!
- 7. Fonte: VersionOne State of Agile (2012) Referência: http://www.versionone.com/state-of-agile-survey-results/ Scrum + Kanban = 72% ~ 75% XP = 2% ~ 7%
- 13. 3 pilares
- 15. Liderar e promover a excelência de software e revolucionar a indústria de TI Gerir um negócio sustentável
- 16. Liderar e promover a excelência de software e revolucionar a indústria de TI Advogar apaixonadamente em favor de justiça social e econômica Gerir um negócio sustentável
- 17. falta de práticas de engenharia é uma barreira
- 18. não atingimos o potencial de agile
- 21. por que falar de práticas?
- 28. práticas
- 29. práticas “O que você faz quando está sob pressão" -- Corey Haines
- 33. Programação Extrema (XP) Práticas de Engenharia
- 34. práticas
- 38. Entrega contínua colaboração testes automatizados design TDD testes automatizados originadas em XP
- 39. Entrega contínua colaboração testes automatizados design TDD testes automatizados design incremental refatoração metáfora linguagem ubíqua TDD originadas em XP
- 40. Entrega contínua colaboração testes automatizados design TDD testes automatizados design incremental refatoração metáfora linguagem ubíqua TDD propriedade coletiva de código standards de código programação pareada gerenciar dívida técnica desenvolvimento no trunk originadas em XP
- 41. Entrega contínua colaboração testes automatizados design TDD testes automatizados design incremental refatoração metáfora linguagem ubíqua TDD desenvolvimento no trunk integração contínua pipeline de implantação implantação automatizada infraestrutura como código propriedade coletiva de código standards de código programação pareada gerenciar dívida técnica desenvolvimento no trunk originadas em XP
- 44. Exploratório Ponta a Ponta Aplicação/ Componentes Integração Unitários cobertura por teste / tempo de execução feedback rápido
- 47. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes
- 48. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes • Testes funcionais seguem user journeys e não por história
- 49. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes • Testes funcionais seguem user journeys e não por história • Testes reproduzem bug no nível certo antes de corrigí-lo
- 50. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes • Testes funcionais seguem user journeys e não por história • Testes reproduzem bug no nível certo antes de corrigí-lo • Tempo necessário para realizar testes manuais reduzido
- 51. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes • Testes funcionais seguem user journeys e não por história • Testes reproduzem bug no nível certo antes de corrigí-lo • Tempo necessário para realizar testes manuais reduzido • Problemas são encontrados rapidamente, perto do momento onde são introduzidos
- 52. TDD
- 54. TDD • Comportamentos: • Testes atuam como documentação executável do código
- 55. TDD • Comportamentos: • Testes atuam como documentação executável do código • Bom design OO: comportamento bem encapsulado e clara dependência entre classes
- 56. TDD • Comportamentos: • Testes atuam como documentação executável do código • Bom design OO: comportamento bem encapsulado e clara dependência entre classes • Testes unitários executam rapidamente: 1000s em poucos segundos
- 57. TDD • Comportamentos: • Testes atuam como documentação executável do código • Bom design OO: comportamento bem encapsulado e clara dependência entre classes • Testes unitários executam rapidamente: 1000s em poucos segundos • Uso justo de mocks: mocks não duplicam comportamento do código
- 58. Design
- 59. Código==Design
- 61. BOM reduz o custo da mudança Design
- 62. Design
- 63. Hipótese da stamina do Design
- 67. Funcionalidades Tempo Bom Design Sem Design Onde o design se paga
- 69. Design “ativo”
- 70. Design “passivo”
- 71. Design ágil == Design evolutivo
- 72. Design ágil == Design evolutivo
- 73. Design Ágil
- 75. Design Ágil • Comportamentos: • Código é fácil de ser testado
- 76. Design Ágil • Comportamentos: • Código é fácil de ser testado • Quando mudanças são necessárias, refatoração acontece antes para que a mudança seja simples
- 77. Design Ágil • Comportamentos: • Código é fácil de ser testado • Quando mudanças são necessárias, refatoração acontece antes para que a mudança seja simples • Time reconhece a diferença entre complexidade essencial e acidental
- 78. Design Ágil • Comportamentos: • Código é fácil de ser testado • Quando mudanças são necessárias, refatoração acontece antes para que a mudança seja simples • Time reconhece a diferença entre complexidade essencial e acidental • Gerenciamento de dívida técnica para reduzir complexidade acidental
- 79. Refatoração
- 81. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE
- 82. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE • Refatoração acontece quando os testes estão passando
- 83. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE • Refatoração acontece quando os testes estão passando • Refatorações são pequenas e incrementais
- 84. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE • Refatoração acontece quando os testes estão passando • Refatorações são pequenas e incrementais • Código de teste também é refatorado
- 85. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE • Refatoração acontece quando os testes estão passando • Refatorações são pequenas e incrementais • Código de teste também é refatorado • Desenvolvedores sabem dividir refatorações grandes em pedaços menores
- 86. Linguagem Ubíqua • Metáfora: • Nem sempre é necessária • Difícil de encontrar • Domain-Driven Design • Objetivo é melhorar comunicação com especialistas de domínio
- 88. Linguagem Ubíqua
- 90. Linguagem Ubíqua • Comportamentos: • Código de produção e de testes usam terminologia uniforme, alinhada com o domínio
- 91. Linguagem Ubíqua • Comportamentos: • Código de produção e de testes usam terminologia uniforme, alinhada com o domínio • Conceitos em um domínio possuem sentido claro dentro de um Contexto Delimitado
- 92. Linguagem Ubíqua • Comportamentos: • Código de produção e de testes usam terminologia uniforme, alinhada com o domínio • Conceitos em um domínio possuem sentido claro dentro de um Contexto Delimitado • Conceitos são bem entendidos por toda a equipe (desenvolvedores, analistas, QAs, clientes, gerentes, etc.)
- 93. colaboração
- 96. Programação Pareada • Benefícios: • Foco • Revisão de código constante • Resultado é maior que a soma das partes
- 99. Programação Pareada • Comportamentos: • Ao parear, papéis de navegador e piloto rotacionam frequentemente
- 100. Programação Pareada • Comportamentos: • Ao parear, papéis de navegador e piloto rotacionam frequentemente • Ambos desenvolvedores trabalham na mesma máquina: 2 monitores, 2 mouses, 2 teclados
- 101. Programação Pareada • Comportamentos: • Ao parear, papéis de navegador e piloto rotacionam frequentemente • Ambos desenvolvedores trabalham na mesma máquina: 2 monitores, 2 mouses, 2 teclados • Pareamento entre papéis também acontece
- 102. Programação Pareada • Comportamentos: • Ao parear, papéis de navegador e piloto rotacionam frequentemente • Ambos desenvolvedores trabalham na mesma máquina: 2 monitores, 2 mouses, 2 teclados • Pareamento entre papéis também acontece • Pareamento oportunista: quando não faz sentido parear, não pareia
- 103. Standards de Código
- 104. Standards de Código • Comportamentos:
- 105. Standards de Código • Comportamentos: • Equipe segue estilo de código comum
- 106. Standards de Código • Comportamentos: • Equipe segue estilo de código comum • Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado
- 107. Standards de Código • Comportamentos: • Equipe segue estilo de código comum • Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado • “TODO”s são corrigidos constantemente
- 108. Standards de Código • Comportamentos: • Equipe segue estilo de código comum • Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado • “TODO”s são corrigidos constantemente • Padrões de estilo da equipe são mais importantes que estilo pessoal
- 109. Standards de Código • Comportamentos: • Equipe segue estilo de código comum • Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado • “TODO”s são corrigidos constantemente • Padrões de estilo da equipe são mais importantes que estilo pessoal • Código de teste também segue padrões de estilo
- 111. Propriedade Coletiva de Código • Comportamentos:
- 112. Propriedade Coletiva de Código • Comportamentos: • Não existe silos de conhecimento na equipe
- 113. Propriedade Coletiva de Código • Comportamentos: • Não existe silos de conhecimento na equipe • Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também
- 114. Propriedade Coletiva de Código • Comportamentos: • Não existe silos de conhecimento na equipe • Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também • Rotação de pares ajuda a disseminar conhecimento
- 115. Propriedade Coletiva de Código • Comportamentos: • Não existe silos de conhecimento na equipe • Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também • Rotação de pares ajuda a disseminar conhecimento • Desenvolvedores consertam o build independente de quem quebrou
- 116. Propriedade Coletiva de Código • Comportamentos: • Não existe silos de conhecimento na equipe • Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também • Rotação de pares ajuda a disseminar conhecimento • Desenvolvedores consertam o build independente de quem quebrou • Desenvolvedores procuram trabalhar em áreas diferentes para aprimorar conhecimento
- 117. entrega contínua
- 118. A “Última Milha” QA + integração QA centralizado release + operação IT operações cliente desenvolvimento análise + design teste + showcase iteração 0 1 2 3 4 Time “Ágil” AGILE 101
- 119. cliente time de entrega fluxo constante de entrega em produção ENTREGA CONTÍNUA
- 130. Servidor Central Desenvolve Build Build pull Máquina Local Build push ✔ Pronto! Todo mundo faz commit no trunk todos os dias
- 131. Integração Contínua
- 133. Integração Contínua • Comportamentos: • Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia
- 134. Integração Contínua • Comportamentos: • Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia • Build roda testes automatizados de diversos níveis
- 135. Integração Contínua • Comportamentos: • Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia • Build roda testes automatizados de diversos níveis • Os builds estão geralmente verdes
- 136. Integração Contínua • Comportamentos: • Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia • Build roda testes automatizados de diversos níveis • Os builds estão geralmente verdes • Desenvolvedores reagem quando o build quebra
- 137. Integração Contínua
- 139. Integração Contínua • Comportamentos: • Desenvolvedores trabalham para reduzir o tempo do build
- 140. Integração Contínua • Comportamentos: • Desenvolvedores trabalham para reduzir o tempo do build • Desenvolvedores sempre rodam testes antes de fazer commit para minimizar a chance de builds quebrados
- 141. Integração Contínua • Comportamentos: • Desenvolvedores trabalham para reduzir o tempo do build • Desenvolvedores sempre rodam testes antes de fazer commit para minimizar a chance de builds quebrados • Desenvolvedores não fazem commit quando o build está quebrado
- 145. Desenvolvimento no Trunk • Comportamentos:
- 146. Desenvolvimento no Trunk • Comportamentos: • Commits que quebram o build são rapidamente consertados ou revertidos
- 147. Desenvolvimento no Trunk • Comportamentos: • Commits que quebram o build são rapidamente consertados ou revertidos • Uso de branches é limitado: vida curta ou branch para releases
- 148. Desenvolvimento no Trunk • Comportamentos: • Commits que quebram o build são rapidamente consertados ou revertidos • Uso de branches é limitado: vida curta ou branch para releases • Desenvolvedores usam “branch por abstração” quando mudanças maiores são necessárias
- 149. Desenvolvimento no Trunk • Comportamentos: • Commits que quebram o build são rapidamente consertados ou revertidos • Uso de branches é limitado: vida curta ou branch para releases • Desenvolvedores usam “branch por abstração” quando mudanças maiores são necessárias • Qualquer commit pode ir para produção
- 151. ESFORÇO DOR
- 152. ESFORÇO DOR
- 154. Gerenciar Dívida Técnica • Comportamentos:
- 155. Gerenciar Dívida Técnica • Comportamentos: • Equipe cataloga e estima items relacionados à dívida técnica
- 156. Gerenciar Dívida Técnica • Comportamentos: • Equipe cataloga e estima items relacionados à dívida técnica • Equipe dedica uma porcentagem de tempo em cada iteração para atacar items de dívida técnica
- 157. Gerenciar Dívida Técnica • Comportamentos: • Equipe cataloga e estima items relacionados à dívida técnica • Equipe dedica uma porcentagem de tempo em cada iteração para atacar items de dívida técnica • Dívida relacionada à arquitetura é capturada e priorizada para permitir evolução a longo prazo
- 158. Gerenciar Dívida Técnica • Comportamentos: • Equipe cataloga e estima items relacionados à dívida técnica • Equipe dedica uma porcentagem de tempo em cada iteração para atacar items de dívida técnica • Dívida relacionada à arquitetura é capturada e priorizada para permitir evolução a longo prazo • Decisões sobre escopo levam dívida técnica em consideração
- 161. Implantação Automatizada • Comportamentos: • Equipe procura automatizar passos para deploy
- 162. Implantação Automatizada • Comportamentos: • Equipe procura automatizar passos para deploy • Script inclui não apenas deploy de código, mas também recursos dependentes: banco de dados, infraestrutura, filas, etc.
- 163. Implantação Automatizada • Comportamentos: • Equipe procura automatizar passos para deploy • Script inclui não apenas deploy de código, mas também recursos dependentes: banco de dados, infraestrutura, filas, etc. • É fácil subir ambientes parecidos com produção
- 166. Infraestrutura como Código • Comportamentos: • É fácil subir ambientes parecidos com produção
- 167. Infraestrutura como Código • Comportamentos: • É fácil subir ambientes parecidos com produção • Alterações de infraestrutura não precisam de tickets para equipes externas
- 168. Infraestrutura como Código • Comportamentos: • É fácil subir ambientes parecidos com produção • Alterações de infraestrutura não precisam de tickets para equipes externas • Código de infraestrutura é testado e parte da pipeline de entrega
- 169. Infraestrutura como Código • Comportamentos: • É fácil subir ambientes parecidos com produção • Alterações de infraestrutura não precisam de tickets para equipes externas • Código de infraestrutura é testado e parte da pipeline de entrega • Pouco uso de ambientes compartilhados
- 171. Pipeline de Implantação “...(a pipeline de implantação) é a manifestação automatizada do processo de levar o software do controle de versão para as mãos dos usuários" -- Jez Humble
- 173. Pipeline de Implantação Serviço B Serviço C App A Testes Unitário Controle de Versão Repositório de Artefatos Testes de Componente Testes Unitário Testes de Componente Testes Unitário Testes de Componente Testes de Contrato Testes de Contrato Deploy em Dev Smoke Deploy em Int Teste de Aplicação Smoke App E App F Serviço D Testes Unitário Testes de Componente Testes Unitário Testes de Componente Testes Unitário Testes de Componente Testes de Contrato Deploy em Dev Smoke Teste de Aplicação Testes de Contrato Deploy em Dev Smoke Deploy em Int Smoke Deploy em Int Teste Ponta- a-Ponta Ambiente de Dev Deploy em QA Smoke Testes de Performance UAT Ambiente de Integração Ambiente de QA Deploy em Production Smoke COTS Ambiente de Produção Deploy em Int (...) (…)
- 175. Pipeline de Implantação • Comportamentos:
- 176. Pipeline de Implantação • Comportamentos: • Mudanças em produção podem ser traçadas desde o commit original
- 177. Pipeline de Implantação • Comportamentos: • Mudanças em produção podem ser traçadas desde o commit original • Pipeline possui diversos estágios para diferentes níveis de teste
- 178. Pipeline de Implantação • Comportamentos: • Mudanças em produção podem ser traçadas desde o commit original • Pipeline possui diversos estágios para diferentes níveis de teste • Estágios são otimizados para maximizar feedback rápido
- 179. Pipeline de Implantação • Comportamentos: • Mudanças em produção podem ser traçadas desde o commit original • Pipeline possui diversos estágios para diferentes níveis de teste • Estágios são otimizados para maximizar feedback rápido • Código de infraestrutura integrado com código de produção na pipeline
- 180. Pipeline de Implantação • Comportamentos: • Mudanças em produção podem ser traçadas desde o commit original • Pipeline possui diversos estágios para diferentes níveis de teste • Estágios são otimizados para maximizar feedback rápido • Código de infraestrutura integrado com código de produção na pipeline • Inclusão de testes pré-release (desempenho, carga, stress, …)
- 181. Resumindo...
- 182. práticas de engenharia são essenciais para ser ágil
- 186. Entrega contínua colaboração testes automatizados design TDD testes automatizados design incremental refatoração metáfora linguagem ubíqua TDD desenvolvimento no trunk integração contínua pipeline de implantação implantação automatizada infraestrutura como código propriedade coletiva de código standards de código programação pareada gerenciar dívida técnica desenvolvimento no trunk
- 187. quais são as suas práticas?
- 188. Danilo Sato @dtsato - www.dtsato.com Desenvolvedor, Arquiteto, Coach, DevOps, Treinador Obrigado!