Agile / SCRUM

Manifesto Ágil

0.jpeg

[2]

Fluxo

  • Release planning (previsibilidade)
  • Gestão Backlog (planejamento)
  • Planning (alinhamento)
  • Daily (comunicação)
  • Review (responsabilidade)
  • Retrospectiva (melhoria contínua)

Release Planning / Roadmapping

Gestão do Backlog

  • Responsabilidade do Gerente de Produto, especificar e manter sempre priorizado
  • Time faz backlog grooming
    • Todo planning, time entende um pouco das estórias seguintes, estima, tira dúvidas e etc

Planning

  • Pega as hipóteses que estão priorizadas no backlog
  • Quebra em atividades menores (ideal 1 ticket/postit por dia por pessoa)
  • Tira dúvidas com Gerente de Produto/stakeholders
  • Estima tudo

Especificação / Requisitos

  • Deve focar na experiência completa, não apenas nos requisitos
  • Representa o comportamento da aplicação
  • Deve ser legível por: QA, DEV, MKT, SAC, Operação
  • Especificação muda logo após começar!
  • É importante ter requisitos priorizados, wireframes e mocks

Sprint

  • Separe uma parte para refatorações. Qualidade de código é lei.
  • Composição do sprint
    • Bugs reportados pelo cliente
    • Features
    • Bugs internos
    • Refactors
    • Performance (reportado por ferramenta como new relic)
    • Erros de log (tipo sentry)
    • Discoverys
    • Melhorias
    • Otimizações

Daily

  • Todos de pé, em frente ao quadro, mesmo horário, todo dia
  • Cada um fala: o que fez, o que está fazendo e impedimentos
  • Passar pelos pontos “a melhorar”, que veio da retrospectiva
  • Cabe ao SM/PO remover impedimentos toda reunião

Review?

  • Se fizer deploy grande
    • Hora de apresentar tudo em homologação
    • Sempre um dev apresenta (importante alternar, pois ninguém quer apresentar algo com bug. Dessa forma todos ficam com “skin in the game”)
    • PO pode abortar uma tarefa e pedir pra não subir se julgar não estar bom o suficiente (importante levar este ponto pra retrospectiva pra aprender pq desenvolveu e não subiu, onde erramos?)
  • Se for microdeploy (minha preferência)
    • A medida que o sprint anda, no daily o dev ja informa ter acabado
    • PO/QA valida a micro tarefa e libera
    • No final do sprint, está tudo em produção

Retrospectiva

Definição: “Uma reunião especial que o time se reune após completar um incremento do trabalho para inspecionar e adaptar seus métodos e forma de trabalhar” Daiana Larsen & Esther Derby

  • Time avalia como foi o sprint. Etapa crucial para melhorar sempre.
  • Quebrar em: continuar, começar, melhorar e parar
  • Ao final, todos votam nos top 3 postits (cada um tem 3 pontos pra votar)
  • Pegam-se os mais votados, atribuem-se donos (Importante ter as pessoas fazendo parte da solução e não só do problema) e coloca no quadro do time. A idéia é acompanhar diariamente os pontos a se melhorar.
  • Deve-se colocar as pessoas certas na reunião. Stakeholders ou envolvidos no sprint
    • No entanto, a lavação de roupa suja é somente com o time. Ou seja, primeiro os stakeholders passam a visão deles do que melhorar, depois o time segue. [1]
  • O que não deve acontecer
    • esta tudo ótimo e não temos nada pra melhorar
    • debater backlog
    • não ter hora pra acabar
  • https://labs.spotify.com/2017/12/15/spotify-retro-kit/
  • https://www.infoq.com/br/presentations/o-invisivel-das-retrospectivas-ageis

Design Sprint

 

[1] http://www.romanpichler.com/blog/sprint-review-tips-for-product-owners/?doing_wp_cron=1511890677.9049379825592041015625

[2] https://www.linkedin.com/pulse/5-organisational-agility-messages-land-1-hour-executive-chris-webb/

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s