Estudo: Certified Scrum Developer

ESTUDO

Avaliar pontos relevantes e melhorias a serem aplicadas no time Tambaqui.

Resultado de pesquisa

02 de Setembro de 2021

Visão geral

Nesse documento vem levantar as possíveis melhorias a serem aplicadas no time Tambaqui.

Aprendizados

• • Sobre como a complexidade aumenta de acordo com as incertezas seja na parte do QUE fazer ou do COMO fazer.
•  
  • O que os clientes querem é prazo e custo (vai depender dos requisitos) e o que nós (time SCRUM) precisamos é dos requisitos para poder estimar.
•  
  • Através dos ciclos curtos junto com a inspeção e transparência (eventos do scrum), pegamos o caos de projetos grandes e/ou complexos e passo-a-passo (a cada MVP entregue), vamos em direção à claridade e mais perto do produto final.
•  
  • Benefícios da metodologias ágeis:
    • Feedback a cada sprint
    • TimeToMarket curto
    • ROI (Return of investiment) - se o investimento acabar antes do fim do produto, vai ter valor entregue.
•  
  • SPRINT (valor) não é REALEASE (MVP - conjunto de valor). Product Owner que define junto ao cliente quando será as RELEASEs.
•  
  • Papéis e eventos SCRUM:
    • Product Owner lidera os stackholders e juntos, eles levantam as necessidades. Idealizam o produto.
    • Com as necessidades levantadas, é montado pelo Product Owner o Product Backlog.
    • A Sprint entrega incremento do produto. A cada incremento, vamos rumo à visão do produto.
    • Na planning, o time SCRUM monta a Sprint Backlog puxando do Product Backlog. Os DEVs são os donos da Sprint Backlog.
    • A Daily é um momento de alinhamento dos DEVs e deve ocorrer diariamente.
    • Sprint Review é um momento onde os stackholders podem ver o que foi desenvolvido (transparência) e dar seus feedbacks (inspeção).
    • Retroespectiva, é um momento de calibragem do time SCRUM. É onde vemos o que deu certo, o que deu ruim e o que pode melhorar.

O que podemos aplicar no time TAMBAQUI

• • É importante ter um refinamento no meio da Sprint (se possível no 5º ou 6º dia de Sprint) pois o Product Owner pode levantar os requisitos e reescrever as storias antes da planning, e assim, diminuir o tempo/esforço do QUE para termos um COMO menos exaustivo.
  • Usar o Miro como ferramenta para refinamento e planning. Será mais prático e depois é só jogar no Pipefy. Onde no COMO da planning, jogamos todas as ideias de tasks no Miro e refinamos antes de jogar no Pipefy.
  • Usar post its ao invés do Planning Poker. Fica mais fluído, simples e prático.

Conclusão

Achamos ótimo o curso para se aprofundar um pouco mais no Scrum, ter uma overview de como funciona e o que cabe a nós tanto como desenvolvedores quanto time Scrum (junto ao P.O. e S.M.). Permitiu que nós pudéssemos ter mais empatia pelos outros papéis ao ver as responsabilidades deles. Como, por exemplo, o Scrum Master que tem que garantir a produtividade do time. Ao invés de ver certas atitudes e iniciativas como cobrança, ver como uma forma de poder avaliar e ajustar o que for preciso para o nosso dia a dia ser mais fluído. Foi bom entendermos que esse curso não é só pra DEVs mas para quem está ali no dia-a-dia metendo a mão na massa para desenvolver o produto (designer, tester, etc).