Post on 14-Apr-2017
ScrumDesenvolvimento ágil
Uma breve introduçãoConcebido como uma metodologia para a indústria
automobilística, com nome análogo a formação usada pelos times de Rugby, o Scrum visa ser uma metodologia de alcance de objetivos de maneira ágil.
Suas equipes são enxutas e multidisciplinares, seus processos não são engessados e mudanças fazem parte da rotina.
A comunicação presencial entre a equipe é mais valorizada que a geração de calhamaços de documentos impessoais.
Características- Iterativo: Pequenos ciclos de desenvolvimento.- Incremental: Construção de funcionalidades em
paralelo.- Dinâmico: Mudanças são bem-vindas.- Ágil: Planejamento de curto prazo, possibilidade de
responder a adversidades de maneira mais flexível.
Alguns exemplos reais- Google- Apple- Amazon- Spotify
Personas - P. O.O papel do P.O. (product owner), é garantir os objetivos
dos stakeholders. É fundamental que possa contar com uma equipe hábil e preparada para mudanças de última hora.
Controla o backlog, prioriza as demandas e fiscaliza o resultado.
Personas - Scrum MasterO Scrum Master deve prezar sempre pela evolução da
sprint, devendo tomar as atitudes necessárias para ajudar o time a resolver qualquer problema, principalmente aqueles que ultrapassam o âmbito técnico.
Participa das reuniões diárias, do planejamento da sprint e acompanha o burn down chart.
Personas - Time de desenvolvimentoEngenheiros, designers e programadores; todos
àqueles que estão envolvidos diretamente com a construção das soluções.
Equipes multidisciplinares e auto-gerenciáveis.
Repositório de demandas conhecidas e priorizadas, definidas pelo P.O.
Base para o planejamento das próximas sprints.Equivalente ao Roadmap.Pode ser alterado a qualquer hora pelo P.O.
Ferramentas - Product Backlog
Ferramentas - Sprint BacklogRepositório das tarefas da sprint corrente.Não deve ser alterado durante a sprint.Tarefas distribuídas entre a equipe, sem interferência
do P.O.
Ferramentas - SprintEspaço de tempo definido para o atingimento de um
determinado objetivo.As sprints tem como característica serem de curta
duração, não devendo haver interrupções ou mudanças durante seu curso.
Ferramentas - Burn down ChartGráfico que exibe a estimativa de sucesso de uma
sprint, pode ser gerado manualmente ou através de uma ferramenta integrada ao desenvolvimento da sprint.
É possível prever se a sprint falhará, acompanhando a tendência deste gráfico.
Ferramentas - Burn down Chart
Controle - Sprint planning Reuniões feitas com toda a equipe para que o próximo
sprint backlog seja definido.O product backlog deve ser o guia desta reunião, pois é
nele em que os objetivos e prioridades foram traçadas, servindo então de base para o planejamento da próxima sprint.
Deve-se prezar pela objetividade, reuniões por volta de 2 horas são consideradas ideais.
Controle - Daily MeetingReuniões diárias entre o time e o scrum master.Curtas, no máximo 15 minutos.Recomenda-se realizar a reunião em pé, encurtando e
tornando a mais objetiva.Identificação de problemas que podem impedir o
funcionamento da sprint; resolução pós-reunião.
Controle - Daily MeetingIndagações que podem ser feitas a cada membro do time de desenvolvimento:
- O quê eu fiz ontem?- O quê vou fazer hoje?- Existe algo que impeça o time de alcançar o objetivo?
Controle - Definição de pronto DoDDoD (Definition of Done), ou definição de pronto, é um
documento que contém os passos que uma release deve ser submetida para ser considerada pronta para funcionar em ambiente produtivo.
Definido por todo o time, deve ser freqüentemente revisto e revisitado ao final de cada sprint.
Controle - Sprint retrospectiveUma rápida reunião entre o time, cerca de 30m.Visa apontar as maiores dificuldades encontradas no
decorrer da última sprint, encontrar pontos de falha e pensar alternativas para contorná-las.
Controle - Sprint reviewIncentiva o time a olhar para entrega efetuada e pensar
na coerência técnica do projeto, avaliando o que foi entregue diante do que era esperado.
Pode-se aproveitar uma única reunião para fazer a retrospectiva e o review.
EvoluçãoFatalmente, as primeiras sprints tendem a falhar. Seja
por desconhecimento da capacidade de entrega da equipe, da falta de conhecimento da metodologia ou por algum percalço encontrado pelo caminho.
Deve-se anotar os sucessos e fracassos para serem revistos, não se deve procurar culpados individualmente, mas sim soluções para o time.
Referências- http://www.mindmaster.com.br/scrum/- https://www.scrumalliance.org- http://scrummethodology.com/
ObrigadoGian Vizzotto - gfvizzotto@gmail.com