Baixado 11 vezes
Carregado porCaelum
Otimizando o time to market - do zero a produção em poucas iterações
O documento descreve a evolução de um fórum de discussão de 9 anos para uma nova versão. Após tentativas frustradas de adaptação de software existente ou evolução gradual, a equipe decidiu criar uma nova versão do zero focando no mínimo viável, entregas contínuas e feedback rápido dos usuários.
Mais conteúdo relacionado
![[QCon 2011] Por uma web mais rápida: técnicas de otimização de Sites](https://cdn.slidesharecdn.com/ss_thumbnails/otimizacoesclientside-qcon2011-sergio-110910194248-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Semelhante a Otimizando o time to market - do zero a produção em poucas iterações
![[FrontInBH 2012] Por uma web mais rápida: técnicas de otimizações de sites - ...](https://cdn.slidesharecdn.com/ss_thumbnails/otimizacoesclientside-frontinbh2012-sergio-120713204920-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Otimizando o time to market - do zero a produção em poucas iterações
- 1. do zero aprodução em poucas iterações otimizando o time to market time to market
- 2.
- 3.
- 4.
- 5.
- 6. 9 anos decódigo fs
- 7. 158 mil usuários 1.5milhões de mensagens fs
- 8. problema: fórum fs assusta novos usuários século 20 vantagem:favorece discussões desvantagem: dificulta QA
- 9. evolução de códigopouco a pouco é possível? 9 anos PQ É DIFICIL EVOLUIR?
- 10. pq é difícilevoluir? 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. versão nova doZERO 9 anos => não dava mais para evoluir aos poucos fs
- 12. Decisão: Não vale apena evoluir o código atual fs
- 13.
- 14. Como fazer? • Compra? •Adapta um open source que já existe? • Cria o código do zero? • Mistura tudo isso?
- 15. diminuir o timeto market (e o custo de entrada) (e o custo de entrada) fs
- 16. 1. buy it“off the shelf” mythical man month
- 17. procuramos um software pago umsoftware pago MUITO CARO!
- 18.
- 19. 2. diversos +adaptaropen source fs
- 20. 3 pessoas +novas e 1 mais experiente Tentamos 3 meses Encontramos diversos problemas fs
- 21.
- 22. Linguagem (python) o problemanão é aprender a linguagem o problema é aprender as boas práticas fs
- 23. contratar o criador? Linguagem(python) curto prazo ok longo prazo ok fs
- 25. um único autor 1)cowboy (“macho” alpha) 2) forever alone
- 26. Problemas de umúnico autor suporte e documentação inexistente contactamos não fechou a conta
- 27.
- 28. 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
- 29. entregou para usersalpha mas ficou a dúvida continua a abordagem? fs
- 31. falhar em 3meses não é falhar rápido
- 32.
- 33. 500 anos semretrospectiva
- 34. a retrospectiva comolhar do produto no lado técnico
- 35. Retrospectiva adicionando umachance para mudar o caminho.
- 36. $ 3. escreve uma versãonova do ZERO ZERO $ $ $ $$ $ $ $ $ $ $ $
- 37. pergunta: - substitui deuma vez - em paralelo em paralelo em paralelo fs
- 38. Feedback zero infinitas reclamações Time tomarket ruim Bugs fs
- 39.
- 41. lembrando que já passaram3 meses! fs
- 42. fixamos prazo e escopo oque acontece nesse caso? vamos tentar substituir em paralelo
- 43. nossa dúvida équal das duas variáveis vai estourar, e pra qual lado
- 44.
- 45.
- 46.
- 47. - escrever dozero - implementar o *mínimo viável* - implementar o *mínimo viável*
- 48. - escrever dozero - implementar o *mínimo viável* do minimo viavel - implementar o *mínimo viável* do minimo viavel
- 49. minimo viavel - implementaro *mínimo viável* do minimo viavel do minimo viavel
- 50. além do releaseplanning, iterações menores menores fs
- 51. reunião++ Text discussões a serem feitas: -linguagem - framework - design e usabilidade - funcionalidades minimas fs
- 52. discutimos: - funcionalidades minimas -funcionalidades minimas fs
- 53. goela abaixo: - linguagemescolhida - framework escolhido - framework escolhido - framework escolhido
- 54. ditador benevolente discussões são aceitáveis eletem a palavra final escolhido um caminho, todos o seguem
- 55.
- 56. usabilidade: ok validações ajax xnão ajax maneira de interagir ao clicar, aparece algo fs
- 58. if pronto =>continuaríamos fs
- 59. se não ficassepronto, voltariamos pro plano anterior Gostei do projeto!
- 60. desafio tempo esperado desafiador tecnologiasque dominamos somos capazes? fs
- 61. ações muita gente pareandomuito 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
- 62. produtividade++ pq? linguagem e tecnologiaque a equipe domina não só a equipe, mas toda a empresa green field desafio topado pela equipe
- 63. equipe x ferramentas a equipeoriginal tinha uma pessoa com mais experiência o problema não estava na equipe problemas mostrados até agora
- 64. resultados da fase 1 iteraçõesacabaram mais cedo 2 semanas, tudo ok sem design usabilidade implementada fs
- 65.
- 66. - continuar - implementaroutras features outras features fs
- 67. lançamento fechado usuários convidados encontra maisbugs design pronto (vários devs envolvidos) fs
- 68. deploy contínuo ambiente deprodução teste de end-to-end scripts de deploy até hoje: +1 deploy por dia, só 2 bugs graves fs
- 69. lançamento aberto usuários que queremse 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
- 70. misc da fase2 iterações continuaram surpreendendo prática de deploy contínuo somente quando necessária menos pareamento
- 71. em beta encontramos problemade performance otimização de performance somente quando necessária até esse instante sem testes ligados a performance há monitoramento (newrelic) fs
- 72.
- 73. hoje 4000 pessoas 2500 perguntas 3700respostas participe! www.guj.com.br/perguntas fs < 2 meses
- 74. revisando fs gs continuar o atual? adaptar? criar do zero? deploy em produção débito técnico m uito alto usuários alfa criardo 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
- 75.
- 76.