Scrum - A Arte de Fazer o Trabalho na Metade do Tempo

Capa do livro "Scrum" de Jeff Sutherland

Opa, blz?

Nesse post vou falar sobre o livro "Scrum - A Arte de Fazer o Trabalho na Metade do Tempo" de Jeff Sutherland, editora LeYa, 1ª edição, 2014.

Jeff é o criador do Scrum e antes que você afirme que o Scrum é de origem Japonesa, da Toyota. Na verdade o modelo Toyota inspirou a criação do Scrum.

A primeira coisa que vem a cabeça quando começamos a leitura ou até mesmo quando somente pegamos o livro é que terá muito conteúdo técnico. Regras a serem seguidas e quadros como os presentes no Canvas.

Mas na verdade esse livro foi feito para que qualquer pessoa e empresa possa ler e aplicar o modelo de produção Scrum no dia a dia. Essa é a proposta do autor com ele. Muito disso devido ao que Sutherland viu de aumento de produção com a aplicação dessa técnica fora do ambiente de T.I.

Ok, mas como realmente Sutherland criou o Scrum?

De forma resumida, depois de vários insights na vida como professor, consultor e militar, Jeff Sutherland percebeu que o modelo atual (aqui estamos no final da década de 80) de desenvolvimento de software não era confortável, pois quase nunca os prazos de entrega e valores de cobrados eram respeitados.

Nessa época o modelo de desenvolvimento em cascata era ainda o mais sofisticado.

Estudando técnicas de produção, Sutherland chegou ao modelo Toyota, que por sinal foi inventado por um americano, pós 2ª Guerra Mundial, para ajudar os japoneses na recuperação do país.

Com o modelo de produção da Toyota se destacando perante aos outros modelos ocidentais na construção de carros, Sutherland aplicou algumas modificações, o adaptou e então em 1993 surgiu o Scrum.

O termo Scrum vem de uma técnica do Rugby, onde a equipe trabalha em conjunto como se fosse uma só indivíduo para avançar e pontuar no campo adversário.

Então, de forma resumida, o que é o Scrum?

É basicamente descobrir, durante o processo de produção, como uma equipe consegue produzir ainda mais, obtendo resultados mais expressivos com um tempo menor investido. A equipe é envolvida em todo o processo de produção do início ao fim.

Membros do time sabem até mesmo de tarefas que não são responsáveis por fazer.

Para com o Scrum conseguir esse entendimento de como uma equipe melhor produz utiliza-se técnicas certeiras, com até mesmo minutos de duração bem definidos. Segue algumas como exemplo:

• Reuniões diárias de 15 minutos para saber se está tudo indo ok com o projeto e caso não, o que pode ser feito para melhorar;
• Sprints, que são períodos de produção com no máximo um mês de duração.
• Reunião Sprint que é uma reunião realizada no início do Sprint para se definir o que será desenvolvido nele;
• Retrospectiva Sprint que é a reunião para saber como se saiu o último Sprint, o que foi ou não feito, os obstáculos que devem ser removidos para aumentar a produção, entre outros aspectos.

Há algumas outras técnicas, mas essas são as principais que queria apresentar aqui. O Scrum também trabalha com personagens.

Um deles é o Dono do Produto que é aquele que conhece bem o domínio do problema (como o cliente do projeto, pode até mesmo ser ele, caso esteja disponível) para que possa informar a cada Sprint se o projeto está indo para o caminho correto.

Note que os conceitos técnicos do Scrum, como qualquer outra técnica, existem, porém são simples e segundo os fatos apresentados no livro, podem, ao menos, dobrar a produção de uma equipe quando comparados com os resultados de outras técnicas como o modelo em cascata.

Lembrando que há outros conceitos técnicos, mas aqui vou me privar a falar sobre o livro, todos os termos e explicações técnicas são simples e cabem em um pouco mais de duas páginas de um livro, você não terá dificuldades em encontrá-los na Internet.

No livro o autor conta muito sobre histórias de empresas que estavam com o modelo em cascata sendo utilizado e tendo com isso inúmeros problemas de produção, onde na maioria das vezes os clientes dessas empresas é que pagavam o prejuízo.

Uma das histórias que impressionam é o caso do FBI. Desde 2001, logo depois do atentado terrorista, foi identificada a urgência em aprimorar o software principal da entidade, porém até 2010 nada de software pronto, incluindo a isso várias demissões devido ao ineficiência desse desenvolvimento.

Com a aplicação do Scrum, em menos de dois anos o novo software já poderia  ser utilizado e enfim a produção tinha aumentado. Sem contar que o dinheiro investido na produção do software onde o processo de desenvolvimento era por meio do Scrum, esse dinheiro foi muito inferior ao pago as empresas de software que utilizavam o modelo cascata de desenvolvimento.

Há muitos outros exemplos de aplicação do Scrum, incluindo ONGs. Muitos exemplos completamente fora da linha de desenvolvimento de software, da T.I.

Como falei no início: o objetivo do autor é mostrar que o Scrum pode ser aplicado em qualquer área. Não somente por ele achar que isso é possível, mas porque ele está vendo muitas entidades aplicando o Scrum no dia a dia delas.

Se você já conhece o Scrum a algum tempo, tendo em mente que ele foi divulgado as massas em 2005, e está achando estranho esse papo de comparação ao modelo cascata, não o ache. Pois eu mesmo, por volta de 2010-2011, estudei o modelo cascata dentro da sala de aula como sendo um dos melhores modelos de produção de software. O Scrum não foi nem sequer mencionado.

O Scrum não foi somente divulgado em 2005. Nesse ano a maioria das startups americanas e europeias já o utilizavam. Provavelmente ainda hoje há pessoas utilizando o modelo em cascata de desenvolvimento, então não se espante com essa comparação.

E qual o verdadeiro problema do modelo cascata?

Ele não permite que a equipe descubra o que está travando a produção, os obstáculos, e nem mesmo permite que o cliente saiba se o que está sendo desenvolvido é realmente o que precisa ser feito. Coisas que o Scrum permite com maestria.

No livro o autor tem até mesmo um aspecto emocional, ele informa ao leitor para não desistir dos projetos até mesmo quando falarem a ele que não é possível. Que o Scrum, independente da área, vai permitir que as ideias saiam do papel e sejam desenvolvidas muito mais rapidamente do que imaginado.

Algo interessante e que já li em outros livros e é apresentado também nesse de Scrum é que quando fazemos mais de tarefa a produção cai consideravelmente, digo, quando há alternância entre tarefas.

Outro ponto interessante apresentado no livro é que quando nos forçamos a produzir mesmo quando estamos fadigado, isso na verdade produz vários problemas, erros. Pelo menos na área de desenvolvimento de software. Esses problemas, para serem corrigidos, consomem muito mais produção fazendo com que o desenvolvimento leve ainda mais tempo.

Pontos negativos

• Há comparação apenas com o modelo cascata de desenvolvimento quando apresentando exemplos de empresas de T.I. Existem outros modelos e achei que ficou faltando uma explicação ou comparação com o modelo de desenvolvimento Lean Software (Software Enxuto) que é também muito atual;
• Quando falado do modelo enxuto de desenvolvimento não ficou muito claro se ele é uma ramificação do Scrum, mas a princípio, com a interpretação do comentário do autor sobre, "parece" que sim;
• Outro ponto negativo é que o autor falou sobre os métodos ágeis de desenvolvimento, mas de maneira muito superficial, sem ficar claro se o Scrum pode ou não ser considerado uma técnica que faz parte desses métodos de desenvolvimento. Eu classificaria não como parte e sim como complemento a essas;
• Não há ao menos uma citação do Canvas. Quem o conhece pode se sentir confuso se esse pode complementar o Scrum ou se ambos são modelos concorrentes. Mesmo que seja possível utilizar ambos, não vejo o Canvas sendo útil quando o Scrum estiver em campo, pois esse último é muito mais dinâmico que o outro. Com os post-its e o quadro Scrum é possível cobrir tudo que há no Canvas.

Pontos de destaque

Sem sombra de dúvidas é o único apêndice do livro. Nele o autor, para acalmar o leitor, apresenta os termos técnicos e explicações de como utilizar o Scrum, além de no decorrer do livro o autor também apresentar o quadro Scrum, veja abaixo:

Conclusão

O livro é excelente. Li ele por indicação de um dos seguidores aqui do blog e realmente valeu a pena. Ainda não trabalho com o Scrum, muito por ele ser aplicado a equipes, mas nada me impede de testá-lo de forma individual.

O interessante do livro são os fatos apresentados, é aquilo: Contra fatos não há argumentos. E provavelmente o principal deles é que a maioria das startups de tecnologia já o utilizam.

Caso você seja desenvolvedor de software e pensou que o modelo Scrum era algo que competia com as técnicas de software limpo ou algo do gênero, não se preocupe, na verdade esses ainda poderão (deverão) ser utilizados, o Scrum vai somente amplificar a produção.

Outro ponto importante é que o livro foi escrito pelo criador da técnica, logo passa ainda mais credibilidade ao conteúdo.

Bom, como já informei, o livro é excelente, recomendo a leitura, é um livro pequeno (240 páginas), não há exercícios é um ótimo primeiro contato com o Scrum caso ainda não o conheça. Se você já é um adepto da técnica muito provavelmente o livro não vai lhe acrescentar em muito. Vou de cinco estrelas.

Vlw.

Relacionado

Padrões de Implementação - Um Catálogo de Padrões Indispensável Para o Dia a Dia do ProgramadorLivros

Refatoração Para PadrõesLivros

Freakonomics / Super FreakonomicsLivros

Use a Cabeça! Padrões de ProjetosLivros