desenvolvimento Ágil e a mudança de mindset envolvida
TRANSCRIPT
Desenvolvimento ágilCarlos Felippe Cardoso (CFC)
[email protected]@carlosfelippe
slideshare.net/cfelippek21.com.br/treinamentos/
Desenvolvimento ágile a mudança no mindset
Carlos Felippe Cardoso (CFC)
[email protected]@carlosfelippe
slideshare.net/cfelippek21.com.br/treinamentos/
Manifesto Ágil
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://www.agilemanifesto.org/
Quais são os principais problemas no desenvolvimento de SW?
Quais são os principais problemas no desenvolvimento de SW?
Já percebeu que a maioria envolve humanos?
“Peopleware”
Métodos ágeis são a confissão de que não sabemos a solução do problema de cara!
Responding to change over following a plan
Customer collaboration over contract negotiation
Beleza! Assumimos que mudanças
acontecem…
Como fazer pra obter feedback mais rápido?
Feedback rápido X
Planejamento extenso
Escolha um.
Construir SW é diferente de construir prédio
Aprendemos a fazer um baita esforço no planejamento
Expectativa
Realidade
E como há um plano, o “recurso” irá executá-lo, basta usar a tática do
chicote para garantir!
recurso recurso recurso recurso recurso recursorecurso recurso recurso recurso recurso recursorecurso recurso recurso recurso recurso recursorecurso recurso recurso recurso recurso recursorecurso recurso recurso recurso recurso recursorecurso recurso recurso recurso recurso recursorecurso recurso recurso recurso recurso recurso
Além do planejamento não precisar ser tão pesado, a nossa forma de
construir SW também precisa mudar!
Entregando por fatiasX
Entregando por camadas
Entregando por camadas
Entregando por fatias
Ciclo Scrum “tradicional”
Working software over comprehensive documentation
Fatos sobre fatiarPriorizando bem, entregamos muito valor logo no início (o que é mais importante)
Permitimos que o projeto acabe antes que os desperdícios apareçam (funcionalidades que ninguém vai usar)
Nosso plano inicial vai mudar
Entregar por fatiasé assumir que o refactoring
é INEVITÁVEL.
“Premature optimization is the root of all evil” Donald Knuth
Como você pode diminuir o impacto dele?
AUTOMAÇÃO
“… Computers are designed to do simple repetitive tasks. The
second you have humans doing repetitive tasks, all the
computers get together late at night and laugh at you…”
Neal Ford
Integração Contínua
Mas a entrega por fatias vai puxar tambem:
Diminuição de silos dentro da própria TI!(criação de times multi-disciplinares)
Falando em agir como time...
A constatação é triste...
A TI cria barreiras para o Negócio colocar código novo em produção!
A constatação é triste...
● Dev x QA● Dev x Ops● Dev x UX● Dev x Dev● ...
A constatação é triste...
● Dev x QA <= Testes automatizados● Dev x Ops <= DevOps● Dev x UX <= Lean UX● Dev x Dev <= Pair Prog
Colaboração!!!
Pegando DevOps como exemplo
E por que isso tudo faz tanto sentido?
(Lead time = tempo total) > 1 mês!!!!As empresas não podem ser tão ineficientes!
Tem que ser rápido, lindo e “du-ca”!
Pontos-chaves para adotarmos
1) Diminuir “Time-to-market”
2) Reduzir Lead Time
3) Melhoria na qualidade
4) Aumentar resiliência
Mas...
1) Produz vários documentos para mandar para outro setor, afinal tudo deve ser bem documentado para servir de “evidência”?2) Nas “salas de guerra”, é comum haver trocas de acusações constantes?3) Alguém sempre diz que não pode ser feito porque a lei SOX não permite, o ITIL não deixa etc?4) Você convida com constância os membros de outras “especialidades” para ajudar no seu trabalho?5) Somos preocupados com o Kaizen, sempre estamos reunindo os vários times envolvidos no projeto para levantarmos pontos de melhoria?
Vamos ver como estamos no teste do “Wall of Confusion”:
livremente inspirado de http://itrevolution.com/devops-culture-part-2/
Beleza! Só derrubar as barreiras então!
“You can’t directly change culture. But you can change behavior, and behavior becomes culture”
Lloyd Taylor
Cavernas (silos) de conhecimento...
Mito do herói!
Na prática, é o famoso funcionário
que perdeu o direito de morrer! :(
Quem é responsável pela qualidade e pelo release?
A transição entre DevOps como prática -> cultura tem tudo a ver com a
agilidade
Ah! E as ferramentas e técnicas estão cada vez melhores!
1) Infra as Code
2) Sistemas baseados em serviços (fail fast)
Ah! E as ferramentas estão cada vez melhores!
3) Containers de Micro-Serviços (ex. Docker)
Evolução dos nossos sistemas
Vamos sonhar alto?
Um bom livro?
