Por: Rodrigo Aquino     17031 visualizações     Tempo leitura: 12 min

Introdução

O Scrum é um processo de desenvolvimento iterativo e incremental e foi criado inicialmente para gerenciamento de projetos de software. Muitas de suas características podem ser relacionadas com os princípios e ferramentas lean. Entender essa relação é uma forma de conhecer com maior clareza como gerar valor ao cliente, alinhar ainda mais o desenvolvimento de software com a estratégia da empresa, diminuir os desperdícios, etc.

Em 1993 Jeff Sutherland, John Scumniotales e Jeff McKenna criaram o Scrum baseado no artigo de Takeuchi e Nonaka, "The New Product Development Game", publicado em 1986 pela revista Harvard Business Review. Por volta de 1995, Ken Schwaber foi quem formalizou a definição e ajudou a difundir o processo em todo o mundo, principalmente na área de desenvolvimento de software.

Diferente do modelo o Cascata, que promove apenas uma única entrega no final do projeto, uma das principais características do Scrum é propiciar várias entregas ao cliente durante toda a concepção do software. Com várias entregas tem-se um maior número de comentários do cliente e, consequentemente, aprendizados constantes da equipe de desenvolvimento por meio de pequenos ciclos PDCA.

Overview do Scrum

A figura a seguir ilustra todas as etapas e as interações entre os envolvidos no processo:

O framework Scrum – adaptada da fonte: http://vdschoot.com/agile/scrum/

Depois que os stakeholders (responsáveis pelo produto no cliente) definem de modo geral o que deve ser desenvolvido, o Product Owner (PO – quem representa o cliente na empresa que desenvolverá o produto) tem a função de priorizar os lotes e montar o Product Backlog (um conjunto de itens a serem trabalhados que formam o produto). Junto com a equipe e o Scrum Master (líder do time), o PO faz uma reunião para planejar a Sprint (pequena entrega funcional do produto), ou seja, quais tarefas terão prioridade no desenvolvimento, além de quando serão entregues (normalmente de 2 a 4 semanas). Durante o desenvolvimento ocorrem reuniões diárias, artefatos são atualizados e durante a entrega da Sprint acontece uma reunião para revisão do que foi desenvolvido e entregue ao cliente. Os clientes recebem o que foi acordado (parte do software funcionando) e no final do ciclo há outra reunião apenas entre a equipe sobre o que foi aprendido durante aquela Sprint.

Os papéis do Scrum

• Product Owner (PO): representa o cliente na empresa que desenvolverá o produto. Essa única pessoa será a responsável em elaborar e manter o Product Backlog, definir as prioridades no desenvolvimento, além de negociar possíveis ajustes no produto. Sob o ponto de vista lean: devido à extrema dificuldade em ter o cliente que utilizará o software ou produto dentro da empresa, no Scrum, elege-se um representante de forma a estreitar o caminho da informação até os desenvolvedores. Essa é uma maneira de diminuir os riscos de retrabalhos que poderão aparecer durante a concepção do produto. Um dos conceitos utilizados na filosofia lean é o Genchi Genbutsu (“Vá ver”). Em outras palavras, o PO deve conhecer muito bem o cliente e certificar de que a equipe de desenvolvimento está trabalhando na correta característica do produto. Além disso, o PO deve estar em constante contato com o cliente e sempre atualizado em relação ao mercado de trabalho de forma a prever futuros ajustes no produto.
• Scrum Master (SM): é o líder da equipe de desenvolvimento e estabelece a relação entre os programadores e o PO. Algumas de suas características são: remover possíveis impedimentos que dificultam o progresso da equipe em relação às entregas como, por exemplo, desentendimentos internos entre pessoas do time, acionar departamento de infraestrutura caso algum hardware não esteja funcionando, etc. Sob o ponto de vista lean: as pessoas são a chave para o sucesso de uma organização, é por isso que elas devem ser tratadas com respeito a todo o momento. Um líder deve estar em constante contato com seu time de forma a conhecer profundamente os problemas que cada integrante está passando no dia a dia, só assim, ele conseguirá ajudá-los, facilitando consequentemente o fluxo do trabalho e a satisfação do cliente.
• A equipe Scrum: são quem desenvolverão o produto e garantirão a qualidade. Apesar de terem um líder, a equipe deve ser auto gerenciável e multifuncional. São eles que fazem as estimativas de entrega ao cliente. Em muitas literaturas você encontrará que a quantidade de pessoas para formar um time deverá ser de 5 a 9 integrantes. Jeff Sutherland, em sua apresentação no último Lean IT Summit realizado em Paris (outubro/2014) informou que, por experiência própria, uma equipe ideal deveria ser de até 5 pessoas. Sob o ponto de vista lean: ter equipes multifuncionais é uma forma de permitir o fluxo da informação mais rapidamente, visto que uma única pessoa pode fazer diferentes tarefas evitando a espera pela disponibilidade de outro integrante da equipe. A quantidade máxima de pessoas em cada equipe está relacionada ao número de colaboradores que o líder consegue gerenciar conhecendo muito bem até os problemas pessoais de cada um.

As reuniões do Scrum

• Reunião de planejamento da Sprint (duração de 8 horas): o Scrum Master, a equipe e o PO são quem participam desta reunião na qual o objetivo é planejar a entrega da Sprint (entrega funcional de uma parte do software). Além da meta, o PO é quem define a prioridade e os itens do backlog que formarão a Sprint. É nessa reunião que acontece a divisão da Sprint em outro backlog por parte da equipe, além das estimativas feitas jogando Planning Poker (é um jogo de cartas em que cada uma contém um número da sequência de Fibonacci para indicar os pontos que cada estória ou tarefa leva para ser desenvolvida. Cada integrante escolhe uma carta com o número que melhor indica a quantidade de esforço que gastará para desenvolver. Às vezes é necessário efetuar algumas rodadas de forma que se tenha a quantidade de pontos com maior repetição pela equipe. Importante: Nunca se deve tirar a média das cartas, mas sim, escolher aquela que mais apareceu na estimativa). Sob o ponto de vista lean: reuniões são desperdícios inerentes do processo. Por isso, o Scrum Master deve certificar-se de que todos estão aproveitando-as ao máximo de forma não perder o foco tendo sempre a preocupação de gerar valor ao cliente. Outra paridade com a filosofia lean é em relação às estimativas (Planning Poker), ou seja, ninguém melhor para estimar quanto esforço (*) será gasto para desenvolver algo do que a própria equipe. Essa forma de estimativa utiliza o mesmo conceito de Gemba, conforme citado anteriormente, por isso, concluímos que a chance de errar é menor.
  * Normalmente estima-se não apenas em horas, mas em quantidade de pontos.
• Reunião diária (duração de 15 minutos): essas reuniões ocorrem no início do expediente de trabalho e participam todos do time, além do Scrum Master. Todos os integrantes com exceção do SM ficam de pé e respondem as seguintes perguntas: O que fiz ontem, o que farei hoje e quais problemas me impede de continuar o trabalho. Sob o ponto de vista lean: No livro Sistema Toyota de Desenvolvimento de Produto, lançado em 2008 por James Morgan e Jeffrey Liker, é possível encontrar reuniões rápidas e frequentes, as quais nesse contexto servem para certificar o líder de que o projeto está sendo feito conforme o planejado. Elas garantem que possíveis problemas possam ser encontrados rapidamente a fim de que sejam solucionados. Recomenda-se utilizar tempos fracionados para ajudar a limitar a duração da reunião, pois isso fará com que o time se organize melhor a fim de que o tempo limite não seja ultrapassado (estabeleça, por exemplo, um limite de 13 ou 14 minutos).
• Revisão da Sprint (duração de até 4 horas): os participantes dessa reunião são o SM, a equipe e o PO na qual o propósito é entregar parte do produto funcionando. Se necessário, outros envolvidos no projeto como o próprio cliente podem participar. Sob o ponto de vista lean: Um checklist deve ser gerenciado pelo PO a fim de certificar que tudo foi feito corretamente conforme o cliente deseja. Um termo conhecido na filosofia lean é o completo e correto que significa certificar-se de que a informação esteja completa e correta antes de passá-la adiante e é durante essa reunião que esse procedimento deve ser feito.
• Retrospectiva da Sprint (duração de até 3 horas): ocorre entre o SM e a equipe com o objetivo de avaliar o que aconteceu durante o desenvolvimento do produto especificamente nessa etapa. Em outras palavras, é levantar os prós e contras de forma a reforçar o aprendizado e melhorar futuramente. Sob o ponto de vista lean: o termo usado para essa atividade é chamado de nemawashi, que significa literalmente reflexão. O espírito kaizen deve tomar conta do time no qual o pensamento deve ser: “hoje melhor do que ontem, amanhã melhor do que hoje”.

Os artefatos do Scrum

• Product backlog: é um conjunto de estórias (User Story - US) que descrevem o que deve conter no produto. Cada User Story pode conter uma ou mais funcionalidades do que deve ser entregue ao cliente. Sob o ponto de vista lean: isso pode ser considerado como um estoque de informação (estoque é um dos desperdícios categorizados por Taiichi Ohno). Por esse motivo precisamos nos concentrar em diminuir o backlog de forma a trabalharmos o mais próximo possível do terceiro princípio lean que é o fluxo contínuo. Como as modificações em um sistema podem também ser causadas devido às demandas do mercado (por exemplo, ajustes no negócio do cliente devido a alterações de leis, etc), quanto menos informação no estoque menor o risco de retrabalhos e priorizações incorretas.
• Sprint Backlog: é uma específica lista de tarefas a qual a equipe deve fazer para que seja entregue parte do produto ao cliente. Entende-se que uma US pode se transformar em uma ou mais tarefas. Sob o ponto de vista lean: dividindo as US em pequenas tarefas ficará mais fácil a solução e a exposição de problemas. Lean é expor problemas de forma que possa ser encontrada a causa raiz e posteriormente o compartilhamento desse conhecimento com os colaboradores da empresa.
• Burndown Chart: é um relatório gráfico que permite verificar o progresso do trabalho da equipe. Ele representa o número de pontos x quantidade de horas permitindo também comparar o planejado com o realizado. Esse gráfico deve ser atualizado diariamente a fim de que se tomem decisões em relação ao que está saindo do previsto. Existe também um quadro chamado de Task Board que compartilha e torna transparente o que cada um da equipe está desenvolvendo em relação às tarefas. Sob o ponto de vista lean: uma das lições tratadas na filosofia é tornar o trabalho das pessoas e o mais visual possível. Esse tipo de gestão ajudará a criar mecanismos a prova de erros conhecidos como poka yoke, dessa maneira, tentaremos chegar o mais próximo possível de uma qualidade na fonte, ou seja, evitando que erros futuros possam ser passados à diante.

Conclusão

Entender as relações do Scrum com o lean é importante para identificarmos quais termos pesquisar nas literaturas de forma a aprofundarmos nosso conhecimento sobre o assunto. Quando surgirem algumas dúvidas durante o gerenciamento de um projeto usando Scrum, a filosofia lean certamente será uma grande aliada no sentido de direcionar o que fazer em situações que ainda não foram documentadas.

É fato que o processo de desenvolvimento Scrum vem ajudando muitas empresas pelo mundo a eliminar uma série de desperdícios durante a concepção de diversos tipos de produtos, principalmente softwares. O Scrum propicia muitas vantagens para quem o utiliza e seu grande sucesso talvez se dê pelo fato de tornar um ambiente apto para valorização das pessoas envolvidas, tornando-as motivadas durante seus trabalhos no dia a dia. A valorização das pessoas, por sinal, é uma característica fundamental da filosofia lean.

Bibliografia

Data da publicação: 17/12/2014

Gostou do artigo? Para receber nossos informativos clique aqui.