Manifesto Ágil
[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/
