---

Certificação Scrum Master a um preço acessível: plano passo a passo

Temos orgulho em anunciar que este artigo foi destacado...
AQUI no LinkedIn >>>

Desde que o framework Scrum se tornou uma das melhores formas de desenvolver e entregar software, todos parecem ter o mesmo objetivo.

Acordar de manhã, abrir o computador portátil e sentir a tranquilidade entusiasmante de possuir algo assim:

Uma certificação Scrum Master.

É esse o sonho, não é?

Entregar excelente software aos seus empregadores e clientes.

Ter uma carreira fantástica, impulsionada pelas suas competências e conhecimentos do processo Scrum e pela sua certificação Scrum Master.

Para a maioria das pessoas, a certificação Scrum Master é a porta de entrada no framework Scrum.

Neste artigo, pela primeira vez, quero partilhar um guia avançado e detalhado, passo a passo, para o ajudar a obter a certificação Scrum Master.

De forma económica, rápida, online e sem complicações!

Em apenas quatro passos simples, pode tornar-se um excelente profissional Scrum com a sua certificação Scrum Master.

O meu objetivo com este artigo é mostrar como Scrum pode apoiar a sua carreira e melhorar a sua eficácia profissional. Também explico por que deve continuar a desenvolver as competências e capacidades de um Scrum Master o mais cedo possível.

Definição — O que é a certificação Scrum Master?

Pode encontrar a melhor definição de certificação Scrum Master no site do International Scrum Institute™— Scrum Master Accredited Certification™.

A certificação Scrum Master é o testemunho da sua competência no processo Scrum de desenvolvimento e entrega de software. A certificação Scrum Master reconhece os conhecimentos demonstrados e a excelente competência no framework Scrum após uma avaliação formal de escolha múltipla.

O processo Scrum de desenvolvimento de software tem proporcionado benefícios imensos a milhões de profissionais até hoje. Por isso, não há motivo para não se juntar a estas pessoas bem-sucedidas que melhoraram as suas carreiras e competências com a ajuda do framework Scrum.

Se ainda tem dúvidas, quero assegurar-lhe que já não consegue imaginar uma carreira em crescimento sem possuir uma certificação Scrum Master. Isto aplica-se independentemente da sua função, cargo e experiência no ecossistema de Tecnologias da Informação (TI) .

Já nem precisa de ser profissional de TI para compreender o que é Scrum, como funciona e obter uma certificação Scrum Master.

Seja qual for a sua profissão, faça ou não parte de um departamento de TI, existe um facto essencial e indiscutível. As suas tarefas e o valor profissional de negócio que proporciona à organização dependem e estão interligados com as TI, o software e os processos e princípios ágeis de Scrum.

Além disso, graças à transformação dos modelos de negócio tradicionais em software como serviço (SaaS) que orienta os negócios, ou ao chamado movimento de digitalização, obter a certificação Scrum Master deixou de ser uma decisão voluntária para qualquer profissional, dentro ou fora do departamento de TI. Pelo contrário, obter uma certificação Scrum Master é hoje uma necessidade.

Pode estar a começar a carreira ou ser um profissional de TI experiente. Isso não altera a questão. Precisa de obter a sua certificação Scrum Master.

A sua função pode incluir ou não atividades de gestão de pessoas e de áreas funcionais. Isso também não importa: continua a precisar de uma certificação Scrum Master.

Pode ter um cargo como:

• analista de negócio,
• arquiteto de software,
• arquiteto empresarial,
• designer de software
• designer de experiência de utilização (UX),
• designer de interfaces de utilização (UI),
• programador de software,
• gestor de desenvolvimento de software,
• engenheiro de testes,
• especialista em automatização de testes,
• gestor de testes,
• especialista em operações de sistemas de TI,
• administrador Unix/Linux,
• engenheiro de segurança da informação (InfoSec),
• engenheiro de redes de TI,
• administrador de bases de dados (DBA),
• gestor de projetos,
• gestor de programas,
• gestor de produto,
• líder de equipa, gestor, diretor ou executivo,
• ou qualquer outro cargo que não tenha mencionado aqui.

Deve aprender o framework Scrum de desenvolvimento de software e tornar-se hoje um Scrum Master, obtendo a sua certificação Scrum Master.

3 elementos de caos e frustração antes do processo ágil Scrum e das certificações Scrum Master

Para compreender melhor o impacto do framework Scrum nas nossas práticas de engenharia de software e nos negócios, faz sentido olhar para um dia de trabalho ou para um projeto de software da vida real.

Por isso, gostaria de falar brevemente sobre um projeto de software do passado, antes de adotarmos o framework Scrum de desenvolvimento e entrega de software nas nossas organizações.

Poucos dias antes de escrever estas linhas, almocei com um antigo colega com quem trabalhei há quase 20 anos. Marcus obteve as suas certificações Scrum Master e Scrum Product Owner no International Scrum Institute™.

Atualmente, trabalha como Scrum Master numa das principais empresas de software da área de gestão ágil de projetos.

Como Scrum Master, Marcus apoia hoje uma equipa ágil Scrum cujos membros estão distribuídos geograficamente pelo mundo.

Durante o almoço, Marcus admitiu que existem muitos desafios habituais nas equipas ágeis Scrum distribuídas. Alguns dos problemas que mencionou especificamente sobre a configuração do seu projeto de software são:

• Diferenças nos estilos de trabalho dos membros da equipa Scrum,
• Diferenças de fuso horário,
• Incompatibilidades culturais e
• Limitações de idioma.

Apesar destas dificuldades, Marcus acrescentou que gerir um projeto de software com o processo ágil Scrum é mais divertido, produtivo e enriquecedor do que a forma como trabalhávamos há 20 anos. Em comparação com a época em que trabalhávamos sem processos Scrum de desenvolvimento e entrega de software.

A afirmação de Marcus era, de facto, um importante testemunho a favor do framework Scrum, vindo de um gestor, Scrum Master e Product Owner muito competente e experiente.

Obrigado, Marcus!

Depois, expliquei-lhe um dos meus projetos de software anteriores ao meu contacto com o framework Scrum. Tenho a certeza de que muitos Scrum Masters reconhecerão semelhanças com os projetos que realizaram antes de obterem as certificações Scrum Master.

No final da década de 1990, integrei um grupo de engenharia de software que desenvolvia, com base em cartões inteligentes, um infraestrutura de chaves públicas. Os cartões inteligentes protegiam com segurança as chaves privadas dos membros da infraestrutura, enquanto as chaves públicas associadas e os certificados que as continham eram distribuídos abertamente, como sugere o nome “pública”.

Na época, esse já era um projeto de TI relativamente complexo, que exigia várias equipes interdependentes de engenharia de hardware e software. Precisávamos realizar um enorme volume de pesquisa e desenvolvimento (P&D) para construir um sistema de hardware e software plenamente funcional.

Lembre-se de que foi antes de termos o produto mínimo viável (MVP) para experimentar, criar, aprender e voltar a experimentar.

Se quiser saber mais sobre como criar um MVP numa metodologia ágil, consulte este artigo da Cleevio, que lhe dará uma visão mais clara deste processo complexo.

Sem Scrum, criar uma infraestrutura tão sofisticada, composta por numerosos elementos de hardware e software, era um verdadeiro desafio.

Eis três dificuldades importantes que enfrentávamos sem Scrum Masters nem pessoas com certificação Scrum Master nas nossas equipas.

O 1.º elemento de caos e frustração sem certificação Scrum Master: tínhamos de planear todo o projeto antes de compreender o seu propósito

Sem Scrum, as nossas equipas desenvolveram e entregaram produtos de software e hardware totalmente errados, que não correspondiam às exigências do cliente.

Houve momentos na nossa vida profissional em que empresas externas impunham como devíamos construir os produtos ou serviços de software.

Capability Maturity Model (CMM), ISO 9001:2008 e outras variantes procuravam ajudar as empresas a garantir que desenvolvíamos o software certo da forma correta.

O grau de sucesso dessas abordagens não faz parte deste artigo. O objetivo é concentrar-se no processo Scrum e nos méritos da certificação Scrum Master, sem tratar as normas de gestão da qualidade e melhoria de processos como alternativas extintas a Scrum.

No entanto, devo acrescentar que estes frameworks de melhoria de processos, anteriores ao framework Scrum de engenharia de software, foram implementados nos nossos projetos através de uma abordagem faseada. Utilizávamos uma abordagem de engenharia de software por fases a que chamávamos modelo de engenharia de software em cascata.

No modelo em cascata, cada projeto de software devia começar com a análise de requisitos, na qual procurávamos compreender o que o cliente precisava e queria.

Depois, concebíamos as soluções para esses requisitos, implementávamo-las, testávamo-las ou verificávamo-las e mantínhamo-las nos ambientes de produção de software. Finalmente, chegávamos ao fim do ciclo de vida da engenharia de software.

Mas a realidade não acontecia assim!

Os efeitos negativos de atrasos imprevistos numa determinada fase do modelo de engenharia de software em cascata afetavam inevitavelmente as fases seguintes.

Era a vida antes do framework Scrum.

Fazer o software circular entre várias equipas, sem a orientação de profissionais com certificação Scrum Master, tornava o trabalho burocrático, complexo e improdutivo.

No fim, não era apenas o produto que sofria: a motivação dos colaboradores e o compromisso com a missão da organização também ficavam completamente comprometidos.

O 2.º elemento de caos e frustração sem certificação Scrum Master: falta de compromisso, gestão da mudança e disciplina de colaboração entre equipas

A maior fraqueza dos modelos de melhoria de processos utilizados antes do Scrum era esta: Concentravam-se sobretudo nas exigências organizacionais da liderança em benefício próprio.

Entre essas demandas estavam monitoramento, conformidade e previsibilidade. Não havia qualquer foco em servir bem os clientes ou aumentar a motivação dos colaboradores.

Assim, membros das equipes de gestão de software e diversas partes interessadas internas e externas buscavam estabelecer um prazo fixo de entrega e acompanhar facilmente o progresso das fases de engenharia de software.

Puniam as pessoas quando algo saía do planejado e esperavam resolver os problemas emergentes antes da data prevista de conclusão do projeto.

Além disso, estruturas isoladas executavam fases de engenharia de software completamente separadas. Por exemplo, a equipa de desenvolvimento era totalmente independente da equipa de testes ou verificação de software. A maioria das pessoas que devia trabalhar para a mesma missão de negócio nem sequer conhecia os nomes das outras.

Você imagina por que nossas organizações tinham essa mentalidade de isolamento, em vez de se concentrarem na missão do negócio e na maturidade profissional dos funcionários?

A razão é simplesmente a gestão matricial. A gestão matricial é uma estrutura de gestão organizacional e de funcionários presente nas empresas desde a década de 1970. À primeira vista, a ideia que diferencia uma organização ou gestão matricial parece inteligente.

A liderança cria uma estrutura organizacional reunindo colaboradores com competências funcionais e técnicas semelhantes nos mesmos grupos isolados ou, no melhor dos casos, em grupos vizinhos.

Nessa época, era bastante comum ver nas empresas os chamados «centros de competências», cada um representando um grupo independente e autónomo.

Uma área para desenvolvedores C++, outra para administradores de bancos de dados e outra área de garantia da qualidade completamente separada, em outro país, e assim por diante. Vai entender!

O maior desafio da estrutura organizacional matricial era o seguinte: para entregar um projeto de software sem o framework Scrum e sem Scrum Masters, os gestores de projetos tinham de pedir temporariamente colaboradores a esses grupos.

Esses colaboradores nem sequer se instalavam fisicamente junto das equipas de projeto, permanecendo nas salas dos seus respetivos centros de competências.

Depois de concluídos os projetos, estas equipas temporárias dissolviam-se e os participantes seguiam para novas tarefas noutros projetos.

Por isso, o valor de negócio pretendido pelos projetos de software em andamento nunca era a prioridade máxima dessas áreas independentes.

Elas tendiam a enxergar o trabalho como itens a marcar numa lista, um para este projeto, outro para aquele.

A liderança e o modelo matricial não ensinavam como profissionais deveriam se comprometer com o negócio para melhorar os resultados, incluindo vendas, receita e lucro.

Um artigo da McKinsey & Company no McKinsey Quarterly também ilustrou claramente essa ilusão de otimização de custos associada à organização matricial.

O artigo original cita uma estimativa da Gartner sobre o total anual mundial de gastando 600 bilhões de USD para recuperar seus sistemas de TI de trabalhos de manutenção não programados e defeitos.

Agora, dediquemos um momento a visualizar como funcionavam a gestão da mudança e o tratamento de impedimentos nos projetos de software. Como funcionavam numa configuração de projeto com o modelo em cascata, uma organização matricial e sem o processo Scrum.

Sim. Você acertou. A gestão e os colaboradores tratavam a gestão da mudança, o tratamento de impedimentos e de erros como exceções indesejáveis que nem sequer deveriam ter surgido.

Por isso, as alterações num projeto de software tornaram-se sinónimo de atrasos. Normalmente criavam um efeito dominó de atrasos em cascata. As equipas precisavam de alguém para culpar pelos defeitos e impedimentos.

Por fim, como as áreas isoladas não tinham um mecanismo para analisar, corrigir e aprender com os erros, continuavam repetindo os mesmos enganos.

Além disso, continuavam a aumentar a quantidade de dívida técnica enquanto tentavam lidar passivamente com seus problemas.

O 3.º elemento de caos e frustração sem certificação Scrum Master: as decisões autocráticas sobrepunham-se às decisões democráticas

Steve Jobs disse certa vez:

“Não faz sentido contratar pessoas inteligentes e dizer a elas o que fazer. Contratamos pessoas inteligentes para que elas nos digam o que fazer.”

No entanto, isso é precisamente o contrário da forma como a maioria das lideranças tomava decisões antes da era Scrum.

Antes de termos o processo Scrum nas organizações, as decisões autocráticas dos líderes sobrepunham-se à inteligência conjunta das equipas.

Invalidavam a capacidade de decisão democrática dos grupos responsáveis por realizar o trabalho efetivo que abrangia todo o ciclo de vida da engenharia de software, da concepção à operação.

Quanto mais uma decisão se afastava das equipas de trabalho que afetava, mais difícil era tomar corretamente uma decisão fundamental para a missão.

As decisões dos líderes costumavam ser impulsivas, pouco refletidas, geralmente tardias e hesitantes, mas às vezes até prematuras.

Essas decisões autocráticas impostas de cima faziam os funcionários se sentirem desvalorizados. Impediam completamente que as organizações criassem soluções inovadoras para enfrentar desafios competitivos de negócio e de software.

Além disso, desencorajavam as equipas de engenharia de software a contribuir nos momentos em que lhes pediam participação nas decisões.

Esta foi uma breve visão geral de como desenvolvíamos e entregávamos os serviços e produtos de software antes de adotar o framework Scrum nas organizações. Vejamos agora como resolvemos estes elementos de caos e frustração com a ajuda do processo Scrum.

O que é Scrum?

Antes de mais, saliento que não pretendi fazer desta secção do artigo uma referência que responda a todas as perguntas sobre o framework Scrum. Ainda assim, os temas aqui discutidos proporcionarão um ponto de partida aprofundado para a maioria dos profissionais Scrum de nível inicial e intermédio.

No entanto, também temos algo para quem procura um guia mais avançado, mas prático, para aprender rapidamente o framework Scrum. Sugiro que aceda ao link e descarregue o nosso guia do framework Scrum.

O que é Scrum? Sem complicar demasiado, o framework Scrum pode definir-se da seguinte forma:

Scrum é um framework leve para gerar valor através de soluções adaptativas para problemas complexos. O desenvolvimento de software iterativo e incremental é uma aplicação importante.

Embora o software seja o principal foco do framework Scrum, o processo Scrum iterativo e ágil pode ser aplicado, e já é aplicado, fora da indústria de software.

Muitas pessoas na indústria de TI acreditam que o termo «Scrum» foi criado no início dos anos 2000, em paralelo com as tendências emergentes de desenvolvimento e entrega ágeis de software. Essa informação está errada!

O artigo da Harvard Business Review de janeiro de 1986 descreveu uma abordagem ao desenvolvimento de produtos que antecedeu o posterior framework Scrum. Hirotaka Takeuchi e Ikujiro Nonaka escreveram o artigo The New New Product Development Game. (Sim, com dois «New»)

Deve consultar «The New New Product Development Game» para descobrir como tudo começou em Scrum!

Quando a indústria de TI fala do framework Scrum, é também frequente ouvir a expressão «Agile Scrum» no mesmo sentido de «Scrum». Isso levou algumas pessoas do setor a pensar e a procurar diferenças entre «Agile Scrum» e «Scrum».

Tenho boas notícias. As expressões «Agile Scrum» e «Scrum» referem-se à mesma coisa. Ambas designam o processo Scrum de engenharia de software. Então por que utilizamos por vezes «Agile» antes de «Scrum»?

Porque o framework Scrum acolheu e integrou plenamente o Manifesto Ágil (Manifesto para o Desenvolvimento Ágil de Software) no seu processo central, nos princípios e na filosofia subjacente. Antes de aprofundarmos os aspetos técnicos do processo Scrum, importa compreender melhor o Manifesto Ágil e os valores de Scrum.

O Manifesto Ágil (Manifesto para o Desenvolvimento Ágil de Software)

Valores do Manifesto Ágil:

• Indivíduos e interações mais do que processos e ferramentas,
• Software funcional mais do que documentação abrangente,
• Colaboração com o cliente mais do que negociação contratual,
• Responder à mudança mais do que seguir um plano.

Embora os fatores do lado direito continuem a ter valor significativo, o Manifesto Ágil valoriza e privilegia mais os fatores do lado esquerdo.

Os elementos privilegiados pelo Manifesto Ágil foram cuidadosamente testados ao longo do tempo e escolhidos para:

• Servir melhor clientes e partes interessadas e criar valor para eles com software,
• Valorizar a profissão de engenharia de software, independentemente da função, cargo ou nível de carreira.

Valores do framework Scrum

Já referi que o framework Scrum não é apenas um processo de engenharia de software. Tem também um conjunto sólido de princípios subjacentes.

Na verdade, a maioria dos domínios profissionais do negócio pode aplicar e utilizar estes princípios.

Obter uma certificação Scrum Master não basta para ter um enorme sucesso com Scrum. É preciso compreender firmemente os seus valores para ter sucesso.

e, assim, realizar um excelente trabalho e criar software fantástico que os seus clientes e empregadores adorem. Deixe-me explicar melhor estes princípios do processo Scrum.

Coragem

Por vezes, fazer o que é correto para servir os melhores interesses e benefícios dos clientes não é o mais fácil. Nesses momentos, o Scrum Master, o Scrum Product Owner e os membros da equipa devem recordar o seu dever e responsabilidade.

Isto significa construir os melhores produtos e serviços possíveis no seu domínio de negócio e de tecnologias de informação. Para superar a mediocridade, uma equipa Scrum terá, mais cedo ou mais tarde, de enfrentar decisões difíceis que não deixarão todos satisfeitos no seu ecossistema de partes interessadas.

Para lidar com isso, todos os membros da equipa devem recordar o que aprenderam durante a formação de certificação Scrum Master.

Devem lembrar-se de ter coragem e aprender a decidir e agir com coragem.

Foco

No framework Scrum, quando ouve falar do valor foco, deve pensar em duas coisas:

• Identificação do Trabalho Certo: Que tarefas são necessárias para concretizar os objetivos do meu Sprint? O que é essencial para desenvolver os melhores produtos e serviços de software para os clientes, para que fiquem satisfeitos com o meu trabalho?
• Priorização: Em que tarefas devo trabalhar a seguir?

Em cada momento, existe uma pergunta fundamental a que toda a equipa Scrum, incluindo Scrum Master e Product Owner, deve responder. A pergunta é: «Quais são as coisas mais importantes que devemos fazer neste momento para corresponder aos motivos pelos quais o empregador nos contratou?»

O framework Scrum integra vários eventos ou rituais para assegurar uma definição razoável das prioridades das User Stories e tarefas. Segundo o processo Scrum, definir a prioridade das User Stories e das tarefas associadas deve ser uma preocupação contínua.

Assim, garantimos que a equipa Scrum trabalha nas coisas certas, pela ordem correta. Os eventos Scrum formais e as práticas relacionadas de refinamento ajudam-nos a inspecionar o nosso foco e a adaptar o trabalho:

• Reunião de refinamento Scrum: O refinamento esclarece, divide e dimensiona os próximos itens do Product Backlog, ajudando também a definir a sua ordem. Uma reunião é uma das opções para esta atividade contínua.
• Reunião de Sprint Planning: Estas reuniões ajudam-nos a compreender as dependências e a ordem correta do trabalho para entregar as histórias de utilizador.
• Reunião de Daily Scrum: As reuniões Daily Scrum, também chamadas de acompanhamento diário, ajudam-nos a orientar o próximo dia de trabalho. Devemos concentrar-nos onde a nossa atenção é mais necessária.
• Reunião de Sprint Review: A Sprint Review mostra-nos indiretamente para onde a equipa Scrum deve orientar a atenção para ter revisões futuras mais bem-sucedidas.
• Reunião de Sprint Retrospective: Estas reuniões ajudam a equipa Scrum a definir quais os aspetos do processo de engenharia que devem ser melhorados primeiro.

Nesta secção, abordei os rituais Scrum apenas na perspetiva do foco. Pode encontrar uma explicação mais detalhada das cerimónias Scrum mais adiante neste artigo.

Depois de ler tudo isto, deve ser claro como a definição de prioridades e o foco são essenciais para o framework Scrum.

Compromisso

Sem o compromisso do Scrum Master, do Scrum Product Owner e da equipa Scrum, não é possível alcançar resultados excecionais com software.

No mundo do processo Scrum de desenvolvimento de software, muitas pessoas interpretam o valor compromisso como o acordo e a delimitação dos objetivos dos entregáveis de um determinado Sprint.

Embora faça todo o sentido, esta compreensão não é perfeita. Quando ouve a palavra «compromisso» no contexto dos valores de Scrum, o autor utiliza «obsessão» para enfatizar a dedicação. Na definição de Scrum, o compromisso diz respeito aos objetivos da equipa e ao apoio mútuo; não exige excesso de trabalho nem certeza sobre todos os itens previstos.

Para ter sucesso na engenharia de software, na vida e nos negócios, deve tornar-se obcecado pelos seus objetivos. Por isso, no contexto do processo Scrum, deve tornar-se obcecado por criar software extraordinário para resolver os problemas dos seus clientes.

Por que são tão importantes o compromisso e a obsessão associada aos objetivos de Scrum? Porque, sem uma dedicação intensa à missão de desenvolver e entregar software excecional, o trabalho abranda e para sempre que a equipa encontra um impedimento não trivial.

Depois, o Scrum Master e a equipa começarão a criar explicações para justificar e legitimar perante o Scrum Product Owner a sua incapacidade de cumprir os objetivos do Sprint. As desculpas deixam de ter lugar na equipa se pretende torná-la melhor do que a média.

Só com um nível de dedicação muito elevado é relativamente mais fácil e gratificante resolver os problemas dos clientes e criar valor para eles com software.

Respeito

Independentemente da idade, género, raça, crença, experiência, competência, opiniões e desempenho, todos os membros de uma equipa Scrum devem respeitar-se e contar uns com os outros.

Este respeito não se limita às fronteiras da equipa. Todas as partes interessadas internas ou externas, de TI ou de negócio, que interagem com a equipa Scrum são plenamente respeitadas e bem-vindas.

Os membros experientes devem ter cuidado para não desvalorizar a vontade de contribuir dos membros menos experientes.

É particularmente importante acolher e responder adequadamente a opiniões contrárias com as quais a maioria do grupo não concorda.

Abertura

O valor Scrum «abertura» é muitas vezes um dos principais fatores que distinguem uma equipa média de uma equipa de elevado desempenho. Pense na capacidade de abertura de uma equipa Scrum como a vasta capacidade de um conjunto de pessoas de mente aberta.

São criativas, inovadoras, intelectuais, honestas, diretas e humildes. No processo Scrum de engenharia e entrega de software, as pessoas devem poder discutir abertamente desafios e perspetivas diferentes. A abertura não torna todas as decisões ou ações adequadas: o respeito, a qualidade e os objetivos da equipa continuam a ser importantes.

A única condição é serem transparentes e procurarem contribuir para a missão conjunta da equipa Scrum.

Isto não significa que todas as decisões e ações tenham necessariamente de acelerar os resultados da equipa ou produzir grandes histórias de sucesso.

Graças aos valores de abertura e coragem, o grupo de desenvolvimento de software Scrum não tem medo de cometer erros. Encara os erros e os resultados abaixo do ideal como oportunidades fundamentais para melhorar significativamente a produtividade global e a qualidade do trabalho.

Principais componentes do framework Scrum

A Scrum Team é composta por um Product Owner, um Scrum Master e Developers, com três responsabilidades distintas. A expressão anterior «Scrum Team Member» utilizada neste artigo refere-se ao grupo de desenvolvimento, não a uma quarta responsabilidade nem a outra Scrum Team completa.

Além dos outros programas que disponibiliza aos seus estudantes de todo o mundo, International Scrum Institute™ disponibiliza três programas principais de formação e certificação para estes três papéis.

Estes programas são Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), e Scrum Team Member Accredited Certification™ (STMAC™).

Uma organização Scrum adequada deve reunir pessoas com estes três conjuntos de competências. Isso é especialmente importante para ter sucesso com o framework Scrum de desenvolvimento de software.

Todas as responsabilidades Scrum devem ser cumpridas. Mantêm-se distintas; um Product Owner ou Scrum Master pode também contribuir como Developer ao executar trabalho do Sprint Backlog, sem perder as responsabilidades da outra função.

Várias Scrum Teams que trabalham num produto partilham um Product Owner, um Product Goal e um Product Backlog. Cada equipa tem a responsabilidade de Scrum Master e precisa de apoio eficaz; Scrum não determina que uma pessoa só possa apoiar uma equipa.

Não subestime a importância de compreender o propósito e a função destes papéis e de os confiar a pessoas com talento adequado. Muitas vezes observámos que a causa profunda das dificuldades de uma equipa Scrum é a falta de compreensão destas funções ou a escolha das pessoas erradas.

Falemos agora destas três funções.

Três funções Scrum — Scrum Product Owner

O Scrum Product Owner ordena o Product Backlog para maximizar o valor do produto e trabalha com as partes interessadas nas decisões de produto e de lançamento. Os Developers selecionam o trabalho que preveem realizar num Sprint; a organização dos lançamentos depende do contexto do produto. Representa as exigências funcionais e não funcionais dos utilizadores finais.

O papel do Product Owner é muito mais amplo que os papéis tradicionais de gestão de projetos, programas ou produtos.

Esta função reúne tarefas de gestão de produto e de projeto e está também fortemente integrada no desenvolvimento e na entrega de software.

As tarefas essenciais de um Scrum Product Owner são:

• Gerir e esclarecer os requisitos do projeto,
• Orientar lançamentos e garantir o retorno sobre o investimento (ROI),
• Trabalhar em estreita colaboração com a equipa Scrum,
• Gerir as partes interessadas.

Três funções Scrum — Scrum Team Member

A equipa Scrum implementa o software. Os Developers selecionam a quantidade de trabalho que preveem conseguir concluir durante um Sprint. O Sprint é um evento com duração fixa; o resultado utilizável do produto criado durante esse período é um Incremento que cumpre a Definition of Done.

Uma equipa Scrum de elevado desempenho reúne normalmente a maioria das competências de engenharia de software. Programadores, arquitetos, profissionais de testes, administradores de bases de dados e membros de todas as outras funções trabalham em conjunto.

Em conjunto, desenvolvem e entregam excelente software pelo qual o cliente paga.

Os membros da equipa Scrum deixam de pertencer a grupos funcionais isolados de uma organização matricial. Os programadores deixam de pertencer a centros de competências de desenvolvimento de software, os profissionais de testes deixam de pertencer a centros de competências de testes de software, e assim por diante.

Independentemente da sua posição anterior na organização, os membros de uma equipa Scrum pertencem ao seu projeto Scrum específico. Agora, a sua função é construir o melhor software possível para responder aos requisitos do Scrum Product Owner.

As características das equipas Scrum são:

• Capacitadas,
• Autónomas,
• Multifuncionais,
• Auto-organizadas,
• Pequenas,
• Participantes com disponibilidade suficiente (a participação a tempo inteiro é uma escolha organizacional comum),
• Capazes de colaborar de perto, no mesmo local ou de forma distribuída,
• Um por todos, todos por um.

Três funções Scrum — Scrum Master

O Scrum Master apoia todos os participantes de um projeto Scrum e as partes interessadas externas na compreensão e aplicação correta do framework Scrum. Ajuda a equipa a executar com sucesso o processo Scrum e a melhorar continuamente a produtividade e o desempenho.

A função do Scrum Master é estabelecer o processo Scrum e a nova forma de pensar e agir.

Além disso, o Scrum Master atua como agente de mudança. Orienta a equipa na criação de novas normas e padrões. Mantém-se acessível à equipa; a proximidade física pode ajudar, mas não é uma exigência de Scrum.

As responsabilidades essenciais do Scrum Master incluem:

• Estabelecer Scrum no seu ecossistema de negócio e TI,
• Orientar a equipa para compreender e viver os valores de Scrum,
• Assegurar uma colaboração próxima entre o Scrum Product Owner e a equipa Scrum,
• Eliminar impedimentos,
• Liderar servindo,
• Apoiar eventos Scrum eficazes e facilitar quando necessário, preservando a responsabilidade dos Developers pelo Daily Scrum.

Product Backlog (Scrum Backlog)

O Product Backlog (Scrum Backlog), ou Scrum Product Backlog, é o elemento central para gerir todos os requisitos conhecidos de um projeto Scrum.

É composto por todos os requisitos dos clientes e itens de trabalho necessários para executar e concluir um projeto bem-sucedido. Os requisitos incluem os funcionais e não funcionais e outras funcionalidades relacionadas com a experiência de utilização e interface de utilização e respetiva conceção.

O Product Backlog contém pedidos de funcionalidades e os respetivos elementos de alto nível de histórias de utilizador. Estes também podem incluir requisitos prévios ou complementares do projeto, como a criação de ambientes de testes e desenvolvimento. Outras User Stories necessárias para resolver erros conhecidos, reduzir a dívida técnica ou melhorar determinadas funcionalidades do software também têm lugar no Product Backlog.

Cada produto tem o seu Product Backlog. O Scrum Product Owner é responsável pela criação, manutenção e aperfeiçoamento do Product Backlog. O Product Backlog não responde, nem deve responder, à pergunta de como estes requisitos serão desenvolvidos e entregues.

Essa é a responsabilidade da equipa Scrum. A equipa decide e documenta nos Sprint Backlogs as tarefas necessárias para responder aos requisitos. Note que Product Backlog e Sprint Backlog são artefactos distintos, mas não necessariamente documentos ou ferramentas fisicamente separados, embora os itens do Product Backlog determinem o conteúdo do Sprint Backlog.

O Product Backlog é um documento vivo. Tal como o software melhora incrementalmente, o Product Backlog muda com a aprendizagem da equipa, incluindo adições, remoções e alterações da ordem. O framework Scrum não exige, por si só, um processo separado de gestão da mudança. O Scrum Product Owner cria as primeiras versões do Product Backlog com base na sua melhor compreensão inicial do produto.

À medida que observa atentamente a evolução do produto entre Sprints e aprofunda os conhecimentos sobre os requisitos dos clientes, acrescenta, retira e aperfeiçoa requisitos no Product Backlog.

O Scrum Product Owner define as prioridades dos requisitos no Product Backlog. Quanto maior for a prioridade de um elemento do Product Backlog, maior deverá ser o seu detalhe. Assim, a equipa Scrum compreende facilmente esses requisitos prioritários e cria as tarefas necessárias para os implementar.

Além disso, utilizando uma abordagem de estimativa como story points, a equipa Scrum estima regularmente os requisitos do Product Backlog. Estas estimativas devem ser aperfeiçoadas e melhoradas nas User Stories prioritárias para as preparar para o Sprint Planning.

Sprints

No framework Scrum, todas as atividades de implementação dos requisitos decorrem durante os Sprints. Os Sprints são ciclos de atividades para desenvolver Incrementos de produto ou serviço de software disponibilizáveis. Os Sprints também são, por vezes, chamados iterações.

Pense nos Sprints como pequenos projetos. Como o termo «Sprint» sugere, não duram muito: um mês ou menos. Sprints de quatro semanas são um exemplo comum, não a duração máxima exata do framework em dias de calendário.

Ao contrário de uma corrida, no fim de um Sprint a equipa Scrum não deve estar sem fôlego e sem energia. Pelo contrário, deve manter-se fresca e começar o Sprint seguinte com energia.

O framework Scrum de desenvolvimento e entrega de software não tem como objetivo criar pressão e stress para os membros. É bem conhecido que as pessoas trabalham melhor quando se conseguem concentrar, sem tensão nem distrações. Aplicados corretamente, os Sprints ajudam-nos a alcançar isso.

Cada Sprint começa com uma Reunião de Sprint Planning. Durante a reunião de Sprint Planning, a equipa Scrum decide quais os requisitos e quantos irá implementar nesse Sprint. Em seguida, começa a executar as atividades necessárias para os entregar.

Daily Scrum (reunião de Daily Scrum) decorre em todos os dias úteis do Sprint, à mesma hora e no mesmo local. Os Developers utilizam-no para inspecionar o progresso em direção ao Sprint Goal e adaptar o plano para o dia seguinte. Os membros da equipa também podem pedir ao Scrum Master ajuda para eliminar impedimentos que possam abrandar ou bloquear o progresso do Sprint.

A equipa Scrum termina um Sprint com as reuniões de Sprint Review e Sprint Retrospective. A reunião de Sprint Review permite à Scrum Team e às principais partes interessadas inspecionar o resultado do Sprint e o progresso em direção ao Product Goal, discutindo depois futuras adaptações. É uma sessão de trabalho, não uma etapa de aprovação pelo Product Owner.

Durante a Reunião de Sprint Retrospective, a equipa Scrum reflete sobre a forma como trabalha em conjunto, como utiliza o framework Scrum e como pode melhorar.

Assim, a equipa considera em conjunto estas oportunidades de melhoria e o feedback durante o Sprint Planning seguinte. Os Sprints permitem estes ciclos de feedback em períodos curtos, com pequenos lotes de trabalho. Esta é uma das principais razões pelas quais o framework Scrum ajuda equipas e organizações a melhorar continuamente.

Inspeção e adaptação em Scrum

A inspeção e adaptação em Scrum é um conceito simples de compreender, mas muito difícil de implementar e dominar corretamente.

As empresas acabaram por confirmar que nenhum dos seus gestores de projetos conseguia prever totalmente o panorama de sistemas complexos. Não conseguiam realizar um planeamento completo fiável. Tornou-se evidente que precisavam de experimentar algo diferente.

Em conjunto com a produção lean (também conhecida como movimento lean), as empresas precisavam de desenvolver um processo que as capacitasse estrategicamente. Precisavam de um procedimento operacional padrão que as ajudasse a aprender e corrigir a direção enquanto executavam os projetos e até as operações.

Assim nasceu o Toyota Improvement Kata, que oferece uma comparação útil com a inspeção e adaptação em Scrum. Estas abordagens de melhoria têm propósitos relacionados, mas Toyota Improvement Kata não é simplesmente outro nome para os pilares empíricos de Scrum. Segundo «Inspeção e adaptação em Scrum»:

• Passo 1. Inspecionar: Fazemos o possível para compreender o estado atual do projeto com o nível de conhecimentos e compreensão de que dispomos.
• Passo 2. Adaptar: Definimos uma direção e visão para os próximos passos do projeto, traçamos uma estratégia e executamos essa visão.
• Passo 3. Aprender: Observamos cuidadosamente, aprendemos e ensinamos uns aos outros ao longo do processo. Registamos continuamente o que funciona e o que não funciona durante o trabalho.
• Passo 4. Recomeçar: Voltar novamente ao passo 1.

Note que os quatro passos abaixo são uma analogia pedagógica, não uma definição equivalente dos eventos Scrum. A inspeção, adaptação e aprendizagem decorrem ao longo de todo o Sprint.

• Passo 1. Inspecionar é análogo às reuniões de Sprint Review e Sprint Retrospective.
• Passo 2. Adaptar é análogo às reuniões de Sprint Planning.
• Passo 3. Aprender é análogo às reuniões de Daily Scrum.
• Passo 4. Recomeçar é análogo ao encerramento de um Sprint e ao início de outro.

Auto-organização

A equipa Scrum organiza-se a si própria. Os membros decidem por consenso as tarefas necessárias para concretizar os objetivos de um Sprint. Uma equipa auto-organizada não precisa de um gestor ou líder de equipa.

A auto-organização no framework Scrum é muito disciplinada.

Sprint Backlog e Reuniões de Daily Scrum apoiam a autogestão. Um gráfico de burndown do Sprint é uma forma opcional de tornar o progresso visível.

Organizar o próprio trabalho exige uma fase de aprendizagem para a maioria das equipas. Scrum Masters competentes e certificados ajudam as equipas a desenvolver rapidamente uma excelente auto-organização.

A auto-organização também inclui a capacidade de trabalhar em conjunto apesar de opiniões diferentes e possíveis conflitos entre membros. Exige respeito e confiança nos processos de decisão conjuntos.

Esses processos de decisão no framework Scrum incluem, entre outros, o planeamento, a estimativa, a implementação, a comunicação e a revisão do trabalho pelo qual a equipa é conjuntamente responsável.

Eventos Scrum e refinamento contínuo do backlog

Evento Scrum 1. Sprint Planning (porquê, o quê e como)

Durante a Reunião de Sprint Planning, a equipa Scrum cria um Sprint Backlog viável que determina os requisitos que irá implementar durante o Sprint.

As responsabilidades das várias funções Scrum durante o Sprint Planning são as seguintes:

• O Product Owner propõe por que razão o Sprint poderá ser valioso. Toda a Scrum Team colabora num Sprint Goal e os Developers selecionam os itens do Product Backlog que preveem conseguir concluir.
• A Scrum Team identifica as tarefas necessárias e as respetivas estimativas. Os Developers decidem quais os itens e quantos preveem conseguir concluir no Sprint, tendo em conta o desempenho anterior, a capacidade e a Definition of Done.
• O Scrum Master modera a reunião. Garante que a auto-organização e a capacidade de decisão autónoma da Scrum Team permanecem intactas.

Durante o Sprint Planning, a presença do Scrum Product Owner é obrigatória. Assim, pode responder às perguntas da equipa e esclarecer os requisitos e os respetivos critérios de aceitação.

A Scrum Team pode convidar outras pessoas, como utilizadores finais ou gestores, para aconselhar durante o Sprint Planning. Os convidados aconselham sem assumir as decisões dos Developers sobre a execução do trabalho.

Evento Scrum 2. Daily Scrum (reunião diária de acompanhamento)

O reunião Daily Scrum é uma reunião com duração máxima de 15 minutos. Estas reuniões decorrem em todos os dias úteis, à mesma hora e no mesmo local. É preferível realizá-las com acesso direto ao Sprint Backlog e ao gráfico de burndown do Sprint. Assim, a Equipa Scrum pode orientar a reunião com base nos factos e no progresso visíveis para todos os seus membros.

A reunião de Daily Scrum pretende apoiar a auto-organização da Equipa Scrum e identificar sistematicamente os impedimentos.

O Daily Scrum destina-se aos Developers. Um Product Owner ou Scrum Master que trabalhe em itens do Sprint Backlog participa como Developer. Outras formas de participação devem preservar o foco e a autogestão dos Developers; Scrum não exige a presença de todas as funções ou partes interessadas.

Os Developers escolhem uma estrutura útil, centrada no Sprint Goal e num plano de ação. As três perguntas seguintes são um formato opcional conhecido, não perguntas atualmente prescritas por Scrum.

• Daily Scrum — Pergunta #1. Que atividades realizei desde a última reunião de Daily Scrum?
• Daily Scrum — Pergunta #2. Que atividades planeio realizar até à próxima reunião de Daily Scrum? Qual é o meu plano de ação?
• Daily Scrum — Pergunta #3. Encontrei ou prevejo algum impedimento que possa atrasar ou bloquear o progresso do meu trabalho?

Os Developers conduzem o seu Daily Scrum. O Scrum Master ajuda os Developers a compreender o propósito e a eficácia do evento quando necessário. O evento mantém-se nos 15 minutos; o formato de três perguntas é opcional.

O objetivo do Daily Scrum não inclui tomar decisões demoradas nem resolver problemas. Para alinhar decisões e resolver problemas, a equipa pode organizar reuniões separadas conforme necessário. Estas reuniões específicas sobre decisões ou problemas decorrem normalmente depois do Daily Scrum.

O Scrum Master documenta os impedimentos identificados e as respetivas datas num registo, quadro ou relatório separado, acessível à equipa. Considero muito útil atualizar rapidamente o estado dos impedimentos em aberto no fim do Daily Scrum.

Evento Scrum 3. Sprint Review

O Reunião de Sprint Review decorre no fim do Sprint. Uma Review de uma a duas horas poderá adequar-se a algumas equipas; o máximo formal é de quatro horas para um Sprint de um mês, sendo habitualmente mais curta para Sprints menores. Dependendo do software e da infraestrutura disponível, as reuniões decorrem numa sala de reuniões, num laboratório ou na sala da equipa Scrum.

O objetivo da Sprint Review é rever o Incremento de produto disponibilizável criado durante o Sprint e tornar transparente o desenvolvimento do produto.

A equipa Scrum demonstra os resultados do trabalho. A Scrum Team e as partes interessadas discutem o que foi alcançado e o que mudou no ambiente. Inspecionam os resultados e ponderam o que fazer a seguir; a Review não é uma verificação de conformidade com uma lista fixa de tarefas prometidas.

A Sprint Review permite à Scrum Team e às partes interessadas inspecionar os resultados do produto e adaptar o Product Backlog. Mais tarde, toda a Scrum Team colabora no próximo Sprint Goal. Por isso, as Sprint Reviews são uma aplicação formal e prática de «inspecionar e adaptar».

Participam na Sprint Review a equipa Scrum, o Scrum Product Owner e o Scrum Master. Outras partes interessadas, como utilizadores finais, clientes e representantes do negócio, podem juntar-se opcionalmente.

Na Sprint Review, podem dar feedback sobre o Incremento de produto demonstrado. Assim, a equipa Scrum tem a oportunidade de receber contributos diretos e sem filtros das partes interessadas para quem desenvolve o software.

Evento Scrum 4. Sprint Retrospective

O Reunião de Sprint Retrospective segue-se à Sprint Review e conclui o Sprint. A duração máxima é de três horas para um Sprint de um mês; nos Sprints menores, costuma ser mais curta.

O objetivo das Sprint Retrospectives é melhorar o trabalho conjunto dos membros da equipa Scrum e a aplicação do processo Scrum.

Por isso, as Sprint Retrospectives levam ao aumento da produtividade, do desempenho dos membros e da qualidade do software.

Uma Sprint Retrospective é, na prática, uma pequena análise posterior para definir oportunidades de melhoria e eliminar obstáculos relacionados com o processo. Alguns exemplos de oportunidades que vemos frequentemente nos nossos projetos são:

• Adoção de práticas de desenvolvimento de software Agile, como programação extrema (XP) ou desenvolvimento orientado por testes (TDD).
• Identificação de novas normas e princípios da equipa ou
• Maior disponibilidade do Product Owner Scrum.

Sem exceção, a equipa Scrum realiza uma Sprint Retrospective no fim de cada Sprint. Só assim estas reuniões permitem à equipa adaptar e melhorar sistematicamente a utilização do processo Scrum às particularidades do projeto.

Prática relacionada: refinamento do Product Backlog (grooming)

Scrum Reuniões de refinamento do backlog (grooming) procuram manter o Product Backlog atualizado. Assim, o Product Backlog reflete os melhores conhecimentos e a compreensão da equipa sobre o projeto Scrum em curso.

O refinamento pode decorrer conforme necessário ou em discussões agendadas. Duas sessões de 30 minutos por semana são um exemplo prático, não uma frequência obrigatória nem um limite máximo. O Product Owner e os Developers colaboram, envolvendo o Scrum Master e outros participantes quando útil.

Durante as reuniões de refinamento do backlog Scrum, os participantes aperfeiçoam o Product Backlog através das seguintes ações:

• Acrescentar novas histórias de utilizador com base em requisitos descobertos recentemente.
• Remover histórias que já não são necessárias para o produto.
• Aperfeiçoar as estimativas das histórias de utilizador.
• Atualizar as prioridades das histórias de utilizador.
• Dividir histórias enormes em histórias mais pequenas e fáceis de assimilar, priorizando-as em conformidade.

Quatro passos simples para obter a sua certificação Scrum Master

Obter a certificação Scrum Master é muito simples, rápido e totalmente online.

Graças ao International Scrum Institute™, pode agora obter a certificação Scrum Master mais depressa e de forma mais económica do que nunca.

Quatro passos simples para obter a sua certificação Scrum Master sem perder tempo, sem desperdiçar dinheiro e sem complicações são os seguintes.

• Passo #1. Inscrever-se online

  Inscreva-se online na certificação Scrum Master através da sua página de inscrição Scrum Master Accredited Certification™.

  Após a inscrição, o International Scrum Institute™ envia imediatamente o seu código de acesso ao exame online.

  No link seguinte, pode inscrever-se no programa de certificação Scrum Master.

• Abrir imagem em tamanho completo ↗

  Passo #2. Estudar online

  Estude online para a certificação Scrum Master utilizando o seu guia de estudo Scrum, The Scrum Framework™.

  The Scrum Framework™ foi concebido para ser inteiramente orientado para a prática. Os conteúdos ajudam-no a enfrentar os desafios diários do trabalho e da carreira como Scrum Master talentoso. The Scrum Framework™ está repleto de estudos de caso e exemplos práticos que mostram o dia a dia dos Scrum Masters mais bem-sucedidos.

  No link seguinte, pode Pedir o seu exemplar gratuito de The Scrum Framework™.

• Passo #3. Realizar online o teste de certificação Scrum Master

  Depois de ler atentamente, estudar e assimilar o seu guia de estudo Scrum, The Scrum Framework™, deverá estar preparado! Deverá sentir-se plenamente confiante para passar no exame de certificação Scrum Master.

  No link seguinte, pode Aceder ao exame de certificação Scrum Master.

• Passo #4. Obter a sua certificação Scrum Master

  Depois de passar no exame, enviamos imediatamente a sua certificação Scrum Master.

  Os seus empregadores e clientes podem validar a autenticidade da certificação utilizando a ferramenta de validação de certificações Scrum para empregadores. No link seguinte, pode aceder à ferramenta de validação de certificações Scrum para empregadores.

A minha conclusão sobre a certificação Scrum Master

É altura de recapitular. Se não teve oportunidade de ler todas as palavras deste guia passo a passo para se tornar Scrum Master, deixo-lhe as ideias principais. Eis o que penso sobre as vantagens e desvantagens de obter esta certificação.

As vantagens

Vantagens para colaboradores, profissionais independentes, coaches e formadores

• Uma certificação Scrum Master reconhecerá a sua competência e os seus conhecimentos atualizados na área Scrum.
• Uma certificação Scrum Master ajudá-lo-á a destacar-se dos seus pares que deixaram de se desenvolver. Ajudá-lo-á a conseguir o emprego de sonho como Scrum Master certificado e competente.
• Uma certificação Scrum Master alargará a sua perspetiva e abrirá ainda mais a sua mente à aprendizagem contínua. Ajudá-lo-á a assumir mais responsabilidades e a encontrar oportunidades profissionais fantásticas.
• Uma certificação Scrum Master proporcionar-lhe-á novas ferramentas para entregar excelentes produtos e serviços de que os clientes e empregadores gostarão.

Vantagens para organizações e empregadores

• As certificações Scrum Master reduzirão custos, melhorando a eficiência das equipas, atividades e processos.
• As certificações Scrum Master ajudá-lo-ão a conquistar, com colaboradores formados e competentes, projetos que de outra forma não conseguiria obter.
• As certificações Scrum Master melhorarão a satisfação e o compromisso dos colaboradores, incentivando-os a formar-se e a desenvolver competências.
• As certificações Scrum Master melhorarão a qualidade dos entregáveis, a satisfação dos clientes e, em última análise, o sucesso e a rentabilidade da organização.

As desvantagens

• Uma certificação Scrum Master não deve interromper a sua aprendizagem. Não se esqueça de que obter a certificação é apenas o primeiro passo.

  No espírito de «inspecionar e adaptar» que aprendeu no framework Scrum, continua a ser seu dever e responsabilidade experimentar, observar e aprender continuamente.

• Não existe uma solução universal para todas as organizações do mundo. O framework Scrum de desenvolvimento e entrega de software não é exceção.

  Observámos que a maioria das organizações que não conseguia obter o melhor desempenho do framework Scrum tinha uma característica comum: não adaptava Scrum aos seus próprios ecossistemas de negócio e TI.

  Por isso, novamente no espírito de «inspecionar e adaptar», não veja o framework Scrum como uma receita de sucesso 100% garantido. Não subestime a sua capacidade de o adaptar à dinâmica específica do seu negócio e das TI. Como profissional remunerado, é precisamente isso que deve fazer para obter o melhor volume de trabalho concluído e os melhores resultados de negócio com o framework Scrum.

• O Scrum não resolveu todos os problemas dos nossos departamentos de TI. Continue se desenvolvendo com processos emergentes de desenvolvimento e entrega de software, como DevOps.

  Para compreender melhor as limitações conhecidas do framework Scrum e a forma como DevOps as aborda, consulte mais tarde este artigo de referência: Quais são as 6 principais diferenças entre DevOps e Scrum?

Em conclusão, uma certificação Scrum Master é uma excelente forma de começar a utilizar práticas ágeis de desenvolvimento e entrega de software.

Segundo um estudo da Gartner “Becoming a Better Scrum Master” publicado em 2019, o artigo previa para 2023 que 92% das empresas do mundo e 96% das empresas dos Estados Unidos adotariam práticas ágeis Scrum. Esta é a previsão relatada no artigo original, não uma taxa de adoção atual medida.

Portanto, não haverá momento melhor do que agora para você

• Comece a aprender gratuitamente o framework Scrum e
• Obtenha a certificação Scrum Master com os preços muito acessíveis do International Scrum Institute™.

A única pergunta que resta é: quando você vai começar?