Skip to content

Instantly share code, notes, and snippets.

@rodrigozrusso

rodrigozrusso/agility.md

Created May 30, 2021 20:48
Show Gist options
  • Save rodrigozrusso/4d87c4ffd100c665a299df5843483bae to your computer and use it in GitHub Desktop.
Save rodrigozrusso/4d87c4ffd100c665a299df5843483bae to your computer and use it in GitHub Desktop.
Download ZIP
Bootstrap de agilidade - Fluxo de trabalho
Raw
agility.md

Bootstrap de agilidade - Fluxo de trabalho

Publico alvo

  • Times novos
  • Times já formados, porém que não seguem nenhuma metodologia
  • Times já formados, porém que não conseguem realizar entregas de valor continuamente.

Preparação

Realizar 3 ou 4 encontros com todos do time (Engenharia + Produto + QA + SRE). É impressindível todos participarem de todos os encontros para auxiliar no team building e também para criar ownership dos acordos firmados. Recomendo agendar encontros de 1h30 em dias sequentes para não ficar massante e para que as pessoas possam digerir o assunto.

Introdução

Cada time é um time, e pode ser que você avance mais ou menos com o time que estiver aplicando a construção do fluxo de trabalho.

  • Começar explicando o que é agilidade. Nos próximos dias vamos definir nosso fluxo de trabalho. Fluxo de trabalho é sobre agilidade, que por sua vez é sobre resiliencia, que na prática é sobre o quanto conseguimos no adaptar ao longo do tempo. Podemos ver o exemplo da Kodak, uma empresa que sucumbiu a medida que as camêras digitais foram nascendo. Neste caso entendemos que a Kodak não é uma umpresa que se adaptou ao longo do tempo. Enquanto ela se manteve firme em manter a produção de camêras análogicas, outra empresas ganharam o mercado com cameras digitais. É justamente isso que queremos evitar, mesmo em uma granularidade menor, nosso time não quer ser a próxima Kodak, por isso é importante nos adaptarmos em ciclos curtos. Diferente métodos ágeis trazem diferentes abordagens sobre o tempo da iteração, também conhecido como sprint, como definido no Scrum. Como estamos falando de agilidade, não vamos nos prender a utilizar uma metodogia ou outra, vamos combinar diferentes práticas para entrarmos o que funcina para nós. É importante deixar claro que vamos acertar e vamos errar, e quando errarmos precisamos identificar e corrigir rápido, por isso minha sugestão é que nossa iteração ou sprint seja de 2 semanas, para iniciarmos. Ao longo do tempo podemos rever esse tempo. Todos confortáveis em começarmos com a iteração de 2 semanas?

Iterações de 1 semana exigem mais maturidade dos times, não recomendo começar com 1 semana. Para times de mobile também é uma boa prática ao longo do tempo diminuir a iteração para 1 semana para alinhar com release train de publicação de apps nas lojas

Mas o que vamos fazer nestas duas semanas?

Vejo que há 3 cerimônias importantes para começarmos a fazer.

  1. Planejamento:
  • Reunião de 1h com todos do time a cada 2 semanas.
  • PM facilita a reunião.
  • Todos contribuem para a discussão e priorização.
  • É importante que engenharia traga itens de débito técnico para o planejamento
  • É importante já definir o dia da semana que será.
  1. Daily
  • Reunião de 15 min todos os dias com todos os participantes do time.
  • Minha sugestão é deixar o clássico das 3 perguntas do scrum de lado, pois essa prática foca no que as pessoas estão fazendo, e neste caso, não queremos que seja uma reunião de status report, mas sim algo que ajude o time a avançar com as demandas até produção.
  • Sugestão de dinâmica para daily é utilizar o Ask Kanban: https://www.cursospm3.com.br/blog/reunioes-de-daily-cards-pm3/
    • Esta prática foca em entrega de valor, senso de urgência, mostrar coisas que as pessoas estão fazendo fora do quadro e remover impedimentos.
  • Facilitador: vamos aproveitar e já definir o facilitador desta reunião, neste caso, minha sugestão é rotacionar toda semana. Ou seja, a cada semana, uma pessoa realiza as perguntas, direciona a reunião, e puxar o foco da reunião. Pode-ser começar a rotacionar por ordem alfabética, assim fica justo para todos.
  1. Retrospectiva
  • Esta cerimônia será crucial para inspecionar e adaptar nosso processo/fluxo de trabalho e práticas, além de outros incomos que estão acontencendo ou que aconteceram durante a iteração.
  • Ao final das duas semanas é importante entender o que deu certo e o que precisa melhorar.
  • É importante já definir o dia da semana que será. Minha sugestão é que seja um dia antes do próximo planejamento, assim cria um senso de trabalho fechado.
    • Não necessariamente uma iteração precisa começar na segunda e finalizar na sexta-feira da semana seguinte, isso depende do time e da dinâmica do time. Pergunte ao time qual dia seria melhor.
  • Sugestão de dinâmica padrão: - 3 colunas: 1. O que foi bom? 2. O que podemos melhorar? 3. Ações - Dinâmica: 1. Criar um quadro virtual com as colunas acima para pessoas incluírem os card nas colunas 1 e 2. - Possíveis ferramentas: https://easyretro.io/, https://www.parabol.co/ - Os cards não podem estar visíveis enquanto as pessoas adicionam os itens (evitar viés) 2. Compartilhar o link do quadro para as pessoas 1 dia antes ou deixar 10 min iniciais da cerimônia para participantes incluirem os cards. 3. Ler todos os cards e mesclar assuntos/tópicos simulares. 4. Solicitar aos participantes que votem nos cards que serão discutidos (sugestão de 3 votos por participantes) 5. Discutir os cards mais votados e criar ações com responsáveis na coluna 3.

Vamos definir a ferramenta e o quadro

  • Explicar que vamos utilizar kanban, que é um sistema puxado. O objetivo é levar o quanto antes e mais rápido os itens da esquerda para a direita. Idealmente itens não voltam para a coluna anterior, incluive um blocker.
  • Definir com o time a ferramenta que você utilizarão para o Quadro Kanban (se quiser eu adiciono a história aqui para explicar a importancia do quadro).
  • Na escolha da ferramenta, escolha uma que:
    • o time se sinta confortável em utilizar no dia a dia.
    • seja simples
    • seja possível coletar métricas (isso vai ajudar mais para frente).

Desenhar o fluxo

  • Criar uma quadro kanban limpo.
  • Pedir para o time descrever todos os passos desde a ideia até deploy em produção de uma mudança.
    • Se quiser focar no delivery, pode-se perguntar para o time: O que eu preciso fazer para que uma mudança em uma linha de código chegue até produção?
  • Conforme o time for explicando, comece a definir as colunas na ferramenta. Não se preocupe, posteriomente vocês vão renomeando e corrigindo. Se a ferramenta for o Jira isso é mais complicado de fazer ao vivo pq demanda configuração, neste caso, sugiro utilizar o https://easyretro.io/ para definir as colunas.
    • Alguns questionamentos são imporantes aqui:
      • Em que momento/coluna fica o card quando um PR está aberto aguardando revisão?
      • Em que momento/coluna fica o card quando é testado por QA? (times que dependem de um tester tendem uma fase de teste manual. A ideia e evidênciar isso no processo/colunas para provicar o time para automatizar esse passo).
      • Em que momento/coluna fica o card quando o card é mergeado na branch principal? (para que times que utilizam gitflow, questionar sobre quando o card vai para develop ou main)
      • Em que momento/coluna é criada uma tag no repositório? e fechamos uma versão?
      • Em que momento/coluna é realizado o deploy em staging/UAT/homolog?
      • Em que momento/coluna é realizado o deploy em Prod?
      • O que é done para nós? (pra mim done é o usuário utilizando o código modificado)

Definir 'Definition of Done' e 'Definition of ready'

  • Algumas etapas (colunas) do processo precisam de acordos de quando um card entra ou sai e segue para a próxima coluna.
  • Ir coluna a coluna e descrever com o time o DoD e DoR. Eventualmente haverá apenas um nas colunas.
  • Importante: na última coluna, em que o card será fechado, definir claramente com o time o que é done.
  • Importante: descrever se é esperado que o PR esteja revisado, mergeado. Descrever em qual ambiente a mudança está implantada.

Definir tipo de trabalho

Definir os tipos de trabalho com o time, e descrever cada um deles para não haver confusão posteriomente. Criar labels para cada tipo de trabalho. Isso ajudará a coletar métricas. Alguns exemplos:

  • user story ou feature: New features or enhancements for the product
  • bug: Something isn't working
  • data: Item for data analysis
  • incident: Incident on production
  • tech (technical debit): Technical debit or security issues

Classes de serviço

Classes de serviço são como raias em uma piscina. Imagine uma turma com nadadores iniciantes, intermediários e avançados. Não é possível misturar todos os nadadores em uma raia só, se não a velocidade entre eles será comprometida. No kaban a ideia é a mesma, em alguns momentos precisamos de uma raia para aumentar o ritmo e ganhar velocidade. Em geral, a única que eu costumo definir no inicio é o expedite. O Expedite é necessário, pois eventualmente algum problema ou alguma demanda urgente pode acontecer. O Expedite é como se fosse a faixa de onibus para os taxis, pois se a via estiver com transito, o taxi pode entrar na faixa de onibus e idealmente chegará mais rápido. Outro exemplo é a faixa da esquerda na Autobahn na Alemanha, é uma faixa exclusiva sem limite de velocidade, entra ali quem precisa chegar antes ao destino. No Expedite, o time todo deve ser informado que um item entrou e o time se organiza para parar algum trabalho que esteja em andamento para imediatamente começar o item em expedite. Em algumas situações o time todo precisa ser envolvido.

Criar um label:

  • expedite: Item with this label take high priority

Outro exemplo é uma classe de serviço para itens com data fixa de entrega, isso pode ocorrer em times que atuem com algo relacionado a legislação/banco.

Outros labels importantes

  • Blocked Pensando que estamos em um sistema puxado, ter uma coluna de blocked não faz sentido, pois um item bloqueado é uma etapa/fase do processo, mas sim um problema que ocorreu durante o processo. Desta forma, sugiro criar uma label:
  • blocked: Item with this label shows that is blocked

Explicar para o time que temos que fazer o máximo possível para desbloquear o item o quanto antes. Pense em uma linha de produção de carros, se a parafusadeira quebra no momento de adicionar a porta no veículo? isso irá parar e atrasar a produção toda, aqui a ideia é a mesma, ou seja, precisamos substituir a parafusadeira o quanto antes. Exemplos comuns são:

  • acesso a ambientes

  • problema com máquina

  • dependencia de outros times (pode-se aplicar inner-sourcing para remover)

  • Unplanned Algo que vejo que é interessante é criar uma label para itens que não foram planejados durante a sprint. Em ferramentas como Jira essa problema já é evidênciado pela ferramenta, mas para outras ferramentas é interessante mapear os itens que entraram durante a iteração após a reunião de planning. Isso irá ajudar o time a entender se estão planejando bem ou não, e se há muita interferencia externa.

Ufa!

Esse é um resumão de vários conceitos. Tem vários exemplos que costumo descrever durante a dinâmica.

Ações

  • Criar agendamento recorrente da cerimônia de daily
  • Criar agendamento recorrente do planejamento - 1h a cada 2 semanas.
  • Criar agendamento recorrente da retrospectiva - 1h30 a cada 2 semanas.
  • Criar quadro kanban com o fluxo definido pelo time.
  • Criar labels para identificar cada tipo de trabalho
  • Criar labels para classes de serviço.
  • Criar demais labels
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment