XP - Extreme Programming

2.596 visualizações

Publicada em

Publicada em: Tecnologia
1 comentário
5 gostaram
Estatísticas
Notas
  • Jogando.net/MU *25*

    Boa tarde amigos,

    Venham conhecer nossos Servidores de Mu
    Online Season 6 http://www.jogando.net/mu/
    >>muitos kits novos;
    >> Nossos GMs online em todos os servers
    Fazem eventos todos os dias:
    Fazemos sua Diversão com qualidade,há mais de 5 anos
    Servers ON 24 horas por dia
    Vários Server esperando por você.Venha se divertir de verdade.
    >>>CURTA nossa Fan page no Facebook e concorra a prêmios.
    SORTEIO de 2 pacotes de 100 JCASHs mais 15 dias VIP Premium
    >>>Conheçam também Animes Cloud -> http://www.animescloud.com, mais de 20.000 videos online,feito exclusivo para sua diversão.
    Site http://www.jogando.net/mu/ Benvindos ao nosso servidor.
    Wartemix Divulgadora Oficial !
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
Sem downloads
Visualizações
Visualizações totais
2.596
No SlideShare
0
A partir de incorporações
0
Número de incorporações
12
Ações
Compartilhamentos
0
Downloads
0
Comentários
1
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

XP - Extreme Programming

  1. 1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br Extreme Programming
  2. 2. @rodrigobranas rodrigo.branas@gmail.comFormação AcadêmicaCiências da Computação – UFSCGerenciamento de Projetos - FGVCertificaçõesSCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM
  3. 3. Rodrigo Branas – rodrigo.branas@gmail.com10 anos de experiência na plataforma Java1000 horas em sala de aulaMais de 50 palestras em eventosLíder da área de desenvolvimento na GenneraAutor da revista Java MagazinePalestranteInstrutor da Academia Java e Agile da GlobalcodeCriador dos treinamentos de Clean Code, Selenium eMaven da Agile CodeTrabalhou com as empresas:EDS, HP, GM, Citibank, OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed, Suntech, Vale do Rio
  4. 4. 1995 – Projeto C3Chrysler Comprehensive Compensation
  5. 5. Payroll System
  6. 6. Migrar a base de código legadaescrita em COBOL e integrar com outros sistemas
  7. 7. Com a complexidade, a situaçãoficou caótica e o software instável
  8. 8. Kent Beck (Criador do Extreme Programming)É chamado para ajudar a salvar o projeto!
  9. 9. Parando de cavar...
  10. 10. Praticamente todo o códigofoi jogado fora!
  11. 11. Reescrever tudo em menos tempo e com metadeda equipe trabalhando de forma diferente!
  12. 12. O conjunto de práticas propostas por Kent paraescrever o código deram origem ao Extreme Programming
  13. 13. Entre as principais práticas utilizadas estão:Pair Programming
  14. 14. Entre as principais práticas utilizadas estão:Pair ProgrammingTDD
  15. 15. Entre as principais práticas utilizadas estão:Pair ProgrammingTDDRefactoring
  16. 16. Entre as principais práticas utilizadas estão:Pair ProgrammingTDDRefactoringBuild automatizado
  17. 17. Entre as principais práticas utilizadas estão:Pair ProgrammingTDDRefactoringBuild automatizadoIntegração contínua
  18. 18. Em 1997 o Projeto C3 foi paraprodução! Mais de 10.000funcionários foram pagos pormeio do novo software!
  19. 19. Extreme Programmingé uma mudança social!
  20. 20. Abandonar velhos hábitos
  21. 21. Foco em técnicas deprogramação
  22. 22. Na comunicação aberta e direta!
  23. 23. Muito trabalho em equipe!
  24. 24. Buscando a excelência emdesenvolvimento de software
  25. 25. Como fica o Extreme Programmingno contexto da agilidade em geral?
  26. 26. Valores do Extreme Programming
  27. 27. Comunicação
  28. 28. Face-a-face
  29. 29. Simplicidade
  30. 30. YAGNI(You Ain’t Gonna Need It)
  31. 31. YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.
  32. 32. Tempo gasto adicionando novas funcionalidades são apenas a ponta do iceberg!
  33. 33. YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.Novas funcionalidades precisam serdebugadas, documentadas e suportadas.
  34. 34. YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.Novas funcionalidades precisam serdebugadas, documentadas e suportadas.Seu código ocupa espaço e aumenta acomplexidade do software como um todo.
  35. 35. YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.Novas funcionalidades precisam serdebugadas, documentadas e suportadas.Seu código ocupa espaço e aumenta acomplexidade do software como um todo.Novas funcionalidades geram novasnecessidades e o Snowball Effect.
  36. 36. Cuidado com o Snowball Effect
  37. 37. O caso da Agenda Telefônica
  38. 38. Feedback
  39. 39. Fail Fast
  40. 40. Perdendo as chaves...
  41. 41. Coragem
  42. 42. Assumir responsabilidades
  43. 43. Trabalhar de formas diferentes
  44. 44. Se adaptar as mudanças
  45. 45. Reconhecer as falhas
  46. 46. “Não importa o quão longe você andou na direção errada, volte imediatamente.” (Provérbio turco)
  47. 47. Primary Practices
  48. 48. Sit Together
  49. 49. Desenvolver software envolve o aprendizado
  50. 50. Compartilhar o conhecimento
  51. 51. Barreiras na comunicação
  52. 52. Times distribuidos podem ser ágeis?
  53. 53. Whole Team
  54. 54. Que tipo de profissionais são necessários?
  55. 55. Problemas na comunicação entre diferentes setores
  56. 56. Teoria das restrições
  57. 57. Equipes multi-disciplinares!
  58. 58. Diferença entre equipes e pessoas multi-disciplinares
  59. 59. Informative Workspace
  60. 60. Irradiadores de informação
  61. 61. Ferramentas Eletrônicas x Físicas
  62. 62. Energized Work
  63. 63. Desenvolvimento envolve estimulara criatividade, idéias e o raciocínio
  64. 64. Condições ideais de trabalho
  65. 65. Produtividade x Carga Horária
  66. 66. Horário fixo para entrar e sair
  67. 67. Baixa motivação com o trabalho
  68. 68. Ficou doente?
  69. 69. Pair Programming
  70. 70. Piloto + Copiloto
  71. 71. Será que a velocidade do projeto será reduzida?
  72. 72. Era uma vez um cliente: “Sem pairprogramming por favor!”
  73. 73. Onde está o gargalo nodesenvolvimento de software?
  74. 74. O caso dos digitadores
  75. 75. Vantagens do Pair Programming: Código de melhor qualidade
  76. 76. Vantagens do Pair Programming: Código de melhor qualidade Aumento do foco
  77. 77. Vantagens do Pair Programming: Código de melhor qualidade Aumento do foco Disseminação de conhecimento na equipe
  78. 78. Vantagens do Pair Programming: Código de melhor qualidade Aumento do foco Disseminação de conhecimento na equipe Melhora na produtividade
  79. 79. É obrigatório trabalhar em par durante todo o dia?
  80. 80. Técnica do Pomodoro!
  81. 81. Escolha a tarefa
  82. 82. Acerte o seu Pomodoro para 25 minutos
  83. 83. Trabalhe até o fim do Pomodoro
  84. 84. Faça um intervalo de 5 minutos
  85. 85. A cada 4 Pomodoros faça umintervalo longo de 15 a 20 minutos
  86. 86. A importância da rotação dos pares
  87. 87. Dica: Não se apaixone pelo seu par!
  88. 88. Slack
  89. 89. “Aliviar a tensão” (Babylon)
  90. 90. Problemas com o overcommitment
  91. 91. Frustração por não atingir a meta!
  92. 92. Atolado?
  93. 93. É necessário finalizar todas as user stories para atingir uma meta?
  94. 94. Decompor as user stories deixando os detalhes menos importantes para o final
  95. 95. Incluir tarefas técnicas importantes mas que possam ser canceladas
  96. 96. Reservar um tempo livre caso seja necessário utilizá-lo
  97. 97. Ten-Minute Build
  98. 98. Ainda existe build manual?
  99. 99. Tarefas mecânicas e repetitivas são desperdício puro!
  100. 100. Desperdício PuroDesperdício Incidental Valor
  101. 101. Gestão de dependências
  102. 102. Ao baixar o código do repositório pela primeira vez, funciona?
  103. 103. Por que realizar o build em nomáximo “10 minutos”?
  104. 104. Se demorar demais o build começará a ser evitado
  105. 105. Perda da oportunidade de feedback
  106. 106. Exercício: Quanto tempo dura obuild em seu ambiente atual? O que pode ser feito para melhorá-lo?
  107. 107. Estratégias para reduzir a demora no processo de build: Modularizar o build
  108. 108. Estratégias para reduzir a demora no processo de build: Modularizar o build Distribuir ou delegar a execução do build (CI)
  109. 109. Estratégias para reduzir a demora no processo de build: Modularizar o build Distribuir ou delegar a execução do build (CI) Otimizar os testes
  110. 110. Estratégias para reduzir a demora no processo de build: Modularizar o build Distribuir ou delegar a execução do build (CI) Otimizar os testes Utilizar a base se possível em memória
  111. 111. Continuous Integration
  112. 112. Feedback integrado e instantâneo!
  113. 113. Desenvolvendo uma cultura “Stop-the-line”
  114. 114. Por que eu não realizo esseprocesso apenas na minha própria maquina?
  115. 115. Evitando a síndrome do...
  116. 116. Última versãosempre prontapara o cliente!
  117. 117. Ferramentas para integração contínua
  118. 118. Test-First Programming
  119. 119. Qual é a vantagem de escrever o teste antes?
  120. 120. Escopo limitado evita escrever código além do necessário
  121. 121. Acoplamento e coesão
  122. 122. Confiança no código
  123. 123. Ganhando ritmoTeste, Código e Refactoring
  124. 124. Métricas
  125. 125. Como é a cobertura de testes dossoftwares em que vocês trabalham atualmente?
  126. 126. Incremental Design
  127. 127. Investir apenas o necessário para implementar as funcionalidades
  128. 128. Como evitar que o projeto daaplicação vire uma bagunça?
  129. 129. Refactoring
  130. 130. As práticas primárias são responsáveis pela base dacomunicação e feedback. Os times podem usá-las para aumentar a confiança e a competência paraconstruir relacionamentos dentro e fora do time.
  131. 131. Corollary Practices
  132. 132. O que aconteceria se você começasse a realizar o DailyDeployment tendo uma taxa de defeitos ainda alta?As práticas a seguir devem serutilizadas quando a confiança estiver consolidada.
  133. 133. Real customer involvement
  134. 134. Metáfora do Alfaiate
  135. 135. O que são clientes reais?
  136. 136. Agile Anti-Pattern: Customer Proxy
  137. 137. Fábrica de salsichas
  138. 138. Beta testers
  139. 139. Incremental Deployment
  140. 140. Antecipar o ROI
  141. 141. Guiar o desenvolvimento doproduto com base em feedbacks
  142. 142. Mitigar riscos na hora de virar a chave
  143. 143. Definindo uma versão mínima para colocar em produção
  144. 144. Cuidado com o resultado caso o produto esteja muito crú
  145. 145. Sistemas legados
  146. 146. Vai doer!
  147. 147. Team Continuity
  148. 148. “Value in software is created not only just by people know and dobut also by their relationships and what they accomplish together.” (Kent Beck)
  149. 149. Problemas nas empresas grandes
  150. 150. Move people around!
  151. 151. Shrinking Teams
  152. 152. Qual é o tamanho ideal de uma equipe?
  153. 153. Manter a capacidade produtivareduzindo o tamanho da equipe
  154. 154. Root-Cause Analysis
  155. 155. Eliminar a causa raiz do defeito
  156. 156. Escreva um teste que evidencie o defeito
  157. 157. Corrija o defeito
  158. 158. Descubra porque o defeito foiinserido chegando a sua causa raiz
  159. 159. Trabalhe na causa raiz previnindo aocorrência de defeito semelhantes
  160. 160. Shared Code
  161. 161. De quem é a responsabilidade pelo código produzido?
  162. 162. Ao encontrar um defeito, corrija!
  163. 163. Quais são os problemasrelacionados a falta de compartilhar a responsabilidade sobre o código fonte? (10 min.)
  164. 164. Code and Tests
  165. 165. Os únicos artefatos criados são código e testes
  166. 166. Toda documentação precisa ser gerada
  167. 167. Single Code Base
  168. 168. Por que utilizar um SCM(Source Code Management)? CVS, SVN, SourceSafe, ...
  169. 169. Apenas medo de perder os dados?
  170. 170. Quando e como são realizados commits de código?
  171. 171. A importância do versionamento a cada commit
  172. 172. Baby Steps
  173. 173. Always shippable code!
  174. 174. Estratégias de branching
  175. 175. Nunca criar branches
  176. 176. Prós:Fácil de seguir
  177. 177. Prós:Fácil de seguirMenos barreiras para novosdesenvolvedores
  178. 178. Prós:Fácil de seguirMenos barreiras para novosdesenvolvedoresNinguém precisa saber criarbranches
  179. 179. Contras:Baseline pode se tornar instávela qualquer momento
  180. 180. Contras:Baseline pode se tornar instávela qualquer momentoDesenvolvimento caótico
  181. 181. Sempre criar branches
  182. 182. Prós:Baseline sempre estável
  183. 183. Prós:Baseline sempre estávelNenhum desenvolvedor precisamanter código em suasmaquinas por muito tempo
  184. 184. Contras:Desenvolvedores isolados
  185. 185. Contras:Desenvolvedores isoladosCriação de muitos conflitos
  186. 186. Contras:Desenvolvedores isoladosCriação de muitos conflitosMuito tempo gasto com merges
  187. 187. Estratégia híbrida(também conhecida como bom senso)
  188. 188. Regras:1. O código do baseline deve sempre passar nos testes
  189. 189. Regras:1. O código do baseline deve sempre passar nos testes2. Uma operação de commit não pode ser muito grande ao ponto de desestimular a revisão de um colega
  190. 190. Daily Deployment
  191. 191. Quanto maior a distância entre o que está em produção e emdesenvolvimento maior é o risco!
  192. 192. Quais são as maiores dificuldades para viabilizar essa prática?
  193. 193. Riscos:Baixo número de defeitos
  194. 194. Riscos:Baixo número de defeitosAmbiente totalmenteautomatizado
  195. 195. Riscos:Baixo número de defeitosAmbiente totalmenteautomatizadoEstratégias de recovery
  196. 196. Ambiente de Stagging
  197. 197. Negotiated Scope Contract
  198. 198. A maioria dos projetos fracassam! (Standish Chaos Report – 2009)
  199. 199. 24% são simplesmente cancelados! (Standish Chaos Report – 2009)
  200. 200. 44% fora do prazo, custo ou escopo! (Standish Chaos Report – 2009)
  201. 201. Apenas 32% tem sucesso! (Standish Chaos Report – 2009)
  202. 202. Sucesso?
  203. 203. Quantos % do Microsoft Word você realmente utiliza?
  204. 204. A maioria das funcionalidades não são utilizadas!
  205. 205. Por que?
  206. 206. Necessidade de segurança!
  207. 207. Quanto custa?
  208. 208. Quando fica pronto?
  209. 209. Tentando prever o futuro!
  210. 210. Fechar o escopo para tentarresponder a essas perguntas!
  211. 211. Qual é o maior risco de um projeto de software?
  212. 212. Não era nada disso que eu queria!
  213. 213. O que toda essa segurança garante?
  214. 214. A quantidade de dinheiro quepoderá ser jogada fora no final do projeto!
  215. 215. Tipos de Contrato
  216. 216. Contrato de Tempo e Material
  217. 217. Alto risco para o cliente
  218. 218. Fornecedor não tem incentivo para finalizar o escopo
  219. 219. Custos fora de controle
  220. 220. Desentendimentos constantesentre o cliente e o fornecedor
  221. 221. Contrato de Preço Fixo
  222. 222. Alto custo para montar o contrato
  223. 223. Risco por conta do fornecedor
  224. 224. Engessado
  225. 225. Qualidade pode ser negligenciada em caso de atrasos
  226. 226. Contratos Híbridos
  227. 227. Custos parcialmente fixos e adicional reduzido Exemplo:80hs com 200 reais por hora =16k 8k fixo e 100 reais por hora
  228. 228. Pré-PagoUm orçamento é definido no início do projeto. Conforme as entregas vão acontecendo, um determinado valor é descontado.
  229. 229. Preço Fixo por Release

×