Um pouco sobre o Framework Scrum

O Scrum é um framework em que as equipes trabalham como uma unidade extremamente integrada com cada membro desempenhando um papel bem definido, eliminando controles desnecessários, inadequados ou burocráticos. A concentração do trabalho está na essência do processo de desenvolvimento de sistemas ou softwares.

Por isso, o Scrum emerge como uma alternativa, principalmente para as organizações de softwares. A metodologia Ágil não está relacionada ao produto, mas ao processo e ao valor de negócio que o produto representa para seus clientes. Essa metodologia possui um manifesto que é balizado por quatro premissas:

  • Responder a mudanças mais que seguir um plano;
  • Indivíduos e interação entre eles mais que processos e ferramentas;
  • Colaboração com o cliente mais que negociação de contratos;
  • Software em funcionamento mais que documentação abrangente.

OK, e os Pilares e os Papéis no SCRUM?

Fundamentado em três pilares (transparência, inspeção e adaptação), o framework Scrum consiste em times e, associado a eles, papéis, artefatos, eventos e regras. Existem três papéis no time Scrum. Nesse grupo de profissionais cada um sabe o que precisa ser feito e como, sem a necessidade de aguardar ordens e, ainda, possuem as competências necessárias para fazer o que tem que ser feito sem dependências que não do próprio time.

  • Product Owner: responsável por maximizar o valor de retorno do produto para o cliente e fornecer o trabalho para o Development Team. É a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings. O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração).
  • Development Team: são os profissionais que, ao final de cada iteração, irão entregar uma versão, incrementada, do produto.
  • Scrum Master: responsável por resolver impedimentos e ajudar o Product Owner e Development Team.

Os famosos artefatos SCRUM, você vai precisar deles!

Os artefatos são os documentos que irão prover a transparência para o Scrum Team dos itens que precisam ser feitos para entrega de um produto.

  • Product Backlog: é uma lista contendo todas as funcionalidades desejadas para um produto e seu conteúdo é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o desenvolvimento do projeto ele cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
  • Sprint Backlog: é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Esses itens são extraídos do Product Backlog pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades. Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.
  • Definition of Done: documento que explica quais serão as definições para as User Stories.
  • Burndown: é um gráfico que mostra o andamento do desenvolvimento do Produto. Pode ser usado para monitorar o andamento do Product Backlog, quanto do Sprint Baklog, indicando se ambos serão completados de acordo com o planejamento.

Os eventos SCRUM, não deixe nenhum de fora de seu planejamento!

Alguns eventos são descritos no Scrum, cada qual com seu propósito, a fim de evitar reuniões desnecessárias. Esses eventos são chamados de cerimônias. Elas devem ter um tempo máximo de duração (time-boxed). Esses eventos são métodos eficientes para transmitir informações.

  • Sprint Planning: é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.
  • Daily Scrum: reunião diária que tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia, normalmente são realizadas no mesmo lugar, na mesma hora do dia. 
  • Sprint Review Meeting: reunião onde o Scrum Team mostra o que foi alcançado durante o Sprint.
  • Sprint Retrospective: ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

As empresas de desenvolvimento de software estão, cada dia mais, aderindo, o modelo Ágil com a ajuda do framework Scrum. A partir da década de 1990 ele tem sido utilizado para controlar o processo de desenvolvimento de produtos complexos para, consequentemente, entregar produtos mais valiosos para os clientes.  Leve e fácil de entender, o Scrum não é um processo ou alguma técnica de criação de um produto e sim um framework na qual podemos empregar diversos processos e técnicas. Quando pensamos no desenvolvimento de algum produto, há um processo de concepção que passa pelo planejamento até chegar à conclusão do mesmo, com softwares não é diferente e foram definidos alguns modelos que representam esses processos, como o modelo Ágil, por exemplo

Você também deve se interessar por:

  1. O Papel do Scrum Master na Gestão de Projetos
  2. Scrum, evite estes 3 erros!
  3. Scrum, teoria e principios
  4. 5 Livros sobre Scrum que você deveria conhecer
  5. Scrum ou PMBOK, qual o melhor para minha empresa?

Quer gerenciar projetos utilizando o Scrum, elaborando um modelo híbrido integrado com ferramentas preditivas e visuais?

Conheça o Netproject. Surpreenda-se!

Sobre Hayala Curto

Sobre o Colunista: Hayala Curto, CEO da NetProject. Mestre em Informática e graduado em Ciência da Computação pela PUC-MG. MBA em Gerência de Projetos e MBA em Gestão Empresarial pela FGV.
Tem mais de 20 anos de experiência profissional, coordenando projetos de TI e implantando Escritórios de Projetos em clientes de diversos portes e segmentos. Participou da abertura de 3 empresas. A primeira faliu, a segunda foi vendida e atualmente trabalha como CEO na terceira.
É certificado PMP desde 2005, PMI-SP e PMI-RMP, pelo PMI. Também é certificado IPMA-C, Prince2 e CSM. Apaixonado por Gerenciamento de Projetos, atua como docente na área, em cursos de pós-graduação/MBA, desde 2009.

Os comentários foram encerrados, mas trackbacks e pingbacks estão abertos.