Latest / Entre Chaves / Snippet #14 Mentalidade Shift Left para eliminar surpresas no desenvolvimento

Transcript

Snippet #14 Mentalidade Shift Left para eliminar surpresas no desenvolvimento · Entre Chaves

• 0:09
  OPA, e aí, pessoal, tudo bem? Boa tarde.
• 0:11
  Me chamo Henrique Oliveira, sou o queaki da dti e vamos lá.
• 0:14
  Hoje eu queria trocar uma ideia com você sobre um conceito que
• 0:16
  na prática muda bastante a forma como o povo trabalha com
• 0:19
  qualidade dentro de um time de desenvolvimento, que é o tal do
• 0:21
  shift left cara. Uma coisa que é muito comum no
• 0:24
  dia a dia é a gente tratar a qualidade como etapa, tipo
• 0:26
  assim, o primeiro desenvolve, depois testa.
• 0:28
  E assim, esse modelo fez muito sentido por muito tempo,
• 0:30
  principalmente em contextos mais estruturados, onde as etapas
• 0:33
  eram mais bem definidas. Só que conforme os sistemas
• 0:35
  foram ficando mais complexos, mais integrados, e o ritmo de
• 0:38
  entrega foi aumentando, começou a ficar mais importante dessa
• 0:40
  visibilidade de qualidade ao longo do processo todo, e não
• 0:43
  somente no final. E é justamente nesse contexto
• 0:45
  que começa a surgir o shift left.
• 0:47
  Esse conceito não é só textar mais cedo, ele se trata de uma
• 0:50
  mudança toda de mentalidade. É sair da ideia que o que é a
• 0:52
  valida no final e começar a pensar que a qualidade é
• 0:54
  construída desde o começo do processo.
• 0:56
  E isso mudou bastante o papel do que há dentro do time.
• 0:59
  Ele deixa de ser a pessoa que encontra problema e passa a ser
• 1:01
  alguém que ajuda a evitar que problemas sequer aconteça.
• 1:03
  Isso aparece muito na prática, em alguns momentos bem
• 1:05
  específicos do dia a dia, tipo reunião de levantamento de
• 1:08
  requisito, refinamento de história, discussão de fluxo,
• 1:10
  que são justamente os momentos onde o time está para tentar
• 1:12
  entender o que precisa ser feito e quando o quer, participa com o
• 1:15
  olho de águia. Ali começa a acontecer uma coisa
• 1:17
  interessante, por exemplo. Mas não é um caso simples, né?
• 1:19
  Você está no reframento e surge uma regra de negócio envolvendo
• 1:22
  a quantidade de convidados num evento.
• 1:23
  E aí você levanta a seguinte pergunta, e se AAPI devolver um
• 1:26
  valor inválido, tipo menos um convidados nunca o é PO site vão
• 1:29
  lidar com isso? Parece que é detalhe, mas é esse
• 1:32
  o tipo de pergunta que já força time a pensar em validação,
• 1:34
  comportamento, fobec esperado e evita ter que resolver um
• 1:37
  potencial problema lá na frente. E esse tipo de situação abre um
• 1:40
  ponto que é muito importante dentro de shift left, que é
• 1:42
  análise de risco, que nem sempre o objetivo é cobrir
• 1:45
  absolutamente todos os cenários, mas sim entender quais cenários
• 1:48
  realmente importam dentro do contexto do projeto.
• 1:50
  E tudo bem que às vezes o valor inválido pode só quebrar um
• 1:52
  layout, mas também pode impactar a regra de negócio, cobrança ou
• 1:56
  gerar inconsistência no sistema. E quando esse tipo de discussão
• 1:58
  acontece cedo, o time consegue priorizar melhor o que precisa
• 2:01
  ser tratado com mais cuidado. Isso conecta com um fenômeno
• 2:04
  enorme, cada vez mais presente hoje em dia também, que é o uso
• 2:06
  de a no próprio processo de desenvolvimento.
• 2:09
  Hoje já é muito comum ver histórias de usuário sendo
• 2:11
  gerado com apoio de a critério de aceite sendo sugerido
• 2:13
  automaticamente e inegavelmente, isso acelera bastante o
• 2:16
  processo, mas também traz um ponto de atenção importante,
• 2:18
  porque quando você gera critério de aceite com IA, você pode
• 2:20
  gerar também ambiguidade com IA, pode gerar lacuna, pode gerar
• 2:23
  cenários não previstos, e é justamente aí que o papel do Ka
• 2:26
  fica ainda é mais importante. Não é só verdade, depois é
• 2:28
  questionar, antes é olhar para aquele cenário de aceitação e
• 2:30
  pensar, isso aqui cobre todos os cenários.
• 2:33
  Isso aqui faz sentido contercial.
• 2:34
  O que que pode dar errado aqui? Que qualidade não nasce da
• 2:36
  ferramenta ou nem na IA, mas ela nasce da forma como o time
• 2:39
  interpreta e valida aquilo. E quando isso não acontece, o
• 2:42
  que geralmente vem depois daquele efeito dominó, pressão
• 2:45
  para testar rápido, corte de cenário importante, decisão sem
• 2:48
  clareza de risco, correção mais cara e releas cada vez mais
• 2:51
  instáveis. Agora, o que não nossa Retro
• 2:52
  qualidade para esse começo do processo?
• 2:54
  O jogo muda, você vai continuar tendo problema?
• 2:56
  Lógico que sim, mas ajuda o time a tomar decisão mais
• 2:58
  inconsciente e esse pra mim, os funcionais importantes.
• 3:01
  Papel do que anão é ficar travando release história de
• 3:03
  usuário é trazer clareza pro time, clareza do que foi
• 3:06
  testado, do que não foi e principalmente do risco
• 3:08
  envolvido. E isso muda bastante a dinâmica
• 3:10
  dentro de um time que uma vez do que a serviço, como um gargalo,
• 3:12
  ele passa a ser alguém que ajuda o time a tomar decisão, tipo,
• 3:15
  OPA, isso aqui foi bem testado, ou isso aqui tem risco ou essa
• 3:18
  parte aqui a gente não cobriu ainda e com essa visibilidade o
• 3:21
  time consegue decidir com muito mais consciência do que fazer.
• 3:24
  Sempre afinando o processo de maneira contínua, até porque no
• 3:26
  fim do dia toda A Entrega tem risco.
• 3:28
  A diferença é se o time está ciente dele ou não.
• 3:30
  E além dessa parte, mais de processo e colaboração, tem um
• 3:33
  outro ponto que potencializa muito isso tudo, que é a
• 3:35
  automação. Quando a gente se testa os
• 3:37
  automatizados rodando pipeline em CICD, cria se um ciclo de
• 3:40
  feedback muito mais rápido. Toda vez que alguém altera
• 3:42
  alguma coisa no sistema, já tem teste rodando, já tem validação
• 3:45
  rolando. Então um erro deixa de ser algo
• 3:47
  que você descobre depois e passa a ser algo que você detecta
• 3:49
  praticamente na hora. E isso muda completamente a
• 3:51
  velocidade com que um Squad aprende e se ajusta.
• 3:54
  Um outro ponto que eu acho interessante também é que isso
• 3:55
  muda a forma como o Tim enxerga o problema, que quando a
• 3:57
  qualidade só aparece no final, o problema ali é uma surpresa ali.
• 4:01
  Agora, quando você trabalha com essa mentalidade mais voltada
• 4:03
  pro shift left, o problema passa a ser parte do processo.
• 4:05
  Ele aparece mais cedo, com mais contexto, com mais tempo pra ser
• 4:08
  digerido e entendido. Isso tira muito aquela sensação
• 4:11
  de ficar colocando o código Band aid o tempo todo.
• 4:13
  Bom, no fim, não é sobre evitar 100% dos problemas, é sobre
• 4:16
  fazer com que eles apareçam no momento certo, quando ainda dá
• 4:18
  para lidar com eles com tranquilidade.
• 4:20
  E, no fim das contas, isso tudo vai muito além de ferramenta ao
• 4:23
  processo. É muito mais sobre cultura
• 4:24
  interna, sobre o time se sentir responsável pela qualidade,
• 4:27
  sobre ter espaço para discutir problema antes dele acontecer,
• 4:30
  que quando se vira parte do dia a dia, a qualidade deixa de ser
• 4:32
  metapa e vira uma característica do produto que a gente entrega.
• 4:34
  Mas, no fim das contas, o shift left não é só sobre testar mais
• 4:37
  cedo, é sobre entender que a qualidade da responsabilidade do
• 4:39
  Sol, do que há, é do time inteiro e quando isso começa a
• 4:41
  acontecer de verdade, mudou completamente o nível do que
• 4:44
  você entrega para o cliente. É isso.
• 4:45
  Espero ter feito sentido e até a próxima.