O que é Scrum?

Scrum é o frameworkmétodo ágil mais conhecido entre todos os existentes. Ele agrupa conceitos, práticas e ferramentas para gerenciar projetos, especialmente projetos de software, mas pode ser aplicado em outros tipos de projeto.

Uma característica de um projeto gerenciado por meio do Scrum é que os times que participam dele têm poucas pessoas. Desse modo, ganha-se em flexibilidade e em qualidade da comunicação, fazendo com que o time seja altamente adaptativo.

Papéis no scrum

No Scrum, o trabalho de um projeto deve ser dividido em Sprints, que são pequenos ciclos de trabalho (de 2 a 6 semanas) que geram pequenas entregas. Essas entregas acrescentam um incremento ao produto final. Ou seja, ao fim de cada ciclo/Sprint, é entregue mais um “pedaço” do projeto. No caso de software, uma nova funcionalidade no produto.

Processo scrum

As práticas do Scrum podem ser adaptadas ao contexto de cada organização. Entretanto, seus princípios ágeis dão a característica de que o escopo do projeto é planejado aos poucos conforme novas informações vão sendo conhecidas e o que já foi feito é entregue, testado e colocado em funcionamento.

Essa é a principal diferença do Scrum (e outros métodos ágeis) em relação às metodologias tradicionais. Se no método cascata, por exemplo, o escopo é totalmente planejado antes do início do projeto, no Scrum novos planejamentos são feitos conforme novos “pedaços” do projeto são entregues e disponibilizados ao cliente.

Conceito de metodologia ágil

O verdadeiro significado de ágil não é necessariamente ser rápido e entregar as atividades no prazo. Ser ágil significa ser capaz de lidar com mudanças no meio do caminho e adaptar o projeto a elas de maneira organizada e segura para todos os envolvidos.

As metodologias ágeis surgiram logo após o manifesto ágil, em 2001. A demanda por uma nova maneira de gerenciar projetos nas empresas de desenvolvimento de software as levou a transformar as metodologias existentes e adaptá-las ao seu contexto.

Em um cenário tão incerto quando o digital, não fazia sentido planejar tudo antes de colocar em prática se o time só descobre o que realmente pode fazer quando está com a mão na massa. Aliás, o desenvolvimento de softwares é um campo onde a inovação é a palavra de ordem, portanto, encontrar coisas inesperadas pelo caminho é praticamente uma regra.

Por isso, as metodologias ágeis idealizadas pelos profissionais dessa área priorizam a entrega de valor mais do que a documentação do projeto, e focam na adaptação às mudanças mais do que na necessidade de seguir um plano pré-estabelecido.

Isso dá certo na prática porque, ao utilizar uma metodologia ágil, a equipe do projeto é preparada para lidar com as adversidades que podem surgir e tem flexibilidade para testar maneiras diferentes de trabalhar, afinal, não há um planejamento engessado que a impede de inovar.

O planejamento, na verdade, é feito aos poucos, no início de cada Sprint, e pode ser modificado a qualquer momento sem precisar seguir um processo de documentação extenso e burocrático.

Vale lembrar, também, que apesar de ter sido idealizado por equipes de desenvolvimento de software, as metodologias ágeis têm se popularizado cada vez mais em outras áreas do negócio. O marketing, por exemplo, que é uma área em constante transformação, tem se beneficiado bastante do uso das metodologias ágeis.

Há alguns conceitos essenciais para entender a metodologia Scrum por inteiro, e a principal delas é o Product Backlog. Vamos falar mais sobre isso a seguir.

Leitura recomendada: Scrum vs Kanban vs Lean, quais as semelhanças, diferenças e relações entre eles?

Product Backlog

O Product Backlog é a relação das principais entregas de um projeto ágil, priorizadas e sequenciadas conforme o nível de valor que podem gerar para o cliente. Quanto mais importante for a entrega, maior a urgência em começar a desenvolvê-la. Esses itens podem ser chamados de entregas, requisitos, funcionalidades, histórias ou User Stories, e em geral correspondem a uma atividade a ser colocada em prática ao longo do projeto.

Sendo assim, a função do Product Backlog é descrever o trabalho previsto de maneira organizada e flexível, servindo como consulta para todos os integrantes do Time Scrum.

Webinar Como priorizar os itens do backlog

Diferente do que acontece ao utilizar uma metodologia tradicional para gerenciar projetos (como a Cascata), ao utilizar o Scrum o escopo do projeto vai sendo definido aos poucos, e não já no começo. Isso explica por que o Product Backlog nunca está completo.

Conforme o produto vai sendo usado e ganha valor, o mercado vai fornecendo feedback e o Product Owner refina o Product Backlog, acrescentando e retirando funcionalidades da lista, atribuindo novas prioridades e adicionando detalhes aos itens abstratos. A essência do Scrum é justamente essa adaptabilidade e flexibilidade em relação aos requisitos e funcionalidades presentes no projeto.

Como fazer o Product Backlog?

Primeiro, é necessário que o Product Owner (que detém toda a responsabilidade sobre o artefato) identifique os desejos do cliente e transforme-os em funcionalidades executáveis pelo Time de Desenvolvimento.

Para que isso seja possível, ele pode recorrer às histórias (ou User Stories, em inglês), que nada mais são do que as necessidades específicas do cliente que o produto se propõe a atender. Observe no exemplo abaixo:

Exemplo de Product Backlog

Cada item da lista corresponde a um desejo dos usuários de uma solução. O administrador, o membro e o visitante apresentam necessidades diferentes dentro do mesmo produto, as quais o Product Owner identifica e descreve na própria linguagem do cliente.

A partir dessa relação de funcionalidades, o Time Scrum pode se reunir para entender a relevância de cada uma, definir a prioridade e em qual Sprint elas serão entregues.

É preciso destacar, porém, que o Product Backlog não tem a obrigação de ser feito em lista, essa é apenas uma das várias formas de organizá-lo. Você pode desenvolver o seu por meio de um quadro com post-its, em um documento no Word ou até mesmo em um software específico de gerenciamento de projetos.

O mais importante na construção deste artefato é que ele seja acessível a todo o Time Scrum e possa ser facilmente modificado, já que está em constante refinamento.

Tendo esclarecido o que é o Product Backlog e como desenvolvê-lo, podemos seguir para o próximo ponto que, segundo o Scrum, é o início da Sprint.

Sprint

Sprint, no Scrum, é um período limitado a um mês ou menos, no qual uma versão incremental e usável de um produto é desenvolvida.

Sendo assim, a ideia da Sprint no Scrum é que deve-se cumprir uma meta dentro de um período determinado, e que ao final o produto seja “Pronto”.

A duração da Sprint é time-boxed, isto é, limitada a um tempo, e pode variar de uma a quatro semanas, dependendo da produtividade do time para entregar uma funcionalidade completa (no caso dos projetos de TI) ou uma parte funcional do produto (em projetos de outras áreas). Porém, uma vez decidida a duração da Sprint, ela deve ser mantida até o final do projeto.

Curioso para saber como a Sprint é realizada na prática? Veja a seguir!

Como fazer uma Sprint?

Para fazer uma Sprint, além do momento da execução, há 4 Eventos: a reunião de planejamento da Sprint, a reunião diária, a reunião de revisão da Sprint e a retrospectiva da Sprint.

1.Reunião de Planejamento da Sprint

A Reunião de Planejamento da Sprint (Sprint Planning) é um evento que acontece antes de cada Sprint, tendo como objetivo definir:

O que poderá ser entregue na próxima Sprint;

Como será realizado o trabalho para produzir a entrega.

Todos os integrantes do Time Scrum participam desta reunião, sendo que o time-box máximo é de 8 horas de duração. Em Sprints menores, a duração tende a ser proporcionalmente menor.
O Product Owner começa a reunião apresentando os itens do Backlog do Produto (ou Product Backlog, que acabamos de apresentar, e o Time de Desenvolvimento avalia quais itens poderão ser entregues no período.

Estabelece-se a meta da Sprint, que corresponde ao(s) item(s) do Backlog do Produto, e o Time de Desenvolvimento então decide como irá construir as funcionalidades necessárias.
Para isso, o Time começa a desenhar o sistema e separar o trabalho em unidades de um dia de duração ou menos, podendo inclusive convidar outras pessoas para participar da Reunião e contribuir com opinião técnica.

Como resultado, é produzido o Backlog da Sprint (ou Sprint Backlog), que é a junção dos itens selecionados do Backlog do Produto e seus respectivos planos de entrega.

2.Desenvolvimento (execução)

Assim que a Reunião de Planejamento da Sprint termina, inicia-se a etapa de execução. Aqui, o Time de Desenvolvimento começa a trabalhar segundo os planos de entrega que planejou, atentando-se aos requisitos de produto delineados pelo Product Owner e ao prazo final da Sprint.

3.Reunião Diária

Ao longo da execução da Sprint, o Time de Desenvolvimento se reúne diariamente para avaliar como está o andamento das atividades e definir o que será feito no dia para alcançar a meta da Sprint. São as chamadas Reuniões Diárias (também conhecidas como Daily Sprints ou Daily Scrum).

O time-box dessas reuniões é de 15 minutos, e elas são comumente realizadas no mesmo local e no mesmo horário. Recomenda-se que o time de Desenvolvimento faça a Reunião Diária em pé, para não correr o risco de se acomodar e ultrapassar o limite de tempo.

É bom lembrar, também, que o Product Owner e o Scrum Master não participam dessas reuniões ativamente, podendo apenas assistir a elas como ouvintes, já que o Time de Desenvolvimento é auto organizado e tem autonomia para decidir sozinho como o trabalho será realizado.
Há três perguntas que devem ser respondidas na Reunião Diária:

  • O que eu fiz ontem que ajudou o time de Desenvolvimento a alcançar a meta da Sprint?
  • O que eu farei hoje para ajudar o time de Desenvolvimento a alcançar a meta da Sprint?
  • Existe algum obstáculo que impeça o Time de Desenvolvimento de alcançar a meta da Sprint?

O responsável por eliminar os impedimentos que atrapalham o trabalho do Time de Desenvolvimento é o Scrum Master. Quando é comunicado a ele que algo está errado, ele é quem deve agir buscando soluções e alternativas, cumprindo com o seu objetivo principal de proporcionar um ambiente favorável para o Time de Desenvolvimento.

Se o problema identificado for técnico demais e o Scrum Master sentir que não conseguirá solucioná-lo sozinho, ele pode pedir ajuda a um dos membros do Time que saiba como resolvê-lo.

4.Revisão da Sprint

Quando a Sprint chega ao final, é necessário realizar a Revisão da Sprint (ou Sprint Review) para inspecionar o resultado e adaptar o Backlog do Produto, se for o caso. Todo o Time Scrum participa do Evento, que tem time-box máximo de 4 horas.

Os principais pontos de discussão da Revisão envolvem o esclarecimento sobre os itens que foram “Prontos” e os que não foram, a reflexão sobre o que foi bem e os problemas que foram encontrados, e as sugestões do Time Scrum para o que deve ser feito a seguir, levando em consideração as mudanças do mercado, a linha do tempo, o orçamento e as prioridades.

Como resultado dessa reunião é produzida uma nova versão do Backlog do Produto, que poderá ser utilizada na próxima Sprint.

5.Retrospectiva da Sprint

Enquanto a Revisão da Sprint busca avaliar o produto do trabalho do Time de Desenvolvimento, a Retrospectiva da Sprint (Sprint Retrospective) é uma oportunidade para que a equipe avalie a si mesma, refletindo sobre suas práticas e desenhando melhorias para aplicar na próxima Sprint.

Participam dessa reunião o Time de Desenvolvimento e o Scrum Master, que tem a responsabilidade de ensinar a equipe a seguir o processo Scrum e a ficar dentro do time-box de, no máximo, três horas.

Ele encoraja a equipe a melhorar o processo de desenvolvimento de acordo com o framework do Scrum, ajudando-a a planejar formas de aumentar a qualidade do produto e a adaptar a definição de “Pronto”.

Desse modo, no final da Retrospectiva da Sprint, o produto será a relação das melhorias a serem implementadas no próximo ciclo. O final desta reunião marca o final oficial da Sprint.

A figura a seguir mostra o processo da Sprint de maneira resumida:

sprint

Depois de todo esse trabalho, talvez você esteja se perguntando se adotar as Sprints no desenvolvimento de seus projetos realmente vale a pena. Acompanhe o próximo tópico e confira a resposta!

Por que adotar Sprints na rotina de projetos?

Como você viu, o principal objetivo de se trabalhar em Sprints é o constante acompanhamento das entregas do projeto, garantindo maior satisfação dos clientes com o resultado final.

Ao contrário do que ocorre nas metodologias preditivas (como a Cascata), onde se planeja tudo de uma vez e há apenas uma entrega ao final do projeto, as Sprints quebram o trabalho em partes menores, fazendo com que a equipe possa ir definindo os pacotes de trabalho ao longo da execução.

Justamente por esse motivo, os atrasos e inconformidades nas entregas das Sprints são significativamente menores do que os apresentados em outras metodologias. O time tem mais consciência sobre os prazos, pois participa ativamente das reuniões de planejamento, e pode comunicar-se internamente quando sentir que não conseguirá cumpri-lo, procurando alternativas e evitando desvios antes que eles tragam consequências sérias para o projeto.

Outro motivo pelo qual a Sprint é uma boa opção para projetos de TI é o fato de que ela obriga os participantes a priorizarem as atividades que eles têm para executar antes do início de cada ciclo de trabalho.

Essa atitude pode revelar tarefas que não façam mais sentido para o produto final depois de um tempo, ou mesmo chamar a atenção da equipe para aspectos que precisem de um esforço extra na hora da execução.

Qual o papel do Product Owner?

Product Owner, ou Dono do Produto, é encarregado de conectar a equipe de desenvolvedores aos pedidos dos clientes. Sua principal responsabilidade é gerenciar o Product Backlog, mantê-lo atualizado e manter todo o Time Scrum ciente dele. Mas seu papel não se resume apenas a isso. Veja:

Planejamento da Sprint

O papel do Product Owner nesse evento é apresentar os itens do Product Backlog priorizado ao Time de Desenvolvedores, os quais selecionam as histórias mais prioritárias que couberem na Sprint. Não é papel do Product Owner, porém, pressionar a equipe ou escolher por ela quais atividades deverão ser feitas, afinal, isso fere o princípio de auto organização presente no Scrum.

Sua função é atuar como motivador e facilitador do processo, criando metas desafiadoras e solucionando dúvidas técnicas do Time de Desenvolvedores, já que ele é um especialista no produto que gerencia e está constantemente renovando seus conhecimentos.

Definir critérios de aceitação de histórias

Os critérios de aceitação de histórias são geralmente compostos por uma lista de itens a serem checados na nova funcionalidade para avaliar se ela foi desenvolvida conforme os requisitos do PO e do usuário. Eles são utilizados na Revisão da Sprint para que o PO valide ou invalide a entrega feita pelo time.

Frequentemente, os critérios envolvem: usabilidade, navegabilidade, responsividade, desempenho e ocorrência de bugs. Ao longo da Sprint, todos os membros do Time de Desenvolvimento têm conhecimento desses critérios, e inclusive operam Testes de Aceitação antes de concluir a entrega, para garantir que os resultados estarão adequados aos requisitos do Product Owner.

Aceitar/reprovar incrementos na Sprint

Assim que a equipe de desenvolvimento chega ao final da Sprint e demonstra a funcionalidade que desenvolveu e testou, é o Product Owner quem tem o poder de aceitá-la ou reprová-la. Como mencionamos há pouco, isso acontece no evento de Revisão da Sprint (ou Sprint Review).

Desse modo, o PO garante a qualidade das entregas, comparando o resultado do trabalho da equipe com os critérios de aceitação já definidos anteriormente. Se há inadequações no produto entregue, o PO sugere melhorias e adiciona-as ao Backlog do Produto. Dependendo de sua relevância, elas são selecionadas e executadas nas Sprints seguintes.

Agora, vamos ao segundo papel que compõe o Time Scrum, o Scrum Master.

Qual o papel do Scrum Master?

O termo Scrum Master significa mestre do Scrum, então para desempenhar esse papel, ele precisa ser familiar com o processo de Scrum e saber como realizá-lo corretamente, já que ele será como um guia para o Time Scrum. Ele atua em todos os setores do processo de Scrum, desde planejar a Sprint junto com o Product Owner, entre outros.

O perfil ideal de um Scrum Master é baseado na ideia de líder servidor, um tipo de gestor que faz mais do que monitorar o andamento do processo e o desempenho das equipes. Continue lendo, pois vamos te explicar o que é um líder servidor.

Líder servidor

Esse conceito se baseia na ideia de que liderar é também servir. Um líder que apenas cobra das equipes e não ajuda, não colabora na execução de um processo, recebe resultados de baixa qualidade e se afasta de seus colaboradores.

Porém, quando o líder se engaja em um processo e se dispõe a ajudar as equipes, prestando atenção às suas necessidades e problemas, quando ele se propõe a servir ao mesmo passo que lidera, o processo produtivo flui mais naturalmente e com menos imprevistos. O líder ocupa uma posição importante na empresa e entre seus colaboradores, e sua atuação causa fortes impactos.

O Scrum Master precisa agir como líder servidor porque sua função consiste basicamente em disponibilizar todo o conhecimento e materiais necessários para que as Sprints sejam executadas corretamente. Ele age como um coach para o Time Scrum, tirando dúvidas e ajudando a resolver problemas que podem aparecer, e também para o Product Owner, para que ele consiga ter uma boa visão do objetivo e de como ele pode proceder de acordo com o processo Scrum.

Se todo o processo de Scrum ocorresse perfeitamente, o Scrum Master não seria necessário. Por isso, ele só interfere em algum processo quando necessário, ou seja, quando o Time Scrum está com dificuldade para realizar um Sprint, quando o Product Owner está se distanciando do objetivo a ser alcançado, entre outros motivos.

Mas essas não são as únicas oportunidades que o Scrum Master tem para ajudar a equipe. Confira as outras:

Ajudar o Product Owner

O Product Owner é designado de acordo com seus conhecimentos no tema do projeto, e por isso pode acontecer que ele não esteja familiarizado com as práticas de Scrum. Nesses casos, a ajuda do Scrum Master é importante para adaptá-lo a essa metodologia.

Além disso, o Scrum Master é o principal canal de comunicação entre Product Owner e Time Scrum quando ela não vai bem. Ele ajuda a equipe a entender a visão e a meta desejada pelo Product Owner, ao passo que faz com que ele compreenda as limitações e considerações da equipe.

Conectar todo o projeto

Uma das funções mais importantes do Scrum Master é criar conexões, não apenas entre os integrantes do Scrum, mas também conexões externas com os gestores da empresa, com fontes úteis para a execução de Sprints, com soluções de possíveis empecilhos, entre outras.

Além disso, o Scrum Master ajuda na realização dos Daily Scrums e no planejamento do Sprint seguinte, buscando sempre alinhar as funcionalidades que devem ser priorizadas e os feedbacks do Product Owner e o Time Scrum. Essas reuniões são muito importantes para mensurar o progresso do projeto e que mudanças devem ser feitas.

Qual o papel do Time de Desenvolvimento?

O terceiro e último papel do Scrum é o Time de Desenvolvimento, a equipe que põe a mão na massa para entregar os incrementos do produto.

Segundo o Guia Scrum, é indicado que o Time de Desenvolvimento tenha entre 5 a 9 integrantes, e que não ultrapasse esse número para não dificultar o gerenciamento.

Além disso, o manual recomenda que não haja segmentações dentro da equipe, isto é, que não se separe os desenvolvedores por funções (arquiteto, designer, programador, testador, DBA etc.). Dessa forma, garante-se um sentimento de unidade à equipe, que deve se responsabilizar pelo cumprimento das atividades como um time, e não como uma pessoa específica. O esforço e os resultados do trabalho (sejam eles positivos ou negativos) são atribuídos a todo o Time de Desenvolvimento, sendo assim, espera-se que os integrantes de mobilizem em prol do objetivo que têm em comum.

As responsabilidades do Time de Desenvolvimento são:

Realizar a execução da Sprint

Como não poderia deixar de ser, o Time de Desenvolvimento detém a responsabilidade exclusiva de executar a Sprint, do início ao fim. Isso envolve os processos de concepção, desenvolvimento, teste e liberação das funcionalidades selecionadas na Reunião de Planejamento da Sprint.

É bom lembrar que o Time de Desenvolvimento é auto organizado, portanto, os membros devem se comunicar e decidir coletivamente os passos que darão para poder concluir as entregas conforme o combinado. A divisão das tarefas e o jeito que elas serão desenvolvidas é responsabilidade total do Time, mas se houver dúvidas e eles sentirem que precisam de ajuda, podem acionar o Scrum Master.

Inspeção e Adaptação

A inspeção e adaptação, que fazem parte dos princípios do Scrum, são garantidas por meio das Reuniões Diárias do Scrum. Estes momentos são quando o Time de Desenvolvimento se reúne para acompanhar o próprio desempenho, buscando saber se há algum impeditivo no caminho e adaptando o planejamento à realidade.

Se essas reuniões diárias não forem realizadas, o Time pode perder muito tempo “patinando” nas atividades erradas, tentando resolver problemas que o Scrum Master poderia resolver ou mesmo com dúvidas que um colega de equipe saiba responder.

Refinar o Product Backlog

Como você já sabe, o Product Backlog nunca está finalizado. Enquanto há Sprint acontecendo, o Time Scrum está aprendendo e refinando a lista constantemente.
Juntamente com o Product Owner e o Scrum Master, o Time de Desenvolvimento se encarrega de atualizar as estimativas de duração das atividades, re-priorizar demandas e adicionar detalhes às funcionalidades que estão pouco claras.

Planejar a Sprint

Além de atuar no refinamento e na execução da Sprint, o Time de Desenvolvimento deve também auxiliar no planejamento da Sprint, aquele momento em que se decide quais funcionalidades serão desenvolvidas no próximo período.

Como os desenvolvedores têm mais noção sobre sua produtividade, é interessante que tenham espaço para decidir o que poderão entregar, mas que também ouçam a opinião dos outros integrantes do Time Scrum.

De maneira resumida, essas são as responsabilidades e atribuições dos integrantes do Time Scrum.

Mas, voltando ao tema do nosso post, que tal entendermos um pouco mais sobre os princípios do Scrum?O Scrum segue os princípios ágeis. Vamos ver mais detalhadamente quais são os princípios do Scrum?

Quais são os princípios do Scrum?

De acordo com o Guia SBOK™ (Scrum Body of Knowledge), o Scrum tem seis princípios. Observe na imagem:

princípios do scrum

1)Controle de processos empíricos

Este princípio representa o fato de que todas as decisões dentro de um projeto Scrum devem ser tomadas com base em observação e experimentos, ao invés de planejamentos antecipados. Nesse sentido, o controle de processos empíricos conta com três ideias principais:

  • Transparência: permite que todos os ângulos do processo Scrum sejam visíveis por qualquer pessoa, por meio de uma comunicação fluida fortalecida pelas reuniões diárias e pelo acesso aos documentos do projeto para todos os envolvidos (Backlog do Produto, Visão do Projeto, gráfico de Burndown etc.).
  • Inspeção: representada pelo uso de um Scrumboard para acompanhar o progresso do Time Scrum, pela coleta de feedback dos clientes e outros stakeholders constantemente, e pela inspeção e avaliação das entregas, feitas pelo Product Owner e pelo cliente.
  • Adaptação: a adaptação é praticada pelo time Scrum quando ele adapta e faz melhorias o processo no que está sendo realizado. Exemplos disso são as mudanças adotadas a partir das dificuldades comunicadas nas reuniões diárias, da identificação de riscos ou mesmo das reuniões de retrospectiva.

2)Auto-organização

No Scrum, os colaboradores são motivados, proativos e buscam aceitar responsabilidades maiores, tendo a auto-organização como principal característica. Essa postura do Time é favorecida pelo modelo de liderança servidora adotado no Scrum, de modo que o líder e o liderado não são separados por fortes hierarquias, mas interagem em prol do projeto na mesma medida.
Além do mais, a auto-organização propicia um ambiente inovador e criativo, tornando a responsabilidade compartilhada e aumentando a satisfação do time.

3)Colaboração

Nenhum projeto pode sair do papel sem colaboração — por isso, o Time Scrum deve trabalhar em conjunto com os stakeholders para criar e validar as entregas do projeto.
Desse modo, todos os envolvidos e interessados no andamento do projeto ficam alinhados e garante-se que a visão do projeto será alcançada.
As três dimensões do trabalho colaborativo são:

  • Consciência: deve-se ter consciência do que os outros colegas de trabalho estão fazendo.
  • Articulação: a articulação precisa ser feita para que o trabalho seja dividido de maneira organizada entre os integrantes do time. O produto final é divido em unidades, distribuído entre os desenvolvedores, e quando pronto, é reintegrado novamente.
  • Apropriação: refere-se à adaptação da tecnologia para as situações do dia a dia. Ter aparato tecnológico para apoiar as operações de trabalho é essencial, principalmente quando falamos em colaboração.
  • 4)Priorização baseada em valor

    O Scrum tem como objetivo oferecer o máximo de valor de negócio em tempo mínimo. Para que isso seja possível, a priorização é um recurso indispensável.
    Assim, quanto maior valor um item tiver o poder de gerar, mais prioritário ele será na fila de atividades (conhecida no Scrum como Backlog do Produto).

    Quem tem a responsabilidade de determinar a prioridade das atividades é o Product Owner, papel do qual falaremos mais para frente. Ainda, é bom lembrar que deve-se considerar, além do valor, os riscos e as dependências entre as atividades que um produto pode ter, procurando tornar a etapa de priorização cada vez mais precisa.

    5)Time-boxing

    Outro princípio muito característico do Scrum é a limitação do tempo de cada Sprint e de cada Evento dentro dela.

    Em todo o projeto Scrum, as restrições de tempo são fixadas previamente, garantindo que a equipe não se perca nos prazos e não atrase entregas. As reuniões diárias de acompanhamento, por exemplo, não devem ultrapassar os 15 minutos de duração, e uma Sprint tem tempo máximo de 6 semanas.

    Isso traz como vantagem a economia com despesas gerais, o aumento da velocidade de trabalho e inclusive da produtividade. Porém, é preciso ter cuidado ao determinar o time-boxing dos eventos para que essa atitude não gere o efeito oposto (alguns integrantes do time podem sentir-se apreensivos e desmotivados caso a cobrança seja muito arbitrária).

    6)Desenvolvimento iterativo

    O princípio de desenvolvimento iterativo é baseado na repetição das Sprints ao longo do projeto, com o objetivo de gerar valor ao produto continuamente. Observe nos gráficos abaixo como isso se dá na prática, em comparação com o modelo tradicional (Cascata):

    modelo tradicional de gestão de projetos cascata e modelo framework scrum

    Enquanto a metodologia tradicional tem cinco etapas e começa a entregar valor apenas no último estágio do projeto, o Scrum tem um ciclo de etapas que se repete a cada Sprint, e assim pode entregar valor continuamente desde o começo. Porém, esse não é o único benefício que o desenvolvimento iterativo apresenta.

    Outra vantagem é que ele permite a correção ao longo do projeto, já que todos os envolvidos vão tendo conhecimento do que precisa ser entregue de maneira iterativa. Desse modo, o tempo e o esforço para chegar ao ponto final é reduzido, já que a equipe tem mais conhecimento e pode se auto organizar para chegar ao objetivo final, e então produz resultados que são mais adequados ao ambiente de negócios.

Vantagens do Scrum

Descentralização do gerenciamento

Uma das partes principais do funcionamento do time no Scrum é que a equipe deve ser autônoma e auto gerenciável. Isso significa que há uma descentralização do gerenciamento, evitando sobrecarga de uma pessoa e permitindo tomadas de decisão mais colaborativas.

Além disso, as informações também ficam descentralizadas. Portanto, todos sabem o que se passa no projeto, de modo que ideias e sugestões podem surgir de toda a equipe. Assim, os membros da equipe ajudam uns aos outros e todos são capacitados para tomar decisões assertivas.

Ajuda na organização das atividades

No Scrum, todo o trabalho do projeto é dividido em ciclos (Sprints). Ao final de cada Sprint, quando é entregue uma nova parte do projeto, são feitas reuniões para revisar o que foi feito e planejar o próximo ciclo.

Todo esse processo ajuda a evitar que o trabalho do projeto se torne um caos e as atividades fiquem desorganizadas. Sendo assim, o Scrum ajuda manter a organização do trabalho e, por consequência, evita retrabalho, atrasos e perda de produtividade.

Ajuda a incorporar mudanças no escopo.

Em metodologias clássicas, é mais difícil aplicar alterações no decorrer dos projetos. No Scrum, por sua vez, as mudanças e novidades no escopo são esperadas a, às vezes, até desejadas.

Sendo assim, a metodologia Scrum oferece flexibilidade suficiente para que o projeto seja adaptado a novas situações sem que seu andamento seja comprometido, de modo a tornar mais fácil a alteração de prioridades.

Ajuda a entregar um produto de qualidade

A metodologia Scrum traz uma série de práticas que ajudam a entregar um produto final de qualidade mesmo com as mudanças ocorridas ao longo de sua realização. Os eventos focados no planejamento e revisão dos processos são responsáveis por isso.

Ao término de cada Sprint, é necessário entregar um produto utilizável que será validado pelo Product Owner. Essa prática, assim como as reuniões para revisão e planejamento de atividades, impacta no resultado final do projeto, ajudando a entregar um produto de qualidade.

Com o sucesso crescente do Scrum e das metodologias ágeis, muitos profissionais tem buscado se qualificar na área e obter certificações para serem reconhecidos no mercado. Pensando nisso, separamos um tópico só para te contar um pouco mais sobre as certificações Scrum. Aproveite!

Certificações Scrum, qual escolher?

Dependendo do momento da sua carreira, pode ser interessante optar por certificações mais ou menos avançadas.

A certificação ACP, por exemplo, é considerada uma das mais complexas, já que exige bastante experiência na área. Em contraponto, a certificação ASF é mais indicada caso o profissional esteja começando a ter contato com o Scrum e prefira fazer o exame em português.

A seguir, vamos abordar cada uma das certificações mais reconhecidas do mercado e explicar para quais perfis elas mais se aplicam.

Certified Scrum Master (CSM) pelo Scrum Alliance

É uma certificação de entrada que agrega bastante conhecimento específico sobre o framework, ajudando os profissionais a entenderem como o processo Scrum deve ser realizado, quais são os papéis, eventos e artefatos que o compõem e, principalmente, qual é o papel do Scrum Master nisso tudo.

Para obtê-la, é preciso fazer um curso presencial de 16 horas credenciado pela instituição, passar por um exame de 50 perguntas e obter pelo menos 37 acertos.

Professional Scrum Master (PSM I) pelo Scrum.org

O PSM I é uma certificação que não exige um curso credenciado, apenas que o participante passe por um teste específico sobre o Guia Scrum. Seu principal objetivo é comprovar o conhecimento do participante sobre as práticas do Scrum.

O teste, disponível apenas em inglês, é composto por 80 questões, e para poder respondê-lo, o profissional deve pagar uma taxa de U$150. A certificação é concedida se a pessoa atingir o número mínimo de acertos, que é 68.

A entidade que mantém essa certificação também oferece outras certificações mais avançadas, como a Professional Scrum Master II e III, Professional Scrum Product Owner I, Professional Scaled Scrum e Professional Scrum Developer, as quais são destinadas aos diferentes papéis dentro do Time Scrum.

Scrum Fundamentals Certified (SFC) pelo SCRUMstudy™

Esta certificação gratuita serve para o participante aprender mais sobre o Scrum, e é mantida pela organização responsável pelo Guia SBOK®, que é um corpo de conhecimento sobre Scrum mundialmente reconhecido.

Ao inscrever-se no curso online, o participante também tem acesso ao exame, que conta com 40 questões e pode ser repetido quantas vezes for necessário. Obtém-se a certificação mediante o acerto de pelo menos 30 questões, e ela tem validade de 3 anos.

Agile Scrum Foundation (ASF) pelo EXIN

A certificação Agile Scrum no nível Foundation oferecida pelo EXIN tem como principal benefício a credibilidade que essa entidade tem no mercado, afinal, o EXIN é reconhecido como um dos maiores institutos de exames de TI no mundo.

Além de atestar o conhecimento do profissional no framework Scrum, esta certificação também envolve o conhecimento em metodologias ágeis no geral.

Não há pré-requisitos para realizar o exame, é necessário apenas realizar o teste online que utiliza a própria webcam no participante para monitorá-lo. Se o profissional desejar continuar a formação, há mais um nível no sistema do EXIN, o Agile Scrum Master (ASM).

Agile Certified Practitioner (ACP) pelo PMI

O PMI, referência mundial em gerenciamento de projetos, oferece uma certificação especial para profissionais focados em metodologias ágeis: a Agile Certified Practitioner. Para consegui-la, o profissional deve comprovar 2.000 horas de experiência em equipes de projetos, 1.500 horas em equipes de projetos ágeis, 21 horas de curso relacionado a metodologias ágeis e realizar o exame aplicado pelo instituto.

O custo para inscrição é de U$495 e a certificação tem validade de 3 anos.

É bom lembrar, porém, que com esta certificação o profissional não terá conhecimento profundo sobre o Scrum, mas uma base sobre todos os frameworks e metodologias ágeis relevantes no mercado. Para quem já conhece o Scrum e busca se aprofundar no universo ágil, é uma boa alternativa.

Leia nosso Guia completo de certificações SCRUM para não restar dúvidas.