Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br     Extreme Programming
@rodrigobranas   rodrigo.branas@gmail.comFormação AcadêmicaCiências da Computação – UFSCGerenciamento de Projetos - FGVCer...
Rodrigo Branas – rodrigo.branas@gmail.com10 anos de experiência na plataforma Java1000 horas em sala de aulaMais de 50 pal...
1995 – Projeto C3Chrysler Comprehensive Compensation
Payroll System
Migrar a base de código legadaescrita em COBOL e integrar com         outros sistemas
Com a complexidade, a situaçãoficou caótica e o software instável
Kent Beck (Criador do Extreme    Programming)É chamado para ajudar   a salvar o projeto!
Parando de cavar...
Praticamente todo o códigofoi jogado fora!
Reescrever tudo em menos    tempo e com metadeda equipe trabalhando de forma          diferente!
O conjunto de práticas    propostas por Kent paraescrever o código deram origem   ao Extreme Programming
Entre as principais práticas     utilizadas estão:Pair Programming
Entre as principais práticas     utilizadas estão:Pair ProgrammingTDD
Entre as principais práticas     utilizadas estão:Pair ProgrammingTDDRefactoring
Entre as principais práticas     utilizadas estão:Pair ProgrammingTDDRefactoringBuild automatizado
Entre as principais práticas     utilizadas estão:Pair ProgrammingTDDRefactoringBuild automatizadoIntegração contínua
Em 1997 o Projeto C3 foi paraprodução! Mais de 10.000funcionários foram pagos pormeio do novo software!
Extreme Programmingé uma mudança social!
Abandonar velhos hábitos
Foco em técnicas deprogramação
Na comunicação aberta e direta!
Muito trabalho em equipe!
Buscando a excelência emdesenvolvimento de software
Como fica o Extreme Programmingno contexto da agilidade em geral?
Valores do Extreme Programming
Comunicação
Face-a-face
Simplicidade
YAGNI(You Ain’t Gonna Need It)
YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.
Tempo gasto adicionando novas funcionalidades são apenas a       ponta do iceberg!
YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.Novas funcionalidades p...
YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.Novas funcionalidades p...
YAGNI (You Ain’t Gonna Need It)Tempo gasto adicionando, testando ecorrigindo novas funcionalidades.Novas funcionalidades p...
Cuidado com o Snowball Effect
O caso da Agenda    Telefônica
Feedback
Fail Fast
Perdendo as chaves...
Coragem
Assumir responsabilidades
Trabalhar de formas diferentes
Se adaptar as mudanças
Reconhecer as falhas
“Não importa o quão longe você andou na direção errada, volte       imediatamente.”       (Provérbio turco)
Primary Practices
Sit Together
Desenvolver software envolve o         aprendizado
Compartilhar o conhecimento
Barreiras na comunicação
Times distribuidos podem ser ágeis?
Whole Team
Que tipo de profissionais são        necessários?
Problemas na comunicação entre       diferentes setores
Teoria das restrições
Equipes multi-disciplinares!
Diferença entre equipes e pessoas        multi-disciplinares
Informative Workspace
Irradiadores de informação
Ferramentas Eletrônicas x Físicas
Energized Work
Desenvolvimento envolve estimulara criatividade, idéias e o raciocínio
Condições ideais de trabalho
Produtividade x Carga Horária
Horário fixo para entrar e sair
Baixa motivação com o trabalho
Ficou doente?
Pair Programming
Piloto + Copiloto
Será que a velocidade do projeto         será reduzida?
Era uma vez um cliente: “Sem pairprogramming por favor!”
Onde está o gargalo nodesenvolvimento de software?
O caso dos digitadores
Vantagens do Pair Programming: Código de melhor qualidade
Vantagens do Pair Programming: Código de melhor qualidade Aumento do foco
Vantagens do Pair Programming: Código de melhor qualidade Aumento do foco Disseminação de conhecimento na equipe
Vantagens do Pair Programming: Código de melhor qualidade Aumento do foco Disseminação de conhecimento na equipe Melhora n...
É obrigatório trabalhar em par     durante todo o dia?
Técnica do Pomodoro!
Escolha a tarefa
Acerte o seu Pomodoro para 25           minutos
Trabalhe até o fim do Pomodoro
Faça um intervalo de 5 minutos
A cada 4 Pomodoros faça umintervalo longo de 15 a 20 minutos
A importância da rotação dos           pares
Dica: Não se apaixone pelo seu par!
Slack
“Aliviar a tensão”   (Babylon)
Problemas com o overcommitment
Frustração por não atingir a meta!
Atolado?
É necessário finalizar todas as user  stories para atingir uma meta?
Decompor as user stories deixando os detalhes menos importantes           para o final
Incluir tarefas técnicas importantes  mas que possam ser canceladas
Reservar um tempo livre caso seja       necessário utilizá-lo
Ten-Minute Build
Ainda existe build manual?
Tarefas mecânicas e repetitivas     são desperdício puro!
Desperdício PuroDesperdício Incidental          Valor
Gestão de dependências
Ao baixar o código do repositório  pela primeira vez, funciona?
Por que realizar o build em nomáximo “10 minutos”?
Se demorar demais o build começará a ser evitado
Perda da oportunidade de feedback
Exercício: Quanto tempo dura obuild em seu ambiente atual? O que  pode ser feito para melhorá-lo?
Estratégias para reduzir a demora       no processo de build:  Modularizar o build
Estratégias para reduzir a demora       no processo de build:  Modularizar o build  Distribuir ou delegar a execução  do b...
Estratégias para reduzir a demora       no processo de build:  Modularizar o build  Distribuir ou delegar a execução  do b...
Estratégias para reduzir a demora       no processo de build:  Modularizar o build  Distribuir ou delegar a execução  do b...
Continuous Integration
Feedback integrado e    instantâneo!
Desenvolvendo uma cultura     “Stop-the-line”
Por que eu não realizo esseprocesso apenas na minha própria           maquina?
Evitando a síndrome do...
Última versãosempre prontapara o cliente!
Ferramentas para integração         contínua
Test-First Programming
Qual é a vantagem de escrever o          teste antes?
Escopo limitado evita escrever  código além do necessário
Acoplamento e coesão
Confiança no código
Ganhando ritmoTeste, Código e Refactoring
Métricas
Como é a cobertura de testes dossoftwares em que vocês trabalham           atualmente?
Incremental Design
Investir apenas o necessário para implementar as funcionalidades
Como evitar que o projeto daaplicação vire uma bagunça?
Refactoring
As práticas primárias são    responsáveis pela base dacomunicação e feedback. Os times podem usá-las para aumentar a confi...
Corollary Practices
O que aconteceria se você começasse a realizar o DailyDeployment tendo uma taxa de     defeitos ainda alta?As práticas a s...
Real customer involvement
Metáfora do Alfaiate
O que são clientes reais?
Agile Anti-Pattern: Customer Proxy
Fábrica de salsichas
Beta testers
Incremental Deployment
Antecipar o ROI
Guiar o desenvolvimento doproduto com base em feedbacks
Mitigar riscos na hora de virar a              chave
Definindo uma versão mínima para       colocar em produção
Cuidado com o resultado caso o   produto esteja muito crú
Sistemas legados
Vai doer!
Team Continuity
“Value in software is created not only just by people know and dobut also by their relationships and what they accomplish ...
Problemas nas empresas grandes
Move people around!
Shrinking Teams
Qual é o tamanho ideal de uma           equipe?
Manter a capacidade produtivareduzindo o tamanho da equipe
Root-Cause Analysis
Eliminar a causa raiz do defeito
Escreva um teste que evidencie o            defeito
Corrija o defeito
Descubra porque o defeito foiinserido chegando a sua causa raiz
Trabalhe na causa raiz previnindo aocorrência de defeito semelhantes
Shared Code
De quem é a responsabilidade pelo       código produzido?
Ao encontrar um defeito, corrija!
Quais são os problemasrelacionados a falta de compartilhar a responsabilidade sobre o código          fonte? (10 min.)
Code and Tests
Os únicos artefatos criados são       código e testes
Toda documentação precisa ser          gerada
Single Code Base
Por que utilizar um SCM(Source Code Management)?   CVS, SVN, SourceSafe, ...
Apenas medo de perder os        dados?
Quando e como são realizados    commits de código?
A importância do versionamento a          cada commit
Baby Steps
Always shippable code!
Estratégias de branching
Nunca criar branches
Prós:Fácil de seguir
Prós:Fácil de seguirMenos barreiras para novosdesenvolvedores
Prós:Fácil de seguirMenos barreiras para novosdesenvolvedoresNinguém precisa saber criarbranches
Contras:Baseline pode se tornar instávela qualquer momento
Contras:Baseline pode se tornar instávela qualquer momentoDesenvolvimento caótico
Sempre criar branches
Prós:Baseline sempre estável
Prós:Baseline sempre estávelNenhum desenvolvedor precisamanter código em suasmaquinas por muito tempo
Contras:Desenvolvedores isolados
Contras:Desenvolvedores isoladosCriação de muitos conflitos
Contras:Desenvolvedores isoladosCriação de muitos conflitosMuito tempo gasto com merges
Estratégia híbrida(também conhecida como bom senso)
Regras:1. O código do baseline deve   sempre passar nos testes
Regras:1. O código do baseline deve   sempre passar nos testes2. Uma operação de commit   não pode ser muito grande   ao p...
Daily Deployment
Quanto maior a distância entre o  que está em produção e emdesenvolvimento maior é o risco!
Quais são as maiores dificuldades  para viabilizar essa prática?
Riscos:Baixo número de defeitos
Riscos:Baixo número de defeitosAmbiente totalmenteautomatizado
Riscos:Baixo número de defeitosAmbiente totalmenteautomatizadoEstratégias de recovery
Ambiente de Stagging
Negotiated Scope Contract
A maioria dos projetos fracassam!                    (Standish Chaos Report – 2009)
24% são simplesmente cancelados!                   (Standish Chaos Report – 2009)
44% fora do prazo, custo ou escopo!                     (Standish Chaos Report – 2009)
Apenas 32% tem sucesso!              (Standish Chaos Report – 2009)
Sucesso?
Quantos % do Microsoft Word você        realmente utiliza?
A maioria das funcionalidades não          são utilizadas!
Por que?
Necessidade de segurança!
Quanto custa?
Quando fica pronto?
Tentando prever o futuro!
Fechar o escopo para tentarresponder a essas perguntas!
Qual é o maior risco de um projeto          de software?
Não era nada disso que eu queria!
O que toda essa segurança        garante?
A quantidade de dinheiro quepoderá ser jogada fora no final do             projeto!
Tipos de Contrato
Contrato de Tempo e Material
Alto risco para o cliente
Fornecedor não tem incentivo   para finalizar o escopo
Custos fora de controle
Desentendimentos constantesentre o cliente e o fornecedor
Contrato de Preço Fixo
Alto custo para montar o contrato
Risco por conta do fornecedor
Engessado
Qualidade pode ser negligenciada       em caso de atrasos
Contratos Híbridos
Custos parcialmente fixos e    adicional reduzido           Exemplo:80hs com 200 reais por hora =16k   8k fixo e 100 reais...
Pré-PagoUm orçamento é definido no início         do projeto.   Conforme as entregas vão acontecendo, um determinado      ...
Preço Fixo por Release
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
Próximos SlideShares
Carregando em…5
×

XP - Extreme Programming

2.530 visualizações

Publicada em

Publicada em: Tecnologia
1 comentário
3 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.530
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
3
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

×