Os desafios da entrega contínua: feedback e colaboração
•Transferir como PPTX, PDF•
1 gostou•876 visualizações
O documento discute os desafios da entrega contínua, mencionando a importância do feedback do cliente e do refinamento do backlog de histórias de usuário. Apresenta alguns conceitos como controle de versão, build contínuo e ferramentas de teste que apoiam a entrega contínua, mas enfatiza que a colaboração com o cliente e a capacidade de responder às mudanças são mais importantes do que seguir um plano ou depender de processos e ferramentas.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Os desafios da entrega contínua: feedback e colaboração
Semelhante a Os desafios da entrega contínua: feedback e colaboração (20)
Mais de Juliano Ribeiro
Mais de Juliano Ribeiro (20)
Último
Último (20)
Os desafios da entrega contínua: feedback e colaboração
- 1. Os desafios da entrega contínua @JulianoRibeiro
- 2. Do que falaremos? História Estórias Mais histórias Como eu faço CD Do que eu preciso? Questionamentos?
- 4. Era uma vez, uma empresa em Maringá…
- 5. Enfim, eu era mais um horse
- 7. Era hora de evoluir…
- 8. Subversion
- 9. Hudson
- 11. A saída da empresa
- 12. E então nasceu a…
- 13. HappinessApp
- 14. O que adotamos no início?
- 15. Era hora de evoluir…
- 16. TestFlight
- 17. Sprint 12
- 18. Sprint 14
- 20. Legal, ótimas histórias, mas qual o ponto?
- 21. Uma boa estória
- 24. PO Fênix
- 25. Quais são os passos então? • Tecnologia é suporte – Controle de Versão: SVN, GIT… – Build Contínuo: Jenkins, Hudson… – Ferramentas de Teste: JUnit, OCUnit… • Workshop de escrita de histórias • Refinamento de Backlog • Ferramentas de feedback: TestFlight (iOS)
- 26. Sim, tem tecnologia mas o ponto é FEEDBACK!
- 27. Agile Manifesto Colaboração com o cliente Negociação de Contratos Software em funcionamento Indivíduos e interações Documentação Abrangente Processos e Ferramentas Responder a mudanças Seguir um plano
Notas do Editor
- Como a maioria de todos os que lêem esse texto comecei minha carreira começou com programador. Comecei num tempo em que se comprava revistas e digitava o código todo no PC, apenas para ver um gorila jogando uma banana em outro, do outro lado da tela. Naquele tempo, sinceramente não me recordo de ouvir alguém falando de boas práticas, de código limpo ou de qualquer outra boa prática que temos hoje como verdade. Enfim, sou "das antigas". Assim, eu gerava código como um genuíno horse. Não me preocupava com a qualidade do que eu produzia, simplesmente produzia.
- E com esse background eu fui contratado pela Produtec. Lá aprendi muito sobre programação. Mas principalmente vi um ambiente que refletia aquele meu histórico. E isso me incomodou profundamente. A maior prática que eles tinham até então era um simples controle de versionamento dos arquivos, com arquivos com lock durante o mês de desenvolvimento e só sendo liberados e reintegrados só no momento da liberação da build. Nem preciso falar dos problemas e do tempo que se tomava do momento do início da liberação até ela finalmente ser entregue ao cliente.
- Free VCS, falar dos locks, da integraçãocomplexa, propriedadecoletiva do código.
- E entãocomeçamos a fazerintegraçãocontínua. E só, nãopudemosavançarmais.
- Haviammuitos bugs, a empresaqueria
- Uma nova esperança, uma novacarreira
- A proposta era quepudéssemosfazer as coisasqueacreditávamos, sembarreiras. Sóaceitaríamosprojetosquecoincidissem com nossascrenças.
- Reuniões, overhead e demora no feedback.
- Entãonóscomeçamos a enviaros apps para o TF. E nessemomento,começamos a ter beta tester funcionando.
- Sai twitter e facebookEntra e-mail
- Vídeodemonstrativo
- Uma boa história de usuário é aonde as coisas começam. Se você vai começar a entregar histórias uma a uma essas histórias devem estar na granularidade adequada para tanto.
- Scrum tem uma cerimônia perfeita para isso, o BacklogRefinement. Nessa cerimonia, o ProductOwner tem a oportunidade de revisar junto ao time as historias futuras, debatendo-as com quem realmente ira faze-las. Isso pode ocorrerem qualquer momento, sempre que o PO precisar e o time estiver disponível. Para esse momento devem estar presentes o PO, o Scrum Master e o time. O Scrum Master sempre está presente, pois é de sua responsabilidade facilitar as cerimonias.