Otimizando o time to market - do zero a produção em poucas iterações

910 views

Published on

agile brazil 2013, guilherme silveira e francisco sokol

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
910
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Otimizando o time to market - do zero a produção em poucas iterações

  1. 1. do zero a produção em poucas iterações otimizando o time to market time to market
  2. 2. chico sokol francisco.sokol@caelum.com.br http://www.caelum.com.br http://www.casadocodigo.com.br
  3. 3. silveira silveira guilherme.silveira@caelum.com.br http://www.caelum.com.br http://www.caelum.com.br/online
  4. 4. PARTE 1: Contexto
  5. 5. guj.com.br guj.com.br
  6. 6. 9 anos de código fs
  7. 7. 158 mil usuários 1.5 milhões de mensagens fs
  8. 8. problema: fórum fs assusta novos usuários século 20 vantagem: favorece discussões desvantagem: dificulta QA
  9. 9. evolução de código pouco a pouco é possível? 9 anos PQ É DIFICIL EVOLUIR?
  10. 10. pq é difícil evoluir? 1. funcionalidade distante do foco 2. falta de testes 3. ausência dos criadores 4. mudanças chateiam usuários 5. pq as decisões foram tomadas? 6. gap de anos desde a última feature nova fs/ gs
  11. 11. versão nova do ZERO 9 anos => não dava mais para evoluir aos poucos fs
  12. 12. Decisão: Não vale a pena evoluir o código atual fs
  13. 13. PARTE 2: COMO FAZER? COMO FAZER?
  14. 14. Como fazer? • Compra? • Adapta um open source que já existe? • Cria o código do zero? • Mistura tudo isso?
  15. 15. diminuir o time to market (e o custo de entrada) (e o custo de entrada) fs
  16. 16. 1. buy it “off the shelf” mythical man month
  17. 17. procuramos um software pago um software pago MUITO CARO!
  18. 18. proposta de internacionalização internacionalização MUITO CARO!
  19. 19. 2. diversos + adaptaropen source fs
  20. 20. 3 pessoas + novas e 1 mais experiente Tentamos 3 meses Encontramos diversos problemas fs
  21. 21. fs internacionalização espalhado por todo canto espalhado por todo canto espalhado por todo canto espalhado por todo canto espalhado por todo canto
  22. 22. Linguagem (python) o problema não é aprender a linguagem o problema é aprender as boas práticas fs
  23. 23. contratar o criador? Linguagem (python) curto prazo ok longo prazo ok fs
  24. 24. um único autor 1) cowboy (“macho” alpha) 2) forever alone
  25. 25. Problemas de um único autor suporte e documentação inexistente contactamos não fechou a conta
  26. 26. espagueti fs código espagueti!=
  27. 27. problemas • i18n espalhada • linguagem desconhecida para a equipe • código espagueti • desenvolvido por um único autor • problemas clássicos de engenharia que não foram cuidados antes fs
  28. 28. entregou para users alpha mas ficou a dúvida continua a abordagem? fs
  29. 29. falhar em 3 meses não é falhar rápido
  30. 30. faltou: a retrospectiva
  31. 31. 500 anos sem retrospectiva
  32. 32. a retrospectiva com olhar do produto no lado técnico
  33. 33. Retrospectiva adicionando uma chance para mudar o caminho.
  34. 34. $ 3. escreve uma versão nova do ZERO ZERO $ $ $ $$ $ $ $ $ $ $ $
  35. 35. pergunta: - substitui de uma vez - em paralelo em paralelo em paralelo fs
  36. 36. Feedback zero infinitas reclamações Time to market ruim Bugs fs
  37. 37. Feedback cedo Time to market #win Bugs Reclamações
  38. 38. lembrando que já passaram 3 meses! fs
  39. 39. fixamos prazo e escopo o que acontece nesse caso? vamos tentar substituir em paralelo
  40. 40. nossa dúvida é qual das duas variáveis vai estourar, e pra qual lado
  41. 41. data+escopo => ~objetivo
  42. 42. pronto! podemos começar podemos começar
  43. 43. FASE 1
  44. 44. - escrever do zero - implementar o *mínimo viável* - implementar o *mínimo viável*
  45. 45. - escrever do zero - implementar o *mínimo viável* do minimo viavel - implementar o *mínimo viável* do minimo viavel
  46. 46. minimo viavel - implementar o *mínimo viável* do minimo viavel do minimo viavel
  47. 47. além do release planning, iterações menores menores fs
  48. 48. reunião++ Text discussões a serem feitas: - linguagem - framework - design e usabilidade - funcionalidades minimas fs
  49. 49. discutimos: - funcionalidades minimas - funcionalidades minimas fs
  50. 50. goela abaixo: - linguagem escolhida - framework escolhido - framework escolhido - framework escolhido
  51. 51. ditador benevolente discussões são aceitáveis ele tem a palavra final escolhido um caminho, todos o seguem
  52. 52. design: depois cores imagens responsivo fs
  53. 53. usabilidade: ok validações ajax x não ajax maneira de interagir ao clicar, aparece algo fs
  54. 54. if pronto => continuaríamos fs
  55. 55. se não ficasse pronto, voltariamos pro plano anterior Gostei do projeto!
  56. 56. desafio tempo esperado desafiador tecnologias que dominamos somos capazes? fs
  57. 57. ações muita gente pareando muito tempo nível de experiência diferente (troca de experiências) + da metade tinha - de 1 ano de experiência fs bastante revisão de código
  58. 58. produtividade++ pq? linguagem e tecnologia que a equipe domina não só a equipe, mas toda a empresa green field desafio topado pela equipe
  59. 59. equipe x ferramentas a equipe original tinha uma pessoa com mais experiência o problema não estava na equipe problemas mostrados até agora
  60. 60. resultados da fase 1 iterações acabaram mais cedo 2 semanas, tudo ok sem design usabilidade implementada fs
  61. 61. FASE 2 fs
  62. 62. - continuar - implementar outras features outras features fs
  63. 63. lançamento fechado usuários convidados encontra mais bugs design pronto (vários devs envolvidos) fs
  64. 64. deploy contínuo ambiente de produção teste de end-to-end scripts de deploy até hoje: +1 deploy por dia, só 2 bugs graves fs
  65. 65. lançamento aberto usuários que querem se aventurar colaboram quem não quer se aventurar, não reclama encontra mais bugs, fica mais estável feedback rápido melhora usabilidade criar usuários fiéis fs gs
  66. 66. misc da fase 2 iterações continuaram surpreendendo prática de deploy contínuo somente quando necessária menos pareamento
  67. 67. em beta encontramos problema de performance otimização de performance somente quando necessária até esse instante sem testes ligados a performance há monitoramento (newrelic) fs
  68. 68. próxima fase troca fs
  69. 69. hoje 4000 pessoas 2500 perguntas 3700 respostas participe! www.guj.com.br/perguntas fs < 2 meses
  70. 70. revisando fs gs continuar o atual? adaptar? criar do zero? deploy em produção débito técnico m uito alto usuários alfa criar do zero m inim um viable product im plem entação lógica aprovação do cam inho design +pareamento revisão de código testes de unidade testes end-to-end integração contínua -pareamento entrega contínua usuários beta todos os usuários problem a de perform ance: otim izações iterações curtas ditadura benevolente FASE 0 FASE 1 FASE 1 FASE 2 FASE 3
  71. 71. Obrigado!
  72. 72. guilherme.silveira@caelum.com.br http://www.caelum.com.br http://www.caelum.com.br/online http://www.casadocodigo.com.br francisco.sokol@caelum.com.br

×