ciclo de vida do scrum

Os fundamentos e as origens do SCRUM. Como dar os primeiros passos

Conheço o SCRUM há alguns anos. Depois de ler o livro SCRUM – A arte de fazer o dobro do trabalho na metade do tempo de Jeff Sutherland pude entender realmente o valor do SCRUM. Principalmente os motivos e contextos que deram origem à um dos frameworks ágeis mais utilizadas no mundo e como ele acelera de forma significativa o trabalho humano. Neste post vou explicar um pouco do que é o SCRUM, como ele surgiu e como dar os primeiros passos na sua utilização.  

 

O que é o SCRUM ?

Segundo o scrumguide.org,  é um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é:  

  • Leve  
  • Simples de entender  
  • Extremamente difícil de dominar

 

As origens do SCRUM

Em 1993, Jeff Sutherland foi chamado para ser vice-presidente de tecnologia em uma empresa chamada Easel, e com o objetivo de desenvolver uma nova linha de produtos em seis meses, uma meta desafiadora no contexto dele. Junto com sua equipe ele passou semanas pesquisando sobre desenvolvimento de produtos e organização de equipes para descobrir a melhor de se trabalhar diante da meta que eles tinham.

Um dos desenvolvedores trouxe um artigo publicado na Harvard Business Review, em 1986, escrito por dois professores de administração japoneses, Hirotaka Takeuchi e Ikujiro Nonaka. O título era “The new New Product Development Game” [O novo jogo para o desenvolvimento de novos produtos]. Neste artigo, eles mostraram suas observações de como empresas multinacionais como Xerox, HP, Honda. Fuji e outras desenvolviam alguns de seus produtos de forma mais ágil e flexível. Eles citaram um abordagem holística que tem seis características: Instabilidade interna, equipes de projeto auto-organizadas, Fases de desenvolvimento sobrepostas, “multilearning”, Controle e transferência organizacional de aprendizagem.

Em outras palavras os dois professores identificaram que nessas empresas haviam pequenas equipes trabalhando e movidas por um grande propósito. Elas tinham grande autonomia e liberdade de como fazer o trabalho. Os superiores não ditavam como o trabalho devia ser feito, eles trabalhavam como facilitadores removendo os problemas que impediam a equipe de ser bem sucedida e o trabalho era conduzido como um fluxo contínuo de geração de valor, evitando desperdícios.

Deste artigo, somado a suas próprias adaptações Jeff Sutherland provavelmente usou o SCRUM pela primeira vez, embora ainda não tivesse esse nome. Mais tarde em 1995 Jeff Sutherland e Ken Schwaber apresentaram um artigo chamado “SCRUM development process”, apresentando a ideia do SCRUM. Desde então foram feitas várias adaptações mas os fundamentos ainda são os mesmos.

 

Mudando a forma como trabalhamos

Parece que instintivamente nós temos um jeito muito falho de executar trabalhos, tarefas, projetos, negócios, etc. Temos a ampla necessidade de querer saber todos os detalhes antes de iniciar qualquer esforço em direção a um objetivo. E esse é o problema, nós somos péssimos em planejar, em tentar prever o futuro, em prever riscos e fazer estimativas. Quanto maior o tempo que estamos tentando prever/estimar, mais errados estamos.

Para simplificar o que quero dizer, pense em quantas horas você ficou em algum projeto planejando tudo o que podia acontecer, necessidades, custos, prazo de conclusão e se sentindo orgulhoso de que planejou e mitigou tudo o que podia acontecer. Agora quantas vezes você realmente acertou o que foi estimado e planejado? E mesmo nas vezes que foi bem sucedido, eu aposto que você teve de ser resistente para que nada do escopo original fosse alterado. No desenvolvimento de software em 8 anos de experiência já passei por isso muitas vezes, e por várias me senti incompetente por não saber planejar ou estimar o trabalho do qual eu era responsável, iniciava cada trabalho conforme a figura abaixo, planejando um trabalho em fases e tentando prever tudo o que podia acontecer em cada fase, mas raramente tinha êxito.

processo em cascata

O SCRUM é fundamentado nas teorias empíricas do controle do processo. O empirismo é uma doutrina que diz que todo o conhecimento  provém unicamente da experiência. Ou seja, você aprende o SCRUM fazendo, colocando em prática. O SCRUM defende uma abordagem incremental e iterativa para melhorar a produtividade e reduzir a incerteza em um trabalho. Ele evita o desperdício de tempo em um planejamento de longo prazo que provavelmente será alterado ou irreal, o que não significa que não há planejamento, vou explicar isso mais a frente.  O foco está em gerar o máximo de valor, o mais rápido possível.

O SCRUM tem suas raízes nas práticas japonesas. Nas artes marciais há um conceito chamado Shu Ra Ri, que explica diferente níveis de habilidades em relação a arte marcial. O primeiro nível é o Shu, nele você aprende todas as regras e normas e as segues até dominá-las. No nível Ra, você já dominou as formas e regras aprendidas e começa a criar e inovar com traços particulares. No último nível o Ri você é livre para ser totalmente criativo, pois já dominou de tal forma a arte que qualquer movimento seu é uma expressão inconsciente da mesma.  

É nesse ponto Ri que todos devemos buscar as práticas do SCRUM segundo seu co-criador Jeff Sutherland, de forma que sejam naturais para quem as aplica. Resumindo o conceito Shu Ra RI, seria algo como: “Siga a regra, quebre a regra e seja a regra”.

 

Conhecendo o SCRUM

Vou explicar o Scrum dividindo-o entre seus papéis, eventos e artefatos.  Os papéis atuantes no Scrum são o Product Owner, o Scrum Master e o Time que executa o trabalho. Os eventos são o planejamento do Product backlog,o Sprint, o planejamento do Sprint, a reunião diária do Sprint, a execução do Sprint, a revisão do Sprint e a retrospectiva do Sprint. Os artefatos do Scrum são o Product Backlog e o Sprint Backlog.

Agora vamos ver como tudo isso se encaixa para atingir um objetivo.

ciclo de vida do scrum

 

Saiba quem é o dono do produto (Product Owner)

Quando se está utilizando o Scrum, você só tem 3 papéis a assumir, ou faz parte do time que executa o trabalho, ou é o Scrum master ou é o Product Owner.

É do Product Owner a responsabilidade de dizer o que deve ser feito, em que ordem deve ser feito e a importância de cada item a ser feito. Não cabe a ele dizer como vai ser feito. Mas sim ser uma ponte entre as pessoas que estão comprando/utilizando o produto e o time.

 

O Product Owner é responsável por traduzir a produtividade do time em valor.

 

Ele não é um gerente, ou um chefe, ninguém deve se reportar ele, ele não tem autoridade, deve se valer da liderança e persuasão para conseguir o que deseja. Acredito que o principal valor do product owner é ter a visão do que o cliente final deseja, traduzir e priorizar( principalmente ) isso de uma forma que o time entenda para desenvolver o trabalho.

O product owner é apenas uma pessoa, não é um grupo ou um comitê, embora possa representar um. Dele é toda a responsabilidade do que está sendo feito e dos próximos itens que ainda serão.

 

Forme um time para realizar um trabalho

O SCRUM se concentra nas pessoas trabalhando de forma colaborativa e com autonomia para cumprir tarefas e entregar resultados. Dito isso, se você tem um projeto, um objetivo para cumprir, o primeiro passo é formar um time que tenha todas as habilidades de completar o trabalho e possam ficar interagindo o tempo todo de preferência no mesmo espaço de trabalho, sem a necessidade de transferir parte do trabalho para terceiros. A transferência de responsabilidades entre equipes, sempre gera uma lacuna de comunicação ou aprendizado.

É do time a responsabilidade de executar o trabalho que será entregue de forma incremental ao produto “pronto” no final de cada sprint.

É fundamental que o time scrum, seja multifuncional, ou seja, que dentro do time se tenha todas habilidades para completar o trabalho. Tenha autonomia para fazer o trabalho da forma que decidir. Ninguém diz ao time como o trabalho deve ser feito, eles decidem como querem executar o trabalho.

O time scrum deve ser movido por um propósito maior, eles devem estar seriamente comprometidos com o objetivo, buscando a excelência em cada detalhe. Gostei da abordagem do Jeff Sutherland dizendo que o time deve buscar a transcendência, devem ter um objetivo maior que eles mesmos individualmente.

Outro aspecto do time é o tamanho, procure formar times pequenos. Times muito grandes costumam ser complexos de se trabalhar. Os números ideais que mais vejo é na média de 6, três a mais ou três a menos.

Para finalizar minha descrição do time, no Scrum todos sabem de tudo, a transparência é um dos pilares. Toda a informação deve ser compartilhada entre todos, não há hierarquias, apenas papéis em direção à um objetivo comum.

 

“O SCRUM se concentra nas pessoas trabalhando de forma colaborativa e com autonomia para cumprir tarefas e entregar resultados”

 

Defina o mestre Scrum ( Scrum Master )

A definição que mais gosto sobre o Mestre Scrum é que ele é um facilitador. Ele ajuda a identificar e remover os obstáculos que estão impedindo o time de realizar seu trabalho e também se certifica que os papéis, eventos e artefatos do scrum estão acontecendo e sendo usados de forma a buscar a melhoria contínua. Ele garante que os valores do Scrum de transparência, inspeção e adaptação estão sendo praticados.

O Scrum Master se concentra na melhoria e identificação de falhas no processo em si e não nas pessoas. Ele busca o motivo pelo qual o time não está tendo a máxima performance.

 

“O trabalho do mestre Scrum é guiar a equipe em direção ao aprimoramento contínuo”

 

Faça uma lista de pendências – O Product Backlog

Como eu disse antes, o Product Owner é responsável pela visão do que se deseja construir, desenvolver, etc. Uma vez que se tenha clareza do que se deseja no final do trabalho, é necessário ter uma lista de pendências de tudo que é necessário fazer para tornar o produto pronto.

Essa lista não tem limites, pode ter poucos itens ou centenas, depende de quão complexo é o que está sendo desenvolvido. Procure colocar tudo o que seria necessário fazer ou que você gostaria que o recurso tivesse, características, funcionalidades, etc. Não que você realmente vá desenvolver ou mesmo precisar de toda essa lista.

O poder do Scrum está em decidir o que fazer primeiro. Ordene os itens em ordem de prioridade. Coloque primeiro os itens que terão maior impacto para a empresa, para os clientes, aqueles que vão agregar maior valor ao produto.

O Scrum inverte uma teoria muito conhecida dos processos de desenvolvimento de produtos, que 80% do valor está em 20% das funcionalidades. Ao se criar uma lista de pendências, priorizá-las e dividi-las em pequenos ciclos ( sprints ) de execução e entrega, focando cada ciclo nos itens da lista de pendências que mais agrega valor naquele momento, nós temos um processo que gera valor incremental desde o início para o produto que está sendo desenvolvido.

Quando estiver desenvolvendo a lista de pendências, procure não escrever apenas palavras soltas que apenas você vai entender. O Scrum nos incentiva a fazer uma lista de pendências baseada em histórias. Para dar um exemplo, ao invés de um item da sua lista ser apenas “login”, se estamos falando de histórias, serial algo como: “O usuário precisa conseguir acessar o sistema fornecendo  um email e uma senha”.

Ao criar as histórias mantenha elas curtas, e procure expressar o porque elas são necessárias, as motivações por trás delas. Assim fica mais fácil o entendimento e até a priorização dos itens.

O Product backlog é isso, uma lista de pendências do produto para ser desenvolvido descrito por histórias.

 

O Sprint

No Scrum o trabalho acontece dentro de um sprint, é um período de tempo de trabalho curto definido pelo time. Recomenda-se que um sprint varie de 1 a 6 semanas, depende de cada caso. Ele é o coração do Scrum, e ao final de cada sprint o time deve ter algo do produto “pronto” para ser utilizado pelo cliente final.

As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho do time, uma revisão da Sprint e a retrospectiva da Sprint.  

Tudo começa com a reunião de planejamento da Sprint, que responde às seguintes questões:  

  • Qual é o objetivo da Sprint?  
  • O que pode ser entregue como resultado do incremento da próxima Sprint?  
  • Qual o trabalho necessário para entregar o incremento será realizado?  

 

É importante também definir entre o time o conceito de “pronto”, deve estar claro entre todos o que significa ter pronto um item de trabalho ou a própria sprint. O “pronto” deve representar algo que o cliente final possa utilizar até a próxima sprint, algo funcional e não meramente um protótipo. A força do Scrum está em dividir um objetivo em pequenos ciclos de trabalho e que se possa gerar algo funcional desde o primeiro ciclo com muita comunicação entre todas as partes, para mim essa é a principal qualidade do Scrum.

Uma vez que o sprint comece, nós temos a reunião diária do sprint. É um evento de no máximo 15 minutos com todos os membros do time. É bom definir sempre o mesmo local e horário, isso evita desperdícios.

O objetivo da reunião diária é basicamente responder a três perguntas:

  • O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?  
  • O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?  
  • Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?  

A reunião diária ajuda a garantir que o objetivo da sprint está sendo cumprido e identifica obstáculos que podem impedir o objetivo de ser cumprido, mas principalmente ajuda a informação a se difundir por todo o time de forma objetiva, dado a exigência de ser no máximo em 15 minutos.

O Scrum ainda tem outro auxiliar para manter o controle de todo o processo que é o quadro Scrum. È uma forma de manter tudo o que está acontecendo visível a todos. Basicamente é um quadro dividido em 3 colunas: a fazer, fazendo e pronto. Pode ter mais colunas dependendo de cada contexto, mas essas são as mais utilizadas. Cada item da lista de pendências é colocada na coluna correspondente e conforme o time avança na execução dos itens eles vão sendo trocados de lugar até que todos os itens estejam na coluna pronto.

Você pode usar post-its, papel com imã, cola, sua imaginação é o limite. O principal é ter os itens da lista de pendências visíveis a todos e olhando para o quadro saber de forma ágil em que situação está cada item.

 

“Ao final de cada sprint, você precisa ter algo pronto, algo que possa ser usado. ”

 

Ao final de cada sprint acontece a revisão do sprint. É um encontro do time com todas as partes interessadas. O Product Owner pode convidar outras pessoas para participar. O time também apresenta o que está pronto para ter um retorno sobre o sprint e discute o que foi bem e o que não foi durante o sprint.

O Product Owner também comenta o quais itens do Product Backlog foram prontos e quais não foram, e o grupo todo discute o que fazer a seguir, fornecendo informações que podem ser usadas para o planejamento do próximo sprint. O resultado de revisão do sprint é um Product Backlog revisado, que pode muito bem já ser o product backlog que vai servir o próximo sprint.

O último evento do scrum é a retrospectiva do sprint, ela ocorre depois da revisão da sprint e antes do planejamento da próxima sprint. É uma forma do time analisar a si mesmo e ver o que pode melhorar em relação ao trabalho para a próxima sprint.

O Product Owner e somente ele pode cancelar a sprint se o objetivo da Sprint se tornar obsoleto ou outro motivo definido pelo Product Owner. Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado.  

 

Estimativas no Scrum

Esse é o assunto mais polêmico não só no Scrum, como em todo o mundo ágil em geral. Como estimar quanto tempo e esforço é necessário para realizar um trabalho ? Eis a questão.

Comece tendo uma lista de pendências priorizada. Você definiu a importância de cada item e agora quer saber quanto tempo e esforço é necessário para realizá-lo. No Scrum isso é de responsabilidade do time. Apenas o time que executa o trabalho pode estimar.

O Scrum se baseia em unidades de valores relativas  e velocidade para estimar o esforço de um trabalho. Ele não usa valores absolutos como horas, dias ou meses atrelados a uma tarefa diretamente. Ele foca em ter acurácia, não em precisão.

Quantas vezes você já estimou que um trabalho levaria 5 horas e de fato ele levou 10, ou que você precisaria de 2 horas e levou 15 minutos. Gostei da passagem do livro de Jeff Sutherland que diz que nós humanos somos péssimos em estimar, e particularmente olhando para meu passado, realmente somos. Isso porque no início de cada jornada de trabalho nós apenas temos previsões e uma vaga ideia do desdobramento que vai acontecer no decorrer do trabalho, mesmo assim nós procuramos pensar e detalhar tudo.

Coloco abaixo a imagem do Cone da Incerteza de Steve McConell. Ele nos mostra que estimativas iniciais de trabalho podem variar até 400% no decorrer de um projeto. Conforme o tempo vai passando e as coisas do projeto vão sendo entregues, as estimativas vão se aproximando da realidade, até que só fique a realidade. Isso é uma base de como somos ruins em fazer estimativas.

cone-daincerteza

OK, somos ruins em estimativas absolutas, mas somos melhores (veja bem, melhores!) em estimativas relativas. Por exemplo, conseguimos claramente distinguir o tamanho de uma moto para um carro ou para um caminhão. Sabemos distinguir os tamanhos de uma camisa pequena, média ou grande.

Passando isso para a estimativa de itens da pendência no Scrum, imagine que você vai desenvolver a parte de um software que é uma autenticação por email e senha. Fazendo a comparação com tamanhos de camisa, esse seria uma camisa pequena, média ou grande ?  

Feito isso procure associar valores aps tamanhos de camisa ou medidas relativas que você utilizar. O mais usado é a sequência de fibonacci com os valores 1, 2, 3, 5, 8, 13 . Agora você pode estimar o valor/pontuação ou tamanho de cada item da sua lista de pendências de forma relativa, lembre-se que nada é absoluto. O bom da sequência de Fibonacci é que os valores são bem espaçados entre si, eliminando uma certa confusão causado pela proximidade de valores.

A técnica mais difundida de estimativa do Scrum é o Poker do planejamento. Diante da lista de pendências, cada membro do time tem um baralho que geralmente corresponde a sequência de fibonacci. Depois de todos discutirem como cada item deve ser o trabalho envolvido para fazê-lo, todos colocam a carta que representa o esforço na opinião deles para fazer o trabalho virada para baixo na mesa. Depois que todas as cartas estiverem na mesa elas são desviradas. Se a diferença entre elas for menor que 2 pontos, soma-se todos e calcula-se a média, se for maior o time discute porque cada um deu sua nota e joga novamente.

O poker do planejamento evita que as estimativas de um membro do time influencie os de outro.

 

Conhecendo sua velocidade

A velocidade é algo chave no Scrum. É nela que você pode se basear para saber quando um trabalho vai ser concluído.

Uma vez que você tenha uma lista de pendências, priorizada e estimada quanto ao esforço para realizar cada item, você pode definir quais itens vão ser dados como pronto no próximo sprint.

Digamos que o time chegou à conclusão que no próximo sprint, que tem duração de 2 semanas vão ser incluídos 5 itens, que somados os valores estimados ( e vou chamar esses valores de pontos, que é o mais usado ) somam 26 pontos. Essa é a sua velocidade estimada, concluindo todos os itens, você tem 26 pontos de velocidade realizada também. Mas no decorrer do sprint você só conseguiu realizar 18, então essa é sua velocidade real.

 

estima em sprint

 

Agora você sabe a velocidade do seu time,que é 18 pontos por sprint (de 2 semanas), e tem condições de saber quanto tempo será necessário para realizar os demais itens da sua lista de pendências.

A cada sprint você vai analisando a velocidade do time e melhorando através das médias anteriores, provavelmente a mais difícil de medir será a primeira, as demais já terão um histórico para se considerar. Se os itens restantes da sua lista de pendências somam 108 pontos, pela sua velocidade de último sprint você vai levar 6 sprint para finalizar todos, ou seja, 12 semanas.

Outra forma de estimar que achei interessante é o que li no Scrum direto das trincheiras de Henrik Kniberg. É uma abordagem baseada no número de recursos disponíveis para estimar a velocidade do time. Vamos supor que você tem 4 recursos disponíveis para um projeto, num sprint de 2 semanas como o exemplo anterior. Então você tem 40 homens-dia disponíveis para o trabalho.  Mas dois vão ter folga no decorrer do sprint, então você tem 38 homens-dia para o trabalho.

Com essa unidade vamos calcular o que Henrik chamou de fator de foco. Na execução de trabalho é raro termos as pessoas 100% focadas, ou seja, trabalhando 100% do tempo sem qualquer interrupção ou distração. Pessoas ficam doentes, tiram folgas, algumas coisas não planejadas aparecem, etc. Por isso o fator de foco é uma forma de melhorar a acurácia da velocidade do time descobrindo quão focado percentualmente o time está. Para calcular o fator de foco do seu time use a fórmula abaixo:

 

Fator de foco = Velocidade realizada / Qtd. Homens-dia disponíveis

 Pelo nosso exemplo anterior, se realizamos a anterior em 18 pontos por Sprint. Nosso fator de foco seria o seguinte:

 

  Fator de foco = 18 / 38

O fato de foco do nosso time nesse cenário é  0,45. Agora vamos ver nossa velocidade estimada para os próximos Sprints e consequentemente para a conclusão de toda a lista de pendências de 108 pontos. A fórmula é a seguinte:

 

Homens-dias disponíveis X  fator de foco = velocidade estimada

Se nada se alterar no contexto do Sprint e do trabalho a fórmula redundante, mas considerando as alterações de recursos que sempre acontecem ela é muito útil, sendo um pouco vaga apenas no primeiro Sprint que você vai ter que inserir algum valor para o fator de foco com base na sua intuição.

 

Um passo a passo simples e básico para um projeto Scrum

1. Defina um dono do produto, a pessoa que tem a visão de como o seu produto deve ser, como o cliente final está esperando que ele seja. Também é a pessoa responsável por definir as prioridades do que deve ser feito no projeto.

2. Forme um time para realizar o trabalho. Comprometidos em realizar a visão que o dono do produto tem. Esse time deve ser formado por pessoas que tenham todas as habilidades para realizar todo o trabalho. Não forme times muito grandes, de três a nove pessoas é o mais utilizado. Por fim, dê autonomia a esse time.

3. Faça uma lista de pendências com tudo que precisa ser feito para transformar o produto em realidade. Só existe uma lista de pendências, tudo o que precisa ser feito deve estar nessa lista e é responsabilidade do dono do produto priorizar essa lista. Também é importante saber que essa lista pode se alterar durante o processo.

4. Estime os itens da sua lista de pendências. Enquanto estiver fazendo isso, procure manter os itens da sua lista pequenos suficiente para que você possa estimá-lo. Você pode usar o poker do planejamento para isso. E o principal é não busque a precisão, mas sim a acurácia, use formas relativas de estimativas.

5. Faça a reunião de planejamento do Sprint com e veja quais itens você consegue realizar dentro do próximo Sprint, e sempre defina quanto tempo terá o seu Sprint. Procure conhecer a sua velocidade para não colocar itens que ultrapasse a sua capacidade de execução. Tenha uma definição clara do que é um item pronto.

6. Durante a execução do Sprint, torne o trabalho visível com o quadro do Scrum, dividindo as tarefas em a fazer, fazendo e pronto.

7. Faça reuniões diárias de 15 minutos no máximo com as três questões básicas que expliquei nesse post.

8. Use a revisão do Sprint para demonstrar o trabalho realizado. Qualquer pessoa pode participar.

9.Faça a retrospectiva do Sprint para reunir todo o feedback sobre o último Sprint e pense no que deu errado e o que pode ser feito de forma imediata para melhorar as entregas do próximo Sprint.

 

Esse post foi um resumo do que achei mais interessante no modo de trabalhar do Scrum. Realmente acredito que a abordagem que ele aplica pode como um dos co-fundadores diz, acelerar os empreendimentos humanos e reduzir os riscos sobre os mesmos.

 

Referências:

Scrum – A arte de fazer o dobro do trabalho na metade do tempo – Jeff Sutherland

Guia do Scrum

Essential Scrum – Kenneth S. Rubin

Scrum direto das trincheiras – Henrik Kniberg

Curso Scrum 100 lero lero – Frederico Aranha