Scrum — o que é, onde vive, o que come?

A definição formal do Scrum é de um framework Agile para planejamento e gestão de projetos complexos, mas Scrum não é isso, ou melhor, não é só isso. Scrum — ou Agile como um todo — é uma nova cultura, uma nova forma de pensar projetos ou qualquer outra atividade que necessite de um desenvolvimento mais rápido e eficiente. Eu diria ainda, esse é o principal ponto do Agile!

“Se não houver esta cultura, uma forma de pensar coletivamente, auto-organizada e horizontal, implementar o Scrum ou qualquer outro framework será apenas uma nova forma de falhar um projeto — quase que com certeza vai falhar.”

Mas por quê? Gosto de fazer um comparativo com seu smartphone, ele é muito mais eficiente e rápido para responder uma mensagem ou um e-mail, certo? Mas se você quiser pensar da forma tradicional vai achar um milhão de defeitos, por exemplo, é muito mais complicado anexar um arquivo para responder do que em um notebook. A bateria dele não dura tanto quanto um celular que “só liga”. Isso não tira o valor do seu smartphone e a tendência é cada vez usarmos mais, acho até mais fácil usar menos anexos do que menos smartphones.

O mesmo acontece com o Scrum, se pensar que o importante é entregar um projeto no Prazo, Custo e Qualidade (os três pilares do PMI) seus projetos vão continuar a falhar — até concordo que vão falhar menos, mais ainda assim a taxa de falha será alta.

Vou colocar parênteses aqui para você nunca ouviu falar em gestão de projetos — se já conhece pode pular este e o próximo parágrafos. Para começar vamos definir as coisas, um projeto é um conjunto de atividades temporárias, pois tem um início e fim, realizadas por um grupo de pessoas a fim de produzir um resultado único, seja um produto ou serviço, e assim tem um escopo delimitado e recursos definidos. O gerenciamento de projetos é a prática de planejamento, organização, execução e controle da forma mais efetiva dos recursos tendo como pilares: prazo, qualidade e custo. A gestão de projetos foi realizada informalmente por muito tempo, e nos meados do século XX começou a emergir como uma profissão distinta.

Na visão tradicional de projeto temos o prazo, qualidade e custo bem definidos, ou seja, sabemos exatamente o que queremos (escopo e qualidade), em quanto tempo vamos ter o que queremos (prazo) e quanto temos disponível para gastar (custo). Se formos fazer uma analogia com uma viagem, sabemos exatamente onde queremos ir (escopo), quanto tempo vamos demorar para chegar (prazo) e quanto vamos gastar para chegar (custo).

Voltando ao comparativo. Aqui entram algumas questões:

Primeiro que é muito difícil prever os projetos no longo prazo, quanto mais complexo e longo maiores são as chances de falha, quem já fez obra em casa ou acompanhou alguma sabe do que estou falando, o pedreiro desaparece, o material de obra nunca é suficiente, o tempo vira e não seca, enfim, tem diversas variáveis que não são controláveis e nem consideradas no planejamento. O mesmo acontece em projetos de software ou qualquer outro que você queira usar como exemplo. Quanto mais longo o projeto maiores as chances de ter um imprevisto no meio. Se você quiser um comparativo com a viagem aí vai, no Scrum ao invés de seguir o plano de viagem a ideia seria ter a melhor experiência possível com ela e se adaptando ao que aparecer, quem nunca viajou e só lá descobriu que tinha uma coisa muito legal para se fazer?!

De madeira alguma isso quer dizer que não devemos planejar!

“No Scrum o planejamento existe, mas é focado em entregar o que tem mais valor primeiro e considerar as mudanças do meio do caminho.”

Segundo ponto, o cálculo de custo e prazo são estimativas — que por definição não são exatas. Assim como podemos falar que vamos entregar algo em determinado tempo e com custo definido? O que se faz é colocar a famosa “gordurinha”, ou “fator cagaço” como dizem nossos amigos portugueses. Nos projetos grandes de implementação de software isso é cerca de 30%. Isso aí, sempre que você comprar um projeto com preço fixo, ou seja, você tem um valor fechado para uma quantidade de featuresdefinidas você está pagando 30% a mais do que o estimado. Mas quer saber o pior, geralmente estouram tanto o custo quanto o prazo.

Por último e talvez mais importante, as coisas mudam, mudam o tempo todo e cada vez mais mudam mais rápido. Eu nunca, repito, nunca vi um projeto de ERP sem ao menos uma mudança. Isso é muito natural, trabalhei por 10 anos em empresas multinacionais e houve mais mudanças do que anos fiscais.

“Isso não é um problema, pelo contrário isso é parte do dia a dia e essencial para sobrevivência de uma empresa na atualidade, a questão é como tratar o desenvolvimento e implantação de soluções para a empresa que acompanhe este movimento.”

Mas essa constância de mudanças é um inferno para um projeto convencional, pois tem que se replanejar tudo, já que quero ver até o final do projeto como será, colocar todos os recursos e prazos, revisitar documentação, etc etc.

Quando estamos falando do modelo atual de empresas, desenvolvimento de produtos ou projetos e startups temos que olhar com outros olhos, se demorarmos um ano para entregar um produto já perdemos o timing, aquilo não é mais necessário ou alguém já realizou antes. Temos que gerar valor o quanto antes e não só nos adaptar a mudança — isso já passou — temos que promover a mudança!

Em resumo, vemos essa diferença assim, se em um projeto tem a definição exata do escopo, o ambiente controlado, as entradas e saídas definidas e o conhecimento necessário para implementar a gestão de projeto tradicional ainda funciona, agora, se você está criando algo que será inovador e/ou se adequará as mudanças que surgirem, o melhor é utilizar uma metodologia que seja feita para isso. Como deve imaginar vou seguir falando desta segunda forma.

Uma Breve História do Scrum

Bom, vamos lá, o termo Scrum tem uma referência voltando lá em 1986, quando Takeuchi e Nonaka, dois grande pensadores de gestão fizeram um paper chamado ‘The New New Product Development Game’ que foi revolucionário. Eles pegaram emprestado o termo do rugby para focar na importância dos times e algumas analogias entre um time de esporte — como rugby — e o sucesso no desenvolvimento no jogo do novo desenvolvimento de produto. Os pesquisadores descreveram no paper mostrando como a performance extraordinária do desenvolvimento de produtos novos e complexos são alcançados quando equipes — de poucas pessoas e auto-organizado — são estimuladas com objetivos, e não com tarefas. Os melhores times são aqueles que são dados direcionamentos e que eles tem espaço para criar suas próprias táticas para atingir aquele objetivo. Equipes necessitam de autonomia para atingir a excelência.

Mais tarde, no início dos anos 90, Jeff Sutherland e Ken Schwaber conceberam o Scrum e o codificaram em 1995 para apresentar na conferência Oopsla em Austin, Texas (US) e publicaram o paper “SCRUM Software Development Process”. Eles pegaram o nome emprestado do Takeuchi e Nonaka — que pegaram emprestado do rugby :).

O framework Scrum para desenvolvimento de software implementa os princípios descritos neste paper para desenvolvimento e sustentação do produtos de software complexos. Enquanto no processo de desenvolvimento e usando as primeiras versões do Scrum, Ken questionou o Professor Babatunde A. Ogunnaike Tunde, um famoso pesquisador de controle de processo, para olhar o processo de desenvolvimento de software. Tunde investigou algumas metodologias comerciais para concluir que o método Cascata e processos preditivos não são adequados para o desenvolvimento de software. Ele confirmou que a abordagem empírica do Scrum seria um processo preferencial.

Aqui entra um ponto bem importante, as origens do modelo tradicional vem lá de (Frederick) Taylor e (Henri) Fayol passando por (Henry) Gantt, que basicamente — dá um super texto falar disso tudo aqui, por isso não vou entrar em detalhes — criaram e disseminaram a administração científica voltada a linha de produção. Daí que mais tarde surgiu o gerenciamento de projetos, como o desenvolvimento é um processo criativo não funciona bem aqui.

“O empirismo funciona muito bem quando o que é desconhecido é maior do que o conhecido e predições tem pouco valor dada a alta taxa de mudanças e incertezas.”

O Scrum foi testado e refinado na Individual, Inc., Fidelity Investments e IDX.

Em fevereiro de 2001, Jeff, Ken e mais outros 17 desenvolvedores de software líderes de mercado criaram o Manifesto for Agile Software Developmente, ou Manifesto Agile, e seguindo estes princípios a Agile Alliance foi fundada com Ken Schwaber sendo seu primeiro chairman.

Ainda em 2001, inspirado pelo Ken Beck, o Ken Schwaber foi co-autor o primeiro livro de Scrum, junto com Mike Beedle, Agile Software Development with Scrum ((( Ver título em PT_BR ))). Em 2002, Ken Schwaber fundou a Scrum Alliance com Mike Cohn e Esther Derby, sendo Ken o chairman da organização. Nos anos seguintes o programa de Certified ScrumMaster e seus derivados foram criados e lançados.

Em 2006, Jeff Sutherland criou sua própria empresa, a Scrum.inc, enquanto continuava a oferecer e ministrar cursos de Certified Scrum.

Ken deixou a Scrum Alliance em 2009 e fundou a Scrum.org para promover a qualidade e efetividade do Scrum.

A primeira publicação do Scrum Guide foi em 2010, e teve incrementos em 2011 e 2013, com Jeff e Ken estabelecendo o globalmente reconhecido corpo de conhecimento do Scrum.

Desde sua primeira publicação em 1995 até hoje, o Scrum tem sido adotado por uma grande quantidade de empresas de desenvolvimento de software por todo o mundo. Hoje ele é reconhecido como o framework mais aplicado para desenvolvimento com Agile. Existem mais de mil livros publicados sobre o Scrum.

Recentemente o uso do Scrum tem sido muito bem sucedido em outros domínios, incluindo manufatura, marketing, operação e educação.

Definição do Scrum

“Scrum é um framework em que pessoas podem endereçar problemas complexos de forma produtiva e criativa entregando produtos com o maior valor possível.”

O Scrum é:

• Leve
• Simples de Entender
• Difícil de Dominar

Como um framework de processo, o Scrum é usado para gerenciar o desenvolvimento de produtos desde o início dos anos 90. O Scrum não é um processo ou uma técnica para se criar produtos, mas um framework no qual você pode implementar vários processos ou técnicas. Ele torna claro a eficácia relativa do seu gerenciamento do produto e as práticas de desenvolvimento para que você possa melhora-las.

O Scrum consiste nos Times Scrum (Scrum Teams) e seus Papéis (roles) associados, Eventos (events), Artefatos (artifacts) e Regras (rules). Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum.

As regras do Scrum juntam os eventos, papéis e artefatos, governando a relação e interação entre eles. Neste artigo vou descrever as regras básicas do Scrum e nos outros vou focar nas táticas específicas.

A Teoria do Scrum

A fundação do Scrum é baseada no empirismo. Este diz que o conhecimento vem da experiência e em tomar decisões com base no que se sabe. O Scrum emprega uma abordagem iterativa e incremental para otimizar a predibilidade e o controle de risco.

“Os três pilares que sustentam cada implementação do processo empírico são: Transparência, Inspeção e Adaptação”

Transparência

Aspectos importantes do processo devem ser visíveis aos responsáveis pelos resultados. A transparência requer que estes aspectos sejam definidos por um padrão comum, desta forma todos que os veem podem ter um entendimento comum do que está sendo visto.

Por exemplo:

• Uma linguagem comum de referencia ao processo deve ser compartilhada por todos os participantes
• Aqueles que estão atuando efetivamente e os que recebem os resultados devem ter uma definição única de “Done”

Inspeção

Os usuários do Scrum frequentemente inspecionam os artefatos e o progresso da Meta do Sprint para detectar variações indesejáveis. As inspeções não devem ser frequentes ao ponto de atrapalhar o trabalho, e elas são mais benéficas quando realizadas diligentemente por pessoas capacitadas e no momento correto.

Adaptação

Se um inspetor determinar que um ou mais aspectos do processo se desviou do que é aceitável, o que resultaria na não-aceitação do produto, o processo ou material deve ser ajustado. Os acertos devem ser feitos o quanto antes para minimizar futuros desvios.

O Scrum prescreve quatro eventos formais para inspeção e adaptação, como descrito na seção de Eventos deste artigo:

• Planejamento do Sprint (Sprint Planning)
• Reunião Diária (Daily Scrum)
• Revisão do Sprint (Sprint Review)
• Retrospectiva do Sprint (Sprint Retrospective)

Valores do Scrum

Quando os valores de comprometimento, coragem, foco, abertura e respeito estão enraizados e vivos no Time Scrum, os pilares de transparência, inspeção e adaptação se tornam reais e constroem confiança para todos. Os membros do Time Scrum aprendem e exploram estes valores conforme eles trabalham nos eventos, papeis e artefatos.

O uso bem sucedido do Scrum depende das pessoas se tornarem mais hábeis nestes cinco valores. Os membros do Time Scrum devem ter a coragem de fazer a coisa certa e trabalhar em problemas difíceis. Cada um deve focar no trabalho do Sprint e nos objetivos do Time Scrum. O Time e as partes interessadas (stakeholders) concordam em ser abertos sobre todo o trabalho e desafio que tem. Deve reinar o respeito para que cada um seja capaz de agir independentemente.

Papéis, Artefatos e Eventos

Aqui vamos falar de forma resumida sobre esses tópicos, cada um deles dá um textão — que vou colocando os links conforme for escrevendo.

Papéis

Para o funcionamento do Scrum o Time (falo mais em detalhes aqui) tem três papéis fundamentais, que são: Product Owner, Time de Desenvolvimento e Scrum Master. Antes de falar de cada um deles é importante falarmos do funcionamento do Time Scrum como um todo. Sempre que falarmos de Time Scrum estamos falando das pessoas que atuam em todos esses papéis — Product Owner, Time de Desenvolvimento e Scrum Master — o que pode confundir um pouco pois um dos papéis é Time de Desenvolvimento, mas eles são coisas diferentes.

O Time Scrum tem como premissa a própria essência do Scrum, empirismo e auto-organização, com isso se descobre a melhor forma de entregar um trabalho. Não tem uma visão hierárquica entre os papéis, são todos horizontais e muito menos uma relação com método cascata de projetos ou qualquer outro, não se pode dizer que o Scrum Master é o Gerente de Projeto, por exemplo, isso seria conceitualmente errado. É multi-funcional evitando separar em caixinhas o que cada um faz, principalmente dentro do Time de Desenvolvimento.

O mais importante na composição do time é ele ser otimizado para flexibilidade, criatividade e produtividade. Por isso deve manter o empirismo, auto-organização, horizontalidade e multi-funcionalidade o tempo todo. Outro ponto importante é o time ter toda competência necessária para concluir o trabalho, sem depender de consultores, agentes externos, analistas ou qualquer outra pessoa que não faça parte do time.

O papel do Time Scrum é entregar — seja o que for — de forma iterativa e incremental mas de forma que a entrega sempre seja utilizável e tenha algum valor.

O Product Owner é o responsável por maximizar o valor do produto entregue, de uma forma geral, gerenciando o Product Backlog para que os itens de maior valor sejam entregues antes e alinhando com os stakeholders as necessidades.

O Time de Desenvolvimento — ou Development Team — é quem realiza o trabalho para entregar um Incremento de Produto, ou seja, algo que poderá ser usado e tenha algum valor. Não existe distinção de função dentro do Time de Desenvolvimento, por exemplo, não existe Developer, Tester e Support, todos do time executam todas as tarefas. Isso não quer dizer que não haja especialização! A auto-organização é essencial dentro do Time de Desenvolvimento.

O Scrum Master é responsável por manter o Scrum funcionando, para isso ele precisa promover a mudança de cultura tanto do Time Scrum quanto da organização a quem o time serve. Inspecionar os artefatos e manter a transparência são vitais para que se tenha adaptabilidade e flexibilidade. A principal função do Scrum Master, porém é se fazer desnecessário, ele deve ensinar e promover a cultura Scrum para que o Time não precise dele.

Eventos

Os eventos são utilizados no Scrum para se manter uma regularidade e diminuir a necessidade de reuniões que não estas definidas. Todos os eventos no Scrum tem uma duração definida, usamos o termo time-boxed para isso, é extremamente importante — e difícil para nós brasileiros — fazer isso. Os eventos do Scrum são: Sprint, Sprint Planning, Daily Meeting, Sprint Review e Sprint Retrospective.

O Sprint é o coração do Scrum, este evento é um time-box de até um mês, mas geralmente de tempos menores, as variações mais comuns são de 1 a 4 semanas. Durante o Sprint um Incremento deve estar “Done”.

O Sprint é um container para outros eventos, sendo eles:

• Sprint Planning: O trabalho a ser realizado durante o Sprint é planejado aqui, ele é o primeiro evento e o Sprint deve começar com ele. A duração time-boxed é de 8 horas para um Sprint de um mês. Durante este evento será definido o que será entregue no Sprint e como o trabalho será realizado.
• Daily Scrum: Este é um evento diário time-boxed de 15 minutos, que se realiza sempre na mesma hora e local para facilitar. É necessário que todo o Time de Desenvolvimento esteja presente e cada um diz o que fez nas últimas 24 horas, o que fará nas próximas e se vê algum impedimento para alcançar a meta.
• Sprint Review: Acontece no final do Sprint e serve para inspecionar o Incremento e adaptar o Product Backlog, se necessário. Todos do Time Scrum e stakeholders colaboram. É um evento time-boxed de 4 horas para Sprints de um mês.
• Sprint Retrospective: Ocorre após o Sprint Review e é usado para o Time Scrum se auto-inspecionar e criar melhorias para o próximo Sprint. É um evento time-boxed de 3 horas para Sprints de um mês.

Artefatos

Os Scrum Artifacts representam o trabalho ou valor para prover transparência e oportunidades de inspeção e adaptação. Os artefatos definidos pelo Scrum são especialmente desenhados para maximizar a transparência das informações chaves de forma que todos tenham o mesmo entendimento do artefato.

Os artefatos minimamente a serem utilizados são:

• Product Backlog: uma lista ordenada de tudo que deve ser necessário em um produto a é a única fonte de requerimentos para qualquer mudança que seja feita no produto. O Product Owner é a pessoa responsável por ele, incluindo seu conteúdo, disponibilidade e ordenação.
• Sprint Backlog: um sub-conjunto de itens do Product Backlog selecionados para um Sprint, mais o plano de entrega do Incremento e entendimento da meta a ser atingida. O Sprint Backlog é previsto pelo Time de Desenvolvimento com relação as funcionalidades que estarão no próximo Incremento e o trabalho necessário para entregar esta funcionalidade em um Incremento “Done”.
• Incremento: O Incremento é a soma de todos os itens do Product Backlog completos durante o Sprint e o valor dos incrementos de todos os outros Sprints.

Nota Final

O Scrum é livre. Todos os papéis, artefatos, eventos e regras são imutáveis e embora seja possível implementar apenas partes do Scrum, o resultado não é Scrum. O Scrum existe apenas em sua totalidade e funciona bem como um container para outras técnicas, metodologias e práticas.

** fonte: http://scrumit.com.br/scrum-o-que-e/