Scrum

As metodologias ágeis chegaram pra ficar e a gestão de projetos se tornou mais próxima de todos com elas.

Uma das mais usadas o Scrum ainda deixa muitas dúvidas nas cabeças e resolvi postar um esclarecimento aos não iniciados, espero que vocês gostem.

O termo “Scrum” foi cunhado por Takeuchi e Nonaka em alusão à formação do Rugby, em que todo o time está junto buscando a posse da bola. Se alguém quebra a formação, todo o time perde. Da mesma forma, quando alguém consegue a posse da bola, o time inteiro é responsável. Ou seja, os indivíduos são menos importantes do que o time em si.

1 – Planning Meeting – Reunião de Planejamento

A Planning Meeting limita-se a 5% da Sprint, e é um processo de planejamento. O time se reúne com o Scrum Master, que trabalha mais a parte da facilitação, os desenvolvedores, para pensarem na parte mais técnica de como realizar certas tarefas. Nisso, o Product Owner é responsável por priorizar um grupo de itens que agregue o máximo de valor possível.

O P.O. chega na reunião com o Product Backlog, lista ordenada ou priorizada dos itens a serem feitos durante o projeto. A ideia é sair da reunião com a lista priorizada dos itens e sub-itens técnicos que o time está comprometido a fazer durante a Sprint em questão. E também com uma meta, uma frase que exprima o valor a ser entregue ao cliente.

O Product Backlog, a lista ordenada de itens a serem feitos no projeto, é o artefato que ajuda o P.O. a manter todos esses pedidos organizados. O P.O. é responsável por mantê-lo atualizado e priorizado de modo a agregarmos o máximo de valor possível para o cliente a cada iteração.

Resumindo, a Plannig Meeting é uma reunião de planejamento que reúne a equipe inteira. Entramos nela com uma lista de todos os afazeres e saímos com outra, de tarefas específicas a serem concluídas. Lembrando que o Planning equivale a um tempo de 5% da Sprint, se o time-box é de 2 semanas, passaremos 4 horas planejando. Para isto, o P.O. deve ter passado um tempo considerável pegando o topo do Backlog, os itens mais importantes, e refinando-os.

Podemos consumir cerca de 10% do tempo do time, pelo menos no início, para perguntar o que faz sentido e o que não faz. Isso é feito individualmente, para que na Planning Meeting o P.O. traga tudo pronto

2 – Review Meeting – Reunião de Revisão

Ao fim de cada Sprint é realizada uma Review Meeting, que é uma reunião na qual são mostrados os produtos elaborados durante esse período. A partir dela recebemos feedbacks, e quanto mais retornos tivermos, melhor será para o cliente e para nós, pois evita a execução de trabalhos desnecessários. Na Review Meeting avaliamos os itens prontos e, se surgem novas ideias ou sugestões, criamos um novo cartão e colocamos no Product Backlog, na prioridade que lhe convém.

Definição de pronto entre cliente e PO devem ser previamente acordadas e estar clara para ambas as partes para evitar problemas futuros. O conceito de “pronto” varia dependendo das necessidades da equipe, que pode considerar que pronto é inclusive o produto posto em circulação. Ou seja, na Review Meeting são levados itens com que os usuários já estão em contato. Lembrando que mesmo o produto já estando em uso, a Review Meeting é essencial, para colocar usuário e/ou cliente em contato com a equipe.

Na reunião de Review, mostra-se para o cliente e, se possível, o usuário homologa tudo o que ficou pronto na Sprint. Além de cliente e usuários convidados, todos os membros do time participam dessa reunião: desenvolvedores, Scrum Master e Product Owner.

A mecânica é geralmente bem simples. O usuário final experimenta cada uma das funcionalidades que o time terminou na Sprint e dá feedback. Esse feedback é variado, afinal o cliente pode dar ok, encontrar bugs e até mesmo pensar em melhorias ou novas funcionalidades.

O PO nesse momento, toma notas desses itens e os adiciona ao Product Backlog na prioridade que lhes couber. Mesmo um bug pode não ser tão importante a ponto de entrar no topo das prioridades: pode ser que valha a pena adiar a correção de um bug não-impeditivo para colocar uma feature que agregue mais valor no lugar.

Ao fim da reunião, definimos se o Sprint foi bem sucedido ou mal sucedido, de acordo com a meta definida na Planning Meeting

3 – Daily Scrum – Diário

É rápido, com duração de no máximo 15 minutos, realizada no próprio ambiente de trabalho do time. Dessa forma, cada integrante compartilha o que fez, o que fará, e quais problemas enfrentou. Esse último aspecto serve para levantar os desafios enfrentados e superados, e os que ainda necessitam de resoluções.

A Daily Scrum é um momento no qual cada indivíduo do time precisa pensar e responder essas três perguntas:

1. o que fez desde o ultimo?
2. O que fará?
3. Quais problemas enfrentou?

É parte do processo responder todo dia essas mesmas questões.

Resumindo, o Daily Scrum é:

• Uma reunião diária;
• com duração de até 15 minutos;
• feita em pé para cansar caso ultrapasse os 15 minutos;
• três perguntas principais devem ser respondidas
• toda a equipe participa: desenvolvedores, Scrum Master e Product Owner.

Dica, use pausas existentes na equipe para fazer o daily.

4 – Retrospective – Retrospectiva

É o último time-box da Sprint. O primeiro é o planning, o segundo o desenvolvimento, o terceiro a Review e o último é Retrospective. Após finalizarmos a última etapa emendamos uma nova Sprint e as próximas iterações do processo.

Versões mais novas do “Scrum Guide” afirmam que a cada duas semanas de Sprint deve ser feita 1h30 de retrospectiva. A versão anterior do Scrum determina que a retrospectiva deve equivaler a 5% da Sprint, ou seja, igual a 2h a cada semana de Sprint. Particularmente, o investimento nas melhoras é algo que deve ser feito com certa constância, portanto, a versão anterior que traz a diretriz de 5% do tempo é mais adequada.

Para começar a retrospectiva, iniciamos citando o Prime Directive, inclusive vários facilitadores da comunidade ágil mundial iniciam assim. Prime Directive é a diretiva primária, que resume-se a um parágrafo com o seguinte conteúdo: não importa o que descobriremos nessa reunião, consideraremos que as pessoas agiram dessa forma devido aos conhecimentos que possuíam na época, tempo e recursos disponíveis. Considerando esses aspectos, as pessoas fizeram seu melhor, e agora devemos seguir adiante.

Uma forma muito comum de fazê-lo é deixar espaço para que todos falem ou façam perguntas. Porém, se há alguém tímido, ele provavelmente não se sentirá à vontade para participar. Uma estratégia é entregar canetas e post-its para todos e pedir para que anotem pontos positivos e negativos: um ponto por post-it. O facilitador da reunião pode passar e recolher esses papéis, ele mesmo colocando-os na lousa. Dependendo da maturidade do time, e se os integrantes não tiverem medo de falar, ele mesmo pode pegar o papel e colocar na lousa.

Os post-its podem ser agrupados caso os assuntos sejam parecidos. Esses grupos de post-its criam o que chamamos de clusters.

Ao observarmos os post-its, podemos verificar que os pontos que juntam aglomerações deles indicam problemas que necessitam ser analisados, ou de repente um aspecto positivo possível de ser discutido mais a fundo. Assim, as aglomerações indicam tópicos.

Observando os pontos focais, comece do que tem maior impacto percebido e siga para os de menor impacto.

A partir da retrospectiva devem sair ações! Tanto dos pontos negativos quanto dos positivos.

No caso dos aspectos negativos levantados, qual deve ser a ação para que o problema diminua ou até desapareça no futuro?

Os papeis

Scrum Master

Como o próprio nome diz, a pessoa que tem o papel de Scrum Master tem que entender muito bem o Scrum e ser capaz de passar isso para todos os envolvidos no projeto: desenvolvedores, Product Owner, clientes e a própria organização na qual o time está inserido.

O Scrum Master não é, contudo, chefe do time e não deve agir como tal. Um bom Scrum Master é um facilitador e coach excelente, que atua como Líder Servidor, isto é, livrando o time dos problemas que o impede de ter uma melhor performance.

Durante o andamento do projeto que usa Scrum, o Scrum Master deve:

• Facilitar as reuniões, quando necessário;
• Atentar para o cumprimento dos time-boxes e explicar o porquê deles;
• Educar desenvolvedores, product owner e clientes sobre o processo;
• Remover ou reduzir impedimentos (não problemas!);
• Buscar continuamente ferramentas para ajudar o time a evoluir.
• E no que pode estar impedindo o time de melhorar sua performance.

Há uma enorme confusão em implantações do Scrum pelo mundo sobre o que é um problema e o que é um impedimento. O mau entendimento da diferença entre eles faz com que diversos Scrum Masters se comportem mais como babás de times do que deveriam – e isso também prejudica a evolução do time.

Como Scrum Master, portanto, é importante que você deixe claro para o time a diferença entre um problema e um impedimento.

Tudo o que atrapalha o time, interno ou externo, é considerado um problema do time e, como tal, é responsabilidade do próprio time (qualquer membro, não apenas o Scrum Master!) resolvê-lo.

Se o time tentou resolver o problema e não conseguiu, isso pode ser considerado um Impedimento.

Assim, lembre-se que Scrum Master não é a pessoa que vai resolver problemas técnicos (ele nem precisa ser técnico!) ou cotidianos (“Acabou o café!”). O time deve trabalhar junto para resolver esses problemas.

Product Owner

O papel do Product Owner é ser representante do cliente em um time de Scrum. Ele é quem escutará as diversas opiniões dos clientes e chegará em funcionalidades que façam sentido para os negócios, de maneira a maximizar valor, captando ideias e prioridades do cliente.

O Scrum Master e o Product Owner não podem ser a mesma pessoa, pois sua listagem de obrigações é muito grande para ser desempenhada por um único indivíduo. No entanto, o Scrum Master e o P.O. podem ser desenvolvedores, isso não tem problema.

Há algumas tarefas que cabem ao time inteiro, como um todo, como por exemplo a decisão do momento de contratação de uma nova pessoa, uma vez que a equipe sente a necessidade de um novo integrante.

O papel do Product Owner, como mencionado, é agregar o máximo de valor possível e, a cada Sprint, ele é influenciado tanto por clientes quanto pelo time de desenvolvimento. Todos podem palpitar, mas a palavra final sobre as prioridades do Backlog é do Product Owner. Como o próprio nome diz, owner é “dono” em inglês, logo, “dono do Product Backlog”.

Outra tarefa do Product Owner é entender os problemas do cliente e ensiná-lo a trabalhar com histórias, se essa for a escolha de documentação do projeto.

Além disso, o P.O. é responsável por falar com o time de desenvolvimento quando houver dúvidas. Nessas, pode acontecer algo interessante, como o desenvolvedor falar com o P.O. para tirar uma dúvida e não saber o que responder ou fazer.

Durante o andamento do projeto que usa Scrum, o Product Owner (P.O.) deve:

• participar das reuniões;
• responder dúvidas dos desenvolvedores sobre histórias ou indicar quem poderia respondê-las melhor;
• deixar claro para o time qual o valor de negócios de cada Sprint;
• obter feedback e expectativas dos diversos clientes e extrair delas as necessidades;
• manter o Product Backlog atualizado, isto é:
  • adicionar itens novos;
    • remover itens desatualizados;
    • revisar a priorização do backlog constantemente;
    • refinar histórias mais importantes em preparação para o próximo Planning.

Desenvolvedor

Desenvolvedor é aquele que ajuda a executar o projeto e o faz andar para a frente: programadores, DBA, arquitetos, analistas, front-ends, testers, entre outros. São todas as pessoas e funções que ajudam o projeto a sair do papel e virar um sistema ou produto final.

Resumindo, com exceção do Project Owner e do Scrum Master, o restante do time é o grupo de desenvolvimento.

O desenvolvedor fará o trabalho que sempre fez, porém, com algumas outras responsabilidades. Ele destrincha as histórias por um viés técnico, por exemplo, de maneira a estimar o esforço envolvido. Este é o primeiro aspecto que diferencia o Scrum de outros desenvolvimentos de projeto: ninguém deve chegar e falar para o desenvolvedor qual deve ser seu trabalho.