APOSTILA UNIDADE 04

Prévia do material em texto

CRIATIVIDADE, IDEAÇÃO ECRIATIVIDADE, IDEAÇÃO E
RESOLUÇÃO DE PROBLEMASRESOLUÇÃO DE PROBLEMAS
METODOLOGIAS ÁGEISMETODOLOGIAS ÁGEIS
DE GERENCIAMENTO DEDE GERENCIAMENTO DE
PROJETOS - SCRUMPROJETOS - SCRUM
Autor: Esp. Anderson Ol iveira
Reviso r : Ra fa e l Ara ú jo
INICIAR
introduçãoIntrodução
Na economia globalizada, a velocidade das ações a serem tomadas precisa
acompanhar o timing esperado pelas empresas, e o planejamento não pode
fugir desse princípio. Na década de 1990, quando iniciou o desenvolvimento
em massa de softwares para as grandes companhias, Je� Sutherland e Ken
Schwaber identi�caram que o planejamento tradicional de projetos já não
era tão e�ciente quanto o mercado exigia, especialmente no tocante aos
prazos que precisavam ser cumpridos para a entrega dos produtos. E como
os clientes não percebiam de imediato os resultados do planejamento, que
durava muito tempo, a proposta de valor se perdia. Para tanto, eles
desenvolveram uma metodologia de planejamento e execução de projetos
que tinham um claro propósito: oferecer ao cliente a percepção do valor do
projeto a ser entregue, num curto espaço de tempo. Surgia assim o Scrum.
Como diz o próprio Sutherland, o Scrum pode ser de�nido como “A arte de
fazer o dobro, na metade do tempo”. Vamos conhecer melhor essa
metodologia e suas aplicações a partir de agora!
Nos dias atuais as transformações são muito rápidas, especialmente devido
ao �uxo incessante de informações e às transformações político-econômicas,
como o surgimento de novos mercados, produtos, concorrentes e até
modelos de negócio baseados no avanço tecnológico acessível a todos.
Nesse sentido, as empresas, para obterem sucesso, precisam ser resilientes
nos processos de gestão, buscando a adaptação aos cenários desfavoráveis,
a agilidade nos processos, e um planejamento que busque estratégias para
atender às suas necessidades. É nesse sentido que o gerenciamento de
projetos busca oferecer uma possibilidade de atingir as metas esperadas.
Com isso, busca-se a melhoria nos processos de gerenciamento de projetos,
dada a importância do tema na gestão organizacional. Para tanto, existem
diversas fontes de conhecimento, habilidades e ferramentas para produzir
resultados interessantes para agir em resposta às mudanças o mais
e�cientemente possível.
O gerenciamento de projetos como um estudo formal que leva as
organizações a obterem resultados positivos iniciou-se a partir da fundação
O GerenciamentoO Gerenciamento
de Projetosde Projetos
do PMI – Project Management Institute – que desenvolveu estudos no campo
do gerenciamento de projetos que culminou na criação de um livro que lista
um conjunto de “boas práticas” em gestão, chamado PMBoK – Project
Management Book of Knowledge.
O modelo proposto pelo PMBoK não pode ser considerado de fato uma
metodologia, visto que não precisa ser cumprido “à risca” para proporcionar
os resultados esperados, mas oferece premissas que os projetos
desenvolvidos pelas empresas mais renomadas no mercado mundial
cumpriram e obtiveram resultados excelentes em seus projetos. O modelo
proposto pelo livro traz a conexão entre 10 áreas do conhecimento (6ª edição
– integração, escopo, cronograma, custos, qualidade, recursos,
comunicações, riscos, aquisições, partes interessadas) que regulam e
associam todos os passos durante o ciclo de vida do projeto, atribuindo
responsabilidades, recursos, prazos e �uxos de comunicações bem de�nidos,
com o objetivo de atender os requisitos de�nidos no escopo para cumprir as
necessidades dos stakeholders (partes interessadas no projetos. De�ne-se
partes interessadas quaisquer pessoas que possam impactar ou serem
impactadas pelo projeto).
O gerenciamento de projetos baseado nas boas práticas oferece uma
assertividade na execução que evidencia sua relevância no planejamento de
soluções para as empresas. Entretanto, apesar das inúmeras vantagens, a
aplicação das ferramentas do PMBoK tem algumas desvantagens, onde a
principal delas advém do conjunto demasiado grande de processos em sua
aplicação. Exatamente por esse motivo, a sua aplicação em alguns casos
especí�cos já não atendia às expectativas de agilidade em seu
desenvolvimento.
Nesse viés, as metodologias ágeis de gerenciamento de projetos ganharam
força em seu desenvolvimento de projetos de software, devido à necessidade
de velocidade na resposta aos clientes. E dada a sua e�cácia nesses casos,
passaram a ter sua aplicação difundida nos mais diversos âmbitos do
planejamento. Assim, a partir do manifesto ágil a metodologia passou a ser
estruturada e organizada. O manifesto ágil é um documento que organiza as
premissas básicas de uma �loso�a que prega a diminuição dos processos
buscando uma maior agilidade na entrega dos projetos aos clientes.
Atualmente, a metodologia de gerenciamento de projetos ágeis mais
conhecida é o Scrum.
Diferenças Entre as Metodologias:
Tradicional x Ágil
Ambas metodologias são relevantes e possuem características semelhantes
em diversos pontos, porém divergem em tantos outros, o que nos faz
precisar avaliar qual delas (ou se até ambas) pode(m) ser utilizada(s) para
produzir o resultado mais satisfatório para o projeto que desejamos
desenvolver.
No método tradicional de gestão (o método mais rígido, proposto pelo PMI
no guia PMBoK), o objetivo é concluir todo o projeto para que haja a
percepção de valor por parte do cliente, ou seja, apenas o projeto �nalizado é
passível de ser avaliado. Já na metodologia ágil, uma das premissas básicas é
a subdivisão das metas a serem atingidas, de�nidas como “entregáveis”. Tal
fato faz com que o cliente possa perceber as funcionalidades, como uma
espécie de “degustação” do resultado �nal do projeto, que vai sendo
construído como um quebra-cabeças, e cada fase do projeto agrega valor
para o cliente.
Outra característica que diferencia as metodologias de gestão toca no fato
que abrange o custo do projeto. A metodologia tradicional preconiza durante
a fase de planejamento seja estabelecido um orçamento prévio e as margens
de erro, especialmente de�nidas (na maioria dos casos) como um dos
critérios de aceitação e qualidade do projeto. Na metodologia ágil, na
maioria dos casos, o escopo é muito aberto e passível a mudanças, o que faz
com que as expectativas de custo �quem distantes daqueles planejados no
início do projeto.
No que tange aos processos, na metodologia tradicional há uma maior
rigidez nos passos a serem cumpridos, no escopo de�nido, gerenciamento
do tempo e recursos, o que faz com que o gerenciamento passe por menos
mudanças. Na metodologia ágil os processos são mais abertos, suscetíveis
às mudanças.
As equipes partícipes de projetos baseados na metodologia tradicional
costumam ser maiores e mais heterogêneas, com papéis e
responsabilidades distintas, competências e habilidades diversas e
hierarquias bem de�nidas. As responsabilidades desses pro�ssionais estão
ligadas à execução do seu trabalho em si, não sendo cobrados pelos
resultados �nais do projeto. Na gestão ágil, as equipes tendem a ser mais
enxutas, multidisciplinares e autogerenciadas. Cada pro�ssional tem
responsabilidades múltiplas, e comprometidos diretamente com o resultado
�nal do projeto.
Em geral, não existe metodologia certa nem errada para a aplicação no
gerenciamento de um determinado projeto. O correto é um planejamento
que contemple as necessidades do projeto, especialmente no que tange ao
atendimento às demandas do cliente, principal stakeholder do projeto (CRUZ,
2018).
praticarVamos Praticar
A metodologia Scrum desenvolvida por Je� Sutherland e Ken Schwaber é uma
proposta de gerenciamento de projetos de maneira mais rápida e sistemática, com
atividades altamente caracterizáveis e com uma proposta clara e objetiva. Assinale
a alternativa que traz a proposta da metodologia Scrum.
a) Gestão heterogênea.
b) Mais processos.
c) Proposta de valor.
d) Rigidez.
e) Boas práticas.
Uma de�nição resumida do Scrum pode ser apresentada como uma
metodologia ágil para proporcionar o desenvolvimento de projetos nosquais
as equipes trabalhem em sinergia para atingir os objetivos propostos. A
metodologia é baseada no preceito de que o cliente enxerga melhor o valor
do projeto quando recebe “pequenos produtos utilizáveis”. E para alcançar
esse objetivo, a metodologia propõe que a equipe de pro�ssionais precisa
ser autônoma, promovendo uma cultura de autogestão, ou seja, cada
membro da equipe está comprometido com o seu “entregável”.
É fundamental para o �uxo correto dos processos uma estratégia de
gerenciamento chamada “gestão à vista” onde os processos precisam ser
visualmente conhecidos para avaliar seu progresso, até mesmo para garantir
o engajamento de todos em prol do resultado �nal, além de evidenciar
gargalos e falhas nos processos preestabelecidos.
Outra premissa atribuída ao desenvolvimento de projetos via Scrum é que os
prazos para a concretização dos chamados “entregáveis” sejam curtos e
críveis, de forma que as medições do projeto aconteçam em intervalos de
Metodologia ScrumMetodologia Scrum
tempo que não passem do horizonte de “alguns dias”. As entregas precisam
ser comunicadas à equipe sempre que as medições forem aceitas pelo
cliente, fomentando o espírito de engajamento da equipe em prol do
resultado �nal.
Além das características apresentadas, ainda existe mais uma que é
fundamental para a e�ciência da aplicação do Scrum: a tendência de
adaptar-se a novas realidades apresentadas pelo ambiente ou exigências
advindas do cliente. Ou seja, as mudanças nos projetos executados via
metodologia Scrum são altamente resilientes no que diz respeito às
mudanças no projeto, cujos processos são muito menos rígidos (em
comparação com a metodologia tradicional do PMI).
Os estudos da metodologia Scrum foram iniciados por Je� Sutherland e Ken
Schwaber, que desenvolveram um documento que norteia a aplicação do
framework nas mais diversas aplicações, cujo propósito, declarado no Scrum
Guide (2013) é contribuir na elaboração e manutenção de produtos
complexos. O guia do Scrum atribui e de�ne os papéis, eventos, artefatos e
as regras do Scrum (SUTHERLAND; SCHWABER, 2013).
De acordo com Sutherland e Schwaber (2013, p. 3), a de�nição formal do
Scrum é “um framework dentro do qual pessoas podem tratar e resolver
problemas complexos e adaptativos, enquanto produtiva e criativamente
entregam produtos com o mais alto valor possível”.
A metodologia foi desenvolvida com o intuito de ser leve, simples de
entender e difícil de dominar. Ainda de acordo com os autores, o Scrum não
pode ser associado a um processo ou técnica para construir produtos. É um
framework aberto, que pode ser associado a diversas técnicas e ferramentas
para seu desenvolvimento. O Scrum tem por objetivo evidenciar a e�cácia
dos processos de gerenciamento de projetos, apresentando um potencial
solução para melhorá-los (SUTHERLAND; SCHWAlBER, 2013).
Teoria da Aplicação do Scrum
O Scrum é uma metodologia que utiliza processos empíricos em sua
estruturação básica. Ou seja, muitos dos conhecimentos aplicados no seu
desenvolvimento são construídos sobre o alicerce da experiência prévia e da
tomada de decisão em cima de lições aprendidas, visto que o Scrum utiliza
uma estrutura iterativa, isto é, seu desenvolvimento é construído em cima de
ciclos de produção incremental, para re�nar os resultados esperados e
reduzir os riscos, apoiados em 3 pilares básicos: transparência, inspeção e
adaptação (SUTHERLAND; SCHWABER, 2013).
Sobre a transparência, a aplicação do Scrum preconiza que os principais
passos e resultados precisam estar acessíveis, especialmente aqueles que
dizem respeito aos principais stakeholders. Entretanto, essa acessibilidade
requer alguns padrões comuns para que todos possam obter o mesmo nível
de entendimento sobre o que está sendo apresentado. Já no que tange às
inspeções, faz-se necessário que, em intervalos de tempo regulares, os
usuários (alguns dos principais stakeholders do projeto) precisam
acompanhar o desenvolvimento dos “artefatos”, documentos que constituem
o planejamento e execução do projeto, com o intuito de procurar
“discrepâncias” entre o planejado e o executado. Essa veri�cação ativa é
fundamental para o re�namento do produto �nal, e precisa ser executado
por especialistas, pois os feedbacks são essenciais para as melhorias,
evidenciando os erros e potenciais ajustes. A adaptação busca realizar os
ajustes, o mais rápido possível para evitar os erros em cascata no projeto. Na
ocasião da inspeção, caso algum processo não esteja adequado com a sua
usabilidade, pode ser ajustado ou realinhado em seu propósito. Conforme
será descrito posteriormente, as inspeções ocorrerão nos eventos formais
em 4 instantes: reunião de planejamento do sprint; reunião diária; reunião de
revisão do sprint; retrospectiva do sprint (SUTHERLAND; SCHWABER, 2013;
SABBAGH, 2014).
O �uxo dos processos da aplicação do framework Scrum pode ser visto na
Figura 4.1. 
A metodologia, até mesmo por conta de sua construção, utiliza vários termos
especí�cos, a maioria deles em inglês, que possuem reconhecimento
mundial e, justamente por esse motivo, serão aqui apresentados.
praticarVamos Praticar
A metodologia Scrum desenvolvida por Je� Sutherland e Ken Schwaber é uma
proposta de gerenciamento de projetos de maneira mais rápida e sistemática, com
atividades altamente caracterizáveis e com uma proposta clara e objetiva,
alicerçada em 3 pilares fundamentais. Assinale a alternativa que apresenta os 3
pilares fundamentais corretamente.
a) Transparência, inspeção e adaptação.
b) Time Scrum, eventos e artefatos.
c) Proposta de valor, boas práticas e framework.
Figura 4.1 - Fluxo de processos da metodologia Scrum 
Fonte: Aleksandra Sabelskaia / 123RF.
d) Backlog do produto, Backlog da Sprint e incremento.
e) Product Owner, Scrum Master e time de desenvolvimento.
O time Scrum é o conjunto de pessoas que planejam, orientam, desenvolvem
e executam o planejamento do projeto através da metodologia Scrum.
Sutherland e Schwaber (2013) dividem a equipe de trabalho de aplicação do
framework em:
Product Owner;
Time de desenvolvimento;
Scrum Master.
A grande premissa para o bom funcionamento da metodologia é a
capacidade de autogerenciamento do time Scrum, além da mobilidade
funcional entre os participantes, dada a multifuncionalidade deles. Esses
times autogerenciáveis determinam as melhores ferramentas a serem
utilizadas no desenvolvimento da metodologia, característica avessa ao
planejamento tradicional (onde as ações a serem tomadas seguem um �uxo
claro de hierarquia, geralmente o sponsor ou patrocinador é o responsável).
Outra característica importante dessas equipes é que cada membro possui
clara responsabilidade sobre suas ações, então todos precisam possuir as
Time ScrumTime Scrum
habilidades e competências necessárias para executar as suas ações
independentemente de qualquer pessoa fora do time Scrum. A metodologia
impõe a utilização dessa estrutura para disseminar a cultura de �exibilidade,
criatividade e produtividade (SUTHERLAND; SCHWABER, 2013).
A proposta clara da formação do time Scrum é oferecer o desenvolvimento
de soluções de maneira iterativa e incremental, aproveitando o feedback
gerado ao longo do processo para retroalimentação. Os entregáveis,
produtos ou parcelas utilizáveis do produto �nal têm a missão de oferecer a
experiência da utilização de funcionalidades do resultado �nal,
proporcionando a valorização contínua do projeto (SUTHERLAND; SCHWABER,
2013).
Vamos apresentar agora, cada um dos “membros” do time Scrum.
Product Owner
O “dono do produto” é o maior responsável pela proposta de valor do projeto
via metodologia Scrum. Possui a missão de explorar todo o potencial do time
de desenvolvimento, com a utilização de diversas ferramentas para atingir
seu objetivo. Também é responsabilidade do Product Owner o
gerenciamento do Backlog do produto (cuja de�nição será apresentada
posteriormente). Segundo Sutherland e Schwaber (2013, p. 5), a
responsabilidade do Product Owner sobre o gerenciamento do Backlog do
produto inclui:Expressar claramente os itens do Backlog do Produto;
Ordenar os itens do Backlog do Produto para alcançar melhor as
metas e missões;
Garantir o valor do trabalho realizado pelo Time de
Desenvolvimento;
Garantir que o Backlog do Produto seja visível, transparente, claro
para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
Garantir que o Time de Desenvolvimento entenda os itens do
Backlog do Produto no nível necessário.
O papel do Product Owner, apesar de, em vários casos atuar sob os
propósitos de uma empresa ou um comitê, é executado sempre por apenas
uma pessoa, responsável direto pelas ações a serem tomadas sob sua área
de competência. Entretanto, as ações sob sua responsabilidade podem ser
executadas por outrem, sob seu controle. É imprescindível que o Product
Owner conquiste o respeito de toda equipe sobre as suas decisões, sem as
quais não será possível obter sucesso em seu gerenciamento. Todas as suas
decisões são evidenciadas no conteúdo e nas etapas de priorização do
Product Backlog. Suas decisões são soberanas sobre as dos demais
membros do time (time de desenvolvimento e Scrum Master), especialmente
no que tange às prioridades de execução (SUTHERLAND; SCHWABER, 2013).
Time de Desenvolvimento
(Development Team)
O time de desenvolvimento do Scrum é o conjunto de pessoas que executam
o trabalho que constrói os “entregáveis”, que segundo o framework Scrum são
chamados de Pronto ou DoD (De�nition of Done), sempre que um Sprint é
�nalizado. Somente os membros do time de desenvolvimento possuem a
responsabilidade de elaborar os incrementos, e exatamente por esse motivo,
os membros estão aptos a gerir seu próprio trabalho, devidamente
autorizados a tomarem as decisões necessárias para cumprir a sua missão. A
efetividade do processo de gerenciamento é garantida pela sinergia entre os
membros do time (SUTHERLAND; SCHWABER, 2013).
Segundo os autores do Guia do Scrum (SUTHERLAND; SCHWABER, 2013, p. 6),
as responsabilidades do time de desenvolvimento são:
Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master)
diz ao Time de Desenvolvimento como transformar o Backlog do
Produto em incrementos de funcionalidades potencialmente
utilizáveis;
Times de Desenvolvimento 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 do Time de Desenvolvimento
podem ter habilidades especializadas e área de especialização, mas
a responsabilidade pertence ao Time de Desenvolvimento como um
todo; e,
Times de Desenvolvimento não contêm subtimes dedicados a
domínios especí�cos de conhecimento, tais como teste ou análise de
negócios.
Outra questão relevante sobre o time de desenvolvimento trata sobre o
tamanho da equipe. A quantidade de membros do time precisa ser de uma
abrangência tal que seja su�ciente para atender às demandas do projeto e
garantir as entregas no �nal do Sprint, porém não pode ser demasiadamente
grande para garantir a agilidade dos processos. De acordo com o Guia do
Scrum (SUTHERLAND; SCHWABER, 2013), usualmente os times têm entre 3 e 9
colaboradores, excluindo-se o Scrum Master e o Product Owner. Nos casos
onde eles também executam o papel de membro do time de
desenvolvimento, eles entram na conta do time.
Scrum Master
O papel do pro�ssional que ocupa a função de Scrum Master no framework é
garantir que a metodologia seja compreendida por todos os membros do
Time Scrum. É da sua responsabilidade garantir o cumprimento dos papéis e
responsabilidades do Time Scrum, e as práticas comuns à metodologia,
como as entregas dos artefatos, o cumprimento dos eventos e as de�nições
de Pronto (DoD). O Scrum Master também tem o papel de avaliar
(especialmente durante as inspeções) as iterações desnecessárias e os erros
nos processos, evidenciando o valor oferecido pelo produto construído via
Scrum (SUTHERLAND; SCHWABER, 2013).
O Scrum Master trabalha no apoio e lida diretamente com 3 stakeholders do
projeto: Product Owner, Time de desenvolvimento e Organização. De acordo
com Sutherland e Schwaber (2013, p. 7) a relação entre o Scrum Master e
cada um deles estão listados como segue:
Scrum Master x Product Owner
Encontrar técnicas para o gerenciamento efetivo do Backlog do
Produto;
Claramente comunicar a visão, objetivo e itens do Backlog do
Produto para o Time de Desenvolvimento;
Ensinar o Time Scrum a criar itens de Backlog do Produto de forma
clara e concisa;
Compreender em longo prazo o planejamento do Produto no
ambiente empírico;
Compreender e praticar a agilidade; e,
Facilitar os eventos Scrum conforme exigidos ou necessários.
Scrum Master x Time de desenvolvimento:
Treinar o Time de Desenvolvimento em autogerenciamento e
interdisciplinaridade;
Ensinar e liderar o Time de Desenvolvimento na criação de produtos
de alto valor;
Remover impedimentos para o progresso do Time de
Desenvolvimento;
Facilitar os eventos Scrum conforme exigidos ou necessários; e,
Treinar o Time de Desenvolvimento em ambientes organizacionais
nos quais o Scrum não é totalmente adotado e compreendido.
Scrum Master x Organização:
Liderar e treinar a organização na adoção do Scrum;
Planejar implementações Scrum dentro da organização;
Ajudar funcionários e partes interessadas a compreender e tornar
aplicável o Scrum e o desenvolvimento de produto empírico;
Causar mudanças que aumentam a produtividade do Time Scrum;
e,
Trabalhar com outros Scrum Masters para aumentar a e�cácia da
aplicação do Scrum nas organizações.
Assim, evidenciamos os papéis e responsabilidades do Time Scrum,
responsáveis diretos pelo planejamento, controle e execução do framework.
Agora apresentaremos os eventos preconizados pela metodologia Scrum,
fundamentais na sua construção. 
As atividades realizadas durante a execução do framework Scrum visam
oferecer a agilidade necessária para a execução do projeto como um todo.
Para tanto, a metodologia visa construir rotinas para o seu desenvolvimento,
de forma a evitar pausas desnecessárias, especialmente as reuniões
improdutivas ao longo do projeto. Todos os eventos executados ao longo da
execução do Scrum acontecem com uma duração especí�ca (time-boxed).
Também durante o planejamento, o Sprint (será apresentada a sua de�nição
logo em seguida) terá a duração do seu ciclo fechado, de tal maneira que não
poderá ser alterada ao longo do projeto. Todos os demais eventos poderão
ser encerrados assim que o objetivo �nal do projeto for atingido
(SUTHERLAND, SCHWABER, 2013).
A lista de eventos do Scrum abrange, além do Sprint, que se subdivide em
alguns outros subeventos, a Reunião de planejamento do Sprint (Sprint
Planning Meeting), a Reunião diária (Daily meeting), Revisão do Sprint (Sprint
Review) e Retrospectiva do Sprint (Sprint Retrospective). A partir da ocasião de
cada um desses eventos, evidencia-se uma oportunidade de inspecionar o
planejamento e restaurar o seu rumo, na ocasião de erros. A proposta da
Eventos ScrumEventos Scrum
realização dos eventos visa oferecer uma maior transparência da execução e
a possibilidade de uma auditoria criteriosa das atividades (SUTHERLAND;
SCHWABER, 2013).
Apresentaremos a seguir cada um dos eventos realizados ao longo do
desenvolvimento do framework Scrum.
Sprint
O Sprint é o principal evento da metodologia Scrum. É o intervalo de tempo
(normalmente cerca de um mês), no qual um produto “Pronto” (DoD) é
entregue. Ou seja, uma parte da solução �nal já pode ser avaliada pelo
usuário do produto/serviço. Durante a execução do Sprint, os demais eventos
são executados, para garantir o cumprimento do planejamento, além da
execução realizada pelo time de desenvolvimento.
De acordo com Sutherland e Schwaber (2013, p. 8), durante a execução do
Sprint:
Não são feitas mudanças que possam pôr em perigo o objetivo do
Sprint;
As metas de qualidade nãodiminuem; e,
O escopo pode ser clari�cado e renegociado entre o Product Owner
e o Time de Desenvolvimento quanto mais for aprendido.
O planejamento do Sprint não contempla prazos (time-box) maiores do que 1
mês, visto que uma das propostas do framework é a adaptação às mudanças,
e nesse intervalo de tempo, muita coisa pode mudar o planejamento, até
mesmo por que cada Sprint têm no seu planejamento, as atividades a serem
realizadas para atingir o objetivo do Sprint, o trabalho executado e o “pronto”
a ser entregue. Os riscos também aumentam e a previsibilidade do resultado
diminuem, reduzindo sua efetividade.
Durante a execução de um Sprint, apenas um membro do Time Scrum possui
a autoridade de cancelar a sua execução antes do �nal do prazo
preestabelecido: O Product Owner. Sua ação (cancelar) pode ser motivada
por outros interesses, mas durante a aplicação da metodologia, a decisão só
poderá ser tomada pelo Product Owner. As ocasiões que levam ao
cancelamento do Sprint são poucas, mas a principal delas é quando o Sprint
já não conseguirá atender a expectativa do usuário �nal do produto. Isso
ocorre em muitos casos devido ao próprio avanço tecnológico, às condições
mercadológicas ou se a própria organização já não possui o mesmo
processo gerencial. Em resumo, o Sprint deve ser cancelado quando o
propósito ao qual ele se destina se extinguiu. Na ocasião do cancelamento,
os artefatos resultantes do processo (Backlog do produto e “Pronto”) são
revisados para avaliar se o trabalho poderá ser aproveitado, e essa
aprovação é realizada pelo Product Owner (KNAPP; ZERATSKY; KOWITZ, 2017).
Reunião de Planejamento do Sprint
(Sprint Planning Meeting)
A reunião de planejamento do Sprint é realizada no início do seu
desenvolvimento, e visa elencar as atividades que serão realizadas no Sprint.
Tem duração estimada de 2h para cada semana de trabalho do Sprint
(Conforme falamos anteriormente, os tempos “time-box” são rigorosamente
de�nidos, de forma a evitar desperdício de tempo com reuniões
desnecessariamente longas). Esse controle rígido do time-box da reunião é
papel do Scrum Master.
De acordo com Sutherland e Schwaber (2013, p.9), a reunião de planejamento
do Sprint precisa responder às seguintes questões:
O que pode ser entregue como resultado do incremento do próximo
Sprint?
Como o trabalho necessário para entregar o incremento será
realizado?
O planejamento do Sprint visa de�nir alguns pontos de alinhamento da sua
execução e controle:
O que será executado e entregue como “Pronto” do Sprint;
Quais os critérios de execução do “Pronto”;
Objetivo ou meta do Sprint.
A reunião de planejamento do Sprint é fundamental para que o time de
desenvolvimento possa entender como e quais atividades deverão ser
executadas prioritariamente para cumprir o incremento planejado para esse
Sprint. Essa reunião auxilia também no estabelecimento de metas do projeto.
Reunião Diária (Daily Meeting)
O evento Reunião diária (em muitos locais também é conhecido como Stand-
up meeting, pois em vários casos, a reunião diária acontece com os membros
de pé, para evitar o prolongamento desnecessário) do framework Scrum é
realizado diariamente, com tempo de�nido de 15 minutos (Controlado pelo
Scrum Master) para avaliar as atividades executadas no dia anterior,
corrigindo possíveis erros ou discrepâncias no planejamento anterior e
planejar as atividades que serão executadas no dia de trabalho. Possui uma
característica interessante para aumentar a produtividade: todos os dias, no
mesmo horário e local.
Segundo Sutherland e Schwaber (2013, p. 11) durante a reunião diária os
membros do time de desenvolvimento buscam esclarecer:
O que eu �z ontem que ajudou o Time de Desenvolvimento a
atender a meta do Sprint?
O que eu farei hoje para ajudar o Time de Desenvolvimento a
atender a meta do Sprint?
Eu vejo algum obstáculo que impeça a mim ou o Time de
Desenvolvimento no atendimento da meta do Sprint?
A principal motivação da reunião diária é inspecionar o desenvolvimento do
framework em prol do “Pronto” de�nido no Planejamento do Sprint, pois
evidencia as divergências entre o “planejado x realizado” e visa distribuir as
atividades para que os membros possam reparti-las para retomar o
planejamento. Por isso mesmo a reunião é totalmente voltada para o time de
desenvolvimento, visto que todos os membros do grupo possuem as
competências e habilidades para desenvolver todas as etapas da construção
do pronto. Essa característica não pode ser dissociada de um time
autogerenciável, competência básica dos times de desenvolvimento. O
Scrum Master regula as ações, mas não interfere na reunião, visto que é
voltado para o time, também evitando que haja interferências de outras
pessoas de fora do time (como o Product Owner, por exemplo). As reuniões
diárias além dos objetivos supracitados ainda reforçam o sentimento de
unidade do time, melhoram a comunicação, eliminam ruídos e evidenciam
as barreiras para o desenvolvimento, melhorando a capacidade de tomada
de decisão (SUTHERLAND; SCHWABER, 2013).
Revisão do Sprint (Sprint Review)
O evento Revisão do Sprint (Sprint Review) tem o objetivo de inspecionar a
iteração para veri�car o incremento realizado, para ajustar o Backlog do
produto caso não esteja de acordo com o planejado. A Revisão do Sprint é
realizada ao �nal do “time-box” do Sprint, e conta com todo o time Scrum
(Scrum Master, Product Owner e Time de desenvolvimento) e os principais
stakeholders para identi�car oportunidades de melhoria para o processo e
garantir a proposta de valor do framework. A Revisão do Sprint, cuja proposta
é engajar ainda mais os participantes do projeto, obter feedbacks e incentivar
a colaboração, é um evento informal no processo de desenvolvimento da
metodologia e possui uma duração estimada de 1h para cada semana do
time-box do Sprint (controlado rigidamente pelo Scrum Master).
Como proposto por Sutherland e Schwaber (2013, p.12), a reunião de revisão
do Sprint precisa abordar os seguintes elementos:
Os participantes incluem o Time Scrum e os Stakeholders-chaves
convidados pelo Product Owner;
O Product Owner esclarece quais itens do Backlog do Produto foram
“Prontos” e quais não foram “Prontos”;
O Time de Desenvolvimento discute o que foi bem durante o Sprint,
quais problemas ocorreram dentro do Sprint, e como esses
problemas foram resolvidos;
O Time de Desenvolvimento demonstra o trabalho que está
“Pronto” e responde às questões sobre o incremento;
O Product Owner discute o Backlog do Produto tal como está. Ele (ou
ela) projeta as prováveis datas de conclusão baseado no progresso
até a data (se necessário);
O grupo todo colabora sobre o que fazer a seguir, e é assim que a
Reunião de Revisão do Sprint fornece valiosas entradas para a
Reunião de Planejamento do próximo Sprint;
Análise de como o mercado ou o uso potencial do produto pode ter
mudado e o que é a coisa mais importante a se fazer a seguir; e,
Análise da linha do tempo, orçamento, potenciais capacidades, e
mercado para a próxima versão esperada do produto.
O principal produto da reunião de retrospectiva do Sprint é a melhoria do
Backlog do produto que será executado no Sprint seguinte.
Retrospectiva do Sprint (Sprint
Retrospective)
O evento Retrospectiva do Sprint (Sprint Retrospective) é executado pelo time
Scrum sempre entre a reunião de revisão do Sprint e o planejamento do
próximo Sprint, com o objetivo de promover uma auditoria nos processos,
inspecionando-se com o intuito de planejar as melhorias potencialmente
aplicáveis nos próximos Sprints. Tem duração estimada de 1,5 h para cada
semana de execução do Sprint. Durante a reunião, o Scrum Master, membro
responsável pela aplicação do framework, deverá utilizar todo o seu
conhecimento sobre a metodologia para incentivar e engajar a equipe na
execução, evidenciando as vantagens da sua aplicação. A �uidez do processo
é essencial para o propósito da metodologia, e o Scrum Master possui a
responsabilidade de evidenciá-la. Para isso, durante a retrospectiva, ele
deverá enxergar os pontosfalhos que podem ser melhorados, para serem
implementados nos próximos Sprints. Como um time autogerenciável, o time
Scrum precisa melhorar-se continuamente, e é na retrospectiva do Sprint que
esse ciclo �ca evidente.
O propósito da reunião de retrospectiva do Sprint é (SUTHERLAND;
SCHWABER, 2013, p. 13):
Inspecionar como o último Sprint foi em relação às pessoas, aos
relacionamentos, aos processos e às ferramentas;
Identi�car e ordenar os principais itens que foram bem e as
potenciais melhorias; e,
Criar um plano para implementar melhorias no modo que o Time
Scrum faz seu trabalho.
Os artefatos produzidos ao longo da execução do framework são os
“entregáveis” desenvolvidos para representar o valor do projeto ao usuário
�nal, ou para oferecer ao time Scrum a oportunidade de se autoavaliar ou
readaptar. São prioritariamente desenvolvidos para evidenciar a
transparência do framework e precisam ser de fácil entendimento para todos
os stakeholders. Dentre os artefatos do Scrum podemos listar o Backlog do
produto, Backlog do Sprint e incremento (SUTHERLAND; SCHWABER, 2013).
Backlog do Produto (Product Backlog)
O Backlog do produto (Product Backlog) constitui-se como um conjunto de
funcionalidades a serem cumpridas para atender aos requisitos do usuário
do produto, listando todas as características, rotinas, requisitos e mudanças
realizadas no objeto do estudo. O único responsável pela administração do
Backlog do produto sobre todos os aspectos (conteúdo, ordem e
disponibilidade) é o Product Owner. O Backlog do produto é desenvolvido
inde�nidamente e dinamicamente, na mesma proporção que o produto é
Artefatos do ScrumArtefatos do Scrum
((Scrum ArtifactsScrum Artifacts))
re�nado, a equipe evolui e o ambiente é favorável. A construção do Backlog
do produto é contínua, e ele perdura enquanto o produto ainda existir, visto
que a proposta de valor do Scrum só estará completa a partir da utilização do
produto, e o feedback gerado após a sua utilização deve constar no Backlog
do Produto. O desenvolvimento do produto deve seguir a ordem
determinada pelo Product Owner, e deve contemplar as mudanças
ambientais as quais afetam o diretamente o framework ou seus stakeholders,
e as alterações feitas nos produtos geram incrementos, que devem ser
registrados no Product Backlog. (SUTHERLAND; SCHWABER, 2013).
Visto que o desenvolvimento do Backlog do produto é realizado a cada
incremento no objeto em estudo, para melhor descrever e organizar as
alterações realizadas nele, apresentaremos alguns itens que podem oferecer
um detalhamento (CRUZ, 2018):
Story (estória) – Processo de desenvolvimento de um novo
incremento;
ID – Identi�cação ou código de um incremento realizado no produto.
É realizado para mantermos o controle sobre as alterações
realizadas;
Nome – Atribuição de uma descrição, que possa ser de fácil
compreensão por parte de todos os stakeholders, para o
incremento realizado;
Importância – Criterização (quantitativamente ou qualitativamente)
do incremento por ordem de relevância, por parte do Product
Owner;
Estimativa de conclusão – Duração estimada para concretização do
incremento;
Demonstração dos resultados – Apresentação da rotina de
utilização do incremento após a entrega;
Notas explicativas.
De acordo com o Scrum Guide (SUTHERLAND; SCHWABER, 2013) no processo
de previsão e ajuste do Backlog do produto podem ser utilizadas técnicas
como burndown, burnup, entre outras técnicas de previsão. Entretanto, ainda
não podemos desprezar o efeito do empirismo no processo de melhoria
contínua do Backlog do produto.
Backlog do Sprint
O Backlog do Sprint reúne todos os requisitos do projeto que devem ser
cumpridos naquele Sprint especí�co, além de incluir o plano de execução
para desenvolvimento do incremento e atender as metas do Sprint. É uma
espécie de estimativa realizada pelo time de desenvolvimento sobre os
requisitos que estarão presentes no produto ao �nal do Sprint e o trabalho a
ser realizado, transformando o incremento em um “Pronto”. Ele contém um
planejamento detalhado das atividades que serão apresentadas a cada
reunião diária. O time de desenvolvimento é inteiramente responsável pela
construção, manutenção e cumprimento do Backlog do Sprint, de forma a
cumprir as metas preestabelecidas. O Backlog do Sprint também tem a meta
de garantir a transparência no desenvolvimento do planejamento do Sprint
além de evidenciar potenciais falhas e oportunidades de melhorias
(SUTHERLAND; SCHWABER, 2013).
Incremento
O incremento de um produto pode ser de�nido como o conjunto de todos os
itens constantes no Backlog do produto, bem como o resultado de todos os
Sprints anteriores. Cada Sprint tem como objetivo produzir um incremento
“Pronto” utilizável ainda que não seja liberado pelo Product Owner.
Conforme falado anteriormente, um dos pilares do Scrum é a transparência,
e os seus processos precisam garantir essa virtude. O Scrum Master tem a
obrigação de, em conjunto com os demais membros do time, proporcionar a
transparência dos artefatos, em um trabalho contínuo e incessante, visto que
a tomada de decisão para aumentar o valor e o controle dos riscos
contemplam o estado em tempo real dos artefatos. Entretanto, muitas
decisões erradas podem acontecer, fazendo com que a proposta de valor ao
usuário diminua, aumentando os riscos (SUTHERLAND; SCHWABER, 2013).
Uma das características que mais demandam a transparência do framework
Scrum é a “De�nição de Pronto” (De�nition of Done – DoD). A de�nição de
“Pronto” a�rma o instante no qual um incremento ou algum item do Backlog
do produto atinge esse status para todos os membros da equipe Scrum. Essa
de�nição é essencial na metodologia, pois guia o time de desenvolvimento
sobre quais itens do Backlog do produto poderão ser realizados durante o
“time-box” do Sprint, visto que um “Pronto” precisa oferecer uma versão
“potencialmente utilizável” do produto, e cabe ao Product Owner liberá-lo ou
não. Caso haja mais de um time Scrum trabalhando em um determinado
projeto, todos eles devem compartilhar a mesma de�nição de “Pronto”,
assim que um determinado incremento de�nido como “Pronto”, testado e
liberado, é somado aos demais incrementos já produzidos. É importante
salientar que com o progresso do time Scrum, e a sua metodologia está
altamente compreendida pela organização, os critérios que levam a
“De�nição de Pronto” são mais rígidas e com altos padrões de qualidade.
A apresentação da metodologia evidencia uma característica fundamental
para o desenvolvimento de projetos que envolvem criatividade: a proposta
de valor para o usuário. Por isso que a metodologia Scrum tem sido aplicada
nos mais diversos planejamentos de produtos/serviços com sucesso, porque
propicia um planejamento com menos erros, transparência, menos custos e
tempo para execução, tornando-se uma excelente opção de planejamento
em detrimento do gerenciamento de projetos.
praticarVamos Praticar
Os artefatos são produtos do desenvolvimento do framework Scrum que são
produzidos ao longo de sua execução. O Backlog do produto é um deles, onde
consta o registro de todas as atividades e incrementos realizados ao longo da
execução da metodologia. Em relação ao assunto, assinale a alternativa que
corresponda ao responsável pela gerência do Backlog do produto.
a) Scrum Master.
b) Product Owner.
c) Time de desenvolvimento.
d) Sponsor.
e) Stakeholder.
indicações
Material
Complementar
F ILME
Invictus
Ano: 2009
Comentário: O �lme relata a história real do time de
rugby sul-africano campeão da copa do mundo de
Rugby, em 1995, inspirado pelo líder da libertação do
país que sofria com o apartheid, Nelson Mandela, e
liderado pelo capitão François Pienaar, superando
todas as diferenças e evidenciando o trabalho em
equipe, fundamental para o sucesso. Uma curiosidade:
O termo Scrum origina-se de uma jogada do rugby: o
scrummage.
Para conhecer mais sobre o �lme, acesse o trailer a
seguir.
TRAIL ER
L IVRO
A arte de fazer o dobro na metade do
tempo
Je� Sutherland
Editora: Leya
ISBN: 978-8544104514Comentário: O livro apresenta a experiência de Je�
Sutherland, um dos fundadores do manifesto ágil que
revolucionou os métodos de planejamento, eliminando
os processos burocráticos, evidenciando a proposta de
valor de um projeto.
conclusão
Conclusão
Ao longo do nosso estudo apresentamos a metodologia de gerenciamento
de projetos ágeis chamado Scrum, cujo objetivo essencial é a proposta de
valor que o framework oferece aos seus usuários, apoiada em 3 pilares
básicos: transparência, inspeção e adaptação.
A metodologia é construída a partir do entendimento de 3 entes
fundamentais: Equipe Scrum, eventos e artefatos. A equipe Scrum é
orientada pelo Scrum Master, executada pelo time de desenvolvimento e
aprovada pelo Product Owner. Os eventos do Scrum têm por característica
básica ocorrerem em intervalos de tempo �xos, chamados “time-box” que
são determinados pela duração do Sprint, intervalo de tempo de geralmente
um mês para execução de um “Pronto”. Ao longo do seu desenvolvimento, a
metodologia evidencia a elaboração dos artefatos, que correspondem à
criação e manutenção do Backlog do produto, Backlog do Sprint e os
incrementos.
Diante do exposto, podemos concluir que a metodologia Scrum possui as
características essenciais para apoiar o desenvolvimento de projetos
criativos, devido essencialmente à proposta de valor ao usuário �nal. 
referências
Referências
Bibliográ�cas
CANAZARO, J. V.; COSTA, J. V. da S.; OLIVEIRA, F. M. de. Gerenciamento ágil de
projetos com scrum e kanban: desenvolvendo competências estratégicas na
elaboração de material didático de um curso superior em EAD. REINPEC -
Revista Interdisciplinar Pensamento Cientí�co, v. 5, n. 1, p. 124-139, 2019.
CRUZ, F. Scrum e Agile em Projetos: guia completo. 2. ed. Rio de Janeiro:
Brasport, 2018.
KNAPP, J.; ZERATSKY, J.; KOWITZ, B. Sprint: o método usado no Google para
testar e aplicar novas ideias em apenas cinco dias. Rio de Janeiro: Intrínseca,
2017.
SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. [S.l.]: Casa do
Código, 2014.
SUTHERLAND, J. Scrum: A arte de fazer o dobro na metade do tempo. São
Paulo: Leya, 2016.
SUTHERLAND, J.; SCHWABER, K. The Scrum Guide. The de�nitive guide to
Scrum: The rules of the game. July 2013. Disponível em:
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf.
Acesso em: jan. 2020.
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf