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”, não podemos deixar de considerar 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. Nunca deixando de lado 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 correspondem às expectativas dos clientes. 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.
