Cockpit – Health check e dti flow
Quiz para apoio da reciclagem sobre as verticas health check e dti flow.
0
0
0
1
Sobre a vertical do health check é verdadeiro:
Reflete a saúde do squad em relação aos pilares de produto, design, engenharia e operação.
Reflete a saúde do squad em relação a qualidade de execução dos ritos.
Reflete a saúde do squad em relação a todos os pilares e sobre do dti flow.
2
Sobre a pergunta de risco do CO:
Caso meu time esteja apontado como risco "baixo" na gestão a vista, posso marcar 3 estrelas.
Caso meu squad esteja apontado como "atenção" posso marcar 3 estrelas, por que a pergunta é sobre risco alto e muito alto.
Se meu squad estiver apontado como risco "baixo" na gestão à vista é importante conversar e entender se reflete a realidade, podendo até mesmo marcar 1 estrela.
Se meu squad tiver apontado como risco "alto" ou "muito alto", é só marcar 1 estrela que a operação vai se aproximar para fazer um plano juntos.
3
Sobre velocidade e WIP, é verdadeiro:
A velocidade e WIP podem ser medidos no azure devops.
Essa é uma pergunta de feeling, pois ninguém melhor do que as pessoas que estão desenvolvendo para dizer como foi a sprint.
O WIP (work in progress) é quando a pessoa que está desenvolvendo está fazendo mais de uma atividade por vez, nesse caso deve mudar a atividade para blocked para baixar o WIP.
4
Sobre a saúde do backlog, é verdadeiro:
O principal indicador de um bom backlog é ter histórias bem refinadas, mesmo que pouquissimas.
Não é possível ter métricas sobre o backlog, pois trata-se uma única lista de itens a ser priorizada pelos POs.
O backlog é responsabilidade de todos: designers, POs e devs.
5
Sobre operação organizada, é verdadeiro:
Para os times que trabalham com kanban, é necessário ter lead time e cycle time, já os times que trabalham com Scrum, só o burndown é sucifiente.
Existem algumas métricas básicas que todo squad deve ter: burndown/burnup, Cumulative Flow Diagram, Cycle time e Lead time, quadro kanban.
Se o time não tem métricas, mas está com sentimento que a operação vai bem, pode marcar 3 estrelas.
6
Sobre entrega de valor, é verdadeiro:
Se o PO homologou o pacote de entrega e não tem nenhum bug, a história já pode ir para o status "closed".
Na hora de responder sobre a entrega de valor, é importante relembrar a proposta de valor do canvas de produto, não é necessário verificar o objetivo do cliclo ou sprint.
Caso o time tenha alguma dependência externa, pode realizar um deploy técnico para ajudar a reduzir os riscos de implantação
É imprescindível que o PO esteja na hora de responder essa pergunta, pois é ele quem sabe se estamos gerando valor e isso não é possível saber por meio de métricas.
7
Sobre a qualidade de código, é verdadeiro:
Não existe a necessidade de ter uma ferramenta para avaliar a qualidade de código, pois as boa práticas podem garantidas por meio de um checklist.
A qualidade de código não influencia do tempo de desenvolvimento, pois trata-se apenas de boa práticas.
Falhas de segurança, baixa manutenibilidade, falta de organização, código não legível e complexo, são indicadores de baixa qualidade de código.
8
Sobre o dti flow, é verdadeiro:
Existem outras versões do dti flow para outros contextos.
Todas as etapas que devem ser feitas com os DLs são instransferíveis.
Todos os squads são obrigados a executar, pois é um fluxo para garantir a qualidade.
9
Sobre a reunião de história, é verdadeiro:
A reunião de história é necessária apenas para os times com baixa maturidade ou que começaram recentemente.
Em casos que o DL for pegar alguma atividade para desenvolver é necessário que faça a passagem de história com outra pessoa do time.
Caso o time tenha feito o refinamento todo em conjunto não existe a necessidade de fazer a reunião de história.
10
Sobre o checklist de história, é verdadeiro:
O checklist deve ser passado entre o roteiro de testes e a validação em dupla.
Existe um padrão de checklist que deve ser seguido por todos os squads da dti.
O checklist contribui apenas com padrões de qualidade, mas não evita bugs.
11
Sobre o teste de bancada, é verdadeiro:
Desde que o roteiro de testes seja muito bem escrito e bem validado com outro membro do time, não é necessário fazer o roteiro antes de iniciar o desenvolvimento.
Não é necessário fazer o roteiro de testes para correção de bugs, uma vez que ele já passou por um roteiro de teste anteriormente.
É uma boa prática descrever todos os casos de erro possíveis, para depois descrever o cenário de acerto.
12
Sobre a validação em dupla, é verdadeiro:
Se o squad estiver muito apertado com a entrega, não é necessário fazer a validação em dupla, desde que o desenvolvedor tenha sido bem criterioso nos seus testes.
A dupla de testes deve atuar como um usuário, buscando falhas que não foram pensadas Durante o desenvolvimento,
A validação é um passo muito importante em que o desenvolvedor mostra o funcionamento da funcionalidade enquanto a outra pessoa da dupla observa se ocorreu como planejado.
13
Sobre testes automatizados, é verdadeiro:
Testes automatizados é um universo bem grande (por isso demos várias recomendações no material) e é importante que o squad se esforce para fazer todos os tipos de testes para então marcar 3 estrelas.
Todas as funcionalidades do produto devem ter testes automatizados, pois é uma boa forma de reduzir atividades manuais.
É importante que o squad já inicie pensando em testes automatizados, pois trata-se de um investimento de médio/longo prazo.
14
Sobre o sonar, é verdadeiro:
O Sonar é uma ferramenta para auxiliar na qualidade de código e permite várias configurações para adequar à realidade do squad.
Considerando que toda a dti utiliza o Sonar, é aceitável meu squad não ter, pois estamos com dificuldade de configurá-lo. (Gente, quem marcar essa... nem sei....)
O sonar é um tipo de gestão a vista sobre engenharia e deve ser observada pelos arquitetos e DLs, não é necessário que todos do time reflitam sobre as métricas.
15
Sobre o code review, é verdadeiro:
A única função do code review é ter mais um etapa de qualidade, evitando bugs em produção.
Apesar de ser uma boa prática pra compartilhar conhecimento, não permite discutir soluções diferentes, pois o código já está pronto e isso causaria retrabalho.
O code review é também um boa prática para reduzir fragilidades, pois dessa forma o código que está sendo gerado não fica retido apenas em uma pessoa.
