Artefatos do Scrum

Esse post faz parte de uma série sobre Scrum e descreve os Artefatos do Scrum. 

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Artefatos

Os artefatos do Scrum foram desenvolvidos para manter a transparência do que está sendo executado, e para garantir que todos da equipe tenham um entendimento do artefato.

O Scrum possui os seguintes artefatos:

• Product Backlog
• Sprint Backlog
• Incremento

Product Backlog

O Product Backlog é uma lista ordenada de tudo o que é necessário para o produto. É a única fonte de informações dos requisitos das alterações que podem ser feitas no produto.

 

O Product Owner é o responsável pelo Product Backlog, incluindo o conteúdo, a disponibilidade e a ordenação.

 

O Product Backlog nunca está completo. A primeira versão possui somente os requisitos iniciais conhecidos até o momento. Conforme o produto vai evoluindo o Product Backlog vai evoluindo também.  

O Product Backlog é dinâmico porque o produto passa por diversas fases, e enquanto o produto existir o Product Backlog deve existir também.

 

O Product Backlog lista todas as características, funções, requisitos, melhorias e correções que constituem as alterações que podem ser feitas no produto para as próximas distribuições.

 

Os itens do Product Backlog possuem os atributos de descrição, ordem, estimativa e valor.

 

Conforme o produto for sendo utilizado e o mercado começar a dar retorno sobre o produto, o Product Backlog vai crescendo e se tornando uma lista cada vez maior. Os requisitos nunca param de sofrer alterações. Mudanças nos requisitos de negócios como, por exemplo, mudanças fiscais, mudanças de condições de mercado ou mudanças tecnológicas podem promover alterações no Product Backlog.

 

O refinamento do Product Backlog é o ato de incluir detalhes, estimativas e dar ordem aos itens. Este é um processo onde o Product Owner e a equipe de desenvolvimento colabora nos detalhes dos itens. 

Durante o refinamento os itens são revisados. A equipe do Scrum decide onde e quando o refinamento deve ser realizado. Ele não deve consumir mais do que 10% da capacidade da equipe de desenvolvimento. Entretanto os itens do Product Backlog podem ser atualizados a qualquer momento pelo Product Owner.

 

Os itens ordenados na posição mais alta são normalmente mais detalhados e claros do que os itens ordenados nas posições mais baixas. As estimativas dos itens mais claros e detalhados são também mais precisos.

 

Os itens do Product Backlog que irão ocupar a equipe de desenvolvimento no próximo Sprint são os que poderão atingir os status Done, dentro de um período de um Sprint.

 

Os itens que podem ser executados pela equipe de desenvolvimento, ou seja, que podem assumir o status Done são considerados como Ready para a seleção do Sprint Planning.

 

A equipe de desenvolvimento é a responsável por todas as estimativas. O Product Owner pode auxiliar a equipe de desenvolvimento no entendimento ou selecionando algumas trocas de itens, mas as pessoas que irão trabalhar no desenvolvimento é que definem a estimativa final.

A Figura abaixo exibe o exemplo de um Product Backlog do projeto de uma Biblioteca Virtual.

Sprint Backlog

O Sprint Backlog é criado pela equipe de desenvolvimento. Possui a previsão sobre qual funcionalidade estará presente no próximo Incremento, e o trabalho necessário para entregar essa funcionalidade.

O Sprint Backlog torna visível todo o trabalho que a equipe de desenvolvimento identifica como necessário para atingir o Sprint Goal. 

A equipe de desenvolvimento modifica o Sprint Backlog durante todo o Sprint. Conforme novos trabalhos são necessários, a equipe inclui os novos trabalhos. A estimativa sofre atualizações à medida que o trabalho é completado. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente a equipe de desenvolvimento pode alterar o Sprint Backlog durante um Sprint.

 

O Sprint Backlog é um retrato em tempo real altamente visível, do trabalho que a equipe de desenvolvimento espera cumprir durante o Sprint, e ele pertence somente à equipe de desenvolvimento.

O progresso do Sprint pode ser monitorado através da verificação do trabalho pendente. A qualquer momento durante o Sprint o total de trabalho faltante pode ser visualizado. A equipe de desenvolvimento monitora o total de trabalho faltante pelo menos uma vez ao dia, durante o Daily Scrum.

A Figura abaixo exibe o exemplo de um Sprint Backlog do projeto de uma Biblioteca Virtual.

Incremento

O incremento é a soma de todos os itens completados do Product Backlog durante o Sprint, e o valor de todos os incrementos de todos os Sprint anteriores.

 

No final do Sprint o novo incremento deve estar com o estado Done, o que significa que ele está em condições de usabilidade independentemente do Product Owner resolver lançar ou não.

Quando um item do Product Backlog ou um Incremento é definido com o estado Done todos devem estar cientes do significado de Done. Apesar de o significado poder variar significativamente entre os membros do Scrum Team, os membros devem compartilhar o significado para que o trabalho esteja completo e a transparência garantida. 

 

A mesma definição guia a equipe de desenvolvimento em quantos itens do Product Backlog podem ser selecionados durante um Sprint Planning. O propósito de cada Sprint é entregar Incrementos de funcionalidades potencialmente prontas para lançamento, que aderem à definição de Done do Scrum Team.

 

A equipe de desenvolvimento entrega um Incremento de funcionalidade do produto a cada Sprint. Esse Incremento é utilizável, portanto o Product Owner pode optar pelo lançamento.

 

O Scrum Team deve seguir a definição de Done se o Incremento é parte da convenção padrão ou orientação da organização de desenvolvimento. Se a definição de Done para um Incremento não é uma convenção na organização de desenvolvimento, a equipe de desenvolvimento do Scrum Team deve definir uma definição de Done apropriada para o produto.

Se existem múltiplos Scrum Team trabalhando no sistema ou lançamento do produto, a equipe de desenvolvimento de todos os Scrum Team, devem mutuamente definir o significado de Done.

 

Cada Incremento é um aditivo de todos os Incrementos anteriores e completamente testados, garantindo que todos os Incrementos trabalhem juntos.

 

Conforme o Scrum Team vai amadurecendo, é esperado que suas definições de Done sejam expandidas a fim de incluir critérios mais rigorosos para melhorar a qualidade. Qualquer produto ou sistema deveria ter uma definição de Done que é um padrão para qualquer trabalho executado.

Eventos do Scrum

Esse post faz parte de uma série sobre Scrum e descreve os eventos do Scrum.

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Eventos

Os eventos são utilizados para criar uma regularidade e minimizar a necessidade de reuniões não definidas. Todos os eventos são definidos com um período fixo e com duração máxima. Os eventos do Scrum são:

• Sprint
• Sprint Planning
• Sprint Goal
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Os eventos restantes terminam quando alcançam o propósito do evento, assegurando uma quantidade de tempo gasta, sem permitir desperdícios no processo.

 

Se houver uma falha em incluir qualquer um dos eventos irá resultar em transparência reduzida e uma oportunidade perdida para inspecionar e adaptar.

Sprint

A parte principal do Scrum é um Sprint que é um período fixo normalmente de um mês ou menos no qual se cria o incremento do produto. O Sprint é o repositório para todos os outros eventos e cada evento é uma oportunidade formal para fazer a inspeção e adaptação.

 

O Sprint consiste basicamente de um Sprint Planning, um Daily Scrum, o desenvolvimento do trabalho, o Sprint Review e o Sprint Retrospective.

A Figura abaixo ilustra as etapas de um Sprint estimado em 30 dias.

Um Sprint pode ser cancelado antes do final de seu período, caso um Sprint Goal fique obsoleto. Isto pode acontecer se a empresa mudar de direção ou se as condições do mercado ou da tecnologia sofrerem alterações. Somente o Product Owner tem a autoridade para cancelar um Sprint.

De um modo geral cancelar um Sprint só faz sentido mediante circunstâncias especiais. Mas devido a curta duração, este evento raramente acontece.

 

Quando se cancela um Sprint podem-se adotar as seguintes providências, dependendo do estágio em que o Sprint se encontra:

• Revisar qualquer item que esteja com o status Done no Product Backlog.
• O Product Owner pode aceitar o produto se puder lançar parte desse produto.
• Estimar novamente todos os itens incompletos e colocar de volta no Product Backlog.
• Estimar novamente o trabalho feito nos itens do Product Backlog.

O cancelamento de um Sprint é ruim porque consome muitos recursos. Todos os envolvidos devem se reagrupar novamente para fazer um novo planejamento. O cancelamento de um Sprint é uma atividade pouco comum.

Sprint Planning

O Sprint Planning define o planejamento do trabalho a ser realizado durante um Sprint. Cria-se o plano através do trabalho conjunto de todo o Scrum Team.

 

O Sprint Planning é um trabalho executado em um período que demora no máximo oito horas para o Sprint de um mês. Para Sprints menores o Sprint Planning pode demorar um pouco menos. 

A função do Scrum Master é garantir que o evento aconteça, que os participantes entendam o propósito do evento e mantenham o planejamento dentro do prazo fixado.

 

O Sprint Planning responde as seguintes perguntas:

• O que pode ser entregue em termos de Incremento?
• Como alcançar o trabalho necessário para entregar o Incremento?

Sprint Goal

O Sprint Goal é um objetivo configurado para o Sprint que pode ser atingido através da implementação do Product Backlog.  Ele funciona como um guia para a equipe de desenvolvimento na definição do porquê construir o Incremento. 

Ele é criado durante as reuniões de Sprint Planing. O Sprint Goal dá à equipe de desenvolvimento alguma flexibilidade em relação à funcionalidade implementada dentro do Sprint. Os itens selecionados do Product Backlog entregam uma função coerente, que pode ser o Sprint Goal.

 

A equipe de desenvolvimento trabalha com o Sprint Goal em mente. Se o trabalho acaba sendo diferente do que a equipe de desenvolvimento esperava, eles colaboram com o Product Owner para negociar o escopo do Sprint Backlog durante o Sprint.

Daily Scrum

O Daily Scrum é uma reunião de 15 minutos realizada pela equipe de desenvolvimento com o objetivo de discutir os seguintes pontos:

• O que “eu” fiz no dia anterior para atingir o objetivo do Sprint.
• O que “eu” farei hoje para auxiliar a equipe de desenvolvimento a atingir o Sprint Goal.
• Se “eu” vejo algum impedimento para atingir o Sprint Goal.

Para evitar complicações o Daily Scrum deve ser feito todos os dias no mesmo local.

 

A função do Daily Scrum é inspecionar o trabalho realizado desde a última reunião e prever o trabalho que será feito até a próxima reunião.

 

A equipe de desenvolvimento ou alguns membros da equipe frequentemente se reúnem após o Daily Scrum, para as discussões mais detalhadas e adaptar ou planejar o resto do trabalho do Sprint.

 

O Scrum Master deve garantir que as reuniões diárias do Scrum ocorram e não durem mais do que 15 minutos. A equipe de desenvolvimento é responsável em conduzir a reunião.

Sprint Review

O Sprint Review é uma reunião informal de no máximo quatro horas, para o Sprint de um mês, a fim de inspecionar o Incremento e revisar o Product Backlog, se necessário.

 

A reunião é formada pela equipe do Scrum e as partes interessadas no projeto. É realizado no último dia do Sprint. Os participantes colaboram com as informações das próximas atividades.

 

O Scrum Master deve garantir que a reunião aconteça obedecendo ao tempo limite. O Sprint Review inclui os seguintes elementos:

• Os participantes são a equipe Scrum e as pessoas chaves convidadas pelo Product Owner.
• O Product Owner explica quais os itens do Product Backlog foram para o status Done. A equipe de desenvolvimento explica o que deu certo, o que não funcionou e como o problema foi resolvido.
• A equipe de desenvolvimento mostra o trabalho que foi realizado e responde perguntas sobre o Incremento.
• O grupo inteiro colabora com as informações do que fazer a seguir, de forma que o Sprint Review gere a entrada para o próximo Sprint Planning.
• Verifica se o mercado ou a função do produto sofreu alguma alteração, para decidir o que fazer a seguir.
• Revisa a linha de tempo, orçamento e mercado para prever o próximo lançamento do produto.

O resultado do Sprint Review é um Product Backlog revisado que define os prováveis itens do próximo Sprint.

Sprint Retrospective

O Sprint Retrospective é uma oportunidade para a equipe Scrum fazer uma avaliação e verificar possibilidades de melhoria no projeto, que podem ser inseridas no próximo Sprint. 

A reunião do Sprint Retrospective deve ocorrer após o Sprint Review e antes do próximo Sprint Planning, normalmente no último dia do Sprint. O Scrum Master deve participar desta reunião como um colaborador e garantir que não demore mais do que três horas, para o Sprint de um mês. Para Sprint menores este tempo pode ser reduzido.

 

A finalidade do Sprint Retrospective é:

• Inspecionar como foi o último Sprint com relação às pessoas, relacionamentos, processos e ferramentas.
• Identificar e ordenar os itens principais que foram bem e verificar as possibilidades de melhorias.
• Criar um plano para executar melhorias, com a finalidade de aprimorar a qualidade do produto.

No fim do Sprint Retrospective as melhorias que serão executadas já foram identificadas. Apesar dos aperfeiçoamentos poderem ser feitos a qualquer momento, o Sprint Retrospective é uma forma de oficializar as melhorias que são necessárias no produto.

Organização do Scrum

Esse post faz parte de uma série sobre Scrum que descreve a organização do Scrum. 

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Organização

A equipe Scrum é composta por um Product Owner, uma Equipe de Desenvolvimento e um Scrum Master. É auto organizada porque escolhe como executar o trabalho da melhor forma possível, ao invés de ser direcionada por outros fora da equipe. É funcional, porque possui todas as competências necessárias para realizar o trabalho, sem depender de outros que não fazem parte da equipe.

A equipe Scrum entrega produtos iterativamente e de forma incremental, para garantir que uma versão do produto funcional esteja sempre disponível, aumentando as oportunidades para um retorno de comentários.

O modelo de equipe do Scrum foi desenvolvido para aperfeiçoar a flexibilidade, criatividade e produtividade.

Product Owner

O Product Owner é o único responsável em administrar o Product Backlog (lista completa de funcionalidades que devem ser incluídas no produto), e possui as seguintes funções: 

• Incluir os itens no Product Backlog.
• Fazer a ordenação dos itens do Product Backlog, de forma a atingir os objetivos e missões.
• Aperfeiçoar o valor do trabalho que a Equipe de Desenvolvimento realiza.
• Garantir que o Product Backlog seja visível, transparente e claro para todos, além de definir para a Equipe Scrum qual é o próximo trabalho.
• Garantir que a Equipe de Desenvolvimento entenda os itens do Product Backlog no nível necessário.

O Product Owner pode fazer todo o trabalho descrito acima, ou passar para a Equipe de Desenvolvimento, entretanto continua sendo o responsável.

 

O Product Owner é uma pessoa, não um comitê. Pode representar o desejo do comitê no Product Backlog, mas os indivíduos que desejam alterar a prioridade dos itens, devem se dirigir ao Product Owner.

 

Para que o Product Owner tenha sucesso, toda a organização deve respeitar suas decisões. As decisões são visíveis no conteúdo e na ordenação do Product Backlog. Ninguém tem permissão de solicitar que a Equipe de Desenvolvimento trabalhe em um conjunto de requisições, e a Equipe de Desenvolvimento também não tem permissão de agir de acordo com opiniões de outras pessoas.

Equipe de Desenvolvimento

A Equipe de Desenvolvimento consiste de profissionais que são responsáveis em entregar um Incremento com status Done do produto, no final de cada Sprint (período onde são desenvolvidos os itens acertados no Product Backlog). Somente os membros da Equipe de Desenvolvimento podem criar o Incremento.

As Equipes de Desenvolvimento são estruturadas e autorizadas para organizar e administrar o seu próprio trabalho. As Equipes de Desenvolvimento possuem as seguintes características:

São auto organizadas, ninguém nem mesmo o Scrum Master, pode interferir na forma de transformar os itens do Product Backlog, em Incrementos de funcionalidades potencialmente prontas para o lançamento.

• São funcionais no sentido de possuir todas as habilidades necessárias em uma equipe para criar o Incremento do produto.
• O Scrum não reconhece nenhum título diferente de "Desenvolvedor", independente da função executada pelo profissional.
• O Scrum não reconhece nenhum subdomínio na Equipe de Desenvolvimento, independentemente de domínios particulares que precisam ser nomeados como testadores ou analista de negócios.
• Os membros individuais da equipe podem possuir habilidades específicas na área do trabalho, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo.

O tamanho ótimo de uma equipe de desenvolvimento pode ser pequeno o suficiente para ser ágil ou grande o suficiente para completar o trabalho dentro de um Sprint.

Menos do que três membros na Equipe de Desenvolvimento, diminui a interação e resulta em um ganho de produtividade menor. Equipes muito pequenas podem encontrar restrições durante o Sprint, que dificultam a entrega de um Incremento.

Equipes muito grandes podem dificultar a coordenação e podem gerar complexidade para administrar um processo empírico.

 O Product Owner e o Scrum Master não entram na contagem da Equipe de Desenvolvimento, a não ser que também estejam executando trabalhos no Sprint Backlog.

Scrum Master

O Scrum Master é responsável para que o Scrum seja entendido, assegurando que a Equipe siga a teoria, práticas e regras do Scrum.

 O Scrum Master auxilia aqueles que estão de fora da equipe a entender quais interações são úteis e quais não são. O Scrum Master ajuda todos a alterar essas interações de forma a maximizar o valor criado pela Equipe do Scrum.

Introdução ao Scrum

Ouvimos falar da metodologia ágil principalmente no processo de desenvolvimento de software. Dentre essas metodologias o Scrum é um método que foi desenvolvido na década de 90, e atualmente é amplamente utilizado nas empresas de desenvolvimento de software de todos os portes.

Você vai encontrar nesse blog uma série de posts sobre Scrum composto pelos tópicos:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode ler o tópico de interesse, ou se preferir faça o download do Ebook com todos os tópicos através do link abaixo.

Download Ebook Introdução ao Scrum

Definição e Exemplo de Scrum

Esse post faz parte de uma série sobre Scrum, descreve a definição e mostra alguns exemplos práticos de utilização do Scrum em projetos de empresas.

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Introdução

O Scrum não é um processo ou uma técnica para construir produtos, ao invés disto é um framework no qual se podem empregar várias técnicas ou processos, para melhorar as práticas de desenvolvimento e gestão do produto.

O Scrum é um framework de processo que tem sido usado para administrar o desenvolvimento de produtos complexos desde o início dos anos 90. O nome Scrum é derivado de uma atividade que ocorre dentro de um jogo chamado Rugby. O Scrum dentro do jogo de Rugby significa que o jogo deve recomeçar, sempre que uma regra é infringida.

O framework do Scrum consiste de Scrum Teams, seus papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum.

A Teoria do Scrum

O Scrum é fundamentado na teoria de controle do processo empírico, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e tomadas de decisões baseado no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental, para aperfeiçoar a previsibilidade e controlar os riscos.

Três pilares apoiam toda a implementação de controle de um processo empírico: transparência, inspeção e adaptação.

Transparência

Os aspectos do processo devem ser visíveis pelas pessoas responsáveis pelo resultado. A transparência requer que estes aspectos sejam definidos em um padrão comum, de forma que os observadores compartilhem o mesmo entendimento do que está sendo visto. Um exemplo de transparência é definir que todos os participantes do processo, utilizem uma linguagem comum, para que todos tenham o mesmo entendimento.

Inspeção

A inspeção deve ser feita durante todo o processo de trabalho, para detectar se ocorreram variações indesejáveis no processo. Mas é preciso ter cuidado para que as inspeções não sejam frequentes demais, de forma a atrapalhar o andamento do trabalho. A inspeção é mais eficiente se as pessoas que executam são conhecedoras do assunto

Adaptação

Se o inspetor detecta que um ou mais aspectos do processo sofreu desvios de forma que o produto resultante seja inaceitável, o processo deve ser ajustado. O ajuste deve ser feito o mais rápido possível para minimizar futuros desvios.

Exemplo de Scrum

Normalmente encontramos muita teoria do que é o Scrum, mas não encontramos com facilidade publicações de exemplos práticos de empresas que adotaram o Scrum.

Nesse post inseri dois exemplos de utilização, um com uma aplicação na área de software e o outro na área de construção. Os exemplos tem um link para os artigos com a história completa, detalhando a utilização do Scrum no processo de desenvolvimento do produto. Os artigos estão originalmente em inglês.

Scrum Aplicado em Projeto de Software nas Ferrovias Holandesas

A ferrovia holandesa tinha a necessidade de desenvolvimento de um software de informações de viagens para os passageiros. As informações como horários, destinos, intervalos, deveriam ser exibidas em displays e comunicadas através de som automaticamente.

A ferrovia contratou uma consultoria que aplicou o Scrum no desenvolvimento do projeto, utilizando equipes na Índia e na Holanda.  O projeto era muito grande envolvendo várias equipes localizadas nos dois países, e com uma integração complicada com outros produtos, além de possuir uma interface de usuário bem complexa.

Uma das exigências do cliente neste projeto era ter a possibilidade de ver o projeto funcionando em etapas, desde o início e não somente na entrega final do produto. Com a utilização do Scrum foi possível fazer entregas incrementais e permitir uma maior participação do cliente em todas as fases. Também permitiu um melhor gerenciamento de todas as equipes envolvidas no projeto.

O artigo descreve detalhadamente como foi todo o processo de desenvolvimento, bem como as dificuldades e as lições aprendidas sobre o início do projeto, a importância da escolha do dono do produto (Product Owner), a importância de estimativas, a efetividade da comunicação e a importância de uma documentação bem elaborada.

A história completa está descrita no artigo Case Study: Distributed Scrum Project for Dutch Railways.

Scrum Aplicado em Projeto de Construção de Viaduto 

Na Índia em Bangalore, existia a necessidade de construir dois viadutos um para cada sentido, para melhorar o tráfego na região. A estimativa do projeto era de entregar os viadutos em dezoito meses.

A ideia era construir duas rotas temporárias uma para cada sentido antes de construir os viadutos, para desviar o tráfego da área de construção. Com a utilização do conceito incremental foi construída uma rota temporária e um viaduto, que ficou pronto em nove meses, e já passou a ser utilizado pelos usuários.

Como um viaduto estava pronto, ele começou a ser utilizado pelos usuários, ao invés de ter que construir a outra rota temporária para o outro sentido. Nos nove meses restantes foi construído o segundo viaduto.

A utilização do Scrum neste caso com a entrega incremental se mostrou eficaz tanto para o projeto como para os usuários, que tiveram a entrega de um viaduto na metade do tempo sem a necessidade de construir duas rotas temporarias.

O detalhe completo do projeto está descrito no artigo A Real Life Example of Agile.

Como podemos observar nos exemplos de Scrum, ele pode ser aplicado tanto na área de software onde a utilização é mais conhecida, como em várias outros áreas de projetos complexos.

História do Scrum

Esse post faz parte de uma série sobre Scrum que descreve a história do processo de criação do Scrum.

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

A História

O Scrum foi criado por Jeff Sutherland e Ken Schwaber em 1995, e apresentado na conferência Ospsla em Austin no Texas. Neste mesmo ano foi publicado o artigo “SCRUM Software Development Process”.

Os autores herdaram o termo “Scrum” do artigo “The New Product Development Game”, publicado por Takeuchi e Nonaka em 1986. Neste artigo eles utilizam o termo “Scrum” obtido do jogo de Rugby, onde fazem uma analogia entre o processo de desenvolvimento de um produto com as táticas de jogo de Rugby, que valorizam o trabalho em equipe.

Neste artigo Takeuchi e Nonaka concluem que as equipes pequenas e auto-organizadas têm um desempenho melhor no desenvolvimento de produtos complexos, quando são definidos objetivos ao invés de tarefas a serem executadas.

No artigo eles mencionam que o mundo do negócio mudou muito, para que uma empresa seja competitiva não basta ter uma boa qualidade, custo baixo e um diferencial no mercado. As empresas também precisam de rapidez e flexibilidade.

O framework do Scrum para desenvolvimento de software foi criado para desenvolver e manter produtos complexos, baseado nos princípios deste artigo.

Durante o desenvolvimento inicial do Scrum, Ken pediu auxílio para o Professor Babatunde A. Ogunnaike Tunde, que é um engenheiro famoso na área de pesquisa de controle de processo, para verificar os processos de desenvolvimento. Ele investigou várias metodologias de desenvolvimento de software e chegou à conclusão que o processo cascata e preditivo não era bom para o desenvolvimento de software, confirmando que a abordagem empírica do Scrum era um processo preferido.

O empirismo é utilizado em trabalhos complexos onde o desconhecido prevalece sobre o conhecido, e predições têm pouco valor devido à alta taxa de alterações e incertezas.

Em 2001 Jeff e Ken estavam entre os 17 líderes de desenvolvimento de software, criando o Manifesto de Desenvolvimento de Software Ágil. Logo em seguida a Agille Alliance foi fundada com Ken sendo o primeiro presidente.

Ainda em 2001, Ken foi coautor juntamente com Mike Beedle do primeiro livro sobre Scrum, “Agile Software Development with Scrum”.

Em 2002 Ken Schwaber fundou o Scrum Alliance juntamente com Mike Cohn e Esther Derby, com Ken presidindo a organização. Nos anos seguintes o programa de certificação em Scrum Master e seus derivativos foram criados.

Em 2006 Jeff Sutherland criou sua companhia a Scrum Inc., enquanto continuava a oferecer e ministrar cursos de Certificações em Scrum.

Ken saiu da Scrum Alliance em 2009 e fundou a Scrum Org., para melhorar a qualidade e efetividade do Scrum.

O primeiro Scrum Guide foi publicado em 2010 e sofreu atualizações em 2011 e 2013, enquanto Jeff e Ken tinham estabelecido o reconhecimento mundial do Scrum.

Evolução do Scrum

Desde a sua publicação em 1995 até os dias de hoje, o Scrum foi adotado por várias empresas de desenvolvimento de software em todo o mundo.

Entretanto, o método também foi aplicado com sucesso em outros domínios como por exemplo, manufatura, marketing, operações e educação.