Your SlideShare is downloading. ×
0
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
XP - Extreme Programming
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

XP - Extreme Programming

2,028

Published on

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • 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 !
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,028
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×