Como seria se você pudesse produzir o dobro na metade do tempo? Isso equivale a uma produtividade tentadora com um aumento considerável de 400%. Embora pareça bom demais para ser verdade, é o que a ferramenta SCRUM promete – e cumpre!

O SCRUM foi desenvolvido no mundo do software por Jeff Sutherland, um ex piloto do exército Norte Americano. Após ter saído das forças aéreas, Jeff começou a trabalhar no setor de tecnologia e se viu obrigado a buscar novas formas de produzir softwares com maior precisão e em menor tempo.

Como você deve saber, qualquer erro de programação pode representar um grande dano para qualquer projeto de tecnologia. Agora, imagine uma realidade onde o projeto era planejado por meses ou anos e entregue só no final – com muitos erros?

Exatamente isso que o SCRUM evita e é o que você irá aprender agora.

As influências do SCRUM

É importante conhecer, acima de tudo, o padrão mental do criador e também das influências que formaram o SCRUM. Ele nasceu de um piloto de caças, ou seja, uma pessoa direcionada à excelência e busca por resultados de maneira rápida e inteligente – caso contrário, poderia morrer em combate.

Além disso, Jeff foi muito influenciado pela forma com que os chineses trabalhavam, sobretudo o modelo Toyota de produção. Com isso, o SCRUM foi modelado para abominar qualquer tipo de desperdício, seja de tempo, recursos financeiros ou humanos.

O desperdício gera retrabalho, e o retrabalho desrespeita todo o esforço já empregado para resolver algum problema. Isso gera um ciclo vicioso, atrasa prazos, exige mais orçamento e energia para entregar a mesma coisa que poderia ter sido entregue de primeira e muito mais cedo.

O SCRUM é, acima de tudo, uma forma de viver e trabalhar. Não apenas uma ferramenta, mas sim uma filosofia de produtividade mais completa, que considera o bem estar e a especificidade de cada um. Além disso, ele fomenta a transparência e o compartilhamento mais horizontal possível: todos sabem o que todos estão verdadeiramente produzindo.

As equipes trabalham juntas, não cada uma em sua sala. Isso fortalece o vínculo entre as pessoas e a sensação de que o trabalho de um influencia diretamente no trabalho do outro.

Estrutura do SCRUM

No SCRUM não há grandes grupos de trabalho. Os grupos devem ter no máximo 9 pessoas e todo grupo precisa ter as habilidades necessárias para entregar o resultado desejado. A produtividade não é avaliada de indivíduo por indivíduo, e sim a produtividade do grupo.

O grupo é sempre mais importante e possui a sua própria capacidade de produção. Ou seja, todos grupos podem aumentar a sua produtividade consideravelmente, porém, cada um da sua maneira.

Cada equipe possui de 3 a 9 pessoas e é composta por um Product Owner, a pessoa responsável pelo produto final que será entregue. Pode ser uma festa de aniversário para sua tia ou um produto e objetivo da empresa.

Essa pessoa será encarregada do produto, por não deixar a equipe desassistida em relação ao que executar. Seu dever é inserir mais tarefas no Quadro Scrum – que falarei mais adiante – considerando o resultado final do produto.

Além do Product Owner, uma equipe SCRUM precisa de um Scrum Master. Essa pessoa é focada na produtividade da equipe, em seu bem-estar e no que a equipe precisa para melhorar ainda mais seu desempenho. O Scrum Master é responsável por manter a harmonia e empenho da equipe.

Entregue o que o cliente realmente quer

No Scrum, a maior parte das tarefas acaba caindo por terra após a reunião de decisão sobre o que realizar – ou reunião de backlog. Isso acontece porque em média 20% das características de um produto ou serviço concentram 80% do seu valor percebido pelo cliente.

Provavelmente você não crie vídeos animados com o PowerPoint, apenas apresentações mais estáticas, com poucas animações, mesmo que ele possa entregar vídeos.

Ou seja, você definitivamente não usa todas as características do sistema, mas usa massivamente as mesmas de sempre: escreve, coloca transições, algum efeito, muda a cor de fundo, da letra, etc.

Por esse motivo que essas funções básicas recebem 80% da atenção dos seus desenvolvedores: por que realmente é o que as pessoas mais usam. Não adianta focar no que não trará resultado: nisso que o SCRUM se concentra – apenas com isso a produtividade já aumenta.

Para isso, a equipe SCRUM faz um levantamento do que o cliente gostaria com a determinada solução, sobre qual o seu desejo e como ele gostaria de se sentir com o produto. Por exemplo, ao invés de usar o meio tradicional para determinar uma tarefa, o SCRUM conta histórias.

As histórias são mais ou menos assim: “como cliente eu gostaria que a minha cerveja ficasse gelada nos jogos de futebol que frequento”.  Isso não parece uma tarefa, não é mesmo? E não é! Isso é o que antecede a tarefa. Na verdade, é o que fará com que a tarefa exata seja construída.

Ao saber o que o cliente quer, é possível determinar quais tarefas serão realizadas para conseguir o objetivo. Talvez uma solução para dar isso fosse criar uma garrafa térmica personalizada que ele pudesse levar aos jogos ou alugar lá. As tarefas poderiam ser “buscar fornecedores”, “criar um novo design”, etc.

Como mensurar a dificuldade de cada tarefa

O ser humano de forma geral é péssimo para especificar quanto tempo uma tarefa irá demorar. Por ser abstrato é difícil conceber com exatidão um prazo. Por esse motivo prazos irreais são dados e consequentemente quebrados.

No SCRUM as tarefas são qualificadas por tamanho ou pontos, sempre tendo uma perspectiva de associação. Nenhuma tarefa é isolada, ela é comparada com outras tarefas do projeto ou, de forma lúdica, com um objeto físico – para facilitar a visualização.

Por exemplo, uma tarefa simples pode ganhar o peso 1, e se equivaler ao “quarto de uma casa”. Uma tarefa um pouco mais complexa pode ganhar o peso 3, e se equivaler a uma “pequena casa”. Uma tarefa com maior nível de complexidade pode ganhar o peso 8 e ser uma “casa de dois andares”. Enquanto uma tarefa super complexa pode ganhar o peso 13 e ser um “prédio de 6 andares”.

Quando você pensa no quarto de uma casa consegue perceber com facilidade que é muito menor do que um prédio de 6 andares. Isso facilita para que você perceba realmente o nível de dificuldade de cada tarefa. Essas associações podem ser feitas assim ou apenas com os números, sendo eles 1, 2, 3, 5, 8, 13, 21, 34, 56…

Caso uma tarefa seja complexa demais, grande demais – um “prédio de 6 andares” -, talvez seja necessário dividi-la em “cômodos da casa”. Em tarefas menores.

Primeiro a equipe deve criar as histórias (o que os clientes desejam com o produto), e criar todas as tarefas necessárias para concluir o produto – ou a parte dele que será feita no período pré-acordado. Ou seja, entregar a história para o cliente no prazo certo. Após isso feito, é hora de qualificar a prioridade de cada tarefa e a sua dificuldade.

Ps* Isso pode ser usado para tarefas do dia a dia. Imagine você criando uma história: “eu adoraria chegar em casa e ter a sensação de que as coisas estão organizadas”. A tarefa com peso 1 poderia ser “arrumar a cama quando acordar”.

A tarefa peso 3 poderia ser “lavar a louça enquanto o café está passando”, a tarefa peso 5 poderia ser “varrer ou organizar um cômodo da casa por dia, antes de sair de casa”.

Os Sprints do SCRUM

As tarefas são selecionadas conforme suas prioridades – foco nos 20% que geram mais valor. O conjunto de tarefas que foram selecionadas devem entregar uma história para o cliente em um tempo pré estabelecido: um sprint. Normalmente os Sprints são de uma semana a no máximo 1 mês.

Ao final de cada Sprint é necessário que o produto em questão seja funcional e tenha usabilidade. Não apenas um desenho ou projeto escrito, mas sim um protótipo real do resultado desejado ou parte do protótipo que possa ser realmente usado e testado por clientes reais.

São os Sprints os responsáveis por comprovarem que a ideia ou a funcionalidade do produto será realmente aproveitada pelos clientes. Enquanto no modelo tradicional há uma energia exagerada para prever todas as variáveis de projetos longos, no SCRUM os Sprints servem para entregar protótipos funcionais e testar na prática o interesse dos clientes.

Ps* usando o mesmo exemplo anterior – chegar em casa com a sensação de que as coisas estão organizadas -, um Sprint semanal poderia ser feito para “arrumar a cama”, outro “organizar um cômodo”, outro “lavar a louça”.

No final de cada Sprint você teria uma “reunião de revisão” consigo mesmo – falarei mais adiante sobre. Nessa reunião ou autoanálise você avaliaria o que mais trouxe a sensação de organização para você: a cama, a louça, varrer, etc.

Isso faria com que você pudesse focar ainda mais no que mais importa

O quadro SCRUM

O quadro SCRUM possui 4 colunas. A primeira é para todas as tarefas que foram levantadas pela equipe e que tiveram algum nível de importância. A segunda coluna é a “A fazer”, contendo as tarefas que serão realizadas naquela semana, consideradas as mais importantes.

A terceira coluna é a “Fazendo”, que são as tarefas que a equipe está envolvida no momento. A última coluna é a “Feito”, que representa que aquele produto ou parte do produto está concluído.

Para que uma tarefa seja passada para a coluna “Feito” o seu resultado deve ser testado e considerado funcional – não pode haver retrabalho. Ou seja, precisa estar realmente funcionando. Se a tarefa for “colocar um artigo no blog”, ela precisa estar no ar com tudo necessário, e não apenas o layout concluído.

Reuniões diárias

Uma equipe SCRUM conta com reuniões diárias, de pé, que não devem durar mais de 15 minutos. A reunião tem um único objetivo: responder 3 perguntas.

O que você fez ontem para ajudar a equipe a concluir o sprint?

O que você fará hoje para ajudar a equipe a concluir o sprint?

Há algum obstáculo que esteja impedindo você ou a equipe de alcançar a meta do sprint?

Se a reunião diária durar mais de 15 minutos está sendo feita de maneira errada.

Reunião de revisão do Sprint

Esta é uma reunião semanal ou mensal, depende da duração do Sprint. Normalmente os Sprints são de uma semana. Ela é uma reunião aberta a todos os envolvidos no processo, seja direta ou indiretamente – até mesmo o cliente.

Ela tem um objetivo central: demonstrar o que foi desenvolvido durante o período e testar suas funcionalidades e resultados.

Essa é a reunião onde é possível avaliar qual a pontuação de produtividade da equipe em específico. Lembra dos números atribuídos a cada tarefa? Eles são somados e isso se tornará a pontuação da equipe.

Nos próximos Sprints será possível prever com mais exatidão sobre quantos pontos cada equipe consegue produzir, o que facilitará para a escolha de quais tarefas colocar dentro de cada Sprint.

O Jeff  Sutherland escreveu um livro, o “SCRUM A arte de fazer o dobro do trabalho na metade do tempo”. Recomendo que você leia este livro para aprimorar ainda mais as suas habilidades produtivas.

Até o próximo artigo.