O documento discute os princípios e benefícios do desenvolvimento ágil, enfatizando a importância da colaboração entre times, entrega contínua de valor ao cliente e adaptação constante às mudanças.

1. Desenvolvimento ágil
Carlos Felippe Cardoso (CFC)
cfc@k21.com.br
@carlosfelippe
slideshare.net/cfelippe
k21.com.br/treinamentos/

2. Desenvolvimento ágil
e a mudança no mindset
Carlos Felippe Cardoso (CFC)
cfc@k21.com.br
@carlosfelippe
slideshare.net/cfelippe
k21.com.br/treinamentos/

3. 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/

4. Quais são os principais problemas
no desenvolvimento de SW?

5. Quais são os principais problemas
no desenvolvimento de SW?
Já percebeu que a maioria envolve
humanos?
“Peopleware”

7. 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

9. Beleza!
Assumimos que mudanças
acontecem…
Como fazer pra obter feedback mais
rápido?

10. Feedback rápido
X
Planejamento extenso
Escolha um.

11. Construir SW é diferente de
construir prédio

12. Aprendemos a fazer um baita
esforço no planejamento

13. Expectativa
Realidade

14. E como há um plano, o “recurso” irá
executá-lo, basta usar a tática do
chicote para garantir!
recurso recurso recurso recurso recurso recurso
recurso recurso recurso recurso recurso recurso
recurso recurso recurso recurso recurso recurso
recurso recurso recurso recurso recurso recurso
recurso recurso recurso recurso recurso recurso
recurso recurso recurso recurso recurso recurso
recurso recurso recurso recurso recurso recurso

16. Além do planejamento não precisar
ser tão pesado, a nossa forma de
construir SW também precisa
mudar!

17. Entregando por fatias
X
Entregando por camadas

18. Entregando por camadas

20. Entregando por fatias

21. Ciclo Scrum “tradicional”
Working software over comprehensive documentation

22. Fatos sobre fatiar
Priorizando 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

23. 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?

24. 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

26. Integração Contínua

31. Mas a entrega por fatias
vai puxar tambem:
Diminuição de silos dentro da própria TI!
(criação de times multi-disciplinares)

32. Falando em agir como time...

36. A constatação é triste...
A TI cria barreiras para o Negócio colocar
código novo em produção!

37. A constatação é triste...
● Dev x QA
● Dev x Ops
● Dev x UX
● Dev x Dev
● ...

38. A constatação é triste...
● Dev x QA <= Testes automatizados
● Dev x Ops <= DevOps
● Dev x UX <= Lean UX
● Dev x Dev <= Pair Prog

39. Colaboração!!!

40. Pegando DevOps como exemplo

42. E por que isso tudo faz tanto sentido?
(Lead time = tempo total) > 1 mês!!!!
As empresas não podem ser tão ineficientes!

43. Tem que ser rápido, lindo e “du-ca”!

44. Pontos-chaves para adotarmos
1) Diminuir “Time-to-market”
2) Reduzir Lead Time
3) Melhoria na qualidade
4) Aumentar resiliência

45. Mas...

47. 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/

49. Beleza!
Só derrubar as barreiras então!
“You can’t directly change culture. But you can
change behavior, and behavior becomes
culture”
Lloyd Taylor

50. Cavernas (silos) de conhecimento...
Mito do herói!
Na prática, é o
famoso funcionário
que perdeu o
direito de morrer! :(

51. Quem é responsável
pela qualidade e pelo release?

52. A transição entre DevOps
como prática -> cultura tem tudo a ver com a
agilidade

53. Ah! E as ferramentas e técnicas
estão cada vez melhores!
1) Infra as Code
2) Sistemas baseados em serviços (fail fast)

54. Ah! E as ferramentas estão cada vez
melhores!
3) Containers de Micro-Serviços (ex. Docker)

55. Evolução dos nossos sistemas

56. Vamos sonhar alto?

57. Um bom livro?

58. PERGUNTAS?
cfc@k21.com.br
@carlosfelippe
slideshare.net/cfelippe
k21.com.br/treinamentos/