Como utilizar o scrum na prática? E como aplicá-lo no dia a dia de forma efetiva?
Se você trabalha com gestão de projetos, ou desenvolvimento de software, com certeza já ouviu falar de Scrum. E provavelmente sobre alguns dos cases de sucesso famosos com sua aplicação, como no Spotify por exemplo.
Apesar de sempre vermos o scrum definido como “um framework simples para gerenciar projetos complexos”. A verdade é que ele é bastante prescritivo, e leva um tempo para a equipe se adequar a todas as suas práticas. Mas com certeza podemos alcançar bons resultados com ele.
Neste artigo vou falar dos conceitos deste framework. Este será o primeiro de uma trilha que irei escrever, que irá desde da teoria até o scrum na prática. Vamos lá?
PILARES
Transparência
Todo o time pode e deve ter acesso a todas as informações relacionadas ao projeto. A ideia é que a informação fique compartilhada, e assim, gestores, clientes e stakeholders possam acessá-la a qualquer momento.
Por isso é importante que a equipe defina quais ferramentas irá utilizar para se comunicar, e quais documentos irá gerar no decorrer do processo. Já que isso não é definido pelo Scrum, que deixa essa parte por conta do próprio time, para que faça da melhor forma.
Uma ferramenta que pode auxiliar nisso, originada de outra metodologia ágil é o quadro kanban. Que pode dar visualização de como estão todas as atividades do time.
Inspeção
Tanto o desenvolvimento das atividades, quanto a execução do próprio processo podem ser inspecionados a qualquer momento. A intenção da inspeção é que todos fiquem sempre alinhados sobre a situação do projeto. Mas essa inspeção, não deve ser excessiva a ponto de atrapalhar o desenvolvimento das atividades, ou de micro-gerenciar as pessoas.
Na parte do desenvolvimento a inspeção ocorre através de dois eventos, que são “Daily Scrum” e “Sprint Review”. Já o processo, pode ser inspecionado durante a “Sprint Retrospective”. Todos esses eventos, serão explicados mais abaixo.
Adaptação
O último pilar, garante que o processo do Scrum seja sempre adaptado quando necessário. O mesmo é válido para as diretrizes do produto, que como possui ciclos menores de interação com o cliente, também tem a possibilidade de ser adaptado com maior facilidade.
PAPÉIS
Product Owner (P.O.)
Responsável por direcionar o produto, é ele quem define quais as funcionalidades que serão desenvolvidas. E também faz a priorização delas para o time. Além disso, ele deve sempre deixar claro quais são os objetivos daquele projeto e passar a visão do produto para sua equipe.
Scrum Master (S.M.)
É o membro da equipe que deve dominar as práticas do Scrum. Conhecido como facilitador, ele sempre auxilia e garante que o time está executando o processo corretamente.
Dev Team
É quem propriamente desenvolve o produto, e tem o poder de decidir a melhor forma de fazer isso. No Scrum o time de desenvolvimento tem autonomia para escolher de qual maneira irá desenvolver suas tarefas, para atingir os objetivos do projeto. A equipe deve ser auto organizada e multifuncional.
EVENTOS
Sprint Planning
Nessa reunião, o dev team conversa sobre os itens do product backlog e seleciona o que entrará na sprint backlog. Sempre respeitando a ordem de priorização definida pelo P.O.
Além disso, o time também aproveita para debater como a demanda será desenvolvida, e nessa hora o P.O. pode explicar os requisitos e objetivos daquela estória de usuário. Assim a equipe conseguirá ter um entendimento mais claro, e poderá definir em conjunto qual a melhor forma de atender a demanda.
Daily Scrum
Reunião que deve acontecer diariamente para que toda a equipe fique alinhada sobre o andamento do projeto. Deve ser feita com todos os membros de pé, pois precisa ser algo rápido, durando no máximo 15 minutos.
Normalmente os desenvolvedores respondem a 3 perguntas:
- O que foi feito ontem?
- O que planeja fazer hoje?
- Teve ou tem algum impedimento?
Sprint Review
Realiza ao final de toda sprint, essa reunião serve para avaliar se todos os itens de trabalho da sprint estão de acordo com o que cliente espera. Aqui o time apresenta o que foi desenvolvido para o P.O., e ele irá avaliar a entrega.
Nesta reunião, é comum a participação de stakeholders do produto. E nela também, que podemos realizar a manutenção do product backlog.
Sprint Retrospective
Realizada após a review, a reunião de retrospectiva serve para equipe avaliar como está trabalhando como o framework em si. Ou seja, como estão utilizando o scrum na prática e quais os resultados disso.
Alguns textos falam sobre levantar pontos negativos e positivos da sprint. Mas eu prefiro os autores que sugerem utilizar os seguintes questionamentos:
- O que fizemos de bom?
- O que precisamos melhorar?
E para tudo aquilo que precisamos melhorar, a equipe pode definir uma ação.
ARTEFATOS
Product Backlog
Lista de funcionalidades do produto, é criada, priorizada e mantida pelo P.O., utilizada pelo time durante o sprint planning.
Sprint Backlog
Funcionalidades selecionadas do product backlog, pelo time de desenvolvimento durante o planning. O ideal é que essa lista de itens, seja entregue no final da sprint.
Entregas Incrementais
Ao final de toda sprint, a equipe deve incrementar o produto com um entrega funcional.
Este foi o primeiro artigo da trilha de “Scrum na prática”. Onde dei uma introdução dos conceitos deste framework. E no segundo artigo, você pode conferir como funciona o fluxo do scrum.
