Scrum: Framework para Gestão de Projetos. O que é

Dúvidas sobre o que é Scrum? Quais são suas etapas (Sprint) e com ele funciona? Então esse artigo é ideal para você.

Scrum é um framework leve, simples e objetivo que ajuda pessoas, equipes e organizações a concluir projetos, gerando valor por meio de soluções flexíveis e adaptativas para problemas complexos. dentro do qual você pode empregar diversos processos, ferramentas e técnicas.

O Framework Scrum é uma estrutura para desenvolver e entregar produtos em um ambiente complexo, com ênfase inicial no desenvolvimento de software, podendo ser usado em outros campos, incluindo pesquisa, vendas, prestação de serviço, marketing e tecnologias avançadas.

O gestor poderá usar o Scrum para gerenciar projetos e também como fonte de inspiração para o aperfeiçoamento da forma como ele exerce a gestão em sua organização. Leia a artigo até o final e entende os principais conceitos relacionados ao Scrum e seu funcioanmento.

Escrito por José Sérgio Marcondes
Postado 25/02/2022

Gerenciamento de Projetos

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. De forma objetiva, é tudo aquilo que precisamos realizar para gerar algo novo. Por sua vez, o gerenciamento de projetos pode ser definido como a aplicação de conhecimentos, habilidades, ferramentas e técnicas para gerir as atividades de um projeto a fim de cumprir seus requisitos e atingir seu objetivo.

A gestão de projetos trata-se de uma competência estratégica para organizações, permitindo que elas unam os resultados dos projetos com os objetivos do negócio e, assim, possam competir melhor na sua área de atuação. Trata-se de planejar, organizar, dirigir e controlar, utilizando e maximizando conhecimentos, habilidades, recursos e técnicas, visando o atingimento de objetivos.

As metodologias ágeis representam um marco para o gerenciamento de projetos, permitindo que equipes atinjam sistematicamente tanto uma disciplina de execução como uma inovação contínua.

Os métodos ágeis buscam um alinhamento melhor entre a equipe, de forma a transmitir mensagens mais claras, mantendo os esforços em busca do objetivo final. Para garantir essa otimização dos processos, e aumentar a eficiência da sua empresa, algumas práticas são utilizadas, dentre elas o uso do Framework Scrum.

O que é Scrum?

Scrum é um framework leve, simples e objetivo que ajuda pessoas, equipes e organizações a concluir projetos, gerando valor por meio de soluções flexíveis e adaptativas para problemas complexos, dentro do qual é possível empregar diversos processos, ferramentas e técnicas.

Framework é um termo inglês que, em sua tradução direta, significa estrutura. De maneira geral, essa estrutura é feita para resolver um problema específico.

O Framework Scrum serve de base para o gerenciamento ágil de projetos. Seu papel principal é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê uma estrutura dentro do qual produtos complexos podem ser desenvolvidos.

Scrum não é uma metodologia prescritiva ou um conjunto de práticas de engenharia, também não é um processo ou uma técnica para criar produtos. Ele é um framework criado para gerenciar o desenvolvimento de produtos. Com base no framework Scrum, é possível adicionar as práticas, técnicas ou ferramentas que julgar mais adequadas de acordo com as características e necessidades do projeto a ser desenvolvido.

O Scrum é usado em trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de práticas que torna tudo visível. Isso permite aos praticantes do Scrum saber exatamente o que está acontecendo ao longo do projeto e fazer os devidos ajustes para manter o projeto se movendo ao longo do tempo visando alcançar os seus objetivos (Schwaber 2004).

Qual a origem do Framework Scrum?

O nome Scrum tem origem no jogo de Rugby, onde ambos as equipes ficam em formação coesa lutando pela posse da bola. Entre as características dessa dessas jogada, podemos destacar: equipes unidas, coesos, em busca de um objetivo comum, com responsabilidades bem claras entre as pessoas, características essas que o framework scrum busca atingir.

Um das ações consideradas precursores do framework Scrum é o artigo publicado na Harvard Business Review em 1986, intitulado “The new product development game”. Nele, Nonaka e Takeuchi (professores da Harvard University) utilizaram a metáfora da jogada do Rugby (scrum) ao descrever a maneira na qual empresas como Honda, Canon e Fuji-Xerox conquistaram grandes resultados em seus negócios.

Observou -se que as equipes dessas empresas utilizavam uma abordagem de trabalho escalável baseada em equipes com autonomia e intensa auto-organização. “Pilares dos métodos ágeis como o framework Scrum”. O modelo PDCA (cuja sigla em inglês significa planejar, fazer, verificar e agir) também foi uma das bases do Scrum.

Tendo como base o modelo PDCA e o conceito de timebox (períodos com duração fixa de tempo), Jeff Sutherland e Ken Schwaber, grandes nomes do desenvolvimento de software, criaram o framework Scrum na década de 90, publicando seu primeiro livro sobre o tema em 2001.

Apesar de ter origens na indústria do desenvolvimento e software, os princípios do Scrum estão sendo amplamente adotados em outras diferentes áreas de negócio para organizar o fluxo do trabalho e aumentar a produtividade, gerando mais resultados e valores.

Conteúdo e Composição do Scrum

O framework Scrum consiste em um conjunto formado por:

1. Scrum Team;
2. Eventos;
3. Artefatos; e
4. Regras.

1. O que é Scrum Team?

O Scrum Team, em português “Equipe Scrum” , é formado por é grupo de pessoas que dedicam-se a realizar tarefas buscando a conclusão de objetivos comuns. São equipes de profissionais auto-organizáveis e multifuncionais.

Team auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Team. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe.

O Scrum Team é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Eles entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.

Personagens do Scrum Team

Cada Scrum Team possui três personagens:

1. Scrum Master: é o Mestre, conselheiro, mentor e líder responsável por garantir que o scrum seja entendido e seguido;
2. Product Owner: é o Dono do Produto, responsável por maximizar o valor do trabalho que o Scrum Team faz; e
3. Developers Team: é Time de Desenvolvimento, equipe responsável por executa o trabalho propriamente dito.

Papéis dos Personagens do Scrum Team

O Scrum Team possui três papéis bem definidos e que devem ser obedecidos durante todo a fase de desenvolvimento do projeto, fazem parte deles o Product Owner, Scrum Master e Developers Team. É recomendável, sempre que possível, que o seja mantido em todas as fases do projeto.

A. Product Owner – Dono do Produto

O Product Owner (PO), ou Dono do Produto em português, é o responsável por maximizar o valor do produto e do trabalho da Equipe de Desenvolvimento (Developers Team). É oficialmente o responsável pelo projeto, pelo gerenciamento, controle e por tornar visível a lista de Product Backlog (requisição/pedidos do produto).

O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Team. O PO deve ser uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá que convencer o Product Owner.

Atribuições/responsabilidades Product Owne:

• Expressar claramente os itens do Backlog do Produto (requisição/pedidos do produto);
• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Garantir o valor do trabalho realizado pela Equipe de Desenvolvimento (Developers Team);
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Scrum Team vai trabalhar a seguir; e,
• Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

B. Scrum Master – Mestre Scrum

O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. Busca com isso para garantir que o Scrum Team adere à teoria, práticas e regras do Scrum. São os facilitadores do scrum, e agem como treinadores e mentores para o resto da equipe.

Scrum Master é responsável por garantir que o projeto é realizado de acordo com as práticas, valores e regras ao Scrum e que avança conforme o planejado. É o guardião do método, responsável pelo comprimento do método, responsável por coordenar a busca de soluções para qualquer problema que possa ocorrer na execução.

C. Developers Team – Equipe de Desenvolvimento

O Developers Team (Time ou Equipe de Desenvolvimento em português) consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint Etapa). Eles são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.

Características Times de Desenvolvimento:

• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Developers Team o como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
• Developers Team são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
• O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.
• Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e,
• Developers Team não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios.

2. Eventos Scrum

Eventos Scrum são atividade que reúnem pessoas e que possui um objetivo específico de realização. São usados para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. Os eventos Scrum seguem o princípio timeboxing.

Um timebox é um período fixo de tempo em que uma pessoa ou uma equipe trabalha em direção a um objetivo acordado. Nos Princípios Agile, o timeboxing aloca uma unidade fixa e máxima de tempo para uma atividade, chamada timebox, dentro da qual a atividade planejada ocorre. Todos os eventos no Scrum são eventos timeboxe, de tal modo que todo evento tem uma duração máxima.

Uma vez que o evento começa, sua duração é fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar sempre que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo seja gasta sem permitir perdas no processo.

Cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar.

Os Eventos com timeboxes (duração fixa) no Scrum são:

• Reunião de Planejamento da Versão para Entrega – Delivery planning;
• Sprint;
• Reunião de Planejamento da Sprint – Sprint Planning;
• Reunião Diária – Daily Scrum;
• Revisão da Sprint – Sprint Review;
• Retrospectiva da Sprint – Sprint Retrospective.

A. Reunião de Planejamento da Versão para Entrega

O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Scrum Team e o resto da organização possam entender e comunicar. O planejamento da versão para entrega responde às questões:

• Como podemos transformar a visão em um produto vencedor da melhor maneira possível?
• Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?”

O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto (requisição/pedidos do produto), os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para entrega do produto.

B. Sprint

Sprints são eventos (atividades) com duração fixa. Um projeto de desenvolvimento baseado Framework Scrum consiste na divisão do projeto em etapas com tempo definido (os chamados Sprint), que pode ter um ciclo com duração de uma semana, duas semanas ou até um mês.

Sprint é o espaço de tempo determinado pelo Time para se desenvolver um parte funcional do produto final. Durante a Sprint, o Scrum Master garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.

Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.

O coração do Scrum é a Sprint, Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

Composição de um Sprint

As Sprints contêm e consistem da:

• Reunião de Planejamento de Sprint – Sprint Planning;
• Trabalhos de desenvolvimento – Development works;
• Reunião Diária – Daily Scrum
• Revisão da Sprint – Sprint Review;
• Retrospectiva da Sprint – Sprint Retrospective.

O sprint pode ser considerado o principal evento do método Scrum, porque é nele que serão aplicados os demais eventos, utilizados os artefatos produzidos anteriormente e desenvolvido de fato o produto. É nele que ocorre a produção de um produto ou parte dele.

As Sprints ocorrem uma após a outra, sem intervalos entre elas. A Sprint é uma iteração (Iteração é o processo chamado na programação de repetição de uma ou mais ações e acúmulo de experiências).

As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa fazê-lo sob influência das partes interessadas, do Time ou do
ScrumMaster. Quando uma Sprint é cancelada, todos os itens do Backlog do Produto que estejam completados e “feitos” são revisados.

C. Reunião de Planejamento da Sprint (Sprint Planning Meeting)

A Reunião de Planejamento da Sprint é quando a iteração é planejada. É fixada em oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, aloca-se para essa reunião aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes.

A primeira parte, um evento com duração fixa em quatro horas, é quando é decidido o que será feito na Sprint. A segunda parte, outro evento com duração fixa em quatro horas, é quando o Time entende como desenvolverá essa funcionalidade em um incremento do produto durante a Sprint.

As entradas para essa reunião são o Backlog do Produto (lista priorizada de tudo que deve ser necessário fazer para concluir o projeto, comumente chamadas de funcionalidades), o incremento mais recente ao projeto, a capacidade do Time e o histórico de desempenho do Time.

Nessa reunião se define o objetivo da Sprint e seleciona-se os itens de Backlog do Produto da Sprint (funcionalidades) que é possível concluir nessa Sprint. É o Time de Desenvolvimento que decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”.

Cabe somente ao Time a decisão de quanto do Backlog ele deve selecionar. Somente o Time pode avaliar o que ele é capaz de realizar na próxima Sprint.

D. Reunião Diária – Daily Scrum

Durante a Sprint cada time se encontra diariamente para uma reunião de 15 minutos a chamada Daily Scrum (Reunião Diária). Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints. Durante a reunião, cada membro explica:

• O que ele realizou desde a última reunião diária;
• O que ele vai fazer antes da próxima reunião diária; e
• Quais obstáculos estão em seu caminho.

As Daily Scrum melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto.

O Scrum Master garante que o Time realize essa reunião e também é responsável por conduzir a Daily Scrum. Ele orienta o time para manter a Reunião Diária com curta duração, reforçando as regras e garantido que as pessoas falem brevemente.

A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estão transformando os itens do Backlog do Produto em um incremento (o Time), e para mais ninguém. O Time se comprometeu com uma Meta da Sprint, e a esses itens do Backlog do Produto.

A Daily Scrum funciona como uma inspeção e aferição do progresso na direção da Meta da Sprint. Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está por vir na Sprint. A intenção é otimizar a probabilidade de que o Time alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação no processo empírico do Scrum.

D. Reunião de Revisão da Sprint – Sprint Review

Entrega e validação funcionalidade validação da entrega da funcionalidade é feita pelo Product Owner junto ao cliente

Ao final da Sprint, é feita uma reunião de Revisão da Sprint. Para Sprints de um mês, essa é uma reunião com duração fixa em quatro horas. Para Sprints de durações mais curtas, essa reunião não deve tomar mais do que 5% do total da Sprint.

Durante a Revisão da Sprint, o Time Scrum e as partes interessadas conversam sobre o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitas durante a Sprint, eles conversam sobre quais são as próximas coisas que podem ser feitas.

Essa é uma reunião informal, com a apresentação da funcionalidade, que tem a intenção de promover a
colaboração sobre o que fazer em seguida.

A reunião inclui ao menos os seguintes elementos.

• O Product Owner identifica o que foi feito e o que não foi feito.
• O Time discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos.
• O Time então demonstra o trabalho que está pronto e responde a questionamentos.
• O Product Owner então discute o Backlog do Produto da maneira como esse se encontra. Ele faz projeções de
• datas de conclusão prováveis a partir de várias hipóteses de velocidade.
• Em seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazer em seguida.

A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.

E. Retrospectiva da Sprint – Sprint Retrospective

Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, o Time Scrum tem uma reunião de Retrospectiva da Sprint. Nessa reunião, com duração fixa em três horas, o Scrum Master encoraja o Time a revisar, dentro do modelo de trabalho e das práticas do processo do Scrum, seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. Muitos livros documentam técnicas que são úteis em Retrospectivas.

A finalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas.

A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do time, preparativos para reuniões,
ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Backlog do Produto em alguma coisa “pronta”.

No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.

3. Artefatos do Screm

Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos.

• Backlog do Produto;
• Backlog da Sprint;
• Incremento.

A. Backlog do Produto

O Backlog do Produto é uma lista priorizada de tudo que pode ser necessário no produto. Os requisitos para o produto que o Time de Desenvolvedores deverá desenvolver devem estar listados no Backlog do Produto.

A grosso modo, refere-se a lista de funcionalidades e características que precisam ser executadas para entrega do produto conforme pedido do cliente.

O Product Owner é o responsável pelo Backlog do Produto, por seu conteúdo, por sua disponibilidade e por sua priorização. O Backlog do Produto evolui à medida que o produto e o ambiente em que ele será usado evoluem. Ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil.

O Backlog do Produto representa tudo que é necessário para desenvolver e lançar um produto de sucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras.

Os itens do Backlog do Produto possuem os atributos de descrição, prioridade e estimativa. A prioridade é determinada por risco, valor e necessidade.

Backlog do Produto deve ser ordenado por prioridade o que tiver mais alta prioridade leva a atividades de desenvolvimento imediatas. Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que diz respeito ao seu valor.

B. Backlog da Sprint

O Backlog da Sprint é uma lista de tarefas para transformar o Backlog do Produto, por uma Sprint, em um incremento do produto potencialmente entregável.

A grosso modo, refere-se a lista de funcionalidades e características que precisam ser executadas para entrega de uma parte funcional do produto final.

O Time modifica o Backlog da Sprint no decorrer da Sprint, bem como surge Backlog da Sprint durante a Sprint. Quando chega às tarefas individuais, o Time pode descobrir que mais ou menos tarefas serão necessárias, ou que uma
determinada tarefa levará mais ou menos tempo do que era esperado. À medida que novo trabalho surge, o Time o adiciona ao Backlog da Sprint. À medida que se trabalha nas tarefas ou que elas são completadas, as horas estimadas de trabalho restantes para cada tarefa são atualizadas.

Quando se verifica que determinadas tarefas são desnecessárias, elas são removidas. Somente o Time pode modificar o seu Backlog da Sprint durante uma Sprint. Somente o Time pode mudar o seu conteúdo ou as suas estimativas. O Backlog da Sprint é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint, e ele pertence unicamente ao Time.

C. Incremento

O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum.

Quais são os Valores do Scrum?

Como toda boa ferramenta de gestão, um bom framework é baseado em valores. Compreender e praticar bem os valores do Scrum é importante pois eles ditam a maneira como as decisões são tomadas, gera clareza em momentos de ambiguidade e comunicam porque a equipe faz o que ele faz, de forma eficaz e eficiente.

Os valores do Scrum são:

• Foco: focar significa direcionar a atenção em energia em algo. No contexto do Scrum, o foco significa evitar trabalhar em uma grande quantidade de itens ao mesmo tempo de forma a minimizar as mudanças de contexto, evitar a falta de foco e reduzir retrabalhos. A equipe de desenvolvimento precisa manter o foco durante toda a Sprint e concentrar-se na entrega a ser feita, evitando interrupções, reuniões desnecessárias, mensagens ou qualquer interrupção que não seja relevante para entregar o trabalho na Sprint corrente;
• Respeito: respeito entre os membros de um Scrum Team é fundamental para o sucesso de um projeto. Em um Scrum Team, não existe “nós contra eles”. Um Scrum Team é uma equipe de trabalho com objetivos em comum. Os membros do Team mantém a confiança uns nos outros sempre com respeito. O respeito permite que seja possível expor quaisquer dificuldades e obstáculos de forma objetiva e transparente.
• Comprometimento: pode ser traduzido como juramento, promessa ou dever em entregar algo. Certamente comprometimentos não devem ser superficiais. A cada Sprint, por exemplo, o Scrum Team define de forma bastante clara e transparente o que se compromete a entregar no Sprint. Uma vez comprometido com as entregas, é obrigação do Scrum Team fazer tudo o que estiver a seu alcance para fazer acontecer.
• Coragem: é a habilidade de encarar desafios e dificuldades, apesar do medo. Todos sentimos medo, a questão é o que fazemos com ele. Nem todos os membros de um Team conseguem lidar com o medo da mesma forma, por isso, eles devem ajudar uns aos outros, aliviando o medo e fazendo com que o Team todo saiba lidar melhor com as maiores dificuldades. A equipe precisa de coragem para discutir dificuldades ou notícias ruins de forma aberta, respeitosa e produtiva, sem julgamentos desnecessários.
• Abertura: em um Scrum Team existe abertura para colocar verbalmente quaisquer pontos relevantes para o desempenho do team do projeto. Procura-se sempre estar aberto para novas ideias, percepções, e diferentes formas de pensar. Isso é combustível para a criatividade e ajuda a construir equipes de alto desempenho e organizações de aprendizagem contínua.

Pilares do Scrum

São considerados pilares do Scrum:

1. Transparência;
2. Inspeção;
3. Adaptação.

1. Pilar da Transparência

A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.

Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto. Por exemplo:

• Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e,
• Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.

2. Pilar da Inspeção

Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção. Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho.

Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar

3. Pilar da Adaptação

Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

O Scrum prescreve quatro eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação:

• Reunião de planejamento da Sprint;
• Reunião diária;
• Reunião de revisão da Sprint;
• Retrospectiva da Sprint.

Como Funcina o Scrum

Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo. Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.

O clico do Scrum tem o seu progresso baseado em um série de iterações bem definidas, cada uma com duração de 2 a 4 semanas, chamadas Sprints. Antes de cada Sprint, realiza-se uma Reunião de planejamento (Sprint Planning Meeting) onde o time (equipe) de desenvolvedores tem contato com o cliente (Product Owner) para priorizar
o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint (Pereira et al 2007).

A próxima fase é a Execução da Sprint. Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias Rápidas (Daily Meeting), não mais que 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown. [Pereira et al 2007].

Ao final de cada Sprint, é feita uma revisão no produto entregue para verificar se tudo realmente foi implementado com a realização uma Reunião de Revisão (Sprint Review), onde o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições aprendidas, com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint [Pereira et al 2007].

Benefícios e Vantagens

Pereira et al (2007) que relatam que o uso da agilidade traz vantagens como:

• Cria um ambiente propício para definição de mudanças de requisitos e inovação durante o ciclo de desenvolvimento do produto, assim como mais colaborativo e produtivo entre desenvolvedores e cliente, resultando em entregas mais rápidas de produto, melhor adaptados à realidade do cliente e com a qualidade esperada.
• Facilita o gerenciamento do projeto, uma vez que existem maior integração e comprometimento da equipe do projeto, que consequentemente se sente mais motivada: a moral da equipe é elevada.
• Reforça o planejamento constante do projeto, o que minimiza os riscos, considerando que o planejamento é mais importante do que o plano. Não se deve parar de planejar até que se tenha encontrado a satisfação do cliente com a entrega do produto.
• Valoriza a satisfação do cliente em primeiro lugar.

Gestores bem sucedidos investem em aperfeiçoamento e atualização profissional constantemente. Saiba mais lendo o E-book Gestor de Segurança Privada

Clique no link a seguir para saber mais sobre o livro

Gestor de Segurança Privada

Você Gostou do Artigo? Sem sim, colabore com o crescimento e divulgação do Blog

Aqui no Blog publico frequentemente artigos relacionados a segurança privada e gestão organizacional, visando sempre agregar conhecimento para os leitores, visando seu desenvolvimento profissional e pessoal.

Para continuar publicando e disponibilizando os artigos de forma gratuita a todos, solicito a você leitor ou leitora, que ajude na divulgação e crescimento do blog, fazendo pelo menos uma das práticas a seguir:

• Deixe seu comentário no final do artigo, ele é muito importante para mim;
• Divulgue, curta e compartilhe as publicações com seus amigos pelas redes sociais;
• Inscreve-se na nossa Newsletter. Cadastre seu e-mail logo abaixo e receba avisos sobre novas publicações.

Forte abraço e sucesso!
José Sérgio Marcondes – CES
Especialista em Segurança Empresarial
Consultor em Segurança Privada
Diretor do IBRASEP

Leia também…

Sugiro a leitura dos artigos a seguir como forma de complementar o aprendizado desse artigo.

Projeto: O que é, Conceitos, Objetivos, Características e Exemplos

Planejamento, Plano e Projeto: Conceitos, Diferença, Relações

Gerenciamento de Projetos: O que é, Objetivos e Áreas de Conhecimento

Gerenciamento Ágil de Projetos: O que é, Conceitos e Características

Dados para Citação Artigo

MARCONDES, José Sérgio (25 de fevereiro de 2022). Scrum: Framework para Gestão de Projetos. O que é. Disponível em Blog Gestão de Segurança Privada: https://gestaodesegurancaprivada.com.br/scrum-framework-para-gestao-de-projetos-o-que-e/– Acessado em (inserir data do acesso).

Referência Bibliográficas

Scrum : a arte de fazer o dobro do trabalho na metade do tempo / Jeff Sutherland; tradução de Natalie Gerhardt. – São Paulo : LeYa, 2014.

Pereira, P.; Torreão, P.; Maçal, A. S. (2007) Entendendo Scrum para Gerenciar Projetos de Forma Ágil. In.: Mundo PM.

Tavares, A. (2008) Gerência de Projetos com PMBOK e SCRUM – Um estudo de caso. Faculdade Cenecista Senhora dos Anjos. Gravataí – RS

GUIA DO SCRUM Por Ken Schwaber- Scrum Alliance – Maio de 2009