Revisitando as Práticas de Engenharia Ágil

1,322 views

Published on

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.

Published in: Technology

Revisitando as Práticas de Engenharia Ágil

  1. 1. Revisitando as práticas de engenharia ágil Danilo Sato @dtsato
  2. 2. Danilo Sato @dtsato - www.dtsato.com Desenvolvedor, Arquiteto, Coach, DevOps, Treinador
  3. 3. Agile virou mainstream
  4. 4. Fonte: VersionOne State of Agile (2012) Referência: http://www.versionone.com/state-of-agile-survey-results/
  5. 5. Fonte: VersionOne State of Agile (2012) Referência: http://www.versionone.com/state-of-agile-survey-results/ Scrum + Kanban = 72% ~ 75%
  6. 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. 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%
  8. 8. Práticas gerenciais práticas de engenharia
  9. 9. Práticas gerenciais práticas de engenharia
  10. 10. Práticas gerenciais práticas de engenharia
  11. 11. http://www.flickr.com/photos/donnieray/9436653177
  12. 12. 3 pilares
  13. 13. Gerir um negócio sustentável
  14. 14. Liderar e promover a excelência de software e revolucionar a indústria de TI Gerir um negócio sustentável
  15. 15. 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
  16. 16. falta de práticas de engenharia é uma barreira
  17. 17. não atingimos o potencial de agile
  18. 18. o potencial de agile
  19. 19. o potencial de agile Leak! Vazar!
  20. 20. por que falar de práticas?
  21. 21. http://www.dtsato.com/blog/2007/08/14/chega-de-processos/
  22. 22. princípios vs. práticas
  23. 23. princípios vs. práticas
  24. 24. princípios vs. práticas
  25. 25. Valores + Princípios
  26. 26. práticas
  27. 27. práticas “O que você faz quando está sob pressão" -- Corey Haines
  28. 28. Programação Extrema (XP)
  29. 29. Programação Extrema (XP) Práticas de Engenharia
  30. 30. práticas
  31. 31. • dependentes práticas
  32. 32. • dependentes • complementares práticas
  33. 33. Entrega contínua colaboração testes automatizados design originadas em XP
  34. 34. Entrega contínua colaboração testes automatizados design TDD testes automatizados originadas em XP
  35. 35. Entrega contínua colaboração testes automatizados design TDD testes automatizados design incremental refatoração metáfora linguagem ubíqua TDD originadas em XP
  36. 36. 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
  37. 37. 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
  38. 38. testes automatizados
  39. 39. http://www.flickr.com/photos/dancoulter/21042744
  40. 40. Exploratório Ponta a Ponta Aplicação/ Componentes Integração Unitários cobertura por teste / tempo de execução feedback rápido
  41. 41. Testes Automatizados
  42. 42. Testes Automatizados • Comportamentos:
  43. 43. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes
  44. 44. Testes Automatizados • Comportamentos: • O time possui uma clara estratégia de testes • Testes funcionais seguem user journeys e não por história
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. TDD
  49. 49. TDD • Comportamentos:
  50. 50. TDD • Comportamentos: • Testes atuam como documentação executável do código
  51. 51. TDD • Comportamentos: • Testes atuam como documentação executável do código • Bom design OO: comportamento bem encapsulado e clara dependência entre classes
  52. 52. 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
  53. 53. 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
  54. 54. Design
  55. 55. Código==Design
  56. 56. Código== Estrutura Organização Flexibilidade Testabilidade Legibilidade Coesão Acoplamento Dependências Design
  57. 57. BOM reduz o custo da mudança Design
  58. 58. Design
  59. 59. Hipótese da stamina do Design
  60. 60. Funcionalidades Tempo
  61. 61. Funcionalidades Tempo Sem Design
  62. 62. Funcionalidades Tempo Bom Design Sem Design
  63. 63. Funcionalidades Tempo Bom Design Sem Design Onde o design se paga
  64. 64. Zero Design Design Ágil Up-front Design
  65. 65. Design “ativo”
  66. 66. Design “passivo”
  67. 67. Design ágil == Design evolutivo
  68. 68. Design ágil == Design evolutivo
  69. 69. Design Ágil
  70. 70. Design Ágil • Comportamentos:
  71. 71. Design Ágil • Comportamentos: • Código é fácil de ser testado
  72. 72. 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
  73. 73. 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
  74. 74. 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
  75. 75. Refatoração
  76. 76. Refatoração • Comportamentos:
  77. 77. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE
  78. 78. Refatoração • Comportamentos: • Desenvolvedores familiarizados com refatorações automatizadas na IDE • Refatoração acontece quando os testes estão passando
  79. 79. 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
  80. 80. 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
  81. 81. 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
  82. 82. 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
  83. 83. https://github.com/npryce/code-words
  84. 84. Linguagem Ubíqua
  85. 85. Linguagem Ubíqua • Comportamentos:
  86. 86. Linguagem Ubíqua • Comportamentos: • Código de produção e de testes usam terminologia uniforme, alinhada com o domínio
  87. 87. 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
  88. 88. 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.)
  89. 89. colaboração
  90. 90. http://www.flickr.com/photos/johncarleton/5355691631
  91. 91. http://www.flickr.com/photos/johncarleton/5355691631
  92. 92. Programação Pareada • Benefícios: • Foco • Revisão de código constante • Resultado é maior que a soma das partes
  93. 93. Programação Pareada
  94. 94. Programação Pareada • Comportamentos:
  95. 95. Programação Pareada • Comportamentos: • Ao parear, papéis de navegador e piloto rotacionam frequentemente
  96. 96. 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
  97. 97. 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
  98. 98. 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
  99. 99. Standards de Código
  100. 100. Standards de Código • Comportamentos:
  101. 101. Standards de Código • Comportamentos: • Equipe segue estilo de código comum
  102. 102. Standards de Código • Comportamentos: • Equipe segue estilo de código comum • Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado
  103. 103. 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
  104. 104. 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
  105. 105. 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
  106. 106. Propriedade Coletiva de Código
  107. 107. Propriedade Coletiva de Código • Comportamentos:
  108. 108. Propriedade Coletiva de Código • Comportamentos: • Não existe silos de conhecimento na equipe
  109. 109. 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
  110. 110. 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
  111. 111. 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
  112. 112. 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
  113. 113. entrega contínua
  114. 114. 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
  115. 115. cliente time de entrega fluxo constante de entrega em produção ENTREGA CONTÍNUA
  116. 116. Servidor Central Desenvolve Máquina Local
  117. 117. Servidor Central Desenvolve Build Máquina Local
  118. 118. Servidor Central Desenvolve Build Máquina Local
  119. 119. Servidor Central Desenvolve Build pull Máquina Local
  120. 120. Servidor Central Desenvolve Build Build pull Máquina Local
  121. 121. Servidor Central Desenvolve Build Build pull Máquina Local
  122. 122. Servidor Central Desenvolve Build Build pull Máquina Local push
  123. 123. Servidor Central Desenvolve Build Build pull Máquina Local Build push
  124. 124. Servidor Central Desenvolve Build Build pull Máquina Local Build push ✔ Pronto!
  125. 125. Servidor Central Desenvolve Build Build pull Máquina Local Build push ✔ Pronto!
  126. 126. Servidor Central Desenvolve Build Build pull Máquina Local Build push ✔ Pronto! Todo mundo faz commit no trunk todos os dias
  127. 127. Integração Contínua
  128. 128. Integração Contínua • Comportamentos:
  129. 129. Integração Contínua • Comportamentos: • Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia
  130. 130. Integração Contínua • Comportamentos: • Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia • Build roda testes automatizados de diversos níveis
  131. 131. 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
  132. 132. 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
  133. 133. Integração Contínua
  134. 134. Integração Contínua • Comportamentos:
  135. 135. Integração Contínua • Comportamentos: • Desenvolvedores trabalham para reduzir o tempo do build
  136. 136. 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
  137. 137. 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
  138. 138. Branch por Funcionalidade
  139. 139. Desenvolvimento no Trunk
  140. 140. Desenvolvimento no Trunk
  141. 141. Desenvolvimento no Trunk • Comportamentos:
  142. 142. Desenvolvimento no Trunk • Comportamentos: • Commits que quebram o build são rapidamente consertados ou revertidos
  143. 143. 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
  144. 144. 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
  145. 145. 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
  146. 146. http://bit.ly/manage-tech-debt
  147. 147. ESFORÇO DOR
  148. 148. ESFORÇO DOR
  149. 149. Gerenciar Dívida Técnica
  150. 150. Gerenciar Dívida Técnica • Comportamentos:
  151. 151. Gerenciar Dívida Técnica • Comportamentos: • Equipe cataloga e estima items relacionados à dívida técnica
  152. 152. 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
  153. 153. 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
  154. 154. 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
  155. 155. Implantação Automatizada
  156. 156. Implantação Automatizada • Comportamentos:
  157. 157. Implantação Automatizada • Comportamentos: • Equipe procura automatizar passos para deploy
  158. 158. 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.
  159. 159. 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
  160. 160. Infraestrutura como Código
  161. 161. Infraestrutura como Código • Comportamentos:
  162. 162. Infraestrutura como Código • Comportamentos: • É fácil subir ambientes parecidos com produção
  163. 163. 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
  164. 164. 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
  165. 165. 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
  166. 166. Pipeline de Implantação
  167. 167. 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
  168. 168. Em Português! http://www.grupoa.com.br/livros/engenharia-de-software-e- metodos-ageis/entrega-continua/9788582601037
  169. 169. 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 (...) (…)
  170. 170. Pipeline de Implantação
  171. 171. Pipeline de Implantação • Comportamentos:
  172. 172. Pipeline de Implantação • Comportamentos: • Mudanças em produção podem ser traçadas desde o commit original
  173. 173. 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
  174. 174. 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
  175. 175. 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
  176. 176. 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, …)
  177. 177. Resumindo...
  178. 178. práticas de engenharia são essenciais para ser ágil
  179. 179. princípios vs. práticas
  180. 180. minhas práticas de engenharia
  181. 181. 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
  182. 182. quais são as suas práticas?
  183. 183. Danilo Sato @dtsato - www.dtsato.com Desenvolvedor, Arquiteto, Coach, DevOps, Treinador Obrigado!

×