Revolucao Agile - UFSCar

966 views

Published on

Slides da discussão sobre métodos ágeis realizada para alunos de graduação e mestrado e interessados no assunto na Universidade Federal de São Carlos - UFSCar, em 26 de agosto de 2010.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
966
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Revolucao Agile - UFSCar

  1. 1. A revolução Agile > Luiz Fernando Ribeiro “Perdido” 26 de Agosto de 2010
  2. 2. Por que você está aqui?
  3. 3. Agenda <ul><li>Sobre a ThoughtWorks
  4. 4. Modelos tradicionais de desenvolvimento
  5. 5. Agile manifesto
  6. 6. Descendo o nível... </li></ul>
  7. 7. Sobre a ThoughtWorks <ul><li>Pioneira e totalmente focada em Agile
  8. 8. Referência em práticas ágeis
  9. 9. 8 países, 21 cidades
  10. 10. Open Source: Cruise Control, Selenium, outros </li></ul>Martin Fowler
  11. 12. Agile funciona!
  12. 13. Mas o que é Agile mesmo?
  13. 14. Modelos tradicionais de desenvolvimento
  14. 15. Características - Previsibilidade - BDUF (engenharia) - Documentação abrangente - Orientado a processo e a ferramentas
  15. 16. Quais os problemas desses modelos?
  16. 17. Baixo índice de interação Pouca comunicação entre pessoas trabalhando em diferentes níveis de abstração
  17. 18. Baixo índice de interação Ciclo de Feedback muito longo Como sabemos se estamos indo no caminho certo?
  18. 20. Baixo índice de interação Ciclo de Feedback muito longo Proteção contra o cliente Qual o valor por trás disso tudo?
  19. 21. Baixo índice de interação Ciclo de Feedback muito longo Proteção contra o cliente Dificuldade de mudança Change requests, change requests...
  20. 22. Baixo índice de interação Ciclo de Feedback muito longo Proteção contra o cliente Dificuldade de mudança Previsibilidade a longo prazo The Standish Group International, “The CHAOS Report ,”
  21. 23. Baixo índice de interação Ciclo de Feedback muito longo Proteção contra o cliente Dificuldade de mudança Previsibilidade a longo prazo Baixa motivação Trate as pessoas como macaquinhos Macaquinhos elas serão
  22. 24. Agile Manifesto
  23. 25. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo.
  24. 26. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
  25. 27. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas
  26. 28. Foco no processo X Foco nos indivíduos
  27. 29. Linha de montagem
  28. 30. Aprendizado
  29. 31. Desenvolvimento de software = Atividade intelectual, criativa
  30. 32. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente
  31. 33. Design sessions Whiteboard Fotos Documentação como ferramenta X Documentação como fim
  32. 34. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos
  33. 35. Documento de requisitos X Comunicação constante
  34. 36. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano
  35. 37. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
  36. 38. Agile Manifesto Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Baixo índice de interação Ciclo de Feedback muito longo Proteção contra o cliente Dificuldade de mudança Previsibilidade a longo prazo Baixa motivação
  37. 39. Mudança de mentalidade
  38. 40. Adaptação “ Esvazie sua mente. Seja sem forma, como a água. Você coloca água em uma caneca, ela se torna a caneca. Você coloca água em uma garrafa, ela se torna a garrafa… A água pode fluir ou pode destruir! Seja água, meu amigo.” Bruce Lee
  39. 41. Pessoas + Confiança
  40. 42. Descendo o nível....
  41. 43. O que é mais difícil em programação? <ul><li>Entender o problema
  42. 44. Estruturar suas ideias
  43. 45. Elaborar uma solução
  44. 46. Conhecer a plataforma de programação
  45. 47. Digitar o código
  46. 48. Testar o resultado </li></ul>
  47. 49. Programação em pares
  48. 50. Vantagens de programação em pares <ul><li>Eficiência (duas cabeças pensam melhor que uma)
  49. 51. Feedback instantâneo
  50. 52. Propriedade coletiva
  51. 53. Menor “fator caminhão” </li></ul>Zaphod Beeblebrox
  52. 54. Testes?
  53. 55. Testes unitários
  54. 56. package calculator; public class Calculator { public float divide( float dividend, float divisor) { if (divisor == 0) { throw new CalculatorException( &quot;Can't divide by zero.&quot; ); } return dividend / divisor; } // other methods.... }
  55. 57. package calculator; import static org.junit.Assert. assertEquals ; import org.junit.Test; public class CalculatorTests { @Test public void divideShouldReturnTheDivisionQuotient() { float result = new Calculator().divide(56, 8); assertEquals (7, result, 0.0); } @Test public void divideShouldReturnDecimalPartsOfNonExactDivisions() throws Exception { float result = new Calculator().divide(5, 2); assertEquals (2.5, result, 0.0); } @Test (expected = CalculatorException. class ) public void divideShouldThrowACalculatorExceptionWhenDividingByZero() throws Exception { new Calculator().divide(5, 0); } }
  56. 58. Test-driven development (TDD)
  57. 59. package calculator; import static org.junit.Assert. assertEquals ; import org.junit.Test; public class CalculatorTests { @Test public void divideShouldReturnTheDivisionQuotient() { int result = new Calculator().divide(56, 8); assertEquals (7, result); } } package calculator; public class Calculator { public int divide( int n1, int n2) { return n1 / n2; } }
  58. 60. package calculator; import static org.junit.Assert. assertEquals ; import org.junit.Test; public class CalculatorTests { @Test public void divideShouldReturnTheDivisionQuotient() { float result = new Calculator().divide(56, 8); assertEquals (7, result, 0.0); } @Test public void divideShouldReturnDecimalPartsOfNonExactDivisions () throws Exception { float result = new Calculator().divide(5, 2); assertEquals (2.5, result, 0.0); } }
  59. 61. Benefícios de TDD <ul><li>Simplicidade
  60. 62. Modularização
  61. 63. Extensibilidade
  62. 64. Produtividade </li></ul>
  63. 65. Testes como documentação
  64. 66. def &quot;project can't be deleted if it has expenses&quot; () { given: currentUserIsProjectOwner() projectHasExpenses() projectHasNoActivities() when: tryToDeleteProject() then: projectIsNotDeleted() } // Taken from: http://www.aqris.com/display/DEV/2010/01/19/Testing+with+Spock
  65. 67. Pessoas Adaptação Colaboração Feedback Software Mentalidade
  66. 68. Mais perguntas? Obrigado!!!!! [email_address] [email_address] (51) 8105-1520 Bora tomar uma cerveja?

×