O conjunto de boas práticas pode ser adotado em qualquer área de negócios e traz ganhos significativos ao organizar a equipe, o processo e o projeto, além de deixar claros os papéis e as responsabilidades de cada um

 

Graziela Tonin*

 

O Scrum é um framework ágil amplamente difundido para desenvolver e manter projetos complexos em ambientes de extrema incerteza. De acordo com um relatório da plataforma VersionOne, o Scrum ainda é a estrutura ágil mais utilizada no mundo. E, segundo um de seus criadores, o consultor americano Jeff Sutherland, é uma metodologia leve e simples de entender, porém extremamente difícil de dominar.

Esse método vem sendo utilizado desde o início de 1990 e consiste em times Scrum associados a papéis, eventos, artefatos e regras, que seguem uma abordagem interativa e incremental, conforme descrevo a seguir.

 

Papéis

• Time Scrum: é composto pelo Product Owner, pelo Time de Desenvolvimento e pelo Scrum Master. O Time Scrum deve ser auto-organizável e multifuncional, ou seja, deve definir a melhor forma para realizar seu trabalho e ter todas as competências necessárias para atingir a meta. Por exemplo, em um modelo tradicional, no qual os times eram separados por diferentes competências (um time de controle de qualidade, outro de desenvolvedores, outro para levantamento de requisitos, outro de design), migra-se para uma estrutura de time que possui diversos especialistas. O time, por exemplo, pode possuir um analista de requisitos, design, desenvolvedor e teste. Não somente o formato do time é diferente, mas também a comunicação e a interação, afetando diretamente a velocidade e a qualidade dos resultados.

Uma dúvida frequente é se uma empresa deve rigorosamente ter um indivíduo de cada competência para cada time. É possível ter um indivíduo de determinada competência em mais de um time, mas é preciso ter cuidado para que isso seja sustentável e ele consiga entregar valor e qualidade. Caso contrário, a qualidade e a produtividade poderão ser comprometidas, exigindo retrabalho.

O Time Scrum entrega partes testáveis do produto de forma interativa e incremental em pequenos períodos de tempo.

 

• Scrum Master: seu foco está no uso das práticas e regras do Scrum. Deve atuar como um líder servidor, buscando entender e remover impedimentos que estejam afetando a produtividade do time. Além disso, deve mediar e filtrar a interação com membros externos ao time, com o objetivo de maximizar o valor entregue e reduzir interferências desnecessárias. O Scrum Master apoia o Product Owner de diversas maneiras. Por exemplo, auxilia na gestão efetiva do backlog da Sprint, na comunicação da visão e do objetivo dos itens do backlog para o Time de Desenvolvimento, na forma de organização e no padrão de criação dos itens do backlog. Além de atuar como um facilitador dos eventos Scrum, dá suporte ao time no uso das metodologias ágeis e guia a compreensão no planejamento empírico do produto de longo prazo.

Ele também pode liderar treinamentos de adoção do Scrum na organização, no cumprimento dos processos e padrões acordados, bem como no seu uso correto para a entrega de melhor resultado.

 

• Product Owner: é responsável por maximizar a entrega de valor do produto. Deve gerenciar e ter clareza do backlog do produto, incluindo criar, categorizar e priorizar as histórias do usuário (requisitos), contribuir para que o Time de Desenvolvimento entenda os itens do backlog, para manter suas atividades focadas no que é prioridade e na entrega de maior valor ao cliente. Para alterar uma prioridade no backlog de produto, a mudança deve ser previamente alinhada com o Product Owner.

 

• Time de Desenvolvimento: seu foco é entregar, a cada Sprint, uma parte funcional do produto. Pode ser formado por indivíduos de diversas especialidades, que definem como transformar os itens do backlog do produto em atividades que se tornarão funcionalidades utilizáveis pelo cliente. A responsabilidade da entrega da meta final é de todo o time, e não de um único indivíduo.

 

Quando falamos de metodologias ágeis, os papéis estão muito alinhados ao conceito de líder-servidor e pouco alinhados ao conceito de chefe. Aqui, liderar exige o desenvolvimento de muitas habilidades relacionadas a soft skills, como empatia, comunicação não violenta, escuta ativa, trabalho em equipe, negociação e diversas outras. Na maioria dos casos, não são habilidades natas, de modo que o primeiro passo é aceitar que será necessário um trabalho árduo e perene para que essas habilidades sejam desenvolvidas e lapidadas constantemente.

 

Eventos

Os eventos no Scrum têm um tempo máximo definido, com objetivos claros, e visam criar uma rotina e minimizar a necessidade de reuniões não definidas e improdutivas. Alguns desses eventos são:

• Sprint: é um intervalo de tempo de um mês ou quinze dias, no qual uma meta clara e mensurável é perseguida e, ao final, uma parte “pronta” e funcional do produto deve ser entregue. Deve-se priorizar o que gera mais valor ao cliente e ao seu negócio.

Embora seja possível aceitar e negociar mudanças durante a Sprint, as alterações devem ser pontuais e apenas em caso de urgência, de modo que não afetem a meta final, não comprometam a qualidade da entrega e não coloquem em risco o valor entregue ao cliente.

Durante a execução de uma Sprint, algumas cerimônias são fundamentais:

• Reunião de planejamento: é o momento em que se define o que será executado na próxima Sprint, a meta, as histórias que serão priorizadas e as atividades que serão desenvolvidas. O Product Owner pode apresentar quais objetivos do negócio são prioridades e quais histórias devem ser priorizadas, mas apenas o Time de Desenvolvimento tem condições de definir quantas consegue atender em uma Sprint e, a partir disso, a meta da Sprint é definida. Para a quebra das histórias em tarefa, é preciso utilizar uma métrica clara, como o modelo T-Shirt, no qual se categorizam as tarefas nos tamanhos P, M e G. O objetivo é não ter ou ter o mínimo possível de tarefas G. O ideal é que o backlog seja composto em sua maioria por tarefas P. Muitas vezes, principalmente no início de implantação do Scrum, há uma resistência em quebrar as tarefas até que atinjam o tamanho P. É comum ouvir: “Não temos como quebrar essas tarefas em P”. O fato é que, após anos de experiência com times ágeis nas mais variadas áreas de negócio, de maior ou menor complexidade, posso afirmar que sempre é possível quebrar uma tarefa até ela se tornar P. Em geral, quando se diz que não é possível, isso se deve ao fato de ainda não haver um entendimento claro do requisito.

 

• Reunião diária: o objetivo é sincronizar o que foi feito, o que está sendo feito e o que será feito nas próximas 24 horas. A recomendação é que essa reunião seja realizada com os participantes em pé e que dure no máximo 15 minutos. Cada membro do time deve responder prontamente a três perguntas:
  • O que fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?
  • O que farei hoje para ajudar o Time de Desenvolvimento a atender a meta da Sprint?
  • Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento de atender a meta da Sprint?

Um ponto de atenção: em geral, as pessoas começam a discutir os detalhes de algum item mais crítico e estendem essa reunião por um período maior. É preciso lembrar que, se algum item precisa ser mais bem definido, discutido ou se alguém apontar que está com um problema e precisa de ajuda, não é este o momento de conversar sobre a questão. Nessa reunião, o problema deve ser apenas listado e deve-se definir um horário a posterior para resolvê-lo, envolvendo apenas os membros indispensáveis para tal, e não paralisando o time todo para discuti-lo.

 

• Reunião de revisão: é realizada ao final da Sprint para inspecionar a parte do produto entregue. É uma reunião informal da qual podem participar o Time de Desenvolvimento, os Stakeholders do projeto, o Scrum Master e o Product Owner. Essa reunião serve para listar o que foi entregue e, caso necessário, definir formas de maximizar a entrega de valor de forma colaborativa. Nessa reunião, também é possível que o roadmap do produto seja apresentado pelo Product Owner, com o objetivo de discutir estratégias para a entrega final.

 

• Reunião de retrospectiva: é o momento em que o Time Scrum revisa o que foi feito em relação às pessoas, aos processos e às ferramentas. A partir disso, identifica-se o que deu certo, valorizando e comemorando cada um desses itens. Mas também se identifica o que precisa ser melhorado e as ações que serão tomadas na próxima Sprint para garantir que isso ocorra, com foco em adaptação e melhoria contínua.

Na prática, outras reuniões intermediárias acontecem, como para definir quais histórias irão para o backlog da Sprint. Dependendo do tamanho e da complexidade do produto — por exemplo, se existirem muitos times focados no mesmo produto —, reuniões de alinhamento entre os Scrum Masters e Product Owners de cada time precisam acontecer para que todos trabalhem em sincronia.

 

Artefatos

• Backlog do produto: é uma lista ordenada de todos os requisitos do produto. O Product Owner é o responsável pelo backlog do produto, que precisa ter regras e métricas claras para priorização e categorização dos requisitos, alinhados com a estratégia do negócio. O Product Owner precisa conhecer em profundidade as regras do negócio, saber negociar e comunicar claramente com o cliente, com o Time de Desenvolvimento e com os seus superiores para que o trabalho sendo feito esteja alinhado estrategicamente. Precisa ser capaz também de articular diferentes necessidades e negociar a sua priorização e execução. Além disso, precisa ter um canal de comunicação rápido e direto com o cliente para a validação e o entendimento de requisitos.

 

• Backlog da Sprint: é composto pelas histórias que foram priorizadas para implementação naquela Sprint. E as respectivas atividades que precisam ser executadas para que, ao final da Sprint, aquelas partes do produto sejam entregues. Uma estratégia usada para que as “urgências” que surgem ao longo da Sprint não atrapalhem substancialmente o seu resultado e a sua meta, é definir um percentual aproximado para categorias de tarefas que serão executadas ao longo da Sprint. Por exemplo: 80% das tarefas serão as histórias do backlog do produto que foram priorizadas, 10% para as urgências e 10% para as atividades voltadas ao controle de qualidade.

 

Monitorando o andamento das atividades

O quadro Scrum, e gráficos como o burnup e o burndown, auxiliam nesse processo de monitoramento do andamento das atividades. Mas se os artefatos e as cerimônias forem bem documentados e padronizados, outras métricas podem ser extraídas e combinadas para entender e monitorar, por exemplo, a produtividade da equipe, o valor e a qualidade do produto entregue, bem como estimar o tempo de entrega do projeto.

O Scrum pode ser utilizado por qualquer área de negócio e traz ganhos significativos pelo simples fato de organizar a equipe, o processo e o projeto, além der deixar claro os papéis e as responsabilidades de cada um. Seu ciclo de feedback curto permite às pessoas perceberem prontamente problemas e agirem de forma rápida e clara, desde que o time não negligencie as evidências.

No entanto, é importante gerir a expectativa e a vontade de utilizar e implantar o Scrum completamente, mudando abruptamente para o uso de metodologias ágeis. Em geral, esse tipo de ação gera mais problemas do que resultados. Planejar primeiro, identificar onde o projeto ou time está e onde pretende chegar, (ponto A e ponto B). A estratégia mais adequada costuma ser implementar partes da mudança, seguindo para o próximo passo somente depois de conseguir rodar completa e efetivamente a etapa anterior.

Outro ponto que merece atenção é que o mesmo padrão e a mesma fórmula, provavelmente, não serão adequados a todos os times e a todos os projetos. Querer prontamente impor tais modelos e padrões a todas as equipes e projetos da companhia tende a dar igualmente errado ou, pelo menos, ser bem menos eficiente para alguns casos. Experimente primeiro em uma pequena amostra, adeque às características do time e do projeto e as estratégias do negócio, faça os ajustes necessários e só então defina uma estratégia para replicar em outros projetos e equipes da empresa. Coletar, analisar e mensurar dados são passos indispensáveis para a gestão ágil moderna, exponencial e focada em resultados.

O objetivo deste texto não é esgotar todos os pontos de atenção e discutir o método do Scrum em profundidade, apenas mostrar que vale a pena considerar seu uso. O processo de implantação — desde o diagnóstico da demanda e o planejamento até a execução, a coleta de dados e a mensuração dos resultados efetivos — é longo. Por isso, comece pelo time mais engajado e tenha um líder resiliente capaz de enfrentar essa transformação.

 

* Graziela Tonin é doutora em Ciência da Computação pela Universidade de São Paulo, na área de Engenharia de Software, Dívida Técnica e Metodologias Ágeis. Ela vai lecionar a disciplina Projeto Ágil e Programação Eficaz no novo curso de Ciência da Computação do Insper.