Gerenciamento De Projetos De Software

Prévia do material em texto

PROCESSOS DE 
DESENVOLVIMENTO 
DE SOFTWARE
Ana Luiza Cerchiari de Andrade 
Métodos ágeis
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Descrever o conceito de método ágil.
  Identificar os princípios e valores ágeis.
  Enumerar os principais métodos ágeis existentes.
Introdução
Atualmente, dois cenários impactam a rotina dos desenvolvedores: o 
cenário da big data e o cenário da Internet das Coisas. Profissionais que 
estudam software e atuam na área de desenvolvimento de software, 
sistemas e sites são forçados a implementar tecnologias novas a todo 
momento. A Internet das Coisas fez com que câmeras, smartphones e 
relógios fiquem conectados à internet a todo momento, e as empresas 
veem nisso uma oportunidade para estudar comportamentos através 
dos logs e registros das pessoas nos sistemas. Quem quer que trabalhe 
na área certamente será forçado a adaptar software rapidamente às tec-
nologias que surgem diariamente. Por isso, a rotina dos desenvolvedores 
é recheada de adrenalina.
Em pouco tempo, vimos os sites que possuíam linguagens HTML 4, 
CSS , PHP 5 e JavaScript se tornarem HTML 5 com suas animações, CSS 3, 
com suas decorações extravagantes, PHP 7, com sua agilidade e códigos 
novos, e JavaScript React, Angular e JQuery, trazendo novas formas de 
controlar e manipular os elementos frontais das páginas. Além disso, você 
deve ter percebido que os bancos de dados SQL ganharam a companhia 
dos bancos NoSQL, que chegaram com agilidade para sites que contêm 
muita interação com pessoas. Na criação de software, percebemos que 
o que antes era feito através de Ionic, um framework JavaScript que cria 
aplicativos com plugins, hoje é feito através de React Native, que traz 
experiências mais satisfatórias ao usuário e usa a linguagem nativa dos 
aparelhos mobiles.
Neste cenário, várias formas de planejamento de criação de software 
disputam as decisões das equipes que desenvolvem, e disso surgem 
dúvidas quanto ao critério de escolha do método de desenvolvimento de 
software mais dinâmico e condizente com o tempo em que vivemos. De 
acordo com Sommerville (2011), em 1980, com o surgimento das lingua-
gens de quarta geração, e em 1990, com o surgimento de metodologias 
ágeis, como a Metodologia de Desenvolvimento de Sistemas Dinâmicos 
e a Metodologia Extreme Programming, os desenvolvedores se viram 
forçados a mudar a forma de trabalho. Vamos discutir um pouco sobre 
isso neste capítulo.
1 Conceito de método ágil
O desenvolvimento ágil envolve mudanças rápidas e prioriza-se, às vezes, 
agilidade frente à qualidade — alguns analistas dizem que este método é 
uma resposta ao cenário tecnológico. Após se fazer um planejamento de 
etapas de requisitos, é comum ter que se deparar com mudanças dos próprios 
requisitos, e isso é aceito neste método de desenvolvimento, pois não impos-
sível antever todas as necessidades do mercado, visto que elas mudam com 
frequentemente; em alguns casos, os requisitos mudam depois da entrega do 
projeto (SOMMERVILLE, 2011).
De acordo com Amaral et al. (2012, p. 21) o conceito de ágil pode ser 
visto como: 
[...] é uma abordagem fundamentada em um conjunto de princípios, cujo obje-
tivo é tornar o processo de gerenciamento de projetos mais simples, flexível e 
iterativo, de forma a obter melhores resultados em desempenho (tempo, custo 
e qualidade), menos esforço em gerenciamento e maiores níveis de inovação 
e agregação de valor para o cliente.
O desenvolvimento ágil é feito em equipes multidisciplinares, onde os 
processos são feitos em espiral e as equipes priorizam conversas em detri-
mento da documentação, ou seja, a rigidez é menor. Aqui, é mais importante 
a funcionalidade do software do que a documentação; é mais importante 
satisfazer as necessidades do cliente do que seguir um plano. No método ágil, 
os colaboradores têm perfil motivado, as entregas são semanais e não mensais, 
o que facilita o acompanhamento da satisfação do cliente. Logo, neste modelo, 
as adaptações falam mais alto do que a disciplina, e o processo de criação 
Métodos ágeis2
de software é transparente, o cliente vê tudo, o que ajuda na customização, 
conforme Sommerville (2011). No método ágil, as equipes são pequenas, com 
alto nível técnico, feedbacks constantes, as reuniões são rápidas — duram 
geralmente 15 minutos — e muitas vezes são feitas em pé, e cada reunião 
gera um plano de ação, em outras palavras, um conjunto de atividades a serem 
realizadas em um intervalo de tempo determinado. A maioria dos métodos 
ágeis foi criada na década de 1990, e eles serão explicados mais adiante.
Ferramentas eletrônicas de métodos ágeis
Que tal falarmos sobre ferramentas de gestão? O primeiro passo para criar um 
painel de metodologia ágil é escolher o seu modelo de gestão, estes modelos 
denominados Scrum, Kanban, entre outros, serão explicados posteriormente, 
mas precisamos mencionar que as empresas estão usando preferencialmente 
dois sites: Trello e Jira.
O Trello é uma ferramenta de gestão on-line para métodos ágeis que au-
xilia na organização de tarefas e possui três versões. O Quadro 1 compara as 
três versões desta ferramenta. A primeira é o plano básico, que é gratuito e, 
mesmo assim, permite vários usuários, porém não tem todas as ferramentas 
dos outros planos. A segunda versão do Trello, chamada Business Class, é 
paga e possui, por exemplo, relação com o Github. Hoje muitas empresas de 
tecnologia usam programas como o Github a fim de salvar versões de cada 
alteração do código automaticamente no servidor da plataforma. A terceira 
versão, o plano Enterprise, também é paga e possui muitas ferramentas de 
gerenciamento de acessos a pastas e a convites, entre outras funcionalidades 
administrativas.
3Métodos ágeis
 Fonte: Adaptado de Trello (c2020). 
Plano básico Plano Business Class Plano Enterprise
  Gratuito
  Permite o acesso de 
vários usuários
  Sem limite de 
quadros
  Contempla os itens 
anteriores
  Acesso sincronizado 
a Jira, Slack, Github
  Suporte em até um 
dia útil
  Classificação 
automática de 
quadros de atividade 
em coleções
  Todas as 
características 
anteriores
  Botões, regras 
e comandos 
agendados 
ilimitados
  Notificações por 
e-mail e solicitações 
externas na web
  Controles de 
cada pessoa pela 
administração
  Restrições de criação 
e exclusões de 
pastas
  Restrições de anexo
  Restrições ao convite 
do quadro de equipe
  Gerenciamento de 
usuários em tempo 
real: desativar em 
massa; ativar em 
massa; filtrar por 
última atividade
 Quadro 1. Comparação entre os três planos do Trello 
O Jira também é uma ferramenta on-line de gestão ágil muito usada em 
métodos ágeis. Esta ferramenta é mais complexa que o Trello e possui maior 
processamento e velocidade, seu suporte é muito completo, atende 24 horas 
por dia, e foi desenvolvido para projetos de software.
O Quadro 2 mostra as utilidades do Jira e compara três planos: o básico, 
gratuito, e os demais, Standart e Premium, sendo este último o mais caro.
Métodos ágeis4
 Fonte: Adaptado de Atlassian (c2020). 
Plano básico Plano Standart Plano Premium
  Visualização do 
trabalho da equipe 
em um painel 
customizado, 
seguindo modelos 
de agilidade como 
Scrum e Kanban
  Até 10 usuários
  2 GB de 
armazenamento de 
arquivos
  100 execuções por 
mês
  Suporte da 
comunidade
  Lista de pendências
  Relatórios de 
desempenho de 
equipes
  Todas as 
características 
anteriores
  Até 5 mil usuários
  500 execuções por 
mês
  Suporte em horário 
comercial
  Permissões 
avançadas
  250 GB de 
armazenamento de 
arquivos
  Acesso anônimo
  Log de auditoria
  Todas as 
características 
anteriores
  Até 5 mil usuários
  1.000 execuções por 
mês
  Suporte em 24 horas
  GB ilimitado de 
armazenamento
  Roteiros avançados
  Arquivamento de 
projetos
  Lista de permissões 
por usuário
 Quadro 2. Comparação entre os três planos do Jira 
2 Valores e princípiosem: 3 jun. 2020.
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
11A equipe e sua estrutura em Scrum
PROCESSOS DE 
DESENVOLVIMENTO 
DE SOFTWARE
Clicéres Mack Dal Bianco
Liderança de equipes 
em Scrum
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Reconhecer quais as condições para a auto-organização de equipe 
em um projeto Scrum.
  Explicar como é a liderança de uma equipe auto-organizada em Scrum.
  Descrever a distribuição de várias equipes em um projeto Scrum.
Introdução
Neste capítulo, você verá que projetos ágeis requerem lideranças afinadas 
com a dinâmica ágil, pois as equipes serão estimuladas a se auto-orga-
nizarem, ou seja, a equipe é independente o suficiente para se organizar 
em torno de um problema, com autonomia para decidir quem e como 
criará a solução. Você também verá que a dinâmica autogerenciável só 
será possível se o ambiente permitir. O líder é o responsável por criar 
esse ambiente e influenciá-lo continuamente, a fim de que a eficiência 
da auto-organização perdure durante a execução do projeto. 
Você verá que a liderança poderá conter condições que favorecem 
a auto-organização de equipes em projetos que usam a metodologia 
Scrum. Assim, toda vez que o líder precisar interferir na equipe, poderá 
fazê-lo por meio dessas condições. Você também aprenderá como é a 
liderança de uma equipe auto-organizada.
Finalmente, você verá os desafios dos líderes quando as equipes 
estão em locais geográficos diferentes, quais são fatores e diferenças que 
equipes nessa condição apresentam e o que o líder precisa observar para 
ser facilitador da auto-organização.
1 Condições para auto-organização de equipe
Um fator decisivo para o sucesso do método Scrum em projetos é a capacidade 
auto-organizacional das equipes. Segundo Beck et al. (c2001), as melhores 
arquiteturas, requisitos corretos e alcance de resultados emergem das equipes 
auto-organizadas. Você deve estar se perguntado: O que são equipes auto-
-organizadas? Que diferença fazem as equipes auto-organizadas? Quais as 
condições que infl uenciam a auto-organização? A seguir você encontrará as 
respostas.
Equipes auto-organizadas
O termo auto-organização é amplo e envolve vários sistemas. Esses sistemas 
estão atrelados a fatores endógenos e exógenos que determinam a sua dinâ-
mica — os exemplos vão da física, química, biologia até a neurociência. Por 
exemplo, o cérebro, com os seus neurônios conectados, que constrói modelos 
mentais sem depender de controle único. Florestas com árvores ligadas pelo 
mesmo sistema subterrâneo. Bando de pássaros e rebanho de ovelhas que são 
capazes de se mover juntos de maneira sincronizada. Esses exemplos também 
refl etem ambientes de negócios auto-organizados.
Se você buscar por teorias relacionadas a este tema verá que a auto-
-organização refere-se ao processo que promove um aumento no nível de 
organização, ou do arranjo de uma parte do sistema que pode promover uma 
função específica, sem presença de controle ou manipulação externa ou central, 
conforme descreve Kaltenecker (2015). Afunilando os conceitos para equipes 
auto-organizadas, o autor Drucker (2001) afirma que os profissionais precisam 
se administrar e ter autonomia para desenvolver suas tarefas. Corroborando 
com Drucker (1999), Sahota (2014) discorre que equipes auto-organizadas 
escolhem a melhor forma de realizar seu trabalho, em vez de serem direcio-
nadas por outras pessoas. Uma ideia de auto-organização de equipes também 
foi apresentada em Anderson (1999 apud COHN, 2011). O autor enfatiza que 
a autonomia das equipes não significa que os líderes serão desnecessários e 
que as pessoas estão livres para fazer o que desejarem. Eles terão o papel de 
guiar os comportamentos que surgirão na atuação de um projeto, mas não 
devem antecipar qual seria o comportamento eficaz. 
Outra afirmação relacionada à auto-organização de equipe e seus líderes 
pode ser vista em Cohn (2011). O autor afirma que equipes auto-organizadas 
não estão livres do controle gerencial. A gerência decide por eles que produtos 
Liderança de equipes em Scrum2
serão construídos e pode selecionar quem atuará no projeto, mas as equipes 
se auto-organizarão e não estão livres de sofrer influência.
Um apontamento importante é feito por Kaltenecker (2015). O autor afirma 
que é preciso consciência de que tornar uma equipe auto-organizada não acon-
tece da noite para o dia. Além disso, também não é algo que acontece uma vez 
e permanece para sempre. Uma equipe nunca finaliza a auto-organização; esse 
processo ocorre continuamente de maneira a atender às demandas e ao contexto, 
ou seja, sempre que a configuração muda, a equipe precisa se reorganizar 
para atender a essa configuração. Neste processo, cada membro da equipe 
precisa se auto-organizar elaborando metas e descobrindo como atingi-las. 
Periodicamente, cada membro precisa sincronizar sua auto-organização com 
o restante da equipe. Para tanto são realizadas reuniões regulares, revisões 
de operações ou retrospectivas. A fim de que cada membro consiga se auto-
-organizar, e consequentemente manter a equipe organizada, o ambiente deve 
fornecer algumas condições, que você verá a seguir.
Condições
Você sabe que as equipes autogerenciáveis decidem como fazer e quem vai 
fazer. De acordo com Sahota (2014), a sinergia que resulta desta dinâmica gera 
engajamento entre os membros, melhorando a efi ciência geral da equipe. Para 
que auto-organização aconteça, no entanto, o ambiente deve proporcionar 
algumas condições. De acordo com Cohn (2011) e Kaltenecker (2015), as con-
dições que favorecem a auto-organização são: contêineres, diferenças e trocas. 
  Contêineres-limites (C): envolvem sistemas para definir a identidade. 
Não existe “eu” bem definido sem uma separação clara dos “outros”. 
Pode-se basear em espaços físicos, em estruturas organizacionais, tais 
como missão, visão desafiadora e diretrizes operacionais e políticas 
claras de tomada de decisão.
  Diferenças (D): é fundamental que os integrantes apresentem diferenças, 
como conhecimento, experiência, educação, idade, gênero ou cultura. 
As equipes de alto desempenho sabem como reconhecer e incorporar 
a diversidade da equipe e como aproveitar essa condição que faz a 
diferença.
  Trocas transformadoras (T): orientando as interações dentro da equipe 
e com seu ambiente. A troca de informações, energia ou material entre 
pessoas ou equipes interdependentes é fundamental para a capacidade 
de se auto-organizar de todo o sistema.
3Liderança de equipes em Scrum
De acordo com Cohn (2011), os limites não necessariamente são físicos, 
mas normalmente comportamentais, organizacionais e conceituais: todos que 
trabalham no campus II, todos que trabalham no desenvolvimento, todos os que 
programam Python, todos os franceses, todos os que são da esquipe do projeto.
Ainda segundo Cohn (2011), as diferenças entre as pessoas do contêiner 
também influenciam a forma como elas se auto-organizam. Se não houvesse 
diferenças entre os membros de uma equipe Scrum, não importaria quem 
faz qual trabalho ou se as pessoas interagem; já que seriam todos igualmente 
habilitados em todos os aspectos, cada membro do grupo trabalharia isolada-
mente. Felizmente, sempre há diferenças entre as pessoas de uma equipe de 
desenvolvimento de software. Elas incluem experiência técnica, conhecimento 
do assunto, poder, gênero, raça, educação, conexões com outras pessoas da 
empresa, abordagem de solução de problemas e assim por diante. Os tipos 
e graus dessas diferenças influenciam como uma equipe se auto-organiza.
Finalmente, Cohn(2011) afirma que uma troca é uma interação entre 
membros de um contêiner em que uma ou mais das pessoas é modificada ou 
influenciada por essa interação. Por exemplo, você se reúne com o dono do 
produto de um projeto que responde às perguntas sobre como um requisito 
deve funcionar. Essa é uma troca transformadora porque você sairá com 
novos conhecimentos. Não são apenas informações que são passadas entre as 
pessoas em uma troca transformadora; pode ser dinheiro, poder, estímulo ou 
várias outras coisas. Uma equipe motivada por uma conversa com seu dono 
do produto vivenciou uma troca transformadora: um estímulo foi criado e 
passado para a equipe. E as trocas transformadoras afetam a forma como uma 
equipe se organiza em resposta a um desafio.
Como parte de um sistema maior, cada unidade do modelo CDT depende de 
um contexto de suporte. Pense que as equipes autogerenciáveis são uma planti-
nha e o contexto organizacional é o solo que fornece os nutrientes necessários 
para a planta crescer e produzir frutos. De acordo com Hundermark (2014), o 
suporte contextual para equipes auto-organizadas consiste basicamente em 
quatro subsistemas. 
1. Comunicação: fornece às equipes os dados que os membros precisam 
para planejar e executar com competência seu trabalho.
2. Infraestrutura: em termos de espaço físico apropriado (um fator de 
muita reivindicação das equipes), infraestrutura técnica e dinheiro.
3. Educação: relacionada a qualquer treinamento ou assistência técnica 
que a equipe possa precisar.
Liderança de equipes em Scrum4
4. Recompensa: fornece consequências positivas, econômicas e simbólicas 
para o bom desempenho da equipe.
Voltando ao modelo CDE, observe que a Figura 1, que mostra como con-
têineres, diferenças, trocas e contexto se combinam.
Figura 1. Combinação da condição com o contexto que envolve infraestrutura e 
comunicação.
Fonte: Kaltenecker (2015, p. 14).
A Figura 1 tem um conjunto de elementos, tamanhos, formas e cores dife-
rentes, representando membros da equipe com diferentes experiências, pontos 
fortes e habilidades. As setas de ligação mostram os membros conectados 
entre si, formando uma equipe multidisciplinar que se fortalece pelas trocas e 
comunicações intensas. O limite de toda a interação da equipe é parcialmente 
pontilhado para indicar que esse contêiner é um sistema aberto e não fechado. 
Longe do ambiente ser uma caixa preta clássica, a equipe depende do ambiente; 
ela precisa de um contexto de apoio em termos dos subsistemas indicados 
de infraestrutura e comunicação. Além disso, precisa de um agente externo, 
representado por um símbolo de círculo (amarelo e laranja), responsável por 
esse suporte. Esse é o papel do gerente/líder.
Além disso, a interdependência da equipe, sua conexão em termos de fluxo 
de valor e o foco necessário no cliente e a conscientização organizacional são 
essenciais para qualquer processo de auto-organização.
5Liderança de equipes em Scrum
2 Liderar uma equipe auto-organizada
De acordo com Audy (2015), quando se trata de times auto-organizados, é 
papel do líder criar o substrato que viabilize e proporcione as condições que 
cada time necessita para fazer um bom trabalho, alinhado ao que se espera 
dele. Perceba que o papel da liderança é colocado em voga, assumindo uma 
postura que permita atender a essa expectativa. 
Algumas formas de liderança não se ajustam aos projetos Scrum. Falando 
em formas de liderança, observe a Figura 2, que apresenta uma distinção 
entre liderança tradicional e liderança ágil. Os gerentes/líderes são os círculos 
cinzas, e os demais círculos representam os membros da equipe. As setas 
representam a direção da comunicação, e as linhas em negrito representam a 
frequência da comunicação. Enquanto o modelo clássico se baseia na interação 
unidirecional e o controle individualizado de membros, o modelo de liderança 
ágil tem uma configuração diferente, com membros que fazem parte da rede 
de comunicação (inclusive o líder) guiados por intensa troca de informação 
que permite a tomada de decisão em conjunto e o engajamento de todos.
Fica evidente que as equipes auto-organizadas são mais eficazes do que 
as equipes sob pirâmides de comando e controle e gerentes. É necessário 
que o líder dê um passo atrás para deixar a equipe ganhar autonomia para se 
tornar mais eficaz.
Figura 2. Comparativo entre lideranças.
Fonte: Adaptada de Kaltenecker e Hundermark (2014).
Liderança tradicional
Intensidade Líder
Integrantes
Direção da
comunicação
Liderança ágil
Liderança de equipes em Scrum6
Em todo o projeto sempre haverá integrantes que são mais ativos, mas isso 
não significa que os mais ativos precisem dominar os processos — o líder 
precisa estar atento minimizando este comportamento. Em relação a isso, há 
uma analogia muito empregada com treinadores de times de futebol. Pense: 
Qual é o papel do treinador/líder? Ele controla o jogo? Ele deve guiar sua 
equipe? Ele monitora todos os movimentos? Ele está envolvido? Na verdade, sua 
influência é bastante limitada. Quando o jogo começa, um time de futebol é um 
conjunto auto-organizado. Independentemente de um treinador se apresentar 
como uma das estrelas, gritar instruções para os principais jogadores, não há 
oportunidade para controlar o que está acontecendo no campo. A equipe deve 
executar o melhor que pode. 
O treinador, entretanto, não é desnecessário; tem uma alta influência na 
composição do time, suas táticas, programa de treinamento, estilo de jogo e 
assim por diante. Ele realiza a substituição de jogadores durante o jogo e pode 
usar o intervalo para executar uma revisão e mudar de tática. Perceba que a 
principal tarefa do treinador é a observação que possibilitará fornecer feedback 
profissional com base em suas observações. Essa dinâmica pode ser relacionada 
com as líderes de equipes ágeis. O objetivo principal do treinador é criar o 
nível certo de direcionamento, estabelecendo ciclos de feedback construtivos.
Qual o papel do líder diante dos fatores contêineres, diferenças e troca? 
Na obra de Cohn (2011) encontramos a resposta para essa questão com vários 
exemplos. O Quadro 1 apresenta algumas situações fundamentais.
7Liderança de equipes em Scrum
 Fonte: Adaptado de Cohn (2011). 
Condições
Maneiras pelas quais o líder pode 
influenciar a auto-organização
Contêineres  Mudar o número de pessoas na equipe.
  Alterar os integrantes da equipe.
  Introduzir um novo contêiner, como uma comunidade 
prática.
  Conferir à equipe mais ou menos responsabilidade.
  Modificar o espaço físico da equipe. Dar aos membros 
da equipe mais ou menos espaço. Remover ou diminuir 
as paredes dos escritórios. Passar todos para o mesmo 
andar.
Diferenças  Introduzir um novo membro com mais experiência ou 
poder.
  Fazer questões complexas para a equipe a fim de 
assegurar que pontos de vistas diferentes sejam ouvidos.
  Mudar o estilo de tomada de decisão.
  Encorajar opiniões divergentes.
Trocas  Adicionar ou remover pessoas de uma troca.
  Formalizar ou informalizar uma troca.
  Mudar a maneira como uma troca ocorre (conversa 
pessoal, documento).
  Modificar a frequência de uma troca.
 Quadro 1. O papel do líder diante dos fatores contêineres, diferenças e troca 
Liderança de equipes em Scrum8
Em sua obra Desenvolvimento de software com Scrum, Cohn (2011) traz alguns casos 
práticos. Agora, você verá um desses casos. Carey, uma diretora de desenvolvimento 
que iniciou a adoção do Scrum em sua empresa, teve problemas com uma recente mas 
sustentável queda na velocidade em uma de suas equipes. A qualidade do trabalho 
continuava alta, mas a equipe estava concluindo menos tarefas do que em meses 
anteriores. Durante reuniões regulares e individuais, Carey perguntou por que achavam 
que isso estava ocorrendo, após participar da retrospectiva de Sprint. 
O que Carey descobriu foi que a equipe tinha tomado algumas decisões de arquitetura 
mal embasadas de seis a nove meses antes. Após analisar as conversase a retrospectiva, 
Carey conclui que, embora certas decisões inadequadas fossem inevitáveis, algumas 
aconteciam devido aos membros não questionarem apropriadamente uns aos outros. 
Carey conhecia a abordagem do modelo CDT (Contêineres, Diferenças e Trocas) e 
buscou uma alternativa ao problema da equipe. Carey descobriu que não existiam 
diferenças suficientes entre os membros da equipe. Ela decidiu que poderia ajudar mais 
essa equipe aumentando as diferenças. Fez isso por meio de perguntas investigativas. 
Carey começou a aparecer inesperadamente quando via que a equipe estava fazendo 
reuniões improvisadas. Durante essas reuniões, fazia perguntas que visavam a extrair 
opiniões divergentes. Ela fez perguntas como as a seguir.
  Que abordagens alternativas vocês consideraram e rejeitaram antes de aceitar 
essa abordagem?
  O que poderia dar errado nessa abordagem? 
  O que tem que dar certo para essa abordagem funcionar? 
  O que poderia fazer com que nos arrependêssemos dessa decisão?
Mesmo quando Carey concordava com a opinião predominante, fazia perguntas 
difíceis, procurando falhas e esperando que pudessem surgir sugestões ainda melhores. 
Neste caso, Carey diminui a incidência de decisões falhas, pois mais possibilidades 
eram investigadas.
Perceba que o líder deve monitorar as equipes a fim de que se mantenham 
dentro da dinâmica ágil, e deve interferir mediante qualquer identificação 
de desvio de comportamento introduzindo elementos para que o objetivo da 
auto-organização não se perca. Você pode perceber que a liderança da equipe, 
assim como a inteligência organizacional em geral, não é algo que reside em 
alguns especialistas. Em vez disso, é uma capacidade que todo o sistema tem 
de receber novas informações, inclusive as desafiadoras, e a forma com que 
cada pessoa processa as informações.
Drucker (1999) afirma que a liderança é melhor pensada como um com-
portamento, não um papel. Precisamos de atos de liderança no planejamento 
9Liderança de equipes em Scrum
de Sprint, por exemplo, mas pode ser realizada por todos os integrantes; ou 
seja, em um momento você pode liderar e em outro estar sendo liderado. 
Diante desse perfil de líder e liderança, Cohn (2011) ressalta que o líder deve 
influenciar a evolução, definir o ambiente externo e proporcionar significado. 
Essas três práticas serão detalhadas a seguir.
Os líderes não devem ficar estagnados esperando que a evolução ocorra 
naturalmente, devem ser propositivos. Anderson (1999 apud COHN, 2011) 
afirma que a evolução está relacionada a três elementos: variação, seleção e 
retenção. Ou seja, uma empresa precisa de variação o suficiente entre funcio-
nários, equipes e processos, possibilitando que os objetivos sejam alcançados 
— esse elemento também está relacionado ao estabelecimento de metas claras, 
mecanismos que possibilitem uma distinção de como se comportar para atingir 
o sucesso. As características com mais chances de ajudar uma pessoa ou grupo 
a sobreviver na empresa são as que serão retidas. São os líderes e gerentes da 
empresa que definem quais características que ajudarão os grupos ou pessoas 
a sobreviver. Se valores do desenvolvimento ágil — como abertura e transpa-
rência — levarem à sobrevivência na forma de promoções, reconhecimento 
público e retenção, esses comportamentos serão os que as pessoas adotarão.
Também é papel do líder definir o ambiente externo, pois segundo Cohn 
(2011) a auto-organização e a evolução estão atreladas ao ambiente que a equipe 
trabalha. Os líderes devem controlar ou influenciar a atividade comercial na 
qual a empresa trabalha. Eles determinam a abordagem usada pela empresa em 
relação a inovações: A empresa é inovadora ou segue de perto as inovações? 
Os líderes também controlam os tipos de projetos que são executados e o ritmo 
com que novos projetos são introduzidos na empresa. Cada um desses fatores 
influenciará como uma empresa evolui e se adapta.
Liderança de equipes em Scrum10
Veja um exemplo extraído de Cohn (2011). Julie era a gerente geral de uma grande 
divisão de uma empresa de software. Era responsável por aproximadamente metade 
dos 500 desenvolvedores de sua empresa. O Scrum começou de uma maneira básica 
dentro de sua divisão. Quando os primeiros resultados se mostraram promissores, 
ela iniciou um plano para espalhar o Scrum para todas as equipes em um ano. Como 
parte desse esforço, Julie também reduziu o fluxo de entrada de novos projetos na 
empresa. Isso não ocorreu porque as equipes Scrum estavam desenvolvendo mais 
lentamente; na verdade, elas estavam desenvolvendo mais rapidamente. Mas suas 
primeiras experiências com o Scrum a ajudaram a perceber que a empresa estava 
tentando executar projetos demais ao mesmo tempo. Experiências com suas primeiras 
equipes Scrum lhe mostraram os benefícios de permitir que as pessoas se dediquem a 
uma ou possivelmente duas equipes. Para chegar a esse ponto, ela precisava adequar 
melhor o fluxo de entrada de projetos ao ritmo com que os projetos estavam sendo 
concluídos.
Finalmente, o líder proporciona significado às mensagens que são recebidas 
pelas pessoas, fornecendo contexto para ajudar os funcionários a interpretar 
essas mensagens. Grande parte desse contexto é fornecido nas histórias, mitos 
e rituais que os líderes repetem. Os líderes selecionam e contam histórias por 
meio das quais desejam que os funcionários interpretem situações atuais. 
Com isso as pessoas evoluem e se autogerenciam em resposta às mensagens 
que recebem.
As equipes e empresas precisam de estímulos. A menos que os estímulos 
sejam oferecidos, a equipe ou empresa sofrerá de entropia. Os gerentes e líderes 
fornecem o estímulo que sustenta a auto-organização e a evolução inspirando 
e desafiando os funcionários. Os desafios criam lacunas entre o estado atual 
de um produto e aquele que é imaginado, ou entre os níveis de desempenho 
atual e desejado de um grupo. Quando um grupo é levado a aceitar um desafio, 
ele se auto-organiza em torno de como enfrentá -lo.
11Liderança de equipes em Scrum
Líderes, gerentes e agentes da mudança mantêm uma empresa alerta modificando seus 
contêineres, diferenças e fornecendo trocas transformadoras. Os líderes influenciam 
a direção em que uma empresa evolui.
Auto-organização não é se deixar as coisas acontecerem. Há maneiras sutis e indiretas 
por meio das quais os líderes influenciam as equipes. É impossível um líder prever como 
uma equipe responderá a uma mudança, não importando se ela envolve a alteração 
de um contêiner, novos padrões de desempenho, um sistema de seleção e assim por 
diante. Os líderes não têm todas as respostas. O que eles têm é a habilidade de incitar 
a empresa em direção a se tornar mais ágil (COHN, 2011).
3 Distribuição de equipes
As empresas estão cada vez mais buscando alternativas em outras cidades e até 
mesmo países, com custos menores e vantagens competitivas, e as empresas 
de software também estão neste rol. Segundo Radigan ([201-]), as empresas já 
apresentam alguma ou várias equipes distribuídas. Isto não é algo passageiro 
ou modismo. Equipes distribuídas podem trabalhar em projetos por mais horas 
(de acordo com o fuso horário do país de cada integrante), e ótimos talentos 
podem ser encontrados em mercados menos competitivos. O senso comum 
é pensar que Scrum se torna impraticável neste cenário, no entanto alguns 
pesquisadores apresentam maneiras de utilizar o Scrum e como o líder ajuda 
no desempenho de equipes geografi camente distribuídas (buscando o mesmo 
desempenho que atingiriam se estivessem fi sicamente reunidas). A descrição 
dessas medidas será apresentada nesta seção.
Cohn (2011) apresenta uma definição de equipes colocalizadas em cola-
boração ou várias equipes deliberadamente distribuídas. Você pode observar 
a Figura 3, que apresenta essas diferentes abordagens. 
As equipes colocalizadas em colaboração ocorrem quando um projeto tem 
pessoas suficientes em duas ou mais cidades para estabelecer uma equipe emcada cidade. Cada uma das equipes colocalizadas contém todas as habilidades 
necessárias para levar um item do backlog do produto da ideia à implementa-
ção. Essas equipes são chamadas colocalizadas em colaboração para reforçar a 
noção de que cada equipe reunida fisicamente está trabalhando com as outras 
equipes remotas (mas elas próprias colocalizadas) para entregar um produto. 
Liderança de equipes em Scrum12
Por outro lado, as equipes deliberadamente distribuídas ocorrem quando um 
projeto poderia usar equipes colocalizadas em colaboração, mas toma uma 
decisão deliberada de distribuir as equipes (COHN, 2011, p. 376, grifo do autor).
Figura 3. (a) Exemplo de equipes localizadas em colaboração e (b) exemplo de equipe 
deliberadamente distribuída.
Fonte: Adaptada de Kniberg (2007).
(a)
(b)
Esse mesmo autor aponta ser fácil identificar as vantagens das equipes 
colocalizadas. Veja a opinião de uma desenvolvedora após ter vivenciado 
desenvolvimento colocalizado e distribuído: “Prefiro equipes colocalizas, 
onde os desenvolvedores de uma cidade trabalhavam em um requisito e o 
mesmo ocorria na outra cidade. As únicas pessoas que sofriam eram os donos 
do produto e o Scrum Master, que tinham que acomodar uma diferença de 
horário de dez horas e meia para fazer reuniões de planejamento da Sprint.”
No entanto, as vantagens também aparecem quando se opta por equipes 
distribuídas deliberadamente. Há relatos como: “Essa distribuição parece 
criar sobrecargas de comunicação, mas o que ocorre é que as reuniões diárias 
de Scrum ajudam a superar barreiras e disparidades culturais nos estilos de 
trabalho ao mesmo tempo em que aumentam o enfoque no cliente e o enten-
dimento à distância de suas necessidades.”
13Liderança de equipes em Scrum
Nessa distribuição destaca-se a importância de selecionar com atenção 
os integrantes de cada equipe. Incluir nas equipes pessoas que trabalharam 
juntas anteriormente ou que tenham contato com toda a empresa, sendo útil 
para outros membros remotos que não sabem quem contatar.
Quanto a escolher entre equipes colocalizadas em colaboração ou equipes deliberada-
mente distribuídas, cada abordagem é adequada para determinadas circunstâncias. A 
decisão se resume a quanto receio existe em relação aos problemas que podem surgir 
da falta de comunicação ou transparência entre as localidades. Se achar que eles podem 
ocorrer ou serão significativos se ocorrerem, a opção será distribuição deliberada. Por 
exemplo, em uma situação em que uma equipe distribuída é composta por filiais reunidas 
por meio de uma fusão ou aquisição, a distribuição será sempre feita deliberadamente. 
Essas situações estão sempre propensas a conflitos entre as filiais, e a distribuição deli-
berada da equipe reduz o risco de disputas em larga escala entre as regiões.
Lopes (2014) apresentou alguns fatores considerados críticos nos processos de 
desenvolvimento com equipes distribuídas. A Figura 4 apresenta esses fatores.
Figura 4. Fatores que influenciam para o sucesso de equipes distribuídas.
Fonte: Adaptada de Lopes (2014).
Liderança de equipes em Scrum14
Diferenças culturais — As diferenças culturais podem afetar a efi cácia da 
equipe na comunicação e na colaboração. Há culturas que promovem assu-
mir riscos, outras não. Além disso, enquanto umas desafi am a todos, outras 
promovem a confi ança (LEFFINGWELL; SMITS; SCHWABER, c2013). A 
questão cultural é tão forte no método Scrum, que os líderes devem estar 
atentos ao adotá-la. Sahota (2014) ressalta que o Scrum deve ser evitado em 
culturas incompatíveis. Isso porque, pela sua própria natureza, forçará uma 
transformação cultural em vez de permitir somente a adoção de práticas ágeis. 
Essas diferenças são mais acentuadas em projetos distribuídos.
Cohn (2011) destaca que as diferenças culturais variam de acordo com 
quatro dimensões: poder, individualismo, orientação a resultados e índice de 
fuga de incertezas. Essas devem ser consideradas pelos líderes, evitando que 
afetem as equipes distribuídas. Acompanhe uma breve descrição delas. Poder: 
todos aceitam que o poder não é igualmente distribuído. Individualismo: as 
pessoas preferem agir como indivíduos em vez de parte de um grupo. Orien-
tação a resultados: em qual nível a cultura é orientada a resultados (ganhos 
financeiros, sinais públicos de sucesso e posses). Índice de fuga de incertezas: 
até onde a cultura é tolerante com incertezas. 
Comunicação — A falta de comunicação faz com que as equipas fi sicamente 
distantes não tenham conhecimento de informações básicas sobre o projeto e 
sua equipe, entre outros. Por isso, deve existir um fl uxo de informações ágil 
e efi caz entre os membros da equipe. 
Confi ança — A confi ança em desenvolvimento distribuído é de uma grande 
importância para o bom fl uxo de informações entre as equipes distribuídas 
e crucial para se ter uma equipe coerente. Ter confi ança é ter segurança e 
fi rmeza no trabalho da equipe como um todo. Por isso, é essencial procurar 
mecanismos que proporcionem um clima de confi ança nas relações e ações 
entre as pessoas envolvidas. Estabelecer confi ança com pessoas que estão 
frente a frente leva menos tempo quando comparado a equipes distribuídas. 
Segundo Cohn (2011), os líderes devem evitar a formação de grupos no início 
do projeto (quando os integrantes estão se conhecendo), a fi m de frustrar a 
formação de grupos por afi nidades (programadores C++, engenheiros de banco 
de dados), ou seja, possivelmente grupos com nível insatisfatório. Para tanto 
é salutar que os líderes posterguem a construção de relacionamentos até que 
os membros da equipe tenham conhecido mais detalhes signifi cativos uns 
sobre os outros, como habilidades específi cas, competências, maneiras de 
trabalhar e assim por diante. 
15Liderança de equipes em Scrum
Transparência — Ressalta que a falta de transparência é a raiz de muitos 
dos problemas que ocorrem entre subgrupos em diferentes regiões, e que, 
em trabalho distribuído, estabelecer a transparência é fundamental. A trans-
parência vai desde o entendimento do que se espera de cada participante, 
até a fornecimento de um ambiente no qual as pessoas possam expor suas 
difi culdades sem represálias.
AUDY, J. H. N. Adaptação à mudanças nas características do trabalho: níveis de demanda 
e controle e durante a adoção do método ágil Scrum por equipes de desenvolvimento 
de softwares. 2015. Dissertação (Mestrado em Administração e Negócios) — Faculdade 
de Administração, Contabilidade e Economia, Pontifícia Universidade Católica do Rio 
Grande do Sul, Porto Alegre, 2015.
BECK, K. et al. Manifesto for Agile software development. c2001. Disponível em: http://
agilemanifesto.org. Acesso em: 23 jun. 2020.
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com 
sucesso. Porto Alegre: Bookman, 2011.
DRUCKER, P. Desafios de gerenciais para o século XXI. São Paulo: Pioneira, 1999.
HUNDERMARK, P. Do better Scrum. 3rd ed. [San Francisco]: InfoQ, 2014.
KALTENECKER, S. Leading self-organising teams: workbook for Lean e Agile professionals. 
[San Francisco]: InfoQ, 2015.
KALTENECKER, S.; HUNDERMARK, P. What Is leading self-organising teams all about? 
2014. Disponível em: https://www.infoq.com/articles/about-self-organising-teams. 
Acesso em: 23 jun. 2020.
KNIBERG, H. Scrum e XP direto das trincheiras: como nós fazemos Scrum. [São Paulo]: 
InfoQ Brasil, 2007.
LEFFINGWELL, D.; SMITS, H.; SCHWABER, K. Cartilha do CIO para adoção do método 
Scrum de obtenção de agilidade em softwares. [S. l.]: Rallly Software Development, c2013.
LOPES, C. S. S. Scrum para ambientes de softwares distribuídos: análise crítica e estudo de 
caso. 2014. Dissertação (Mestrado em Engenharia e Gestão de Sistemas de Informação) 
— Escola de Engenharia, Universidade do Minho, Braga, 2014.
RADIGAN, D. Pense globalmente, codifique localmente: o segredo de equipes remotas. 
[201–]. Disponível em: https://www.atlassian.com/br/agile/teams/remote-teams. Acesso 
em: 23 jun.2020.
SAHOTA, M. Transformação e adoção Agile: um guia de sobrevivência. [São Paulo]: 
InfoQ Brasil, 2014.
Liderança de equipes em Scrum16
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
17Liderança de equipes em Scrum
PROCESSOS DE 
DESENVOLVIMENTO 
DE SOFTWARE
Clicéres Mack Dal Bianco
Scrum e os requisitos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Apresentar o processo de coleta visual de requisitos para o Scrum.
  Identificar os stakeholders e seus objetivos em um projeto Scrum.
  Descrever como coletar requisitos para backlog de produto.
Introdução
O sucesso de um projeto Scrum está atrelado às estratégias adotadas 
na coleta de requisitos. Nela, o foco está em identificar o que o cliente 
e os usuários realmente desejam e o que precisa ser implementado 
para satisfazer os usuários. Para tanto, os processos de documentação 
exigidos nos projetos tradicionais são resumidos, pois a prioridade é 
entender corretamente o que deve ser implementado. Além disso, umas 
das atividades mais críticas do projeto Scrum é identificar os stakeholders 
e seus objetivos. Por meio dos stakeholders, serão coletados requisitos 
para contemplar as necessidades dos usuários. Ainda referente às ne-
cessidades dos usuários, o backlog do produto desempenha um papel 
especial no Scrum. Todos os requisitos considerados necessários ou úteis 
para o produto estão listados no backlog. Você verá que ele pode ser 
comparado a um documento de requisitos incompleto e em constante 
mudança, contendo os requisitos necessários para o desenvolvimento. 
Neste capítulo, você verá que, tanto para identificação dos stakeholders 
quanto para identificação dos requisitos do backlog, existem técnicas que 
podem ser empregadas nestas etapas, tais como Árvores e Florestas, 
SMART, mapeamento de histórias e histórias de usuários.
1 Coleta visual de requisitos para o Scrum
A coleta de requisitos é um processo utilizado para identifi car quais são as 
necessidades do cliente. Posteriormente, defi ne-se quais são as funcionalidades 
e se estabelece prioridades no desenvolvimento de um projeto. Para melhor 
esclarecermos isso, vamos supor que João, um profi ssional de TI que atua como 
operador de suporte técnico, deseja se tornar um administrador de sistemas.
Nesse caso, sua primeira iniciativa é a obtenção de informações pertinentes 
ao cargo almejado, mais especificamente quanto aos requisitos necessários 
para se tornar um aspirante a administrador de sistemas. João reconhece que 
ainda precisa estudar e se qualificar. Então, João faz um levantamento das 
principais disciplinas e técnicas que deve dominar, direcionando seus estudos 
para os requisitos mais valorizados pelo mercado.
Nesse processo de coleta de requisitos todas as especificações do cliente 
são trazidas à mesa, e são estabelecidas as prioridades do projeto. Isto é, 
identifica-se os aspectos imprescindíveis do software a ser desenvolvido. E a 
importância disso se reflete nos benefícios de se conhecer mais profundamente 
as necessidades do cliente. O maior deles, sem dúvidas, é a compreensão do 
seu dia a dia, pois é isso o que permitirá à equipe desenvolver uma solução 
mais condizente com os problemas do cliente, otimizar o uso do tempo e 
reduzir as possíveis falhas. 
A coleta de requisitos pode ser realizada por meio de entrevistas, questioná-
rios, brainstorms, prototipação, entre outras. No desenvolvimento tradicional 
o foco é a documentação. O desenvolvimento Scrum, por sua vez, objetiva 
atender às expectativas do cliente de maneira rápida documentado o mínimo. 
Pham e Pham (c2012a) apresentam uma estratégia de coleta visual de requisitos. 
Essa estratégia é apresentada a seguir.
Coleta visual
Em projetos ágeis você precisa ter uma boa maneira de identifi car os requisitos. 
Uma forma de realizar a coleta de requisitos em projetos ágeis é por meio de 
histórias de usuários. Pham e Pham (c2012a) apresentam uma abordagem para 
auxiliar as equipes no processo de identifi cação das histórias de usuários para 
criar os backlogs de produtos. Dada a complexidade de outras técnicas, essa 
se apresenta como uma alternativa para facilitar esse processo. Pham e Pham 
(c2012a) sugerem que a coleta visual seja realizada em dois passos. No primeiro 
passo deve-se identifi car os stakeholders e seus objetivos. No segundo passo 
deve-se coletar requisitos daqueles usuários que representam stakeholders 
e relacionar esses requisitos aos seus objetivos, para que sejam priorizados, 
usando para isso usando a analogia Árvores e a Floresta. A seguir você verá 
com detalhes esses dois passos.
Scrum e os requisitos2
Os stakeholders (partes interessadas, em português) são pessoas e organizações que 
podem ser afetadas por um projeto ou empresa, de forma direta ou indireta. Os 
stakeholders devem fazem parte do projeto de desenvolvimento de software e são 
importantes para o planejamento e a execução de um projeto. De acordo com Barbi 
(c2009–2010), considera-se stakeholders desde o patrocinador, os fornecedores, os 
membros da equipe de projeto, membros da diretoria da empresa até o público 
externo (usuários e vizinhos) que seja afetado pelo projeto.
Identificar os stakeholders
Os stakeholders são fundamentais em projetos Scrum, e identifi cá-los não 
é um processo simples. Para ter sucesso nesta tarefa é necessário fazer per-
guntas como: Quais são os objetivos ou metas de negócio? Como você mede 
a realização de metas? Por que você precisa deste projeto?
Uma maneira de identificá-los é utilizar a regra SMART, que é usada 
extensivamente para ajudar a definir objetivos. Essa técnica é um acrônico 
que apresenta as seguintes características.
  Específico (specific): todos terão o mesmo entendimento do que são 
os objetivos.
  Mensurável (measurable): podemos determinar claramente se os ob-
jetivos foram alcançados.
  Alcançável (achievable): os stakeholders concordam sobre os objetivos.
  Realista (realistic): seremos capazes de realizar os objetivos do projeto 
com recursos que temos.
  Baseada em tempo (time-based): teremos tempo suficiente para realizar 
os objetivos
3Scrum e os requisitos
O Quadro 1 apresenta um exemplo de objetivos e métricas dos stakeholders.
 Fonte: Adaptado de Pham e Pham (c2012a). 
Stakeholders Objetivos Métricas
Desenvolvimento 
do negócio
  Aumentar a parcela 
de mercado em 15% 
atingindo 200 mil 
clientes até o final 
do ano.
  Aumentar o número 
de usuários em 10 
mil a cada mês.
Serviços ao cliente  Reduzir as ligações 
dos clientes em 20% 
a cada trimestre.
  Reduzir o tempo de 
uma reclamação 
para 50% do tempo 
real.
  Números de 
chamadas.
  Tempo gasto ao 
telefone com o 
cliente com uma 
reclamação.
 Quadro 1. Gerenciar os stakeholders 
Técnica Árvores e a Floresta
Para conhecer os stakeholders você se reunirá com os usuários que os re-
presentam, cada com seu papel e talvez com objetivos distintos. O dono do 
negócio (product owner), por exemplo, desejará escalabilidade e lucros, e o 
usuário (que é quem realmente usará) desejará telas amigáveis. Para entender 
as necessidades dos usuários e transformá-las em requisitos do produto de 
software, você pode utilizar a técnica Árvores e a Floresta, descrita por Pham 
e Pham (c2012a). A Figura 1 apresenta a estrutura desta técnica.
Scrum e os requisitos4
Figura 1. Técnica Árvores e a Floresta.
Fonte: Adaptada de Pham e Pham (c2012a). 
Você deve iniciar pelo nível floresta, ou produto global. Verifique se o 
seu produto deveria ser composto — em outras palavras, quantas árvores 
devem existir na floresta, ou seja, quantosstakeholders (observe a Figura 2a). 
Em seguida, divida as arvores em seus galhos, a fim de agrupar as pessoas 
conforme funções ou seus objetivos com o produto, conforme ilustra a Figura 
2b. Depois, relacione as folhas que são as histórias, para listar as prioridades 
e necessidades dos stakeholders.
5Scrum e os requisitos
Figura 2. (a) Os stakeholders, representados de maneira análoga pelas árvores que compõem 
a floresta, e (b) as pessoas, representada por cada galho, que compõem um grupo.
Fonte: Adaptada de Pham e Pham (c2012a).
(a)
(b)
A técnica Árvores e a Floresta pode ser empregada para identificar os 
requisitos do backlog do produto da mesma forma como mostrado para os 
stakeholders. Você deverá buscar identificar quais são os requisitos chaves, 
que neste caso são as árvores, e para cada árvore busque localizar as categorias 
que estão relacionadas (galhos) e, posteriormente, liste as folhas, ou seja, os 
recursos que devem ser implementados para cada requisito. Um exemplo será 
apresentado na última seção deste capítulo. 
Scrum e os requisitos6
Na próxima seção você verá detalhes sobre a identificação dos stakeholders 
e seus objetivos.
2 Stakeholders e seus objetivos
O conjunto stakeholders de um projeto engloba todas as pessoas que de al-
guma forma podem infl uir no sucesso do projeto. Cada projeto tem seu grupo 
de stakeholders próprio. A questão crítica é identifi car todos os que podem 
infl uir (BARBI, c2010).
Diante disso, se você estiver criando um aplicativo ou serviço deve se 
preocupar em saber quem são os principais stakeholders. E então surgem as 
dúvidas: Como identificar quem são os stakeholders que estarão diretamente 
envolvidos? E se projetarmos um sistema que agrade os nossos stakeholders 
diretos e indiretos? E os patrocinadores do projeto? Se desenvolvermos um 
sistema que atenda às necessidades estaremos obtendo sucesso? E quais são 
os principais stakeholders? 
Embora esteja claro que os usuários são realmente os principais interes-
sados no projeto e que devemos, em grande parte, projetar considerando suas 
necessidades, deve-se ir além e analisar amplamente quem são os stakeholders 
do sistema proposto. Ao fazê-lo, é útil pensar em duas classes de stakeholders: 
stakeholders do sistema e stakeholders do projeto. 
Conforme Leffingwell (2011), os stakeholders do sistema são os participan-
tes interessados nele: uma parte interessada do sistema é qualquer pessoa que:
  usa diretamente o sistema;
  trabalha com os resultados de quem usa o sistema;
  será impactado pela implantação e operação de um sistema.
Essas partes interessadas incluem usuários e operadores, além de usuários 
que recebem relatórios e outras saídas do sistema; gerentes, compradores e 
administradores desses usuários; equipe de suporte e suporte técnico; desen-
volvedores trabalhando em outros sistemas que integrar ou interagem com o 
sistema; profissionais de instalação e manutenção; e mais. Esses stakeholders 
do sistema serão os principais impulsionadores dos seus requisitos. Assim, 
para que o sistema seja bem-sucedido, é necessário considerá-los.
Os stakeholders do projeto têm interesse substancial e capacidade de 
investir no projeto que está desenvolvido. Incluem-se aí os patrocinadores do 
projeto, gerenciamento de projetos, gerenciamento de portfólio, executivos, 
7Scrum e os requisitos
equipe de governança financeira e assim por diante. Neste caso, stakeholder 
do projeto é qualquer pessoa que:
  tem interesse no orçamento e no cronograma;
  tem interesse em compreender como o produto/sistema/solução será 
desenvolvido(a);
  estará envolvido no marketing, venda, instalação ou manutenção do 
sistema.
Nessa definição você pode ver que usuários diretos não são o único foco 
de um projeto. De fato, existe uma gama ainda maior de pessoas potencial-
mente afetadas por um novo sistema. Para ter sucesso, a equipe deve primeiro 
identificá-los, e então sintetizar seus objetivos em uma visão coesa.
A identificação e entendimento dos stakeholders pode proporcionar uma 
visão mais ampla dos processos em um negócio. A partir delas, é mais fácil para 
que os responsáveis pelo planejamento compreendam como a empresa pode 
melhorar, como processos podem ser otimizados e como garantir benefícios 
para todas as partes envolvidas. 
Lyra, Gomes e Jacovine (2009) dividiram os interessados em internos e 
externos. Os stakeholders internos são aqueles que possuem alguma afiliação 
formal com a empresa. Ou seja, incluem: colaboradores, gestores, gerentes, 
proprietários e acionistas. Os stakeholders externos são aqueles que, apesar 
de diretamente afetados pela direção dos projetos da empresa em questão, não 
possuem afiliação com ela. Por exemplo: clientes, fornecedores, credores e 
investidores, Estado, ONGs, mídia e concorrentes.
Uma técnica para identificar os stakeholders é a árvores e florestas, que 
foi apresentada na seção anterior. Após serem identificados e classificados os 
stakeholders, também é importante entender quais os objetivos ou necessidades 
de cada um deles. Para entender os objetivos dos principais stakeholders, 
deve-se primeiro identificar aqueles que influenciam a organização. 
Jemilo (2012) apresenta um framework para mapear os stakeholders, 
baseado nos seus objetivos ou interesses e no seu potencial para influenciar a 
cooperação ou não com o sistema. Analisando por esse viés, há quatro classes 
de stakeholders, segundo classificação de Savage et al. (1991 apud LYRA; 
GOMES; JACOVINE, 2009). A Figura 3a apresenta esse framework. No eixo 
y está a relação da influência ou poder. No eixo x está a relação de interesse 
ou objetivos com o projeto. 
Scrum e os requisitos8
Figura 3. (a) Mapeando os stakeholders conforme suas influências e interesses e (b) iden-
tificando a abordagem para diferentes stakeholders.
Fonte: Adaptada de Jemilo (2012).
(a)
(b)
1. Stakeholders com alta influência e alto interesse — Podemos listar os 
donos do negócio e outras pessoas com autoridade para tomar decisões. 
São fáceis de identificar e darão sustentabilidade ao projeto, além de 
poderem cancelá-lo. Esses stakeholders são de fácil envolvimento; são 
todos aqueles que precisam ficar sabendo das decisões mais importantes e 
seus possíveis impactos. Nesses casos é importante mantê-los engajados.
2. Stakeholders com alta influência e baixo interesse — Neste grupo estão 
as pessoas com autoridade decisória significativa, mas falta de disponibi-
lidade ou interesse para envolverem-se ativamente. Geralmente é difícil 
ter pontos de contato consistentes, sendo importante mantê-los satisfeitos.
9Scrum e os requisitos
3. Stakeholders com baixa influência e alto interesse — Podem ser im-
pactados pelo projeto, mas têm pouca influência. Podem demandar 
mais do seu tempo do que você pode dar. Busque maneiras eficientes 
de se comunicar e mantenha-os informados sobre o projeto através de 
atualizações por e-mail e apresentações.
4. Stakeholders com baixa influência e baixa disponibilidade — Eles não 
estão (e não espere que estejam) significativamente envolvidos. Eles 
podem nem estar cientes do seu projeto e talvez não o querer. Saiba 
quem eles são; monitore-os, e talvez você consiga fazê-los mudar de 
quadrante.
A Figura 3 apresenta uma classificação observando a influência e o in-
teresse dos diferentes stakeholders. De acordo com Jemilo (2012), os donos 
do negócio ou empresários e os principais stakeholders devem participar do 
Planejamento da Realize, dos workshops de Adapt e de seção de histórias de 
usuários (quando necessário) para opinarem, sugerirem, revisarem requisitos 
e, além disso, conhecerem o progresso do planejado versus o real.
Os principais stakeholders também devem estar envolvidos nas demons-
trações das Sprints. Por sua vez, os demais stakeholders (normalmente são 
grupos menores e com menor influência) serão acionados conforme surgir a 
necessidade de mantê-los informados. Os especialistas no assunto são con-
tratados conforme necessáriopara auxiliar nos dados de entrada.
Ainda de acordo com Jemilo (2012), é necessário priorizar os stakeholders 
conforme suas influências e interesses (objetivos). Além disso, deve-se avaliar 
o tempo que será despendido em cada Sprint e Release com os stakeholders 
certos. Segundo Pham e Pham (c2012a), a maior parte do seu tempo deve ser 
gasta trabalhando com os stakeholders da categoria (1), que possuem muita 
influência e interesse em seu projeto. Ao mesmo tempo você deve tentar 
fazer a categoria 2 se movimentar em direção à 1. E, em menor escala, fazer 
a categoria 4 se movimentar em direção à categoria 3.
Como não haverá terá tempo suficiente para conversar com todos os 
stakeholders. Sugere-se usar algum plano de gerenciamento de stakeholders, 
tentando atender seus objetivos maneiras diferentes, conforme a influência 
de cada um para o sucesso do seu projeto. 
Vamos ver esse gerenciamento por meio de um exemplo. Carmem trabalha 
em uma empresa de TI e é responsável por gerenciar os stakeholders. Ela sabe 
quem são eles e quais são suas influências e seus interesses. Para tanto criou 
um plano de abordagem para os diferentes stakeholders, conforme você pode 
observar no Quadro 2.
Scrum e os requisitos10
 Fonte: Adaptado de Jemilo (2012). 
Papéis
Responsáveis/
pessoas/grupos
Métodos de engajamento/
frequência
Dono do negócio/
empresários
Bruno Smith  Reuniões individuais para 
discutir a visão, o roteiro e o 
recursos antes de cada reunião 
de planejamento.
  Participação em workshops de 
requisitos (conforme necessário).
  Participação no workshop de 
Inspect & Adapt.
  Enviar e-mail quando o escopo 
do projeto está em risco.
Stakeholders 
principais
Carol Ollis  Participação em workshops 
investigativos.
  Apresentar a lista de backlog 
priorizada antes da reunião de 
liberação.
  Participação no workshop de 
Inspect & Adapt (conforme 
necessário).
  Participação na demonstração 
das Sprints do sistema.
  Participação nas Sprints das 
equipes (opcional).
  Comunicação por e-mail quando 
o escopo da Sprint ou do 
programa está em risco.
Demais 
stakeholders
Pedro Maulos  Atualização por e-mail (conforme 
necessário).
  Participação em workshop de 
requisitos (caso necessário).
Especialistas 
no assunto
Eloísa Natan  Conduzir reuniões de Sprints 
(conforme necessário).
  Participar de reuniões individuais 
ou em grupo (conforme 
demandas).
 Quadro 2. Gerenciar os stakeholders 
11Scrum e os requisitos
Essa técnica de mapeamento dos stakeholders pode orientar o tipo e a 
frequência de interações — conversas individuais, reuniões, convite para 
cerimônias, eventos e workshops.
A identificação dos stakeholders, os usuários responsáveis ou representati-
vos, seus papéis e seus objetivos auxiliarão no entendimento das necessidades 
dos usuários e de como incluir essas necessidades por meio de requisitos no 
novo software. Na próxima seção será apresentado o backlog do produto, que 
contemplará todos os requisitos considerados necessários ou úteis ao produto.
3 Coleta de requisitos para o backlog de 
produto
O backlog do produto é uma lista de funcionalidades priorizada e desejada 
do produto. Essa lista fornece um entendimento centralizado e compartilhado 
do que implementar. De acordo com Rubin (c2012), o backlog é um artefato 
altamente visível, considerado o coração do Scrum, e que deve ser visível a 
todos os participantes do projeto.
A técnica Árvores e a Floresta é empregada como um recurso para auxiliar 
na identificação dos requisitos, sendo uma técnica visual e fácil de usar. A 
Figura 4 apresenta três árvores (ou áreas de interesses) para o novo produto 
– neste caso um software para reserva de quarto em um hotel. Mais especifi-
cadamente, as três árvores neste produto serão chamadas gerenciamento de 
usuários, gerenciamento de quartos e gerenciamento de reservas. Observe que a 
árvore gerenciamento de usuários tem dois galhos: “gerenciar novos usuários” 
e “referenciar usuários atuais”. Agora, analise as folhas dos respectivos galhos: 
“Verificar faturamento”, “Cancelar contas” e “Logins”. Finalmente, observe 
que visualmente é como o produto de software se parecerá com todas as folhas, 
todos os galhos e todas as árvores dentro da floresta.
Scrum e os requisitos12
Figura 4. Técnica Árvores e a Floresta aplicada no desenvolvimento de software.
Fonte: Adaptada de Pham e Pham (c2012b).
Como dito anteriormente, o backlog do produto será composto por uma lista 
de requisitos que surgirão ao logo do desenvolvimento. Para identificar esses 
requisitos, são utilizadas as técnicas de mapeamento de histórias, histórias de 
usuários ou PBIs (itens do backlog do produto). De acordo com Rubin (c2012), 
as features, ou funcionalidades, normalmente são descritas por histórias de 
usuários. Inserir um recurso novo na tela de login para um website, ou alterar 
uma funcionalidade existente, tal como uma tela de login mais amigável, são 
exemplos de funcionalidades.
Contrariando as tradicionais coletas detalhadas de requisitos, o Scrum 
usa esse tempo para identificar os requisitos principais, que são discutidos 
e aprimorados progressivamente ao longo do projeto. Cada item da lista do 
backlog do produto representa um valor comercial desejável. Embora não exista 
um formato padrão para um PBI, o mapeamento de histórias foi proposto por 
Jeff Patton (2004), sendo uma ferramenta muito eficaz e útil para capturar 
requisitos, principalmente na fase inicial da coleta de requisitos.
De acordo com Parekh (2015), o mapeamento de histórias é uma ativi-
dade considerada envolvente. Possibilita um maior engajamento no processo 
de criação do backlog do produto. Uma parede pode servir de apoio para a 
13Scrum e os requisitos
elaboração das histórias, em vez de escrever 100 páginas de uma maçante 
documentação de requisitos.
O mapeamento de histórias é uma abordagem top-down de coleta de re-
quisitos e é representado como uma árvore. Inicia com uma visão abrangente 
alcançada através de objetivos, que são definidos através da conclusão de 
atividades. E para concluir uma atividade, os usuários precisam definir tare-
fas. Essas tarefas podem ser transformadas em histórias de usuários para o 
desenvolvimento de software.
Estrutura do mapa de histórias: Objetivos – Atividades – Tarefas 
– Histórias
Imagine um aplicativo de loja on-line e considere que o objetivo é localizar 
um produto. Podemos criar um ramo do mapa de história para entendê-lo 
melhor.
Existem várias maneiras de o usuário atingir esse objetivo, tais como: 
navegar na árvore de categoria do produto, buscar texto livre no campo pes-
quisar ou em produtos em promoção. Para exemplificar, vamos demonstrar 
pela opção navegar na categoria de produto e criar o mapa de histórias.
Agora, para encontrar o produto desejado, o usuário precisa executar 
determinadas tarefas; a relação dessas tarefas representa o mapa de histórias. 
Outro fato importante é que essas tarefas podem ser convertidas em histórias 
de usuários para o desenvolvimento de software. Veja a seguir a relação de 
tarefas (em amarelo).
Scrum e os requisitos14
Dessa maneira, pode-se detalhar cada ramo do mapa de histórias, come-
çando pelas metas e construindo todo o mapa de histórias. De acordo com 
Parekh (2015), a construção de um mapa completo pode levar de 3 dias a 2 
semanas, com base no tamanho e na complexidade do projeto. Em algum 
momento, precisamos de mais informações: por exemplo, é bom ter histó-
rias, perguntas de acompanhamento, abordagens e alternativas. Isso é como 
enriquecer o mapa de história com mais informações. A seguir, algumas 
recomendações.
  Use cores diferentes para representar níveis diferentes no mapa da 
história, como laranja para objetivos, azul para recursos, verde para 
tarefas e amarelo para histórias.
  Use adesivos com pontos ou estrelas para representar notações especiais.
  Use pequenos adesivos para capturar notas, hipóteses, detalhes ou 
perguntas.
  História de usuários.Outra técnica amplamente usada para criar a lista de backlog é a história 
de usuários. De acordo com Cohn (c2004), cada história descreverá um item 
ou uma necessidade para o usuário ou para o dono do negócio. Isso facilitará 
que o dono do produto priorize a lista do backlog, pois neste caso todos os 
itens estão apresentados em um formato compreensível, facilitando a sua 
tomada de decisão — relembrando que no início da coleta não é importante 
identificar exaustivamente todos os requisitos, no entanto, quanto mais itens 
foram capturados no início mais eficiente será o desenvolvimento. Perceba 
que, definindo o papel dos stakeholders e focando nas histórias de usuário, o 
Scrum torna-se uma boa ferramenta de coleta de requisitos.
15Scrum e os requisitos
Apesar de não existir um formato específico de história de usuários, exis-
tem alguns termos considerados necessários. Veja uma estrutura clássica de 
história de usuário.
O formato típico é especificar o papel do usuário (a função do usuário), o que esse 
usuário deseja alcançar (a meta) e por que ele quer alcançá-la (o benefício). 
Veja a estrutura de uma típica história de usuário para requisitos do backlog.
Como um eu posso/gostaria/devo/ para 
Exemplos:
1. Como um cliente, eu gostaria de pagar usando meu cartão crédito para poder 
pagar minhas parcelas. 
Pode-se incluir observações e, se necessário, detalhar as restrições: p. ex.: observa-
ções — aceitar Master, Visa e Amex; restrições — parcelar no máximo em 10 vezes; 
cliente não pode estar no SPC.
2. Como um vendedor, eu gostaria de consultar a produção semanal para ver se 
bateu a meta.
De acordo com Barbi (c2009–2010), ao descrever um requisito que é impor-
tante para um usuário ou para comprador de um sistema de software, deve-se 
considerar três aspectos:
1. uma breve descrição da história para servir como lembrete da 
funcionalidade;
2. conversações sobre as histórias para confirmar os detalhes escritos 
na descrição;
3. testes que podem ser usados para determinar quando uma história está 
completa.
As histórias de usuário, segundo Jeffries (2001), podem ser pensadas de 
uma maneira simples; mais especificadamente, a partir de três componentes, 
conhecidos como os três Cs: cartões, que são o meio físico no qual as his-
tórias são escritas; conversação, que é a discussão em torno das histórias; e 
confirmação, que são os testes que verificam as histórias.
Scrum e os requisitos16
Épico
Uma grande história de usuário representa um conjunto de elementos que 
precisam ser analisados ou trabalhados. Estão em alto nível e devem ser 
decompostos para deixar clara a real necessidade. Pode ter a mesma estru-
tura ou outros formatos de história de usuário. Um requisito épico não pode 
ser realizado em uma Sprint, sendo necessário um trabalho de análise para 
decompor os épicos (JEMILO, 2012).
Exemplo de requisito ágil épico.
1. Como um vendedor, eu gostaria de poder visualizar minhas vendas para que 
possa analisar meu desempenho. 
Perceba que visualizar minhas vendas é um requisito que precisa ser de-
composto. Não está bem definido. Estamos, neste caso diante de um épico.
Uma visão abrangente do uso de histórias em projetos Scrum é apresentada 
por Leffingwell (c2011), conforme Figura 5. As funcionalidades ou recursos 
do produto ( features) irão compor o backlog do produto. As funcionalidades 
são identificadas por meio de histórias (story). No momento do planejamento 
da release as funcionalidades podem ser decompostas em histórias. Essas 
funcionalidades são normalmente expressas com no máximo duas frases. 
O gerente do projeto juntamente com dono do produto irá definir a lista de 
features, ou funcionalidades, do produto. Cada funcionalidade fornece dados 
para a lista de backlog por meio das histórias de usuários (story).
17Scrum e os requisitos
Figura 5. Funcionalidades são itens do backlog do produto.
Fonte: Leffingwell (c2011, p. 75).
Nem sempre, no entanto, deve-se utilizar histórias de usuários, especial-
mente em situações em que parece forçado, como a representação de certos 
defeitos.
Ao final deste capítulo você pode observar como é realizada a coleta 
visual de requisitos e que essa é considerada uma maneira simples de coleta 
ao ser comparada com outras técnicas existentes. A coleta visual pode ser 
empregada inicialmente para identificar os stakeholders e os requisitos do 
backlog do produto. Outros detalhes dos stakeholders foram apresentados 
para identificar seus objetivos e influências, possibilitando assim definir 
maneiras de inclui-los no projeto. Você também verificou como os requisitos 
do backlog podem ser coletados usando árvores e florestas, mapeamento de 
histórias e histórias de usuários.
BARBI, F. C. Gestão de projeto. c2010. Disponível em: https://sites.google.com/a/gesta-
odeprojeto.info/www/analise-dos-stakeholders. Acesso em: 26 jun. 2020.
COHN M. User stories applied for agile software development. Boston: Addison-Wesley, c2004.
JEFFRIES, R. Essential XP: card, conversation, confirmation. 2001. Disponível em: https://ron-
jeffries.com/xprog/articles/expcardconversationconfirmation/. Acesso em: 30 jun. 2020.
Scrum e os requisitos18
JEMILO, D. The stakeholders management framework: for teams, programs, and por-
tfolios. [2012]. Agile Alliance, 2020. Disponível em: https://agilealliance.org/wp-content/
uploads/2016/01/Stakeholder-Management-by-Drew-Jemilo-Agile2012.pdf. Acesso 
em: 26 jun. 2020.
LEFFINGWELL, D. Agile software requirements: lean requirements practices for teams, 
programs, and the enterprise. Upper Saddle River: Addison-Wesley, c2011.
LYRA, M. G.; GOMES, R. C.; JACOVINE, L. A. G. O papel dos stakeholders na sustentabi-
lidade da empresa: contribuições para construção de um modelo e análise. Revista 
da Administração Contemporânea, v. 3, Edição Especial, p. 39–52, 2009. Disponível 
em: http://www.spell.org.br/documentos/ver/8257/o-papel-dos-stakeholders-na-
-sustentabilidade-da-empresa--contribuicoes-para-construcao-de-um-modelo-de-
-analise. Acesso em: 26 jun. 2020.
PAREKH, S. Story mapping, visual way of building product backlog. 2015. In: ThoughtWorks, 
c2020. Disponível em: https://www.thoughtworks.com/insights/blog/story-mapping-
-visual-way-building-product-backlog. Acesso em: 26 jun. 2020.
PATTON, J. User story mapping: building better products using agile software design. 
Sebastopol: O’Reilly Media, 2004.
PHAM, A.; PHAM, P. V. Scrum em ação: gerenciamento e desenvolvimento ágil de 
projetos de software. São Paulo: Novatec, c2012a.
PHAM, A.; PHAM, P. V. Scrum in action: agile software project management and deve-
lopment. Boston: Course Technology PTR, c2012b.
RUBIN, K. S. Essential Scrum: a practical guide to the most popular agile process. Upper 
Saddle River: Addison-Wesley, c2012.
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
19Scrum e os requisitoságeis
De acordo com o site do Manifesto Ágil (BECK et al., c2001), no ano 2001, 
em Utah, nos EUA, 17 profi ssionais que praticavam metodologias ágeis se 
reuniram para praticar Snowbird e conversar sobre métodos de planejamento 
de software. Criaram, portanto, um documento, chamado de grito de guerra, 
o Manifesto Ágil, que possui quatro valores (contidos na coluna da esquerda 
na Figura 1). Estes valores priorizam os pontos a seguir.
1. Pessoas frente aos processos — Este tópico objetiva favorecer relacio-
namentos no ato da construção do software.
2. Funcionamento versus documentação — Este tópico objetiva favorecer 
a funcionalidade da criação de software, e não somente o design.
5Métodos ágeis
3. Colaboração do cliente, a funcionalidade da criação de software — Este 
tópico objetiva favorecer a interação contínua com o cliente, a fim de 
compreender seus desejos e anseios com mais precisão.
4. Consertar problemas e se adaptar a mudanças — Este tópico objetiva 
favorecer uma construção dinâmica e não engessada, onde consertar 
problemas é mais importante que manter a burocracia.
Figura 1. Valores do manifesto ágil.
Fonte: Adaptada de Isotani e Rocha ([20––]).
Indivíduos e
interações
Software funcionando
Colaboração
do cliente
Responder às
mudanças
“Embora os itens à direita sejam importantes,
valorizamos mais os que estão à esquerda”
Processos e
ferramentas
Documentação
compreensível
Negociação
de contrato
Maior
do
que
Seguir um plano
Perceba o quanto esses valores são aplicáveis. Não se trata de deixar de 
se organizar ou de documentar, obviamente, mas de tornar o trabalho mais 
funcional e orgânico. Considere que os profissionais da área de programação 
ficam sobrecarregados e que a área de tecnologia é estressante; há muita 
demanda para pouco profissional, e a tendência é aumentar a necessidade de 
profissionais. 
Uma situação que pode acontecer durante o desenvolvimento de um soft-
ware, por exemplo, é, apesar de haver um plano de ação, as pessoas perceberem, 
em meio ao processo, a necessidade de alterações ou de inclusão de novas 
funcionalidades. Outro exemplo seria, na criação de um app, constatar que 
os dados precisam ficar em uma tabela temporária, e então ter que parar tudo 
e criar um banco de dados temporário no painel do servidor.
Agora, imagine que você tem que ficar documentando os detalhes de tudo 
que fizer. Os programadores ficariam mais sobrecarregados ainda, pois além 
Métodos ágeis6
de programar eles teriam que documentar. Neste ponto, ferramentas como o 
Github ajudam, pois salvam automaticamente as versões.
Imagine agora que você não permite que seus funcionários mudem um 
pouco o curso? Isso acabaria atrapalhando um atributo muito importante: 
funcionalidade! Por isso devemos seguir, sim, as boas práticas, sem, contudo, 
negligenciar o tempo de execução, pois cada minuto poderia ser um recurso 
a mais no seu software.
Falamos dos quatro valores do Manifesto Ágil. Vejamos agora seus 12 
princípios desenvolvimento de software? Eles estão presentes do próprio site 
oficial do Manifesto Ágil (BECK et al., c2001).
  Nossa prioridade é satisfazer o cliente através da entrega contínua e 
adiantada de software com valor agregado.
  Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. 
Processos ágeis se adequam a mudanças, para que o cliente possa tirar 
vantagens competitivas.
  Entregar frequentemente software funcionando, de poucas semanas a 
poucos meses, com preferência à menor escala de tempo. Indivíduos e 
interação entre eles mais que processos e ferramentas.
  Pessoas de negócio e desenvolvedores devem trabalhar diariamente em 
conjunto por todo o projeto.
  Construir projetos em torno de indivíduos motivados, dando a eles o 
ambiente e o suporte necessário e confiando neles para fazer o trabalho.
  O método mais eficiente e eficaz de transmitir informações para e entre 
uma equipe de desenvolvimento é por meio de conversa face a face.
  Software funcionando é a medida primária de progresso.
  Os processos ágeis promovem desenvolvimento sustentável. Os patro-
cinadores, desenvolvedores e usuários devem ser capazes de manter 
um ritmo constante indefinidamente.
  Contínua atenção à excelência técnica e bom design aumentam a 
agilidade.
  Simplicidade: arte de maximizar a quantidade de trabalho não realizado 
é essencial.
  As melhores arquiteturas, requisitos e designs emergem de times 
auto-organizáveis.
  Em intervalos regulares, a equipe reflete sobre como se tornar mais 
eficaz, e então refina e ajusta seu comportamento de acordo.
7Métodos ágeis
Como você pode perceber, é um método poderoso, para quem já atua com 
programação ele faz muito sentido. O sistema tradicional se mostra lento: nele, 
os clientes chamam a empresa de criação de software, e para fazer a elicitação 
são necessárias longas visitas técnicas, análises de documentos, entrevistas e 
análises de processos, para então dar uma data relativamente demorada com 
um valor relativamente alto para entregar a aplicação. Resultado? Alto custo e 
lentidão. No sistema ágil o processo é mais fatiado e incrementado. Falaremos 
agora sobre algumas metodologias famosas.
3 Principais métodos ágeis existentes
Primeiramente, listaremos os métodos ágeis famosos. O primeiro citado é o 
Scrum (será explicado adiante), no Trello. Na década de 1990 vários modelos 
infl uenciaram na criação de métodos ágeis. Podemos citar como exemplo os 
seguintes modelos: Desenvolvimento Incremental, DSDM (Metodologia de 
Desenvolvimento de Sistemas Dinâmicos), Crystal Clear, FDD (Desenvolvi-
mento Direcionado a Funcionalidade), XP (Extrem Programming) e Scrum.
O Quadro 3 mostra a recomendação de métodos por fases do projeto de 
desenvolvimento de software.
 Fonte: Adaptado de Alegría et al. (2011). 
Área Métodos com maior contribuição
Gerenciamento de requisitos XP
Medição e análise XP, Scrum
Planejamento de projeto XP, Scrum
Monitoramento e controle XP, Scrum
Gerenciamento do subcontratado Não se aplica
Gerenciamento de qualidade 
de produto e processo
FDD
Gerenciamento de configuração Nenhum
 Quadro 3. Áreas de gerenciamento e métodos com mais contribuição 
Métodos ágeis8
O primeiro, desenvolvimento incremental, criado pela IBM em 1990, faz a 
construção do sistema de pedaço em pedaço, ou de incremento em incremento. 
Geralmente, um pedaço é feito, e após o cliente dá alguns feedbacks. Cada 
pedaço é uma parte inteira: por exemplo, uma página de login link com acesso 
a banco de dados é um incremento (SOMMERVILLE, 2011).
O segundo método cabível de explicação é a Metodologia de Desenvolvi-
mento de Sistemas Dinâmicos, o qual é usado em situações onde o tempo e a 
verba são limitados. De acordo com Cruz (2018, p. 316) “[...] tem um conceito 
mais próximo a um framework do que um método propriamente dito, sua ênfase 
foca a criação de protótipos que posteriormente evoluem para o sistema, e 
para isso é utilizada muito fortemente a colaboração próxima com o cliente”.
Este método buscar entregar 80% do projeto em 20% do tempo disponí-
vel. Ele é composto por três fases: a fase do pré-projeto (onde se elabora o 
orçamento), a fase do ciclo de vida (onde se analisa a viabilidade) e a fase do 
pós-projeto (onde ocorrem as alterações), conforme a Figura 2.
Figura 2. Fases da Metodologia de Desenvolvimento de Sistemas Dinâmicos.
A Metodologia de Desenvolvimento de Sistemas Dinâmicos é reco-
mendada quando os projetos são urgentes, quando os projetos são formados 
por uma nova tecnologia e precisam ser acompanhados de testes do usuário, 
ou quando remetem a um lançamento de produto com data marcada. Qual é 
a diferença entre este método e outros? Em metodologias tradicionais, como 
por exemplo, o famoso Project Management Institute (PMI), o cronograma e 
o orçamento são abertos, e o escopo é fechado; já a Metodologia de Desen-
volvimento de Sistemas Dinâmicos tem cronograma e orçamento fechados, 
mas o roteiro é aberto (SOMMERVILE, 2011).
9Métodos ágeisO Crystal Clear (ISOTANI; ROCHA, [20––]) é outra metodologia ágil. 
Ela atende vários tipos de projetos e tem como valor a comunicação com o 
cliente, bem como o relacionamento do desenvolvedor com o cliente, a fim de 
que possa captar com facilidade suas expectativas. Este método evita a criação 
de ferramentas complexas que não serão utilizadas, objetivando reduzir tempo 
e custo na entrega. Este método busca diferenciar a metodologia específica 
conforme a natureza de cada projeto e permite que os desenvolvedores se ma-
nifestem quando algo os incomodar. O método Crystal é um cristal em figura 
elaborado pela gestão e mostrado com uma escala de cores, onde as cores variam 
de acordo com nível de criticidade e com o tamanho da equipe: quanto mais 
escuro o cristal, mais crítico de fazer é o software ou projeto; já as cores claras 
(branco e amarelo) atestam que os software ou projetos serão simples e poucas 
pessoas serão necessárias; projetos alaranjados ou até vermelhos demandam 
mais pessoas e são mais arriscados. No Crystal da Figura 3, desenhado pela 
gestão, C significa confortável e D significa baixo custo, E significa alto custo, 
e L significa risco de vida. O números indicam o número de funcionários.
Figura 3. Método Crystal.
Fonte: Adaptada de Abrahamsson et al. (2002).
Branco Amarelo Laranja Vermelho
A metodologia Feature-driven development (FDD), ou “Desenvolvimento 
Dirigido por Funcionalidades”, em português, fragmenta os projetos de gestão 
e de software em features (funcionalidades). Ela foi concebida na década de 
1990, e tem como características os pontos, de acordo com Sommerville (2011):
Métodos ágeis10
  elaboração de lista de tarefas de funcionalidades, ou seja, cada passo 
tem foco em alguma funcionalidade do software;
  planejamento voltado ao método incremental por funcionalidade, ou 
seja, planeja-se etapas de acordo cada parte. Por exemplo: o primeiro 
item a ser feito é a área do cliente completa; o segundo item será o 
carrinho de compras completo; o terceiro item será o catálogo completo, 
e assim por diante;
  design voltado à funcionalidade, ou seja, criar um design que simplifica 
a navegação e promove a experiência do usuário;
  teste de software orientado à funcionalidade, ou seja, testar cada função 
em detrimento de testar uma interface, por exemplo.
Pode-se perceber que neste projeto a soma de cada etapa se faz maior do 
que o todo; assim, recomenda-se dividir em features curtas, a fim de agilizar a 
conclusão de cada função, aumentando a eficiência da construção do programa. 
Por exemplo: cria-se uma função de upload de imagens, cria-se uma função 
de adicionar produto, e assim sucessivamente.
De acordo com Sommervile (2011), o quarto método a ser citado é o XP, 
mais conhecido como Extremming Programing. Criado em 1996, possui 
como princípios básicos: trabalho de qualidade, mudanças incrementais, 
feedback rápido e abraçar mudanças. A metodologia possui algumas práticas:
  Jogos de planejamento: no início da semana os clientes e developers 
(desenvolvedores) se reúnem parar priorizar funcionalidades que serão 
entregues no final da semana. Cada versão deve ser pequena.
  Propriedade coletiva: qualquer pessoa do time pode usar o código do 
programa sem precisar de permissão para alterar, assim todos têm a 
oportunidade de conhecer o código inteiro e se familiarizar com ele. 
Isso é muito importante para agilizar manutenções.
  Teste de usuário: em equipes pequenas são realizados testes do software 
por clientes e desenvolvedores da empresa para avaliar sua qualidade.
  Ritmo sustentável: as equipes devem trabalhar 40 horas, divididas em 
8 horas por dia, sem sobrecarga.
  Equipe inteira: as reuniões devem ser em pé e devem ser rápidas.
  Programação em par: um desenvolvedor mais experiente fica com um 
novato, o novato codifica e o mais experiente programa. O benefício 
deste método é que ele é revisado por duas pessoas.
  Padronizações de código: a equipe de dev (developers) determina regras 
de codificação de salvamento, bem como as boas práticas que devem 
11Métodos ágeis
ser seguidas. Assim, parecerá que foi a mesma pessoa que editou o 
código, ele ficará com uma “cara” única.
  Desenvolvimento orientado a teste: elaborar códigos de forma que 
sejam capazes de ser testados por software de teste como Imeter (um 
software que mede desempenho), Selenium (um software que mede 
erros de sites), etc. 
  Refatoração: é o processo de otimizar a estrutura do código sem alterar 
o seu comportamento externo para o usuário final.
  Integração contínua: integrar alterações de forma contínua, sem esperar 
uma semana, por exemplo. Permite saber a real situação do software 
da programação.
  Entregas curtas: entregar pequenos pedaços para o cliente corrigir e 
avaliar, aumentando a probabilidade de acertar o todo.
  Metáfora: entender a linguagem e as expressões do cliente.
  Design simples: o código deve ter exatamente o que o cliente pediu.
A quinta metodologia a ser citada é a Scrum. Ela também é citada por 
Sommervile (2011). Não citaremos todas que existem, obviamente. Vamos 
abordar alguns pontos sobre o Scrum.
  Três pessoas principais devem ser citadas:
 ■ o Product Owner, que define o que comporá o Product Backlog (lista 
de ações do Sprint) e prioriza isso nas Sprint Planning Meetings 
(reuniões de planejamento do Sprint);
 ■ o Scrum Master (geralmente um gerente ou líder técnico), que ve-
rifica se todos seguem as regras e também busca impedir trabalhos 
excessivos;
 ■ o Scrum Team é a equipe de desenvolvimento.
  No Scrum os projetos são divididos em etapas geralmente mensais. 
Pode-se dizer que são ciclos mensais. Essas etapas chamam-se Sprints. 
Cada Sprint é um Time Box, uma caixa no tempo com um conjunto 
de metas.
  No Scrum existem reuniões diárias, chamadas Daily Scrum. Elas são 
feitas no início do expediente e revisam os itens do dia anterior e de-
terminam o que será feito no dia.
  As funcionalidades são agrupadas em uma lista. Product Backlog é 
esta lista; ela contém todas as funcionalidades necessárias para um 
produto, e é feita pelo Product Owner.
Métodos ágeis12
  O Sprint Planning Meeting é uma reunião feita no início de cada Sprint. 
Nesta reunião estarão presentes o Product Owner, o Scrum Master, o 
Scrum Team e interessados. Nesta reunião o Product Owner determina 
as prioridades, e todos juntos definirão um objetivo para aquele Sprint.
  Este objetivo Sprint será revisado na Sprint Review Meeting, uma reu-
nião com o Product Owner, o Scrum Team, o Scrum Master, e algumas 
vezes com gerência e clientes, a fim de revisar o que foi atingido e o 
que não foi.
  O Release Burndown Chart é uma análise de metas atingidas no final 
de cada Sprint (iteração).
Criar um sistema básico Scrum na prática
Vamos agora criar um projeto Scrum no Trello. Neste Scrum usaremos a 
Backlog (a lista priorizada com todas as atividades que se desenvolvem para 
ter o projeto completo), o Sprint e as reuniões diárias. Vamos à prática? Abra o 
Trello, conforme a Figura 4, e clique em “Quadros” e crie um quadro chamado 
“Gerência de Softwares”.
Figura 4. Etapa 1: criação de Scrum básico, criando quadros.
Agora crie três listas, conforme Martin (2011), conforme a metodologia 
Kanban (metodologia destinada a dividir o que foi feito, o que há a fazer e 
o que estão fazendo em um painel): Feito, A fazer e Concluído, e acrescente 
mais uma chamada Backlog, e lembre-se: esta Backlog pertence ao Sprint 1. 
Veja a Figura 5.
13Métodos ágeis
Figura 5. Etapa 2: criação de Scrum básico, criando Backlog.
A Figura 6 a seguir mostra os dados de cada tarefa como se fosse um local 
para colocar os detalhes, como etiquetas, membros que participarão, prazo, 
imagens etc. Agora abra cada tarefa, adicione os dados da Figura 6, que são: 
Membros, prazo, checklist.
Figura 6. Configurando etapas Scrum.
Métodos ágeis14
No final da execução, vale a pena anotar, em comentários, qual foi a duração 
do trabalho,que pode ser 3, 4, 5 ou qualquer outra quantidade de horas — isso 
irá para o Realease Burndown, com a finalidade de analisar perfomance. 
Neste Backlog arrastamos os Sprints para suas devidas caixas e incluímos 
em frames. Veja a Figura 7.
Figura 7. Etapa 3: criação de Scrum básico, criando Backlog.
Crie agora mais dois Sprints: um chamado “reunião”, e convide os mem-
bros do time, e outro “Sprint”, para o Burndown. Cabe citar que é ideal que 
o Burndown tenha gráficos de análise de desempenho. O gráfico a seguir 
já tem um gráfico demonstrativo, mas normalmente ele é feito no final do 
Sprint. Veja a Figura 8.
Figura 8. Inclusão de reunião e de gráfico Release Burndown.
15Métodos ágeis
ABRAHAMSSON, P. et al. Agile software development methods: review and analysis. 
Espoo: VTT, 2002.
ALEGRÍA, J. H. A. et al. An MDE approach to software process tailoring. In: INTERNATIO-
NAL CONFERENCE ON SOFTWARE AND SYSTEMS PROCESS, 2011, Honolulu. Proceedings 
[…]. New York: ACM, 2011. p. 43–52.
AMARAL, D. C. et al. Gerenciamento ágil de projetos: aplicação em produtos inovadores. 
São Paulo: Saraiva, 2012.
ATLASSIAN. Jira sotware: planos e preços. c2020. Disponível em: https://www.atlassian.
com/br/software/jira/pricing. Acesso em: 15 jun. 2020. 
BECK, K. et al. Manifesto para desenvolvimento Ágil de software. c2001. disponível em: 
https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 15 jun. 2020.
CRUZ, F. Scrum e Agile em projetos: guia completo. 2. ed. Rio de Janeiro: Brasport, 2018.
ISOTANI, S.; ROCHA, R. V. Desenvolvimento Ágil. [20––]. Disponível em: https://edisci-
plinas.usp.br/pluginfile.php/3128670/mod_resource/content/1/Aula04_Desenvolvi-
mento_agil_Rafaela.pdf. Acesso em: 15 jun. 2020.
MARTIN, R. C. The clean coder: a code of conduct for professional programmers. Upper 
Saddle River: Prentice Hall, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice-Hall, 2011.
TRELLO. O Trello do seu jeito. c2020. Disponível em: https://trello.com/pricing. Acesso 
em: 15 jun. 2020.
Leituras recomendadas
CAMPOS NETTO, C. Autodesk Revit Architecture 2018: conceitos e aplicações. São Paulo: 
Érica, 2018.
LACERDA, G. S.; BARBOSA, A. B.; RIBEIRO, V. G. Adoption of CMMI and agile methodologies 
in brazilian companies. Revista Avances en Sistemas e Informática, v. 8, n. 3, p. 33–42, 2011.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto 
Alegre: AMGH, 2011.
Métodos ágeis16
Os links para sites da web fornecidos neste livro foram todos testados, e seu funciona-
mento foi comprovado no momento da publicação do material. No entanto, a rede 
é extremamente dinâmica; suas páginas estão constantemente mudando de local 
e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade sobre 
qualidade, precisão ou integralidade das informações referidas em tais links.
17Métodos ágeis
PROCESSOS DE 
DESENVOLVIMENTO 
DE SOFTWARE 
Diego Martins Polla de Moraes
Introdução ao 
método Scrum
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Definir o método Scrum e seus papéis.
  Reconhecer os principais eventos em Scrum.
  Descrever os principais artefatos em Scrum.
Introdução
A transformação digital é o assunto do momento em qualquer organi-
zação. A empresa que não está buscando meios de se reinventar através 
da transformação digital está correndo sérios riscos, inclusive no curto 
prazo. Para fazer frente a esses desafios, equipes de desenvolvimento de 
software buscam meios de entregar as soluções necessárias aos negócios, 
cumprindo os prazos (cada vez mais curtos) e o orçamento (cada vez 
mais apertado).
Neste capítulo, você vai estudar sobre o método Scrum, os papéis 
envolvidos, eventos e regras que permitem o gerenciamento ágil de uma 
equipe de desenvolvimento de software. Este conhecimento permitirá 
que você participe de times ágeis que utilizam o Scrum com condições 
de obter os melhores resultados em relação ao escopo e à qualidade 
dos produtos, aos prazos de entrega e, consequentemente, aos custos.
Uma das principais características do Scrum é o aprendizado facilitado 
do próprio método. Com um pouco de dedicação, você entenderá o 
Scrum e conseguirá aplicá-lo no seu time. Quando uma equipe passa a 
dominar o método, a sua principal característica é o autogerenciamento. 
O comprometimento mútuo faz com que equipes autogerenciáveis 
entreguem resultados inéditos.
1 Scrum e seus papéis
Scrum é um método para organização de equipes criado por Schwaber e 
Sutherland (2017), no qual um grupo de pessoas se organiza para desenvolver 
soluções para problemas complexos e adaptativos gerando produtos com alto 
valor para as organizações. O Scrum vem sendo adotado amplamente por 
equipes de desenvolvimento de software ao redor do mundo, pois sua utilização 
tem trazido resultados expressivos.
Para Pressman e Maxim (2016), os princípios encontrados no Scrum são 
coerentes com o manifesto ágil e oferecem condições de aplicar um processo 
de desenvolvimento que envolva requisitos, análise, projeto, evolução e entrega. 
O elemento-chave que faz com que o processo do Scrum seja executado é a 
Sprint. A Sprint é um espaço de tempo definido para execução de um conjunto 
de atividades.
Em sua obra, Cohn (2011) enfatiza que a adoção bem-sucedida e duradoura 
do Scrum depende de cinco principais atividades:
1. reconhecimento que o processo atual não está mais permitindo a entrega 
dos resultados esperados;
2. desejo de adotar o Scrum como meio de resolver os problemas atuais;
3. aptidão da equipe para obter êxito com o Scrum;
4. promoção do Scrum por meio de compartilhamento de boas práticas 
para reconhecer o sucesso da aplicação do método;
5. transferência das implicações do uso de Scrum para toda a empresa.
A estrutura do método Scrum consiste na associação de times aos papéis, 
na execução de eventos, na produção de artefatos e no cumprimento de suas 
regras. Por se tratar de um método ágil, enxuto, cada componente do método 
tem um motivo de existir e é essencial para o uso e sucesso da utilização do 
Scrum (PRIKLADNICKI; WILLI; MILANI, 2014).
A fundamentação do Scrum está nas teorias empíricas de controle de pro-
cesso. Schwaber e Sutherland (2017) pontuam que o conhecimento do método 
vem da experiência e a tomada de decisões é baseada neste conhecimento 
acumulado. O Scrum permite que a utilização de uma abordagem iterativa e 
incremental apresente previsibilidade e elevado controle de riscos, ampliando 
cada vez mais o conhecimento do time.
Para implementar o controle de processo empírico é necessário dar atenção 
a três pilares: transparência, inspeção e adaptação.
Introdução ao método Scrum2
  Transparência: os responsáveis pelos resultados devem ter visibilidade 
sobre os aspectos significativos do processo. Isto requer aspectos defini-
dos por um padrão comum para que, independentemente do observador, 
a leitura seja a mesma.
  Inspeção: os times que aplicam Scrum tem que inspecionar frequente-
mente os artefatos e o progresso em andamento para detectar desvios. 
É necessário haver uma dosagem na periodicidade de inspeções, para 
que não prejudique a execução das tarefas.
  Adaptação: quando é detectado algum desvio de qualidade no produto 
ou no processo, a equipe deve solucionar o mais rapidamente possível.
São características dos times de Scrum:
  auto-organizáveis;
  multifuncionais;
  criativos;
  flexíveis;
  produtivos.
O Scrum tem três papéis principais, Product Owner (PO), Scrum Master 
e Time de Desenvolvimento, que não devem ser confundidos com cargos. Os 
papéis são atribuições que cada membro envolvido no Scrum tem, e envolvem 
habilidades, responsabilidades e atribuições.
Product Owner (Dono do Produto)
Em sua obra, Prikladnicki, Willi e Milani (2014) afi rmam que o PO é responsá-
vel por representar as necessidades dos usuários do produto a ser desenvolvido 
perante o time. A tradução literal — dono do produto— representa exatamente 
o papel de um PO: ele é o guardião do produto, responsável por torná-lo um 
sucesso, utilizando o trabalho do Time de Desenvolvimento.
A principal função de um PO é o gerenciamento do backlog do produto. 
Segundo Pressman e Maxim (2016), o backlog do produto é uma lista de requi-
sitos ou funcionalidades do projeto que gerarão algum impacto nos negócios do 
cliente, ou seja, que fornecerão algum valor comercial. Schwaber e Sutherland 
(2017) apresentam um detalhamento de como o gerenciamento deve ocorrer.
  expressar de forma clara os itens do backlog do produto;
3Introdução ao método Scrum
  ordenar os itens do backlog do produto a título de prioridade para 
alcançar melhor as metas de negócios do cliente;
  garantir o reconhecimento do valor do trabalho realizado pelo Time 
de Desenvolvimento;
  garantir que o backlog do produto seja visível, transparente, claro para 
todos, e mostrando o que o time Scrum precisa trabalhar no próximo 
ciclo;
  garantir que a equipe tenha entendimento pleno dos itens do backlog 
do produto.
É importante ressaltar que o PO é uma pessoa e não um comitê. O PO pode 
ser o representante de um grupo que envolva mais pessoas, mas as decisões 
devem ser únicas. Quem precisar de uma alteração nas prioridades dos itens 
de backlog deve negociar com o PO.
Por isso para que a execução do Scrum ocorra com sucesso, toda a orga-
nização deve respeitar a atribuição e autonomia de um PO. Absolutamente 
ninguém, mesmo que de um nível hierárquico organizacional mais alto tem 
permissão para alterar as prioridades do Time de Desenvolvimento sem que 
essa decisão tenha passado pelo PO.
Scrum Master
O Scrum Master é um líder servidor para o Time Scrum. Ele atua de modo 
a garantir que o Scrum seja entendido e aplicado dentro do time. Ele atua 
como um facilitador, um apoio para o time de desenvolvimento e para o PO 
(PRESSMAN; MAXIM, 2016). O Scrum Master apoia o PO e o Time de 
Desenvolvimento de diversas formas (SCHWABER; SUTHERLAND, 2017):
  definindo técnicas para o gerenciamento do backlog do produto;
  mantendo a comunicação da visão, do objetivo e de itens do backlog 
do produto para o Time de Desenvolvimento;
  apoiando o Time de Desenvolvimento a criar itens de backlog do produto 
de forma clara;
  praticando e compreendendo a agilidade;
  sendo um facilitador dos eventos do Scrum conforme exigidos ou 
necessários;
  treinando o Time de Desenvolvimento para que ele seja autogerenciado 
e interdisciplinar;
Introdução ao método Scrum4
  exercendo a liderança do Time de Desenvolvimento na criação de 
produtos que agregam valor aos negócios;
  removendo impedimentos para o progresso das Sprints;
  planejando implantações de Scrum dentro da organização;
  ajudando colaboradores e partes interessadas a compreender e tornar 
aplicável o Scrum e o desenvolvimento de produto;
  fazendo acontecer mudanças que aumentam a produtividade do time 
Scrum;
  aumentando a eficácia da aplicação do Scrum em conjunto com outros 
Scrum Masters.
Scrum Team (Time de Desenvolvimento)
É composto pelos profi ssionais responsáveis por entregar uma versão utilizável 
que tem potencial para incrementar o produto ao fi nal de cada ciclo, que no 
Scrum é chamado de Sprint (PRIKLADNICKI; WILLI; MILANI, 2014).
Existe uma discussão sobre o tamanho ideal de um time de desenvolvi-
mento. A ideia é que ele seja grande o suficiente para entregar dentro de um 
ciclo resultados significativos para o produto, mas pequeno o bastante para 
se manter ágil. O Scrum tem uma série de eventos que envolvem o time de 
desenvolvimento, portanto uma equipe muito numerosa pode gerar eventos 
com tempo muito longo e inconclusivos. É importante ressaltar que equipes 
minúsculas, com 3 ou menos integrantes, podem ter dificuldade de ter sucesso, 
pela falta de multidisciplinaridade nas habilidades dos membros. Já equipes 
com mais de 9 membros, por sua vez, têm uma tendência de ocupar um 
tempo de trabalho de gerenciamento maior do Scrum Master (SCHWABER; 
SUTHERLAND, 2017).
Os Times de Desenvolvimento são estruturados e autorizados pela organiza-
ção para organizar e gerenciar seu próprio trabalho. Eles têm as características 
a seguir (SCHWABER; SUTHERLAND, 2017):
  São auto-organizados: o próprio Time de Desenvolvimento determina 
como transformar o backlog do produto em entregas de funcionalidades 
utilizáveis.
  São multifuncionais: para criar o incremento do produto, o time de 
desenvolvimento deve ter todas as habilidades necessárias. Devem 
fazer parte do time todas as pessoas necessárias para garantir a entrega. 
É bem comum que integrantes do Time de Desenvolvimento tenham 
5Introdução ao método Scrum
habilidades específicas, mas a responsabilidade da entrega permanece 
no time como um todo.
  O Time de Desenvolvimento é único: o time é um só e não contém 
subdivisões dedicadas a domínios específicos de conhecimento, tais 
como análise de requisitos ou testes, por exemplo.
2 Eventos do Scrum
O Scrum tem sua execução baseada em eventos que têm objetivos específi cos. 
A previsibilidade de uma série de eventos tem o intuito de criar regularidade 
e reduzir a necessidade de ocorrer outras reuniões que não são previstas no 
Scrum. Todos eventos têm uma duração máxima defi nida, priorizando a pro-
dutividade do time e evitando desperdícios (SCHWABER; SUTHERLAND, 
2017).
A Sprint é o evento concentrador do Scrum, em que todos os outros eventos 
estão contidos/vinculados. Segundo Pressman e Maxim (2016), a Sprint é um 
período definido, que deve ter no máximo 1 mês de duração, em que uma equipe 
Scrum se organizará para atingir um objetivo. O início de uma nova Sprint 
acontece exatamente quando a anterior se encerra, mantendo um ciclo vivo.
Para Schwaber e Sutherland (2017), algumas regras precisam ser conside-
radas em relação a uma Sprint.
  Uma Sprint não pode ter seu término adiado. Chegada a data fim, es-
tando o trabalho totalmente concluído ou não, deve ser formalizado seu 
encerramento. Nos eventos de encerramento da Sprint existe previsão 
para tratar do trabalho não concluído.
  Após o início da Sprint as mudanças só podem ser executadas se não 
colocarem em risco o objetivo da Sprint.
  As prioridades podem mudar a qualquer momento, mas quanto maior 
for o tamanho da Sprint, maior a chance de isso ocorrer. Por isso, a 
maioria dos times prefere utilizar Sprints com tempo de 15 dias de 
trabalho. Quando o tamanho da Sprint é muito longo, os riscos são 
potencializados, pois a necessidade de mudanças é muito mais provável.
Na Figura 1 é possível verificar como ocorre a sequência dos eventos de 
uma Sprint: primeiro, na Sprint Planning (Reunião de Planejamento) são 
selecionados itens do backlog do produto para formar o Sprint Backlog. A 
Sprint se inicia com um período entre 1 a 4 semanas, e diariamente ocorre 
Introdução ao método Scrum6
a Daily Meeting (Reunião Diária). Ao término da Sprint, para inspecionar o 
incremento do produto entregue, é executada a Sprint Review (Reunião de 
Revisão), e, para inspecionar e adaptar o processo, a Sprint Retrospective 
(Reunião de Retrospectiva). A seguir você conhecerá melhor todos os eventos 
do Scrum: Reunião de Planejamento da Sprint; Reunião Diária; Revisão da 
Sprint; Retrospectiva da Sprint.
Figura 1. O ciclo do Scrum representando a ordem de execução dos eventos e os artefatos 
gerados.
Fonte: Scrum.org (c2019, documento on-line).
Sprint Retrospective
Sprint Review
Sprint
1–4 Semanas
Daily Scrum
Sprint Planning
Backlog Sprint Backlog Incremento
do Produto
24h
Sprint Planning (reunião de planejamento)
A reunião de planejamento é o marco de início de uma Sprint. Nesta reunião, 
com a presença do PO, do Scrum Master e do Time de Desenvolvimento, o 
backlog do produto será avaliado e o time determinará o que pode ser entregue 
como incremento do produto nessa Sprint e como o trabalho para realizar 
esta entrega deve ser organizado (COHN, 2011). Para que isso ocorra,o PO 
deve manter em dia todas suas atividades de gerenciamento de backlog. Ele 
deverá apresentar ao Time de Desenvolvimento, em ordem de prioridade, o 
que são os objetivos da Sprint. Cabe ao Time de Desenvolvimento avaliar a 
quantidade de itens que poderão ser completados dentro do período da Sprint 
(SCHWABER; SUTHERLAND, 2017).
Para que o time possa realizar essa definição, ele precisa determinar a sua 
capacidade e produtividade dentro de uma Sprint. O time deverá determinar 
como pretende executar todas as atividades para permitir realizar as entregas 
da Sprint. Neste momento, o PO pode auxiliar a detalhar itens do backlog em 
7Introdução ao método Scrum
que o time tenha dúvidas. A oportunidade de o time se tornar auto-organizável 
está neste evento. Todos têm oportunidade de discutir o plano a ser executado 
na Sprint para permitir o sucesso.
Na conclusão de uma Sprint Planning, todos deverão estar alinhados com o 
objetivo da Sprint, com a lista completa dos itens que serão executados dentro 
daquele período, que se chama Sprint Backlog.
Daily Meeting (reunião diária)
A reunião diária, como seu próprio nome menciona, deve ocorrer em todos os 
dias de trabalho. Este evento deve ter até 15 minutos de duração e ocorrer no 
mesmo lugar e horário (trazendo simplicidade). O Scrum Master é responsável 
por este evento acontecer, mas quem deve conduzi-la é o próprio Time de 
Desenvolvimento (PRIKLADNICKI; WILLI; MILANI, 2014).
A ocorrência da reunião diária tem por objetivo reduzir a necessidade de 
outras interações e concentrá-las, num momento único. Schwaber e Sutherland 
(2017) sugerem que com a equipe reunida, cada membro do time deverá, de 
forma estruturada ou não, responder às perguntas a seguir.
  O que eu executei ontem com o intuito de atingir a meta da Sprint?
  O que eu pretendo executar hoje com o intuito de atingir a meta da 
Sprint?
  Eu estou com algum impedimento para executar minhas atividades 
ou enxergo algum impedimento para que o time atinja seus objetivos?
Quando algum membro identifica a necessidade de obter um detalhamento 
maior, ou até mesmo oferecer um auxílio na remoção de algum impedimento, 
deve tratá-lo após a reunião diária, com o envolvimento apenas dos membros 
necessários, que fazem parte daquela situação. Isso faz com que o tempo da 
reunião seja mantido, e por consequência a produtividade do time (SCHWA-
BER; SUTHERLAND, 2017). 
Nesta reunião, o time exercita os princípios da inspeção e adaptação — 
pois todos conseguem obter informações sobre os andamentos dos trabalhos 
e podem discutir meios de manter o rumo em direção ao objetivo da Sprint.
Introdução ao método Scrum8
Sprint Review (reunião de revisão da Sprint)
Na reunião de revisão da Sprint, todo o trabalho concluído durante o período 
da Sprint será evidenciado pelo time. Participam desta reunião o time e as 
partes interessadas que são convidadas pelo PO (COHN, 2011).
Segundo Schwaber e Sutherland (2017), o PO apresenta quais itens do 
backlog foram considerados prontos na Sprint, e quais não ficaram prontos. 
O time deve discutir os problemas que ocorreram durante a Sprint, o que pôde 
ser resolvido, o que ocorreu bem.
Para os itens que não ficaram prontos, é necessário tomar algumas decisões: 
Os que não foram iniciados, ou seja, nenhum esforço da equipe foi despendido, 
se mantêm necessários? Redefinir a prioridade desses itens é essencial. Agora, 
para os itens que tiveram algum progresso mas que não foram concluídos o 
time deve determinar a quantidade de trabalho necessária para concluí-lo na 
próxima Sprint. Também é o momento para se discutir os próximos passos; 
revisar o backlog do produto e identificar prováveis novas metas, incluindo 
orçamento e escopo do produto para as próximas versões.
Ao fim de uma reunião de revisão da Sprint o backlog do produto deve 
estar revisado, contendo os prováveis itens para a próxima Sprint.
Sprint Retrospective (reunião de retrospectiva da 
Sprint)
A Retrospectiva da Sprint é o momento em que o Time Scrum terá opor-
tunidade de inspecionar a si mesmo e traçar um plano de melhorias para 
serem aplicadas na próxima Sprint. O objetivo da retrospectiva da Sprint é 
evidenciar e incentivar a continuidade de práticas que foram benéfi cas para o 
time e o andamento da Sprint, além de discutir e apresentar alternativas para 
as situações que foram prejudiciais.
Para Schwaber e Sutherland (2017), o propósito da Retrospectiva da Sprint é:
  inspecionar como a Sprint ocorreu em relação às pessoas, aos relacio-
namentos, aos processos e às ferramentas;
  identificar e ordenar os principais itens que foram bem e as potenciais 
melhorias;
  traçar um planejamento para implementar melhorias no modo que o 
Time Scrum faz seu trabalho.
9Introdução ao método Scrum
Ao final da Retrospectiva da Sprint, o Time Scrum terá identificado as 
melhorias que serão implementadas na próxima Sprint. Isto passa a ser um 
compromisso, mais uma vez firmando o conceito de auto-organizável. As 
melhorias podem ser implementadas a qualquer momento, mas a reunião de 
retrospectiva e as ações decorrentes dela farão com que o processo de inspeção 
e adaptação se torne institucionalizado.
Apesar do Scrum ser de fácil entendimento, a sua aplicação, com resultados efetivos, 
leva um certo tempo. A organização e a equipe têm que ter em mente que precisam 
rodar vários ciclos até adaptar o seu meio de trabalho para obter resultados expressivos. 
É comum que equipes que tiveram resultados ruins em duas ou três primeiras Sprints 
abandonem o método afirmando que ele não funciona. Mas o aprendizado do Scrum 
vem exatamente das experiências obtidas em cada ciclo.
3 Artefatos do Scrum
O Scrum é um método que permite a execução de um processo. Todo processo 
utiliza artefatos como saídas e entradas de atividades. Eles são a representação 
do trabalho da equipe, e permitem que as características de transparência, 
inspeção e adaptação do Scrum sejam evidenciadas.
Backlog do produto
Segundo Schwaber e Sutherland (2017), o backlog do produto é composto 
por todas as necessidades de desenvolvimento do produto através da visão do 
cliente. Prikladnicki, Willi e Milani (2014), por sua vez, afi rmam que somente 
o PO pode inserir, remover ou reordenar a prioridade de itens. O backlog do 
produto é um documento vivo, e nunca estará completo. O PO interagirá cons-
tantemente com as partes interessadas do produto a fi m de manter este backlog 
priorizado, atualizado e evoluindo (SCHWABER; SUTHERLAND, 2017).
Na Figura 2, temos um exemplo de um backlog de produto de um software 
de controle de estoque. Nele estão listados uma série de requisitos funcio-
nais que o software deve atender. O PO deve manter esta lista priorizada e 
atualizada, com todas as necessidades do cliente.
Introdução ao método Scrum10
Figura 2. Um exemplo do backlog de um produto de software de controle de estoque.
Backlog da Sprint
O backlog da Sprint é o conjunto de itens do backlog do produto selecionados 
para serem desenvolvidos durante a Sprint. Ele também contém o plano para 
tornar aquele backlog em um produto real e utilizável pelo cliente (PRIKLAD-
NICKI; WILLI; MILANI, 2014).
Somente o time de desenvolvimento tem autonomia para alterar os itens de 
backlog durante uma Sprint. Isso é necessário pois o time tem o controle do 
andamento das atividades e poderá decidir se algo pode ser alterado, paralisado 
ou adicionado (SCHWABER; SUTHERLAND, 2017).
Na Figura 3, podemos observar uma lista de itens do backlog do produto, 
selecionadas para serem desenvolvidas na Sprint 001. Esta seleção ocorre 
na reunião de planejamento mediante a análise da capacidade de entrega da 
equipe versus os itens do backlog do produto em ordem de prioridade. Quando 
a Sprint é executada com sucesso, os itens do backlog da Sprint passam a 
fazer parte do Incremento do Produto e podem ser utilizados pelos usuários.
Figura 3. Um exemplo de backlog da Sprint, com itens selecionados do backlog de um 
produtode software de controle de estoque.
11Introdução ao método Scrum
Quadro Kanban
O quadro Kanban é uma ferramenta de gestão visual que representa a carac-
terística de transparência do Scrum. Através de um quadro de tarefas, que 
pode ser físico ou digital, a equipe visualiza os itens a serem desenvolvidos e 
seu andamento (PRIKLADNICKI; WILLI; MILANI, 2014).
A divisão das colunas do quadro, que são os espaços em que os itens 
podem ser alocados, geralmente é entre “Backlog”, “A fazer”, “Fazendo” e 
“Pronto”. Estas divisões também podem ser personalizadas de acordo com a 
necessidade da equipe, mas devem seguir a tendência do ágil — simplicidade.
Incremento
Espera-se que ao fi nal de cada Sprint o time de desenvolvimento entregue uma 
nova versão do produto que contenha os itens do backlog da Sprint para uso 
pelo cliente. A equipe de desenvolvimento deve ter a visão que o cliente pode 
decidir por publicar em produção aquele incremento do produto, portanto sua 
qualidade deve estar ajustada às necessidades do cliente (PRIKLADNICKI; 
WILLI; MILANI, 2014).
Definição de pronto
Este conceito é muito importante numa equipe Scrum. Podem existir vários 
entendimentos do que seja “Pronto” para um item do Sprint backlog. Para um 
determinado membro do time a defi nição de pronto pode signifi car que o item 
foi acoplado ao código fonte sem causar erros. Já na visão de um tester, pode 
signifi car “sem bugs”. E na visão de um analista de negócios, que atende às 
necessidades do cliente (SCHWABER; SUTHERLAND, 2017).
É, no entanto, o consenso em torno desta definição que balizará a decisão 
de quantos itens podem ser selecionados na reunião de planejamento. Afinal, 
toda a equipe terá o mesmo entendimento do que é o “pronto”, permitindo 
assim definir o quanto de capacidade produtiva a equipe possui. Com um 
time de Scrum em constante evolução, é esperado que a definição de “pronto” 
também siga evoluindo, considerando cada vez mais critérios de qualidade.
Introdução ao método Scrum12
O Scrum pode e deve ser implantado nos mais diversos ambientes organizacionais, 
até mesmo nos mais tradicionais. A prova disso é o que aconteceu no Departamento 
Federal de Investigação dos Estados Unidos (FBI) com o projeto Sentinel. Depois de 
10 anos atuando neste projeto que estava perto do seu cancelamento, decidiu-se por 
adotar o Scrum como última medida (SUTHERLAND, 2016).
O backlog do produto foi organizado em 670 histórias de usuário que foram de-
senvolvidas em 21 Sprints com 15 dias de duração. Se ao final da Sprint nem todas 
histórias estavam prontas, mesmo assim a equipe apresentava as histórias finalizadas, 
e apenas as que passassem nos testes eram dadas como concluídas. Desta forma o 
projeto foi concluído cumprindo as metas de escopo, custo e prazo (REBELO, 2012).
O projeto foi tão bem-visto dentro do governo americano, que outros órgãos de-
cidiram adotar o Scrum, como o Departamento de Defesa, o Gabinete de Prestação 
de Contas do Governo, a Nasa, o Escritório de Patentes e Marcas, o Departamento 
de Relacionamento dos Veteranos e a Secretaria da Receita Federal (REBELO, 2012).
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com 
sucesso. Porto Alegre: Bookman, 2011. 
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 
8. Porto Alegre: AMGH, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software. 
Porto Alegre: Bookman, 2014.
REBELO, P. Agile no FBI: fazendo em 2 anos o que não se conseguiu em 10. InfoQ, [s. 
l.], 14 nov. 2012. Disponível em: https://www.infoq.com/br/news/2012/11/agile-fbi/. 
Acesso em: 22 maio 2020.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum: um guia definitivo para o Scrum: as 
regras do jogo. [S. l.: s. n.], 2017. Disponível em: https://www.scrumguides.org/docs/scru-
mguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf. Acesso em: 22 maio 2020.
SCRUM.ORG. What is Scrum? A better way of building products. c2019. 1 ilustração. 
Disponível em: http://revistas.poli.br/index.php/repa/article/view/1234/531. Acesso 
em: 22 maio 2020.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. 2. 
ed. São Paulo: Leya, 2016.
13Introdução ao método Scrum
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
Introdução ao método Scrum14
PROCESSOS DE 
DESENVOLVIMENTO 
DE SOFTWARE 
Diego Martins Polla de Moraes
A equipe e sua 
estrutura em Scrum
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Identificar como é a estrutura da equipe em um projeto Scrum.
  Relacionar a colaboração em um projeto Scrum e a responsabilidade 
compartilhada entre a equipe.
  Reconhecer o papel dos especialistas em um projeto Scrum.
Introdução
Desenvolver software é uma tarefa complexa, e o método Scrum traz uma 
série de mecanismos para tornar as equipes mais produtivas e eficientes. 
A implantação do Scrum exige uma mudança muito forte em relação à 
gestão das equipes, principalmente dos altos níveis gerenciais, da gestão 
tradicional, do comando e controle para a auto-organização. 
Desde a discussão em relação ao tamanho da equipe até a decisão 
da inclusão de especialistas, o Scrum proporciona um ambiente para 
que as equipes se tornem autogerenciáveis e multifuncionais. Apesar 
disso, não existem fórmulas que se apliquem a qualquer equipe. Neste 
capítulo, você estudará sobre o assunto e verá estratégias para lidar com 
as equipes Scrum.
1 Estrutura da equipe em um projeto Scrum
Há muito que se discutir em relação a como um grupo de pessoas pode se 
organizar para desenvolver um trabalho específi co. Com desenvolvimento de 
software não é diferente, e principalmente por ser um trabalho essencialmente 
intelectual, os desafi os são ainda maiores.
Uma equipe de desenvolvimento de software deve ser consistente. É um 
grupo de pessoas trabalhando em conjunto, onde o todo é maior que a soma das 
partes. Existem alguns atributos que são geralmente encontrados em equipes 
de desenvolvimento de software eficazes (PRESSMAN; MAXIM, 2016): 
  senso de propósito; 
  senso de envolvimento;
  senso de confiança;
  senso de melhoria.
Na sequência serão apresentados cada um destes atributos, e veremos como 
o Scrum os proporciona para uma equipe (PRESSMAN; MAXIM, 2016).
Senso de propósito: está vinculado a todos os membros concordarem com 
um propósito específi co. O Scrum facilita isto através do envolvimento efetivo 
da equipe na defi nição do objetivo da Sprint.
Senso de envolvimento: signifi ca que os membros da equipe sentem que suas 
contribuições e suas qualidades têm importância. Dentro do Scrum isso está 
presente em todos os eventos nos quais o time é envolvido — responsável por 
defi nir o planejamento, acompanhar o andamento e, no fi nal, apresentar os 
resultados e rever o processo.
Senso de confi ança: a equipe deve confi ar nas habilidades e na competência de 
seus pares. A ideia de possuir uma equipe multidisciplinar e auto-organizável 
propicia um ambiente de confi ança mútua.
Senso de melhoria: a equipe deve manter revisões periódicas da sua maneira 
de trabalhar a engenharia do software e seu processo. O Scrum propicia que a 
cada ciclo a equipe tenha a oportunidade de praticar a melhoria contínua, na 
reunião de revisão da Sprint e de retrospectiva, e defi nindo estratégias para 
os planos de ação na reunião de planejamento. 
No Scrum as equipes são auto-organizadas e decidem sozinhas a me-
lhor forma de realizar o seu trabalho. Essas equipes são multifuncionais e 
têm capacidade de ser autossuficientes. Uma equipe de desenvolvimento em 
Scrumé responsável por entregar incrementos de produto, levando em conta 
a definição de “pronto” que a equipe definiu. Além disso, a equipe deve ser 
capaz de estimar o tamanho dos itens do backlog do Produto, com o intuito 
de selecioná-los para definir o backlog da Sprint e, consequentemente, seu 
objetivo (PRIKLADNICKI; WILLI; MILANI, 2014).
A equipe e sua estrutura em Scrum2
Segundo Schwaber e Sutherland (2017), ninguém precisa orientar como uma 
equipe Scrum transforma o backlog do produto em incrementos do produto 
potencialmente utilizáveis pelos usuários, ou seja, uma equipe Scrum deve 
ser capaz de definir sua própria estratégia para que, a partir da necessidade 
do usuário, consiga entregar-lhe um software em funcionamento.
Uma das maiores discussões em relação à formação de uma equipe Scrum 
é o seu tamanho. O guia do Scrum é bem claro em relação a isso: entre 3 a 9 
integrantes, sem contar o product owner e o Scrum Master, a não ser que eles 
também executem trabalho para entregar o backlog da Sprint. Este tamanho 
é determinado baseado no que se espera de uma equipe Scrum. Uma equipe 
muito pequena terá dificuldade de cobrir todas as habilidades e especialidades 
necessárias para transformar os itens do backlog do produto em software pronto. 
Por outro lado, uma equipe com muitos membros tornará o trabalho de geren-
ciamento complicado em virtude de (SCHWABER; SUTHERLAND, 2017): 
  quantidade de pessoas nos eventos;
  senso de pertencimento diminuído;
  organização de entregas dificultada.
Em sua obra, Cohn (2011) chama atenção para o fato desses limites de 
tamanho não serem levados tão à risca. Suponha que você tem uma equipe 
Scrum com 10 pessoas. Isso significa que o limite foi desrespeitado. Na Figura 
1 você pode verificar a representação de um time Scrum com 10 pessoas, um 
product owner, um Scrum Master e a execução de um evento de cada tipo, 
exceto a reunião diária.
Figura 1. Representação de um time Scrum com 10 membros.
3A equipe e sua estrutura em Scrum
Se seguirmos a regra do guia do Scrum e da maioria dos estudiosos do 
assunto, teríamos que dividir esta equipe. Será que dividir em duas equipes, 
com cinco integrantes cada, vai gerar um resultado melhor? Na Figura 2, esta 
divisão é representada. Neste caso, o product owner e Scrum Master teriam 
que dividir a atenção entre as duas equipes. Além disso, todos os eventos 
ocorreriam duas vezes. Esta representação é para fazer você refletir que o 
tamanho sugerido é uma orientação. Deve-se estudar o contexto do seu projeto 
e definir conforme o cenário que traz mais desempenho. Isso será possível 
através de inspeção e adaptação, presentes no planejamento e retrospectiva 
constantes do time nas Sprints.
Figura 2. Representação de dois times Scrum com cinco membros cada.
No seu estudo, COHN (2011) apresenta as vantagens das equipes pequenas.
Diminui a ociosidade social: existe uma tendência de as pessoas diminuírem o 
esforço quando acreditam que outras pessoas assumirão as responsabilidades. 
Há um senso de responsabilidade pessoal mais apurado em uma equipe pe-
quena, pois os membros estão mais próximos, compartilham mais informações 
e estão mais ligados ao resultado.
Interações construtivas: equipes com mais de 12 pessoas têm difi culdades 
para criar relacionamento de confi ança, responsabilidade mútua e coesão.
A equipe e sua estrutura em Scrum4
Menos tempo gasto com gestão: planejar os eventos e coordenar a comuni-
cação com uma equipe menor é muito mais rápido.
Todos têm oportunidade de participar: em equipes maiores, há uma partici-
pação menor de cada membro em discussões em grupo. São muitas pessoas para 
falar e, por vezes, existe uma disparidade entre espaços de fala e protagonismo 
entre os membros da equipe.
Satisfação individual é maior: existe uma tendência dos membros das equipes 
menores de se sentirem mais responsáveis, pois suas contribuições são mais 
visíveis e signifi cativas.
Tendência de multifuncionalidade: em uma equipe menor, não há muito 
espaço para alguém que só faça uma função, ou seja, tenha uma única especia-
lidade. Todos tendem a executar mais funções com o objetivo de transformar 
itens de backlog em software pronto.
Para formar uma equipe Scrum, deve-se considerar alguns fatores (COHN, 
2011): 
  incluir todas as áreas de atuação necessárias para que o time seja 
realmente multifuncional; 
  equilibrar os níveis de habilidade técnica para que os membros mais 
experientes façam atividades de acordo com a habilidade e não se sintam 
entediados em trabalhar em atividades mais básicas, estas executadas 
pelos mais iniciantes;
  equilibrar os níveis de conhecimento sobre o negócio para que os times 
tenham acesso a este conhecimento e garantir que ele seja disseminado 
na empresa; 
  buscar a diversidade, pois equipes heterogêneas têm uma tendência de 
levar mais tempo para tomar decisões, mas costumam ter uma visão 
de diversas perspectivas, e estas decisões consideram isso. 
5A equipe e sua estrutura em Scrum
As equipes de desenvolvimento de software precisam lidar constantemente com 
urgências. A pergunta é: como lidar com o atendimento de uma urgência que só 
poderá ser planejada num período específico, já que o Scrum prescreve ciclos de 
Sprint planejados entre 7 a 30 dias?
Quando a quantidade de urgências é muito grande, tornando impossível a conciliação 
com as atividades da Sprint, a sugestão é que se crie uma equipe paralela para tratar 
as urgências, o que Kniberg (2007) chama de “equipes de bombeiros”. Uma equipe de 
bombeiros blindará o time Scrum de uma série de intervenções, como correções de 
bugs e melhorias urgentes, e podem atuar na prevenção de novas falhas. 
Se for necessário criar uma equipe de bombeiros, lembre-se de dividir membros 
experientes entre a equipe Scrum e a equipe de bombeiros, e de criar uma rotina de 
rodízio entre as equipes. Assim, cada uma enxerga a realidade do projeto como um todo.
2 Time Scrum: auto-organizável e colaborativo
O manifesto ágil deixa bem claro a importância que a equipe tem para o 
desenvolvimento de software. Como você pode verifi car a seguir, entre os 12 
princípios ágeis, cinco falam diretamente sobre a equipe (BECK et al., c2001):
  pessoas de negócio e desenvolvedores devem trabalhar diariamente em 
conjunto por todo o projeto;
  construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente 
e o suporte necessários e confie neles para fazer o trabalho;
  o método mais eficiente e eficaz de transmitir informações para uma 
equipe de desenvolvimento é através de conversa face a face;
  as melhores arquiteturas, requisitos e designs emergem de equipes 
auto-organizáveis;
  em intervalos regulares, a equipe reflete sobre como se tornar mais 
eficaz, e então refina e ajusta seu comportamento de acordo com esta 
percepção.
O Scrum, através dos seus papéis e eventos, proporciona às suas equipes um 
cenário adequado para que estes princípios possam ser vivenciados na prática.
Em sua obra, Cohn (2011) ressalta um ponto muito relevante em relação 
à equipe Scrum: não existe trabalho individual, existe o trabalho da equipe. 
A equipe e sua estrutura em Scrum6
Portanto o sucesso ou fracasso nunca é atribuído de forma individual, e sim 
reconhecido pela equipe como um todo.
Você pode pensar, por exemplo, que um código fonte limpo, bem escrito e com 
qualidade deve ser responsabilidade única e exclusiva dos programadores. Mas e 
se um testador identificar alguma funcionalidade que tem uma alta incidência de 
problemas e montar algum tipo de cenário de testes para ajudar os programadores 
a testar o código de uma forma mais apurada? É este tipo de abordagem que o 
Scrum proporciona. Não interessa exatamente o papel mais específico que cada 
um exerce, mas o que cada um pode fazer para que a equipe em conjunto entregue 
o resultado esperado no prazo e com qualidade (COHN, 2011).
Para reforçar este conceito, Cohn (2011) afirma que a única forma de criar 
um ambiente em que a responsabilidadeé compartilhada é acabar com a ideia 
de que é preciso culpar alguém. Afirmar isso não significa que não haja um 
responsável, e sim que, em uma equipe de sucesso, os membros fazem a sua 
parte e vão até mesmo além do papel que se vinculam a fim de garantir que 
a equipe alcance seus objetivos.
Uma equipe Scrum é auto-organizável. Mas será que um time Scrum é 
auto-organizável já no primeiro dia que começa a executar o método? Quando 
você poderá ter certeza de que seu time é auto-organizável e a empresa para 
a qual atua o reconhece assim? 
Ao conhecerem o Scrum, diretores e gerentes de empresas costumam fazer 
as perguntas a seguir (COHN, 2011).
  Se eles determinam como trabalhar e quanto tempo levam, irão reduzir 
a velocidade e entregar menos, afinal não tem ninguém cobrando?
  Se a responsabilidade é da equipe, ninguém se responsabilizará? Todos 
repassarão a responsabilidade para outro?
  Se eles se autogerenciam, para que eu vou servir?
A resposta para estas perguntas vem da maturidade na utilização do método. 
É natural que a adaptação ao método Scrum cause estas dúvidas a todos, não 
só à alta gerência. Mas a verdade é que numa equipe de desenvolvimento de 
software não há méritos ou culpas individuais, o trabalho é executado em con-
junto e o time deve ser responsabilizado como um todo. O apoio das gerências 
funcionais para utilização do Scrum, seguindo suas regras e investimento na 
melhoria contínua, dará ao time cada vez mais autonomia.
No Scrum, o sentimento de pertencimento e de responsabilidade dos mem-
bros da equipe começa na reunião de planejamento. Naquele momento o time 
será responsável por determinar quanto tempo e como realizará o trabalho para 
7A equipe e sua estrutura em Scrum
concluir um item de backlog. Veja como isso faz toda a diferença: ao invés de 
um gerente determinar à equipe como ela deve se organizar e quanto tempo 
levará para executar uma atividade, a própria equipe faz isso. A tendência é que 
as pessoas se comprometam muito mais com algo que elas mesmo planejaram. 
Se alguém determinar o modo de realizar uma tarefa e o tempo que você deve 
levar para executá-la, se você não conseguir seguir aquele plano, ou atrasar 
a entrega, é bem provável que simplesmente culpe quem o delegou. Agora, 
se você mesmo determinou o modo de trabalho e o tempo necessário, se não 
conseguir cumprir, irá procurar os motivos por que isso ocorreu e uma forma 
de evitar que aconteça novamente (COHN, 2011).
Na reunião de retrospectiva, conforme afirmam Schwaber e Sutherland 
(2017), a equipe irá identificar as práticas que devem ser continuadas e estimu-
ladas, o que deve ser revisto e o que não deve ser repetido. É o momento para 
que a própria equipe corrija seu modo de trabalhar. Dessa forma o time pratica 
a melhoria contínua, aplicando na próxima Sprint os planos de ação definidos. 
A realização dos eventos do Scrum pela equipe é o ponto crucial para que o trabalho seja 
executado e o processo, aprimorado. A retrospectiva é um evento muito importante, 
pois traz a oportunidade de a equipe se autoavaliar e propor formas de melhorar 
sua performance. Por ser um evento que consiste em uma reunião com toda equipe, 
é importante que ocorra de forma célere e produtiva. Leia o artigo “5 passos para 
melhorar as dinâmicas para retrospectivas Scrum”, de Lauren Moon, para conhecer 
formas de otimizar sua reunião de retrospectiva. 
3 Especialistas ou generalistas em uma equipe 
Scrum?
Schwaber e Sutherland (2017) dizem que o time Scrum é autossufi ciente e 
multifuncional. Isso por acaso signifi ca que todos membros serão generalistas 
e deverão saber fazer tudo? Veremos a seguir.
Desenvolvimento de software é uma atividade muita complexa, que envolve 
muitas habilidades, formações e conhecimento sobre tecnologias específicas, 
e exigir que todos os membros da equipe tenham esses requisitos é inviável. 
Torna o custo da equipe altíssimo. 
A equipe e sua estrutura em Scrum8
Em uma equipe, sempre existirão pessoas especializadas em determinadas 
atividades, tecnologias ou áreas de negócio específicas. O convite que o Scrum 
faz é que elas não se isolem. Em equipes tradicionais, a tendência é que um 
especialista sempre seja demandado para executar as atividades dentro da sua 
especialidade: ele executará rápido, sem muitas perguntas, e com qualidade, 
considerando toda sua experiência. O Scrum sugere que as equipes criem 
um ambiente de compartilhamento, para que este especialista aos poucos 
repasse esse conhecimento a outros membros da equipe. Assim, se em uma 
determinada Sprint houver uma demanda alta daquele tipo de atividade, outros 
membros podem ser envolvidos e permitir que a equipe faça aquela entrega, 
sem sobrecarregar o especialista.
Um dos maiores exemplos disso, e uma das grandes dúvidas em relação às 
equipes Scrum, é a inclusão ou não de especialistas em qualidade de software na 
equipe. Se a definição de “pronto” do time diz que o incremento é um software 
funcionando, como garantir isso sem uma pessoa especializada em qualidade?
Na Figura 3, você pode visualizar a representação de uma Equipe Scrum 
sem especialista em qualidade de software. Esta equipe só tem desenvolvedores 
de software, programadores. Eles não têm nenhuma habilidade específica de 
testes, mas se comprometeram com a qualidade do software. Eles executam 
testes sempre que acabam uma funcionalidade, mas às vezes não têm tempo 
para isso, pois a maior parte do tempo deles é utilizada com o que mais 
gostam e saber fazer: desenvolver código. O software é liberado com muitos 
bugs, os testes deles são muito viciados, sem uma estrutura, um pensamento 
como usuário.
Figura 3. Equipe Scrum sem um especialista em qualidade.
9A equipe e sua estrutura em Scrum
Já na Figura 4, é retratada uma Equipe Scrum com especialista em qualidade 
de software. Esta equipe tem um desenvolvedor a menos que a anterior — que 
foi substituído pelo especialista em qualidade de software. A pergunta que 
você pode fazer é: enquanto os desenvolvedores não entregaram nenhuma 
funcionalidade testável, o que o especialista em qualidade faz? A resposta é 
simples: ele planeja como executar os ensaios de qualidade, e pode inclusive 
se especializar em testes automatizados e apoiar a equipe em decidir sobre 
detalhes de regras e experiência do usuário. Ele também deve ser responsá-
vel por disseminar este conhecimento com os outros membros do time, que 
continuam responsáveis pela qualidade.
Figura 4. Equipe Scrum com um especialista em qualidade.
Leia o artigo “Garantia de qualidade no Scrum: muito além dos testes”, de Priyanka 
Hasija, em que é apresentado de que forma a garantia de qualidade pode levar um 
time Scrum a ótimos resultados.
A equipe e sua estrutura em Scrum10
BECK, K. et al. Manifesto ágil: manifesto para o desenvolvimento ágil de software. 
c2001. Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso 
em: 3 jun. 2020.
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com 
sucesso. Porto Alegre: Bookman 2011. 
KNIBERG, H. Scrum e XP direto das Trincheiras: como nós fazemos Scrum. [S. l.]: InfoQ, 2007.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: AMGH, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. (Org.). Métodos ágeis para desenvolvimento de 
software. Porto Alegre: Bookman, 2014.
SCHWABER, K.; SUTHERLAND, J. Um guia definitivo para o Scrum: as regras do jogo. [S. l.: s. 
n.], 2017. Disponível em: https://www.Scrumguides.org/docs/Scrumguide/v2017/2017-
-Scrum-Guide-Portuguese-Brazilian.pdf. Acesso em: 3 jun. 2020.
Leituras recomendadas
HASIJA, P. Garantia de qualidade no Scrum: muito além dos testes. muito além dos 
testes. 2012. Disponível em: https://www.infoq.com/br/articles/experience-qa-Scrum/. 
Acesso em: 3 jun. 2020.
MOON, L. 5 passos para melhorar as dinâmicas para retrospectivas Scrum. 2015. Disponível 
em: https://blog.trello.com/br/dinamicas-retrospectivas-Scrum. Acesso