O documento discute três eixos para pensar sobre qualidade de software: gestão, fatores humanos e engenharia. Também levanta provocações sobre sair da caixa de pensamento tradicional e reflexões sobre valores ágeis e desafios na garantia da qualidade.
3. Esclarecimentos
Uso de boa fé de imagens de outros
Opiniões são minhas, não necessariamente
as das pessoas com quem trabalhei
História não é necessariamente factual
Posso estar errado, e vc tb
Não sou politicamente correto o tempo todo
40. Fluxo ponta-a-ponta
erro defeito falha diagnóstico correção
ão, ão
k e , te ta ç cu ç de s ,
y o f or en x e o
tã ncia e ão
a- m s m e s s s
ok ge t te tr u de s ia te Ges dê o d ção gr
e
P a es es ns ha õe itor luen ci tã ra
tip to
t T I l
i eç ud s f in es gu Re
au P c a o
x / ad G n fi
E g c
o di co
L e
Pr
Integração contínua / agile operations
48. Bebendo na fonte do XP
Pareamento
Automação de testes de aceitação
Automação de testes do programador
Testes como especificação
Retrospectivas
Integração Contínua
Metáforas
Refatoramento
Propriedade coletiva do código
75. O que já sabemos
Quanto maior a distância entre o erro e a
correção, muito maior o custo de corrigir e o
risco de não corrigir
Uso ingênuo de métricas geralmente tem
efeito oposto ao esperado
Registrar o que não é necessário atrapalha a
comunicação.
Um sistema só começa a gerar valor depois
de entrar em produção.
76. O que já sabemos
Registro não garante comunicação
Inspeções / revisões são úteis
Testes através da interface usuário são
caros e frágeis
Ciclos precisam ser de poucas semanas no
máximo
Estimativas furam
Intermediários geram ruído
77. Então por que ...?
… não desapegamos do modelo em cascata /
V?
… investimos tanto esforço em teste
automatizado através da interface de
usuário ?
… documentamos com o principal objetivo de
tirar o nosso da reta ?
… definimos padrões de codificação onde
código bom = código comentado ?