Fundamentos do SCRUM

Prévia do material em texto

Rodrigo Alves Costa
Fundamentos 
do Scrum
A RNP – Rede Nacional de Ensino 
e Pesquisa – é qualificada como 
uma Organização Social (OS), 
sendo ligada ao Ministério da 
Ciência, Tecnologia e Inovação 
( M C T I ) e r e s p o n s á v e l p e l o 
Programa Interministerial RNP, 
que conta com a participação dos 
ministérios da Educação (MEC), da 
Saúde (MS) e da Cultura (MinC). 
Pioneira no acesso à Internet no 
Brasil, a RNP planeja e mantém a 
rede Ipê, a rede óptica nacional 
acadêmica de alto desempenho. 
Com Pontos de Presença nas 
27 unidades da federação, a rede 
tem mais de 800 instituições 
conectadas. São aproximadamente 
3,5 milhões de usuários usufruindo 
de uma infraestrutura de redes 
avançadas para comunicação, 
computação e experimentação, 
que contribui para a integração 
entre o sistema de Ciência e 
Tecnologia, Educação Superior, 
Saúde e Cultura. 
Rodrigo Alves Costa
Fundamentos 
do Scrum
Fundamentos 
do Scrum
 
Rodrigo Alves Costa
Rio de Janeiro
Escola Superior de Redes
2016
Copyright © 2016 – Rede Nacional de Ensino e Pesquisa – RNP 
Rua Lauro Müller, 116 sala 1103 
22290-906 Rio de Janeiro, RJ
Diretor Geral 
Nelson Simões
Diretor de Serviços e Soluções 
José Luiz Ribeiro Filho
Escola Superior de Redes
Coordenador Nacional 
Leandro Marcos Oliveira Guimarães
Edição 
Lincoln da Mata
Coordenador Acadêmico da Área de Governança de TI 
Edson Kowask Bezerra
Equipe ESR (em ordem alfabética) 
Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlinéa Miranda, Elimária Barbosa, 
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato , 
Renato Duarte e Yve Marcial.
Capa, projeto visual e diagramação 
Tecnodesign
Versão 
1.0.0
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de 
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e 
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a 
pessoas ou bens, originados do uso deste material. 
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
iii
Sumário
1. Introdução
A importância da informação e a crise do software  1
Crise do software 2
Por que se tornar ágil vale a pena?  3
Exercício de fixação – Como você entende que o Scrum pode melhorar a produtividade na 
sua organização? 7
Processo Scrum 8
Papéis, fluxo e artefatos do Scrum 9
Papéis do Scrum 9
Exercício de fixação – Na sua organização, que papéis atuais poderiam ocupar os papéis do 
Scrum em uma eventual transição para Scrum? 9
Fluxo do Scrum 9
Visão Scrum 13
Transparência 14
Inspeção 14
Adaptação 14
Scrum e processos de desenvolvimento 14
Exercício de fixação – O que você acha que precisa mudar na mentalidade da sua organiza-
ção para adotar um processo de gestão de projetos ágil como o Scrum? 15
Introduzindo um processo ágil em uma organização  16
Desenvolvedores 16
Realizando a transição de um processo peso-pesado 16
Scrum Escalável 17
Atividades práticas – Cenário para escolha sobre um processo a ser adotado  18
iv
2. O Scrum
Fase de especificação 19
Fase de projeto 20
Fase de implementação 20
Fase de teste 20
Fase de manutenção 21
Metodologias de desenvolvimento tradicionais: 
vantagens e desvantagens 21
Vantagens e desvantagens 22
Exercício de fixação – Que metodologias de desenvolvimento são utilizadas na sua organização? 
Você enxerga vantagens e desvantagens no seu uso? Quais? 23
Metodologias de Ágeis de Projetos 23
Software Funcional em vez de Documentação Detalhada 24
Colaboração ao cliente em vez de negociação de contratos 24
Indivíduos e iterações em vez de somente processos e ferramentas 25
Responder à mudanças x planos detalhados 25
Velocidade e qualidade 26
Vantagens e desvantagens 26
Exercício de fixação – Você acredita que a sua organização e os seus clientes se beneficia-
riam da adoção de uma metodologia como o Scrum? 27
Histórico do Scrum 27
Toyota, uma grande influência para o Scrum 27
Exercício de fixação – Como eliminar a restrição tripla na sua organização? 28
Exercício de fixação – Você acredita ser possível ter uma equipe auto-organizável na sua 
organização? Qual o contexto para possibilitar tal auto-organização? 29
Origem do nome 29
O processo 31
Empírico 31
Iterativo e incremental 32
Fases do Scrum 32
Tamanho de projetos 33
Atividades práticas – Cenários para levantamento de requisitos 33
3. A metodologia 
Papéis 36
Product Owner 36
Scrum Master 36
Equipe de desenvolvimento 37
Cerimônias 38
v
Reunião de planejamento da Sprint (Planning Meeting) 38
Reuniões diárias de Scrum (Daily) 40
Artefatos 43
Planning Poker 45
Product Backlog 51
Sprint Backlog 53
Release Burndown 54
Gráfico de Burndown 55
Task Board 57
Release 57
Atividades práticas 58
4. Scrum e a organização
Scrum e o ciclo PDCA 59
Escalando projetos com Scrum 60
Infraestrutura 61
Staging 61
Equipes distribuídas 62
Reunião de planejamento da Sprint 63
Daily Scrum 64
Szcrum of Scrums 66
Sprint reviews e retrospectivas 66
Dicas gerenciais 66
Coexistindo com outras abordagens 67
Misturando Scrum e desenvolvimento sequencial 67
Governança 68
Conformidade a padrões 69
Recursos humanos, instalações e o PMO 70
Atividades 72
vi
1
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
 
 
ob
je
tiv
os
conceitos
1
Introdução
Entender a crise do Software. Por que se tornar ágil vale a pena? Introdução 
ao processo scrum. Realizando a transição de um processo peso-pesado para um ágil.
Crise do Software. Processos ágeis e Motivação. Processos peso-pesado e transição
A importância da informação e a crise do software 
qExiste nas organizações uma constante sinergia de pressões e forças que criam ameaças 
e oportunidades para a expansão e retração do seu negócio, e que alimenta o processo 
de tomada de decisão. 
É por essa razão que gestores necessitam ter cautela nesse processo, bem como contar 
com ferramentas que habilitem uma decisão que seja tomada estrategicamente, orientada 
de maneira a não prejudicar a organização, levando em consideração as oportunidades de 
negócio e garantindo a prosperidade das empresas, e o prejuízo que pode incorrer caso 
decisões sejam tomadas incorretamente. 
As organizações hoje consideram a informação como o seu principal ativo – é através dela 
que os gestores decidem os caminhos a serem traçados. A informação tem o poder de dar 
suporte e orientar decisões de negócios.
qAssim, a informação é o canal que dá acesso ao conhecimento e que contribui para a 
mudança e o aperfeiçoamento, propiciando o conhecimento necessário para a tomada 
de decisão e execução das ações. 
Os administradores precisam analisar como um ambiente estrategicamente alimentado em 
termos de informação pode afetar a posição competitiva de uma empresa no mercado. 
qNesse contexto, independente da fonte, o valor ou a validade da informação, as orga-
nizações necessitam de meios de armazenamento das informações relevantes e o 
realizam em seus repositórios e bancos de dados. 
Na verdade, a era do acesso a repositórios online já chegou. Os usuários conectados à 
internet têm a possibilidade de acessar os mais variados tipos de informação. 
2
 
Fu
nd
am
en
to
s 
do
 S
cr
um
A existência de um universo rico com uma quantidade imensa de informação tem deixado 
pessoas e empresas um pouco perdidas, e o tomador de decisão pode, por vezes, ficar 
confuso. Ter muita informação não significaque a empresa está bem informada. 
qÉ nesse contexto que surge a ciência da gestão da informação que, para Siqueira 
Marcelo Costa, autor do livro “Gestão Estratégica da Informação”, significa “a ação 
sistêmica de procurar entender as necessidades informacionais de uma organização e 
disponibilizá-las para a solução de problemas organizacionais, de forma estruturada 
e clara, com conhecimento pleno de todos os procedimentos e processos da solução 
encontrada, garantindo assim que ele seja eficaz e repetível”. 
Como se pode imaginar, ter a informação certa na hora certa e não é uma tarefa fácil. 
As informações devem ser exatas, relevantes e estar disponíveis em tempo hábil. 
A gestão da informação, portanto, busca resolver o problema de buscar uma forma eficiente 
de coletar e processar apenas as informações essenciais e indispensáveis, uma vez que é 
humanamente impossível digerir a imensa quantidade de informações colocadas à disposição.
Como o compartilhamento e a distribuição do conhecimento organizacional é condição 
vital prévia para transformação de informações e experiências organizacionais isoladas em 
algo que a organização possa utilizar, e sendo a informação um ativo, ou seja, um bem que 
agrega valor à empresa, é necessário fazer uso de recursos de Tecnologia da Informação (TI) 
de maneira apropriada. 
qÉ necessário utilizar, produzir e adquirir ferramentas de software para gerenciar bases 
de dados que cresçam à medida que a informação se transforma e se torna disponível e 
relevante organizacionalmente.
Crise do software
qParalelamente a essa necessidade pela produção de software relevante, que existe até os dias 
de hoje, um termo acerca de sua produção foi firmado nos primeiros dias da ciência da com-
putação e diz respeito à dificuldade de escrever programas de computador realmente úteis e 
eficientes dentro do tempo necessário para as partes interessadas: “crise do software”. 
A crise do software se deu por causa das melhorias rápidas nas capacidades dos compu-
tadores, e levando em consideração as complexidades dos problemas que conseguiriam 
resolver. Com o aumento da complexidade dos softwares, muitos problemas dessa 
natureza surgiram porque os métodos existentes não se mostraram suficientes.
O termo “crise do software” foi cunhado pelos participantes na Conferência de Engenharia 
de Software da OTAN, em 1968, em Garmisch, na Alemanha. A palestra de Edsger Dijkstra, 
da ACM, de 1972, faz referência a esse mesmo problema: "A principal causa da crise de 
software é que as máquinas tornaram-se várias ordens de grandeza mais potentes! Para 
colocá-lo muito claramente: enquanto não havia máquinas, a programação foi nenhum 
problema em tudo; quando tivemos alguns computadores fracos, a programação tornou-se 
um problema leve, e agora temos computadores gigantescos, a programação tornou-se um 
problema igualmente gigantesco.”
3
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
qAs causas da crise do software estão ligadas à complexidade geral do hardware e o pro-
cesso de desenvolvimento de software. A crise manifesta-se de várias maneiras:
 1 Projetos em execução que estouram o orçamento;
 1 Projetos que atrasam;
 1 Software que, depois de entregue, se mostrou muito ineficiente;
 1 Software de pouca qualidade;
 1 Software que, muitas vezes, não atendeu aos requisitos;
 1 Projetos se mostraram incontroláveis com um código difícil de manter;
 1 Software nunca foi entregue.
A ideia principal por trás da crise é que as melhorias no poder de computação sobre-
pujaram a capacidade dos programadores de utilizarem eficazmente esses recursos. 
Vários processos e metodologias foram desenvolvidos ao longo das últimas décadas 
para melhorar a gestão da qualidade de software, tais como programação processual 
e programação orientada a objetos. No entanto, projetos de software que são grandes, 
complicados, mal especificados e que principalmente envolvem aspectos desconhecidos 
ainda são vulneráveis a problemas grandes demais, imprevistos.
Por que se tornar ágil vale a pena? 
qEm uma realidade de crise, equipes ágeis de sucesso têm produzido software de melhor 
qualidade que atende às necessidades do usuário mais rapidamente e a um custo menor 
do que as equipes tradicionais. 
As organizações que se tornam ágeis adotando um processo como o Scrum têm expe-
rimentado benefícios significativos, incluindo ganhos dramáticos de produtividade com 
diminuições correspondentes em custo. Elas são capazes de levar produtos ao mercado 
muito mais rapidamente e com maior grau de satisfação do cliente, além de experi-
mentar maior visibilidade do processo de desenvolvimento, o que leva a maior previsibi-
lidade de resultados. 
Uma das primeiras organizações a entender esses benefícios a adotar o Scrum foi a 
Salesforce.com. Fundada em 1999 em um apartamento de San Francisco, a Salesforce.
com é uma das histórias de sucesso duradouras da época das pontocom. Em 2006, com 
uma receita de mais de US$ 450 milhões e 2 mil funcionários, a Salesforce.com notou que 
a frequência das suas releases tinha diminuído de quatro por ano para apenas uma. Os 
clientes estavam recebendo menos entregas e esperando mais tempo para obtê-las, e algo 
precisava ser feito. A empresa decidiu a transição para Scrum. Durante o primeiro ano de 
mudança, a Salesforce.com:
 1 Liberou 94% mais funcionalidades;
 1 Entregou 38% mais funções por desenvolvedor;
 1 E mais de 500% mais valor aos seus clientes em relação ao ano anterior. 
Nos dois anos seguintes, a receita mais que dobrou, para mais de US$ 1 bilhão. Com 
resultados como esses, não é surpreendente que tantas organizações fizessem a tran-
sição para Scrum. Ou pelo menos tentassem.
A transição para Scrum e outros métodos ágeis é difícil: muito mais difícil do que muitas 
empresas antecipam. As alterações necessárias para colher todos os frutos que se tornar 
ágil pode trazer são de longo prazo. Tais mudanças exigem grande quantidade de esforço 
não só por parte dos desenvolvedores, mas de toda a organização. Não se trata apenas de 
4
 
Fu
nd
am
en
to
s 
do
 S
cr
um
uma mudança das práticas, é necessário mudar a mentalidade e a forma de trabalho esta-
belecida. O objetivo deste curso, portanto, não é apenas mostrar como fazer essa transição 
adequadamente, mas também como obter sucesso no longo prazo.
qToda mudança é difícil. Mudanças maiores podem ser ainda mais difíceis. No entanto, 
existem ainda certas características de transição para Scrum que o tornam mais difícil 
do que a maioria das outras mudanças. 
Uma mudança, para ser considerada de sucesso, não depende exclusivamente de ser 
de cima para baixo ou de baixo para cima (ou seja, há múltiplos fatores que determinam 
o sucesso da mudança): em uma mudança top down (de cima para baixo), um líder 
influente compartilha uma visão do futuro e a organização segue o líder em direção a 
essa visão. 
Imagine um líder carismático, respeitado e poderoso como Steve Jobs dizendo a seus 
funcionários da Apple que eles são se movendo “para além de hardware e software de 
computador para dominar a música digital”. A sua reputação e estilo poderia ter apontado 
a empresa em uma nova direção, mas isso por si só não teria sido suficiente para realizar 
uma proeza tão improvável. Da mesma forma, sem compromisso operacional, as pessoas 
resistem à cadeia de comando. Assim, a participação bottom-up (de baixo para cima) será 
necessária, pois será o indivíduo, ou seja, os membros da equipe que trabalham com as 
questões que vão descobrir como Scrum vai funcionar melhor dentro de sua organização. 
Assim, a chave para qualquer sucesso na adoção de Scrum será a combinação elementos de 
bottom-up e mudança top-down.Criar esse plano exigiria saltar dois obstáculos impossíveis: em primeiro lugar, saber exata-
mente onde nós queremos acabar e, em segundo, saber exatamente os passos para chegar 
lá. Como não podemos superar essas impossibilidades, o melhor que se pode fazer é adotar 
uma abordagem de “provocar e observar” (Avery De, 2005), em que se pode tentar algo, ver 
se ele nos move mais perto de um objetivo intermediário, verificar se o estado melhorou e, 
em caso afirmativo, fazer mais do mesmo. Esses processos da organização não são aleató-
rios, são cuidadosamente selecionados com base na experiência, conhecimento e intuição, 
para dirigir uma transição para o Scrum.
Apresentar a revisão de prontidão operacional quase certamente vai impactar as finanças, 
vendas ou outros departamentos. Portanto, cada um desses departamentos pode ser 
afetado pela Scrum. Dessa maneira, grupos financeiros terão de conciliar as políticas da 
empresa na capitalização com a maneira de como projetos Scrum se comportam quando 
estão em execução. As vendas e o marketing podem querer alterar como comunicam os 
seus prazos e o escopo, e podem mudar a forma como estruturam contratos. Com mais 
grupos afetados por uma mudança para o Scrum, há mais chance para aumentar a resis-
tência e certamente mais chance de problemas, o que pode tornar a transição para Scrum 
ainda mais difícil.
Muitos testadores, por exemplo, aprendem ao longo dos anos que o seu trabalho é testar 
para conformidade com uma especificação de requisitos. Por sua vez, os programadores 
foram treinados para analisar um problema em profundidade e para conceber uma solução 
perfeita antes que qualquer codificação comece. Em um projeto Scrum, testadores e progra-
madores precisam desaprender esses comportamentos. Testadores passam a entender que 
o teste é também entender que o sistema precisa estar em conformidade com as necessi-
dades do usuário. Já os programadores entendem que um design nem sempre é necessário 
(e às vezes nem mesmo desejável) antes que a codificação comece.
O estado final é 
imprevisível: uma 
transição para Scrum 
não pode ser tal que 
“articula e define o todo 
o processo de mudança 
necessária para 
preencher a lacuna 
entre ‘como’ e ‘ser’ e 
cria planos táticos”, 
como em um de 
gerenciamento de 
mudanças tradicional, 
segundo Carr, Duro, e 
Trahant.
l
Scrum é generalizada: 
se tornar ágil terá 
implicações para a 
organização que vão 
muito além do 
departamento de 
desenvolvimento de 
software.
l
Scrum é dramatica-
mente “diferente”: as 
mudanças criadas 
através da adoção do 
Scrum se permeiam ao 
longo do desenvolvi-
mento, e muitas dessas 
mudanças vão de 
encontro à formação 
passada da maior parte 
dos funcionários.
l
5
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
Como a transição para Scrum inclui pedir às pessoas para trabalhar de uma forma diferente 
daquela que estão familiarizadas, ou seja, de uma forma que contradiz aquela da sua for-
mação e experiência, os funcionários muitas vezes se apresentam muitas vezes resistentes 
à mudança. 
As melhores práticas são arriscadas: como a maior parte de toda e qualquer 
mudança organizacional, depois que alguém descobre a melhor maneira de fazer 
alguma coisa, essa forma de fazer é capturada e registrada como uma “melhor 
prática”, e compartilhada com todos os outros. 
Para alguns tipos de trabalho, a coleta e reutilização de melhores práticas é uma tremenda 
ajuda para o esforço de mudança. Por exemplo, uma organização que está vendendo um 
produto para um novo tipo de cliente pode capturar as melhores práticas para superar 
objeções por parte dos prospectos. Ao fazer a transição para Scrum, no entanto, a coleta 
de melhores práticas pode ser arriscada, pois elas tentam fazer a equipe “relaxar e parar o 
esforço de melhoria contínua”, que é essencial ao Scrum.
Embora os membros da equipe devam sempre pesquisar para compartilhar uns com os 
outros as suas recém-descobertas acerca das melhores formas de trabalhar, eles devem 
resistir ao impulso de codificá-las em um conjunto de melhores práticas. 
Apesar de todas as razões pelas quais a transição para Scrum pode ser particularmente 
difícil, partes interessadas nas organizações que a realizaram têm o tempo para o mercado 
de seus produtos reduzido e se mostram satisfeitos depois de implementar um processo 
ágil como Scrum. 
Esse tempo de colocação no mercado mais rápido é possibilitado pela maior produtividade 
das equipes ágeis, o que por sua vez é o resultado da maior qualidade de projetos nessa 
disposição. Como os funcionários podem realizar trabalhos de alta qualidade e como eles 
passam a ver o seu trabalho entregue mais cedo nas mãos dos usuários, a satisfação com o 
trabalho sobe. Com maior satisfação dos funcionários, nota-se maior envolvimento, o que 
leva a ganhos de produtividade, iniciando um ciclo virtuoso de melhoria contínua.
qPodemos listar as seguintes razões porque uma transição para um processo ágil como 
Scrum é importante:
Aumento da produtividade e redução de custos
Infelizmente, não há medidas universalmente padronizadas para medição de produ-
tividade. Martin Fowler (2003) diz que medir a produtividade dos desenvolvedores de 
software é impossível. No entanto, algumas equipes usam medidas como o número de 
linhas de código como uma entrada para a produtividade. Outros usam como o número 
de pontos de função, ou seja, pontos entregues ao cliente. Algumas equipes medem sua 
produtividade por meio do número de características entregues, ignorando que nem 
todas as características são do mesmo tamanho. 
Obviamente, nenhuma dessas formas de medir produtividade é perfeita, mas a utilidade de se 
tentar medi-la encontra-se na aproximação do entendimento do que se quer gerenciar.
qNesse sentido, a QSMA calcula sua produtividade por meio de um sistema que considera 
esforço, cronograma, dificuldade técnica das atividades e alguns outros fatores em uma 
tentativa de realizar comparações entre equipes mais significativas. 
6
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Em sua comparação entre projetos tradicionais e ágeis, Mah (2008) entende que projetos 
ágeis são 16% mais produtivos em qualquer situação. A figura 1.1 mostra a comparação de 
projetos ágeis (pontos) comparado com a produtividade média de o desvio padrão na base 
de dados da QSMA. 
qComo se pode ver, a maioria dos pontos encontra-se acima da média da indústria, com 
uma boa parte dos projetos mais de um desvio padrão acima de um nível de produtivi-
dade dessa média. 
Alto
Pr
od
ut
iv
id
ad
e
Baixo
Menor
Tamanho do projeto
Maior
Projetos ágeis
+/- 1 Desvio padrão
Média
Os resultados da QSMA são corroborados por outras pesquisas, tais como as da DDJ e 
VersionOne. De acordo com a primeira, 82% dos participantes sentiram que a produtividade 
foi um pouco ou muito mais elevada do que antes, quando se utiliza métodos ágeis como o 
Scrum. De acordo com a VersionOne, 73% acreditava que ser ágil tinham significativamente 
melhorado (23%) ou melhorado (50%) a produtividade.
Ora, é razoável entender que, se os funcionários em uma organização são mais produtivos, 
os custos serão menores. Embora encorajadores, esses números contam apenas parte 
da história. Uma das críticas dos processos tradicionais é que eles são tão onerosos. Que, 
muitas vezes, quando o software é entregue, algumas funcionalidades – ou o aplicativo 
inteiro – não são mais necessárias. Um benefício significativo de ser ágil é que equipes ágeis 
possuem a tendência de produzir apenas funcionalidades necessárias. Graças ao feedback 
constante e à habilidade de priorizar novamente a cada Sprint, uma equipe Scrum é capaz 
de trabalhar apenasnaquelas funcionalidades que os usuários realmente precisam. Se isso 
for incluído no nosso requisito de produtividade, provavelmente veríamos resultados ainda 
mais dramáticos.
qDe acordo com o levantamento de Rico, com base em estudos de caso de equipes ágeis 
publicados até 2016, mostrada na tabela 1.1, há um aumento médio de produtividade de 
88% e economias de 26% de custos quando se transiciona para ágil. Esses indicam uma 
evidência sólida de que equipes ágeis são mais produtivas, o que leva à redução de 
custos para os seus projetos.
Categoria Melhoria Mais 
Baixa 
Melhoria Média Melhoria Mais 
Alta
Produtividade 14% 88% 384%
Custo 10% 26% 70%
Figura 1.1 
Equipes ágeis são 
significativamente 
mais produtivos 
que a média da 
indústria.
Tabela 1.1 
Melhorias 
verificadas com ágil 
por categoria.
7
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
Exercício de fixação e 
Como você entende que o Scrum pode melhorar a produtividade na 
sua organização?
O envolvimento dos funcionários melhora também a satisfação no trabalho
Um fator que contribui para a maior produtividade e menores custos em projetos ágeis 
é: os trabalhadores passam a gostar mais do que fazem. Quinze meses após a adoção do 
Scrum, a Salesforce.com realizou uma pesquisa junto a seus funcionários e constatou que 
86% estavam “gostando” ou o “gostando muito” de trabalhar na empresa. Antes de adotar 
Scrum, apenas 40% respondiam a mesma coisa. Além disso, 92% dos funcionários disseram 
que recomendariam uma abordagem ágil para os outros. Resultados como esses são 
comuns. Em seu levantamento na indústria, a VersionOne constatou que 74% dos entrevis-
tados relataram que a “moral” foi melhorada (44%) ou significativamente melhorada (30%). 
Time to Market mais rápido
qEquipes ágeis tendem a lançar seus produtos mais rapidamente do que as equipes tradi-
cionais. De acordo com o estudo da VersionOne, 64% dos participantes relataram que o 
tempo de comercialização foi melhorado (41%) ou significativamente melhorado (23%). 
O estudo da QSMA comparou 26 projetos ágeis em uma base de dados de 7.500 
projetos, em sua maioria tradicionais, chegando à conclusão de que os projetos ágeis 
chegaram 37% mais rapidamente ao mercado, como mostrado na figura 1.2.
Ti
m
e 
to
 m
ar
ke
t
Média
Projetos ágeis
Alto
Baixo
Menor Maior
Tamanho do projeto
+/- 1 Desvio padrão
Melhoria na satisfação das partes interessadas
qTendo em conta todos os benefícios de processos ágeis até agora, não é surpreendente 
que eles conduzam a uma melhoria na satisfação das partes interessadas. A pesquisa da 
DDJ descobriu que 78% dos participantes da pesquisa acreditam que o uso de um pro-
cesso ágil levou a uma melhoria “um pouco maior” (47%) ou “muito mais elevada” (31%) 
na satisfação das partes interessadas. 
Uma das razões pelas quais as partes interessadas ficam mais satisfeitas com processos ágeis 
é porque as suas práticas são mais amigáveis com relação às mudanças de prioridades, o que 
é uma necessidade na vida das organizações de ritmo acelerado e competitivo de hoje. 
qNo estudo da VersionOne, 92% dos participantes consideraram que as metodologias 
ágeis melhoraram a capacidade de gerenciar mudanças de prioridades. 
Uma razão pela qual os 
funcionários podem 
aproveitar mais os seus 
trabalhos é devido ao 
ritmo sustentável 
promovido por 
processos ágeis.
l
Figura 1.2 Projetos 
ágeis possuem 
um time to Market 
37% mais rápido 
comparado com a 
média da indústria.
8
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Além disso, juntamente com a capacidade de mudar mais facilmente as prioridades, as 
partes interessadas em projetos ágeis aprendem a gerenciar o impacto da mudança. Outras 
razões incluem a melhoria na visibilidade dos projetos, a melhoria do alinhamento da TI e 
objetivos de negócio, e a redução de riscos de projeto.
O que as organizações têm feito não funciona
Uma razão final para considerar a mudança para o Scrum é se o seu processo de desen-
volvimento atual não está mais funcionando. Quando um processo que até funcionou no 
passado encontra muitas barreiras, uma tendência comum é “fazer mais do mesmo”. Esse foi 
certamente o caso no Yahoo!, onde o diretor de produto Pete Deemer foi um dos primeiros a 
reconhecer a necessidade de mudança: “Inicialmente, o Yahoo! tentou Scrum puramente por 
desespero. A abordagem sequencial claramente não estava funcionando, e fizemos uma ten-
tativa de um ano para fazer a sequencial ‘melhor’ através de um planejamento e uma análise 
mais aprofundada de documentos, mais sign-offs e, assim por diante, era tornar as coisas 
piores, não melhores. Para as equipes que viram benefícios, que eram a maioria das equipes 
que tentaram Scrum, os benefícios eram visíveis quase que imediatamente.”
qAssim, ao adotar o Scrum, é interessante identificar continuamente os benefícios 
obtidos até determinado ponto, selecionar fatores de interesse da organização e fazer 
com que tais fatores sejam uma linha de base contra a qual se possa comparar mais 
tarde – uma boa dica é qualidade, moral da equipe e satisfação das partes interessadas. 
Processo Scrum
qTodas as práticas do Scrum estão cravadas em um esqueleto de processo incremental. 
Esse esqueleto é mostrado na figura 1.3. O círculo de baixo representa uma iteração de 
atividades de desenvolvimento que ocorrem uma após a outra, e a saída de cada uma 
delas é um incremento no produto. Já o círculo superior representa uma espécie de 
inspeção diária que ocorre durante a iteração citada anteriormente, durante a qual cada 
membro da equipe se reúne para acompanhar as atividades umas dos outros e realizar 
adaptações adequadas. O que guia as interações são uma lista de requisitos e o ciclo se 
repete enquanto houver orçamento disponível para o projeto.
Reunião de 
Scrum Diária 24 h
Sprint 
Backlog
Product 
Backlog
2 – 4 semanas
Incremento 
no Produto
qO esqueleto de processo funciona da seguinte maneira: no início de uma iteração, a 
equipe analisa o que deve fazer. Em seguida, seleciona o que acredita que pode se trans-
formar em um incremento potencialmente utilizável de funcionalidade até no final de 
um ciclo da iteração, que dura entre duas e quatro semanas. Cada ciclo desses é conhe-
cido como Sprint. A equipe é então deixada sozinha para fazer o seu trabalho durante a 
Sprint. No final, ela apresenta o incremento de funcionalidade que construiu, de modo 
que as partes interessadas podem inspecionar a funcionalidade e as adaptações opor-
tunas para que o projeto possa ser feito.
Crie cartões para 
compartilhar com 
outras equipes com os 
seus resultados, 
explicando por que vale 
a pena mudar para o 
Scrum, se mostrarem 
interesse na transição. 
Isso pode diminuir a 
resistência da 
organização como um 
todo. 
l
Figura 1.3 
O processo Scrum.
9
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
qO coração de Scrum reside na iteração. A equipe lança um olhar sobre os requisitos, con-
sidera a tecnologia disponível, e avalia as suas próprias habilidades e capacidades. Em 
seguida, coletivamente determina como construir a funcionalidade, modificando a sua 
abordagem diariamente, à medida que encontra novas complexidades, as dificuldades e 
surpresas. A equipe descobre o que precisa ser feito e seleciona a melhor maneira de fazê-
lo. Esse processo criativo é o coração da produtividade Scrum. 
Papéis, fluxo e artefatos do Scrum
Papéis do Scrum
Scrum possui três papéis: product Owner, Scrum Master e a equipe. 
q 1 Product Owner: o Product Owner deve ser a pessoa com visão, autoridade e dispo-
nibilidade. O Product Owner é responsável por se comunicar continuamente com o 
time de desenvolvimentosobre a visão do projeto e as prioridades. 
Muitas vezes, é difícil para os Product Owners atingir o ponto ideal de envolvimento. Como 
Scrum valoriza auto-organização entre equipes, um Product Owner deve lutar a necessi-
dade de microgerenciar. Ao mesmo tempo, Product Owners devem estar disponíveis para 
responder questões da equipe;
q 1 Scrum Master: o Scrum Master age como um facilitador para o Product Owner e 
para a equipe. O Scrum Master não gerencia a equipe. O Scrum Master trabalha para 
remover quaisquer impedimentos ou barreiras que porventura venham atrapalhar a 
equipe para atingir os objetivos da Sprint. 
Isso ajuda a equipe a se manter criativa e produtiva ao mesmo tempo em que garante que seus 
sucessos estão visíveis ao Product Owner. O Scrum Master também trabalha para auxiliar o 
Product Owner em como maximizar o ROI (retorno sobre investimento) para a equipe;
q 1 Equipe: de acordo com os criadores do Scrum, “a equipe é totalmente autogeren-
ciável”. A equipe de desenvolvimento é responsável por se auto-organizar para 
completar o trabalho. Uma equipe de desenvolvimento Scrum contém mais ou menos 
sete membros completamente dedicados (oficialmente de 3 a 9), idealmente em uma 
sala protegida de distrações externas. 
Para projetos de software, uma equipe típica inclui uma mistura de engenheiros de sof-
tware, arquitetos, programadores, analistas, especialistas em qualidade, testadores e desig-
ners de interface gráfica. A cada Sprint, a equipe é responsável por determinar como vai 
conseguir finalizar o trabalho. A equipe possui a autonomia e responsabilidade para atingir 
os objetivos da Sprint.
Exercício de fixação e 
Na sua organização, que papéis atuais poderiam ocupar os papéis do Scrum 
em uma eventual transição para Scrum?
Fluxo do Scrum
qUm projeto Scrum começa com uma visão do sistema a ser desenvolvido. A visão pode 
ser vaga no início, talvez expressa em termos de mercado, em vez de requisitos de 
sistema, mas ela se tornará mais clara à medida que o projeto avança. 
10
 
Fu
nd
am
en
to
s 
do
 S
cr
um
qO Product Owner é responsável por garantir o financiamento do projeto e por entregar a 
visão de uma forma que maximiza o retorno do investimento. O Product Owner também 
formula um plano para fazê-lo, que inclui um Product Backlog. O Product Backlog é uma 
lista de requisitos funcionais e não funcionais que, quando transformado em funciona-
lidade, vai entregar essa visão. O Product Backlog é priorizado para que os itens com 
maior probabilidade de gerar valor sejam prioridade e estejam divididos em lança-
mentos propostos. 
O Product Backlog priorizado é um ponto de partida, e os seus conteúdos, as priori-
dades, e agrupamento em releases geralmente muda no momento do início do projeto, 
como esperado. Mudanças no Product Backlog refletem mudanças nos requisitos de 
negócios e quão rapidamente a equipe pode transformar esses requisitos em funcionali-
dade implementada.
Todo o trabalho é feito em Sprints. Cada Sprint é uma iteração de 30 ou 15 dias conse-
cutivos e é iniciada com uma reunião de planejamento, onde o proprietário do produto 
e equipe se juntam para colaborar sobre o que será feito para a próxima Sprint. A ideia 
é que o Product Owner selecione o item de mais alta prioridade no Product Backlog, e 
que a equipe explique ao mesmo o quanto do que é desejado ela acredita que pode ser 
transformado em funcionalidade ao longo da próxima Sprint. Reuniões de planejamento 
da Sprint não podem ser muito demoradas, não devendo durar mais do que oito horas, 
evitando muita angústia sobre o que é possível. O objetivo é começar a trabalhar, não 
pensar em planejar o trabalho.
Todos os dias, a equipe se reúne para uma reunião de 15 minutos chamada Daily Scrum. 
O objetivo da reunião é sincronizar o trabalho de todos os membros da equipe diaria-
mente e agendar quaisquer reuniões adicionais que a equipe necessite para transmitir o 
seu progresso.
No final da Sprint, uma reunião de revisão da Sprint é realizada. Essa é uma reunião de 
quatro horas em que a equipe apresenta o que foi desenvolvido durante a Sprint para o 
Product Owner e quaisquer outros interessados que queiram participar. Trata-se de uma 
reunião informal em que a funcionalidade é apresentada e destina-se a reunir as pessoas 
e ajudá-los de forma colaborativa, determinando o que a equipe deve fazer a seguir. 
Após a revisão da Sprint, e antes da próxima reunião de planejamento da Sprint, o 
ScrumMaster realiza uma reunião retrospectiva da Sprint com a equipe. Nessa reunião, 
o ScrumMaster encoraja a equipe a rever seu processo de desenvolvimento, no âmbito 
e práticas do processo Scrum, para torná-lo mais eficaz e agradável para a próxima 
Sprint. Juntos, a reunião de planejamento da Sprint, o Daily Scrum, a revisão Sprint e a 
retrospectiva da Sprint constituem as práticas de inspeção e de adaptação empíricos de 
Scrum.
Na figura 1.4, podemos encontrar o processo Scrum estendido, incluindo as reuniões 
recém-citadas.
11
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
A cada 
24 horas
Sprint
Backlog da Sprint 
Selected Product Backlog
Backlog do Produto: Emergente, 
requisitos priorizados
Nova funcionalidade 
demonstrada ao final 
da Sprint
Visão: ROI esperado, 
lançamentos, Millestore
Scrum diário
Artefatos qScrum introduz alguns novos artefatos. Estes são utilizados em todo o processo de 
scrum e são descritos a seguir.
Product Backlog
qOs requisitos para o sistema ou produto que está sendo desenvolvido pelo projeto estão 
listados no Product Backlog. O Product Owner é responsável pelo conteúdo, priorização 
e a disponibilidade do Product Backlog. O Product Backlog nunca está completo, 
finalizado, ou seja, o Product Backlog utilizado no plano de projeto é apenas uma 
estimativa inicial das necessidades e evolui à medida que o produto e o ambiente em 
que será usado evolui. Em outras palavras, o Product Backlog é dinâmico e a gestão 
muda constantemente tal documento para identificar o que o produto necessita para 
que seja adequado, competitivo e útil. Enquanto o produto existir, o Product Backlog 
existe. Um exemplo pode ser encontrado na tabela 1.2: 
Product Backlog
Requisito Num Categoria Status Pri Estimativa
Registrar requisitos na base de dados 17 funcionalidade em curso 4 5
Processar cenário de saque simples 232 caso de uso em curso 4 60
Aprovação de crédito muito lento 12 problema não iniciado 3 10
Cálculo de comissão de venda 43 defeito finalizado 2 2
Captura de venda em ponto de venda 321 melhoria não iniciado 1 100
Processar cenário de crédito PMT 45 caso de uso em curso 3 30
Figura 1.4 
Visão geral do 
processo do Scrum.
Tabela 1.2 
Product Backlog.
12
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Sprint Backlog
qO Sprint Backlog define o trabalho (ou as tarefas que uma equipe define para transformar os 
itens do Product Backlog que ele escolheu para o Sprint), de maneira a transformá-lo em um 
incremento de funcionalidade do produto potencialmente utilizável. Somente o time pode 
mudar o Sprint Backlog. O Sprint Backlog deve ser altamente visível, e deve ser um quadro 
que demonstra em tempo real o trabalho que a equipe planeja efetuar durante a Sprint. 
Um exemplo de um Sprint Backlog é mostrado na tabela 1.3. As linhas representam 
tarefas do Sprint Backlog; as colunas representam os 30 dias no Sprint. Uma vez que uma 
tarefa é definida, a estimativa do número de horas restantes para completar a tarefa é 
colocada no cruzamento da tarefa, e o dia Sprint pela pessoa que trabalhe com a tarefa.
Sprint Backlog
Horas de trabalho restantes por dia
1 2 3 4 5 6 7 8 9 10 11 12
Release do 
serviço
Rosa Joãoem curso 8 8 8 8 8 8 8 8 8 8 8 8
Gerar docu-
mentação 
do SDK
Pedro não 
iniciado
16 16 16 16 16 16 16 16 16 16 16 16
Disponibilizar 
documen-
tação na wiki
João não 
iniciado
6 6 6 6 6 6 6
LDAP: grupos 
de suporte
Maria finalizado 26 18 10 2 0 0 0 0 0 0 0 0
Documen-
tação de 
branch: 
fontes e 
builds
Pedro não
iniciado
4 4 4 4 4 4 4 4 4 4 4 4
Impedir 
criação de 
relações 
"erradas"
Maria finalizado 20 12 4 0 0 0 0
Descrever 
extensão 
de PDA
Pedro em curso 64 58 50 42 34 26 18 10 2 2 2 2
Incremento potencialmente utilizável de funcionalidade de produto 
qScrum exige que os times desenvolvam um incremento de funcionalidade do produto a 
cada Sprint. Esse incremento deve ser potencialmente utilizável, porque o Product 
Owner pode optar por implementar a funcionalidade imediatamente. 
Tabela 1.3 
Sprint Backlog.
D
es
cr
iç
ão
 d
a 
 
A
ti
vi
da
de
O
ri
ge
m
Re
sp
on
sá
ve
l
St
at
us
13
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
Isso requer que os incrementos precisem ser exaustivamente testados e bem estruturados, 
que o código seja construído em um arquivo executável e que a funcionalidade implemen-
tada para operação do usuário seja escrita em um código bem documentado e disponibili-
zada em arquivos de ajuda ou em outra documentação de usuário acordada. 
Visão Scrum
qScrum é uma ferramenta para desenvolver e manter produtos complexos. A ciência do 
Scrum está por trás do desenvolvimento de software complexo. 
Obviamente tal fato não é muito surpreendente, porque o universo é cheio de complexi-
dades. A maioria delas são desconhecidas para a maioria das pessoas. Algumas – como 
o processo através do qual a pressão transforma carvão em diamantes, por exemplo, é 
irrelevante para a maioria das pessoas por ser natural e cuidar de si mesma. Outras, como o 
deslocamento para o trabalho diariamente, podem tolerar alguma imprecisão. 
qNo entanto, é impossível ignorar a complexidade no desenvolvimento de software. Seus 
resultados são efêmeros, consistindo apenas de sinais que controlam máquinas de estado. 
O processo de desenvolvimento de software é totalmente intelectual, e todos os seus 
produtos intermediários são representações marginais dos pensamentos envolvidos. 
Os materiais que usamos para criar o produto final são extremamente voláteis: os requisitos 
dos usuários para um programa que utilizarão no futuro, a interoperabilidade de sinais 
entre outros programas com o aplicativo a ser desenvolvido e a interação dos organismos 
mais complexos do planeta – pessoas.
qDessa forma, Scrum se propõe a ser visto como um quadro no qual as pessoas podem 
resolver os problemas adaptativos complexos, ao mesmo tempo em que o realizam de 
forma produtiva e fornecem, de maneira criativa, produtos de maior valor possível. Scrum é:
 1 Leve (Lightweight);
 1 Simples de entender;
 1 Difícil de dominar.
Scrum é uma estrutura de processo que tem sido utilizada para gerenciar o desenvolvimento 
de produtos complexos desde o início da década de 1990. Scrum não é um processo ou 
uma técnica para a construção de produtos; ao contrário, é um quadro no qual você pode 
empregar vários processos e técnicas.
Scrum torna clara a eficácia relativa das suas práticas de gestão e desenvolvimento de pro-
dutos para que você possa melhorar. O framework Scrum consiste em equipes Scrum e seus 
papéis associados, eventos, artefatos e regras. Cada componente no quadro serve a um 
propósito específico e é essencial para o sucesso e uso do Scrum.
qAs regras do Scrum unir os eventos, papéis e artefatos, que rege as relações e interações 
entre eles. As regras de Scrum são descritas ao longo desse documento. Táticas espe-
cíficas para o uso do framework Scrum variam. Scrum é fundada na teoria de controle 
de processos empíricos: o empirismo. Essa teoria afirma que o conhecimento vem de 
decisões de experiência, preparando com base no que é conhecido. Scrum emprega uma 
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.
São três os pilares que sustentam qualquer implementação de controle de processos empí-
ricos: a transparência, a inspeção e a adaptação.
Essa é a definição 
de um incremento 
“pronto”. 
l
14
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Transparência
qAspectos significativos do processo devem ser visíveis para os responsáveis pelo resul-
tado. A transparência exige que esses aspectos sejam definidos por um padrão comum 
de modo que observadores compartilhem um entendimento comum sobre o que está 
sendo visto. Por exemplo:
 1 Uma linguagem comum referindo-se ao processo deve ser partilhada por todos 
os participantes; 
 1 Aqueles que executam o trabalho e aqueles que aceitam o produto do trabalho 
devem compartilhar uma comum definição de “Pronto”.
Inspeção
qUsuários de um projeto do Scrum devem frequentemente inspecionar artefatos pro-
duzidos pelo projeto e progredir em direção a uma meta de uma Sprint para detectar 
variações indesejáveis. Obviamente, a inspeção não deve ser tão frequente de maneira a 
tornar a inspeção uma barreira ao trabalho.
As inspeções são mais benéficas quando a diligência é realizada por inspetores qualifi-
cados no trabalho.
Adaptação
qSe um inspetor determina que um ou mais aspectos de um processo se desvia dos 
limites aceitáveis e que o produto resultante será inaceitável, o processo ou o material a 
ser processado tem de ser ajustado. Um ajuste deve ser feito o mais rapidamente pos-
sível para impedir desvios futuros.
Os eventos prescritos pelo Scrum para garantir inspeção e adaptação são: 
 1 Planejamento da Sprint;
 1 Scrum diária;
 1 Revisão da Sprint.
 1 Retrospectiva da Sprint
Scrum e processos de desenvolvimento
qA abordagem Scrum para o desenvolvimento de software ágil marca uma saída radical 
das abordagens tradicionais. Scrum e outros métodos ágeis foram inspirados pelas defi-
ciências daquelas abordagens, e enfatizam em colaboração, software funcional, auto-
gestão de equipe e na flexibilidade a adaptar-se a necessidades emergentes de negócios. 
Essas necessidades são as mais comumente verificadas em negócios de software, cujos 
clientes normalmente não conhecem todos os requisitos de negócio no começo do 
projeto, e têm necessidades emergentes durante a sua execução.
Scrum é parte do movimento ágil. Esse é uma resposta à falha da maioria dos para-
digmas de gestão de projetos de desenvolvimento, e toma emprestado muitos princí-
pios de lean manufacting. Em 2011, 17 pioneiros de métodos similares se reuniram no 
Resort Snow Bird Ski, em Utah, e escreveram o Manifesto Ágil, uma declaração de quatro 
valores e doze princípios. Esses valores e princípios contradizem fundamentalmente as 
áreas de conhecimento tradicionais do PMBoK.
No entanto, o Manifesto Ágil não provê passos concretos. As organizações normalmente 
procuram métodos mais específicos dentro do movimento Ágil. Estes incluem Crystal Clear, 
15
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
Extreme Programming, Desenvolvimento Orientado a Funções, Scrum e outros. Tipica-
mente, uma solução que possui definições simples como o Scrum habilita a equipe com a 
autonomia necessária para realizar o melhor trabalho enquanto auxilia a alta gestão (cujos 
membros podem se tornar Product Owner) a obter os resultados de negócio que desejam. 
Scrum é capaz de abrir portas para outras abordagens ágeis úteis como desenvolvimento 
orientado a testes. Uma organização realmente ágil dificilmente possui um lado “técnico” e 
um lado “de negócios”, mas possui equipes trabalhando diretamente que desejam entregar 
valor de negócios. Ora, os melhores resultadosde negócios são entregues quando o negócio 
inteiro está envolvido no processo. 
Os primeiros defensores do Scrum foram inspirados por ciclos de feedback de inspeção 
e adaptação para se adaptar a complexidade e risco. Scrum enfatiza que o processo de 
decisão deve ser baseado em resultados do mundo real, em vez de especulação. O tempo 
deve ser dividido em cadências pequenas de trabalho, conhecidas como Sprints, de uma 
ou duas semanas. O produto é mantido em um estado potencialmente entregável (ou seja, 
adequadamente integrado e testado) o tempo inteiro. No fim de cada Sprint, as partes inte-
ressadas e os membros de equipe se reúnem para uma demonstração de uma melhoria do 
produto e planejar seus próximos passos.
Dessa forma, podemos ver Scrum como um conjunto simples de papéis, responsabilidades 
e reuniões que nunca mudam. Ao remover toda imprevisibilidade não necessária, é possível 
se adaptar à necessária imprevisibilidade da descoberta e aprendizagem típica dos projetos. 
Assim, as regras e práticas para Scrum – um processo simples para gerenciar projetos 
complexos – são poucas, diretas e fáceis de aprender. No entanto, a simplicidade do Scrum 
em si e sua falta de prescrição podem ser tão sensibilizantes que novos praticantes acabam 
em situações em que aos poucos revertem para velhos hábitos e ferramentas de gestão de 
projetos, produzindo resultados menos satisfatórios.
qAssim, para entender a base na teoria e prática do Scrum, é necessária uma mentalidade 
que possibilite:
 1 Controlar até mesmo os mais complexos projetos;
 1 Gerir eficazmente os requisitos do produto desconhecidos ou mudança;
 1 Simplificar a cadeia de comando com as equipes de desenvolvimento de autogestão;
 1 Receber mais claras especificações e feedback de clientes;
 1 Reduzir grandemente o tempo de planejamento de projeto e ferramentas necessárias;
 1 Construir e lançar produtos em ciclos de 30 dias para que os clientes obtenham resul-
tados mais cedo;
 1 Evitar erros inspecionando regularmente relatórios sobre os projetos e realizar ajuste 
fino constantemente sobre estes;
 1 Apoiar várias equipes trabalhando em um projeto em larga escala a partir de muitas 
localizações geográficas;
 1 Maximizar o retorno sobre o investimento.
Exercício de fixação e 
O que você acha que precisa mudar na mentalidade da sua organização para 
adotar um processo de gestão de projetos ágil como o Scrum?
16
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Introduzindo um processo ágil em uma organização 
qO Manifesto Agil estabelece uma base comum para esses processos: valorizar mais 
os indivíduos e as interações que os processos e as ferramentas, trabalhar mais no 
software do que no detalhamento da documentação, colaborar mais com o cliente na 
negociação do contrato e responder mais rapidamente às mudanças do que seguir um 
plano à risca. As metodologias ágeis mais conhecidas são Extreme Programming (XP), 
Lean Development, Crystal e Scrum.
Com o Scrum, os projetos progridem em uma série de interações mensais, denominadas 
sprints. Antes de cada sprint, as equipes de desenvolvimento se reúnem com o cliente, 
ou com o product owner, para priorizar o trabalho a ser realizado e selecionar as ativi-
dades que a equipe pode finalizar na próxima sprint. Durante a sprint, a equipe é acom-
panhada através de reuniões diárias (daily scrum) e, no fim das sprints, a equipe entrega 
um incremento do produto que pode ser potencialmente utilizado pelo cliente.
O Scrum é, portanto, ideal para projetos que possuem requisitos que ou mudam cons-
tantemente ou são desconhecidos no começo do projeto e que possuam a tendência de 
surgir rapidamente, como projetos para web e para desenvolvimento de produtos em 
novos mercados. 
Desenvolvedores
qA maioria dos desenvolvedores respondem à introdução de um processo ágil com uma 
combinação de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores, 
no entanto, tendem a resistir à mudança ou simplesmente iniciar o projeto sem preme-
ditação. É importante ressaltar que ambas as reações podem causar problemas.
Em geral, processos ágeis valorizam mais a produção de código do que processos orientados 
a planejamento. Em um processo assim, os desenvolvedores tratam a UML e outros itens 
que não são código como artefatos de primeira classe. Em um processo ágil, no entanto, 
esses itens só existem para suportar a atividade de codificação.
Ao introduzir o Scrum em várias equipes de projeto, é normal encontrar programadores que 
passam mais tempo produzindo artefatos que não são código do que necessário. Também 
encontramos desenvolvedores que medem seu nível de contribuição no projeto pelo 
número de reuniões de que participam. Esses analistas vão além da “paralisia da análise” 
e ativamente buscam oportunidades para adicionar novas atividades no processo ágil, 
deixando-o mais complicado do que precisa ser.
Em tais situações, o melhor é não intervir. Outros membros da equipe avaliarão a efetivi-
dade e o valor dessas atividades, e não as adotarão se estas não ajudarem o esforço de 
desenvolvimento geral da equipe.
Realizando a transição de um processo peso-pesado
qUm número surpreendente de desenvolvedores enxerga o uso de um método ágil 
como uma tentativa da gestão de microgerenciá-los. Abordagens como o Scrum e o XP 
aceleram ciclos de projeto, e assim desenvolvedores interagem com seus gerentes mais 
frequentemente, mas por períodos mais curtos. Em um processo orientado a planos, 
um gerente pode passar até a semana inteira sem conversar com um desenvolvedor em 
particular, enquanto o contato diário é a norma na maioria dos processos ágeis.
17
 
Ca
pí
tu
lo
 1
 - 
In
tr
od
uç
ão
Programadores que têm essa visão percebem as interações com seus gerentes de projeto 
como sendo sobre datas de entrega e prazos perdidos. Para impedir esse problema, os 
líderes devem constantemente demonstrar seu desejo de remover obstáculos assim que 
possível e evitar reclamar se uma atividade demorar mais do que o previsto. Gestores 
podem se surpreender, mas não devem se mostrar excessivamente críticos ao serem infor-
mados de que uma tarefa vai demorar mais do que se pensava originalmente.
qA transição gradual de um processo mais pesado para um processo ágil pode tornar a 
mudança mais fácil para a equipe de desenvolvimento. Algumas equipes, em seu pri-
meiro contato com o Scrum, ficam estagnados com a falta de ação gerada pela liberdade 
de não possuir um cronograma diário direcionando seu trabalho. A ideia é ajudar esses 
times ao definir tipos de sprint:
 1 Prototipação;
 1 Captura de requisitos;
 1 Análise e design;
 1 Implementação;
 1 Estabilização.
A cada reunião de planejamento, trabalha-se com as equipes para definir os artefatos 
que vão resultar de cada tipo de Sprint. Ao usar tipos de Sprint, introduzimos um nível de 
formalidade suficiente para permitir que as equipes vejam mais claramente sua função ao 
longo do projeto. Na medida que os times se tornam mais familiarizados com a informali-
dade do processo ágil, eles gradualmente abandonam o conceito de tipos de Sprint. 
Scrum Escalável
qQuando muitas equipes trabalham no mesmo produto, eles normalmente usam um 
mesmo Product Owner (que realmente toma decisões de negócio) e um único Backlog 
de Produto com requisitos orientados ao cliente. Cada equipe do Scrum deve buscar 
se tornar uma equipe de funcionalidades, capaz de desenvolver uma fatia completa 
de produto que pode ser entregue ao cliente. Quando interdependências aparecem, 
equipes de funcionalidade devem aprender a usar princípios da auto-organização para 
coordenar com outras equipes. 
Infelizmente, a maioria dos times não estão inicialmente acostumadoscom esse nível de 
responsabilidade, e hábitos pré-existentes de gestão e hierarquias apresentam impedi-
mentos organizacionais. 
qA ideia do Scrum é eliminar papéis de coordenação como gestor de projetos e PMO, pois 
entende que eles interferem na auto-organização da equipe. O Scrum também elimina 
papéis ditatoriais como “arquitetos”, pois entende que as decisões técnicas devem ser 
tomadas por times colaborativos. 
Enquanto um cenário de agilidade ótima requer mudanças fundamentais na estrutura 
organizacional, é tentador usar algumas abordagens híbridas que combinam uma versão 
enfraquecida do Scrum ao mesmo tempo em que se utiliza uma gestão hierárquica tradi-
cional. Recomenda-se que organizações maiores que estão comprometidas com valores 
e princípios do Manifesto Ágil aprendam sobre LeSS (Large Scale Scrum).
18
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Atividades práticas e 
Cenário para escolha sobre um processo a ser adotado 
Tutorial para uso de uma ferramenta Scrum (sugestão: Tuleap)
19
 
C
ap
ítu
lo
 2
 - 
O
 S
cr
um
 
 
ob
je
tiv
os
conceitos
2
O Scrum
Metodologias tradicionais: vantagens e desvantagens. Filosofia por trás das 
metodologias ágeis. Metodologias ágeis: características, vantagens e desvantagens.
O Scrum. Metodologias de desenvolvimento de software. Filosofia do Scrum.
 
Processo de software
qEm uma visão geral do processo/projeto de desenvolvimento de software, podemos 
subdividi-lo em cinco fases genéricas que independem da área de aplicação, tamanho ou 
complexidade do projeto: 
 1 Especificação;
 1 Projeto; 
 1 Implementação;
 1 Validação; 
 1 Manutenção. 
Para cada uma delas, existe uma série de atividades que são executadas.
O processo de software pode ser visto como um gerador de produtos, sendo o software 
em si o produto final – no entanto, é importante perceber que existem subprodutos 
gerados em cada fase. Por exemplo, no final da fase de especificação, é comum se pro-
duzir e entregar um ou mais documentos em que se detalham os requisitos do sistema. 
A seguir, detalharemos um pouco essas fases e suas atividades associadas.
Fase de especificação
qÉ uma das etapas iniciais do projeto, pois é onde procuram-se identificar funcionali-
dades, restrições, validações, interfaces e principalmente os requisitos-chave que o 
projeto deve cobrir. 
Deve haver interação com o cliente para validar todas as informações por ele passadas e 
com ele coletadas, a fim de que todos os requisitos sejam atendidos de maneira correta no 
decorrer da implementação do produto.
20
 
Fu
nd
am
en
to
s 
do
 S
cr
um
qÉ composta por três atividades principais, que são executadas, independentemente dos 
métodos utilizados, porém podem variar de acordo com o paradigma usado. As suas 
tarefas são:
 1 Engenharia de sistema: estabelecimento de uma solução geral para o problema, 
envolvendo questões de tecnologia e equipamento;
 1 Análise de requisitos: levantamento das necessidades do software a ser implementado 
– tem como objetivo produzir uma especificação de requisitos em forma de documento;
 1 Especificação de sistema: descrição funcional do sistema. Pode incluir um plano de 
testes para verificar adequação.
Fase de projeto
qO projeto é finalizado quando seus objetivos propostos são alcançados e quando se 
encontra estruturado, em termos de arquitetura, interface e técnicas. Suas atividades são:
 1 Projeto arquitetural: aqui se desenvolve um modelo conceitual para o sistema, com-
posto por módulos mais ou menos independentes;
 1 Projeto de interface: onde cada módulo tem sua interface de comunicação estudada e 
definida. Pode resultar em um protótipo;
 1 Projeto detalhado: onde os módulos em si são definidos e, possivelmente, traduzidos 
para pseudocódigo.
Fase de implementação
qTambém chamada de fase de desenvolvimento ou codificação. É a fase que define como 
os dados serão estruturados e implementados tecnicamente. Em outras palavras, é 
quando o projeto, que antes estava documentado em papel, passa a ser transformado 
para entrar em operação de fato. Linguagens de programação, técnicas e métodos – que 
podem variar de projeto para projeto –, contudo, atividades comuns a todas metodolo-
gias precisam ser realizadas, tais como:
 1 Projeto de software: parte central do desenvolvimento, que mostra o que e como 
será desenvolvido;
 1 Geração de código: que consiste em traduzir em linguagem de programação o que foi 
especificado no projeto de software.
Fase de teste
qNesta fase, encontram-se as não conformidades com o que foi especificado durante a 
fase de especificação, com o objetivo de aumentar a qualidade do produto. Suas ativi-
dades são:
 1 Teste de unidade e módulo: consiste na realização de testes para verificar a 
presença de erros e comportamento inadequado relacionado às funções e módulos 
básicos do sistema;
 1 Integração: reunião dos diferentes módulos em um produto de software homogêneo 
e verificação da interação entre esses quando operando em conjunto.
21
 
C
ap
ítu
lo
 2
 - 
O
 S
cr
um
Fase de manutenção
qConsiderada a fase final, onde se analisa todo o produto. Tem como foco principal as 
modificações, como correções de erros, adaptações necessárias e melhorias (novas 
funcionalidades não planejadas inicialmente) para evolução do software. 
Nessa fase, o software em geral entra em um ciclo interativo que abrange as fases anteriores. 
Como ocorrem alterações, a fase de manutenção abrange características das fases anteriores, 
porém seu enfoque é um software já existente.
qSão quatro os tipos de modificações que podem ocorrer:
 1 Manutenção corretiva: visa corrigir os defeitos que ocorreram durante a fase de 
desenvolvimento;
 1 Manutenção adaptativa: modifica o software para adaptá-lo a alterações no 
ambiente externo;
 1 Manutenção perfectiva: adiciona novas funcionalidades ao software. Essas novas 
especificações estão fora do escopo do projeto original e são consideradas como 
melhorias de produto;
 1 Manutenção preventiva: assume que mudanças tanto no ambiente externo quanto 
de especificações vão ocorrer – portanto, já é implantado para que o impacto 
causado por essas alterações não afete o sistema.
Para tornar o desenvolvimento de software uma atividade menos caótica, e buscando 
aumentar a qualidade e produtividade em seus projetos, as organizações produzem 
seus próprios modelos de processo de software.
Assim, é impossível conceber um modelo uniforme que possa descrever com precisão o que 
de fato acontece durante todas as fases de produção de um software – os procedimentos 
utilizados são variados e as necessidades organizacionais diferem substancialmente. 
qO que se pode dizer é que todo modelo de software deve levar em consideração as fases 
descritas anteriormente; no entanto, cada organização organiza as fases do seu Modelo 
de Processo de Software de acordo com sua filosofia.
Assim, um modelo, ou uma metodologia de desenvolvimento, é uma filosofia do anda-
mento das fases – ciclo de vida – e não uma descrição de como cada atividade deve ser 
executada ao pé da letra. Um modelo de desenvolvimento corresponde a uma repre-
sentação abstrata do processo de desenvolvimento que vai, em geral, definir como as 
etapas relativas ao desenvolvimento do software serão conduzidas e inter-relacionadas 
para atingir o objetivo do desenvolvimento – que é a obtenção de um produto de sof-
tware de alta qualidade a um custo relativamente baixo.
Metodologias de desenvolvimento tradicionais: 
vantagens e desvantagens
qAs Metodologias de Desenvolvimento de Software são uma resposta das organizações, 
em especial das Software Houses, que buscavam desenvolver projetosde maneira mais 
organizada e profissional, à Crise do Software. Linguagens foram criadas para modelar e 
facilitar o produto pelo cliente e pela própria empresa desenvolvedora.
A documentação gerada a partir da análise e especificação dos projetos era acompa-
nhada por um método de desenvolvimento para suportar o processo de fabricação do 
software. Os métodos surgiram para dividir todo o processo em etapas e prover sua 
melhor visualização, sempre com foco na melhor qualidade final do produto.
22
 
Fu
nd
am
en
to
s 
do
 S
cr
um
qDe acordo com Sommerville, metodologia de desenvolvimento é o “conjunto de práticas 
recomendadas para o desenvolvimento de softwares, sendo que essas práticas geral-
mente passam por passos ou fases, que são subdivisões do processo para ordená-lo 
e melhor gerenciá-lo”. As metodologias consideradas tradicionais, também chamadas 
de “pesadas”, têm como característica marcante a sua divisão em etapas e fases bem 
definidas, como Análise, Modelagem, Desenvolvimento e Testes. A conclusão de cada 
fase gera um marco, que tipicamente refere-se um documento, protótipo do software ou 
versão do sistema.
O foco principal dessas metodologias é a previsibilidade dos requisitos do sistema, que 
traz a grande vantagem de tornar os projetos completamente planejados, facilitando 
sua gestão, mantendo uma linha de comando e caracterizando o processo com bas-
tante rigor. Essa previsibilidade é alcançada porque mais tempo é dedicado na fase de 
análise e na elaboração da documentação de planejamento. Como se pode imaginar, o 
controle do projeto é dificultado já que, em situações reais de projeto, sempre que se 
deseja alterar um requisito, ou parte do escopo, é necessário voltar ao início do projeto 
e reiniciar todo o processo de planejamento. 
As metodologias pesadas defendem que uma documentação detalhada é necessária por 
oferecer um embasamento maior para manutenção do software e prevenir a troca de 
recursos. Caso um desenvolvedor resolva sair do projeto, por exemplo, todo o projeto 
estará documentado e quem assumir estará munido de informações para continuar o 
projeto sem necessidade de perder muito tempo.
Apesar de os modelos de desenvolvimento terem atendido diversos problemas originados 
pela Crise do Software, eles possuem limitações que na prática acabam não atendendo as 
necessidades de uma equipe técnica, podendo até mesmo inviabilizar os projetos de desen-
volvimento em função dessas deficiências. 
Levando em consideração que o processo de desenvolvimento é bastante mutável, ele 
acaba demandando muito tempo de trabalho, pois frequentemente há o surgimento de 
novos requisitos por parte do cliente, tanto funcionais como não funcionais, assim como a 
não conformidade de algumas solicitações resulta na necessidade de alteração constante na 
documentação e no produto em si.
Vantagens e desvantagens
qAs vantagens principais das metodologias de desenvolvimento tradicionais são: redução 
de riscos envolvendo custos a um único incremento e aceleração do tempo de desenvol-
vimento do projeto como um todo, visto que os desenvolvedores trabalham de maneira 
mais eficiente quando buscam resultados objetivos.
Quando se segue uma metodologia moderna como o Rational Unified Process (RUP), as 
metodologias tradicionais incorporam uma série de outros benefícios, tais como: 
 1 Gerenciamento de requisitos: para garantir que as mudanças nos requisitos, que 
são comuns após o início do desenvolvimento, sejam administradas em um projeto 
desenvolvimento iterativamente;
 1 Integração de elementos: quando cada módulo desenvolvimento é integrado ao 
sistema como um todo, evitando que a atividade de “juntar as partes” seja um pro-
blema no fim do projeto;
23
 
C
ap
ítu
lo
 2
 - 
O
 S
cr
um
q 1 Gerenciamento de riscos: a cada iteração, é possível analisar pontos críticos e pla-
nejar estratégias para não perder tempo durante o desenvolvimento;
 1 Testes: são realizados no fim de cada módulo, permitindo que erros e não conformi-
dades possam ser tratados ainda dentro do mesmo ciclo.
Embora as abordagens tradicionais tenham surgido como um recurso para empresas 
desenvolvedoras de software, são diversas as críticas e limitações que surgiram. Além das 
já citadas anteriormente, o enorme número de documentos exigidos em cada atividade 
dificulta a implantação por empresas que não possuem recursos para criar e gerenciar tal 
documentação. Com isso, são muito poucas as pequenas organizações que conseguiram 
implantar processos pesados e tradicionais com sucesso – eles são mais indicados para 
grandes equipes de desenvolvimento.
Exercício de fixação e 
Que metodologias de desenvolvimento são utilizadas na sua organização? 
Você enxerga vantagens e desvantagens no seu uso? Quais?
Metodologias de Ágeis de Projetos
qNa última década, um novo segmento da comunidade da Engenharia de Software vem 
defendendo processos simplificados, com foco nas pessoas que compõem o processo 
e, principalmente, no programador. Também chamada de metodologia de desenvol-
vimento leve, as metodologias ágeis propõem a execução dos passos do projeto em 
paralelo, e sua principal característica é o menor esforço à documentação.
A documentação do projeto tende a ser simplificada e orientada pelo código-fonte. 
A crítica mais frequente às metodologias tradicionais é que são burocráticas. Para seguir 
a metodologia, é produzida grande quantidade de material, que faz diminuir a veloci-
dade de desenvolvimento.
Arquitetura / 
Projeto
Prototipação
Validação 
do clienteImplantação
Levantamento 
Requisitos
DesenvolvimentoTestes
Figura 2.1 
Fases de uma 
metodologia 
tradicional.
24
 
Fu
nd
am
en
to
s 
do
 S
cr
um
qO novo advento ágil iniciou com alguns especialistas da indústria do desenvolvimento de 
software, que se uniram para encontrar valores e princípios relacionados ao desenvolvi-
mento, que escreveram o Manifesto Ágil. Esse manifesto destacava quatro valores:
 1 Software funcional em vez de documentação detalhada;
 1 Colaboração ao cliente em vez de negociação de contratos;
 1 Indivíduos e iterações em vez de somente processos e ferramentas;
 1 Responder às mudanças em vez de seguir um plano minuciosamente detalhado 
inicialmente.
Software Funcional em vez de Documentação Detalhada
qA ideia dos projetos ágeis é medir o progresso do projeto em função da quantidade de 
software funcional existente, em vez de considerar um grande volume de documentos 
e a fase do processo em que o projeto se encontra como fatores determinantes para o 
progresso atual. Considera-se que 30% do projeto estão prontos quando 30% das funcio-
nalidades necessárias estiverem funcionando. 
A documentação de um projeto é extremamente necessária para o seu sucesso, e projetos 
ágeis reconhecem isso. O código não é o melhor meio de comunicação entre o racional e a 
estrutura do sistema. Documentação legível é necessária para manter o sistema e fazê-lo 
evoluir; porém, o excesso de documentação é pior do que a falta dela. O manifesto, no 
entanto, sugere que somente a documentação necessária seja gerada, e que esta seja 
sempre atualizada com o código gerado.
Uma documentação enxuta promove integração na equipe em função da transferência de 
conhecimento sobre o projeto que será realizado paralelamente com o código, uma vez que 
este não permite duplas interpretações. De nada adianta ter uma extensa gama de docu-
mentos que demandam muito tempo para serem gerados, depois lidos e, principalmente, 
para mantê-los atualizados. A documentação tem o papel de orientar todos os membros 
envolvidos no projeto.
Documentações e papéis não contam como entregas, pois não satisfazema necessidade do 
cliente. O cliente escolhe se vai implantar o sistema incompleto, se vai apenas testá-lo para 
definir novas funcionalidades ou se vai apenas testá-lo para encontrar não conformidades 
com aquilo que deseja.
Colaboração ao cliente em vez de negociação de contratos
qAs metodologias leves enfatizam o relacionamento próximo com o cliente, exigindo que 
sua participação seja dedicada, inteligível, colaborativa e efetiva. Esse envolvimento 
favorece caso os requisitos sejam imprevisíveis e sujeitos a mudanças; porém, havendo 
pontos de vista diferentes entre os desenvolvedores e cliente, possivelmente ocorrerão 
conflitos, riscos e negligências. Esses riscos podem ser reduzidos através de métodos 
guiados por documentação, planejamento e revisão na arquitetura. 
As metodologias ágeis abordam o desenvolvimento de uma lista de prioridades e funcio-
nalidades, para que o cliente defina e classifique o que é prioritário para ele. Tal definição é 
atualizada constantemente no início de cada ciclo.
O Manifesto Ágil, no 
entanto, não é contra 
documentação. Ele diz 
claramente: “Nenhum 
documento é gerado a 
não ser que seja 
necessário e significante.”
l
25
 
C
ap
ítu
lo
 2
 - 
O
 S
cr
um
Indivíduos e iterações em vez de somente processos e ferramentas
qA experiência e capacitação dos profissionais no desenvolvimento do projeto afetam 
diretamente na qualidade do produto e no bom desempenho da equipe do projeto. Ter 
excelentes profissionais, no entanto, não é uma garantia de sucesso, pois eles dependem 
diretamente do processo. 
Um processo de má qualidade pode fazer com que os melhores desenvolvedores 
não sejam capazes de usar todo o seu talento.
qAlém da combinação do processo adequado com bons profissionais, é preciso que toda 
a equipe possa interagir perfeitamente entre si. Comunicação é mais importante que 
simples talento para programação. Um desenvolvedor que consegue se relacionar bem 
e trabalha bem em equipe tipicamente é mais produtivo que um excelente programador 
que só consegue trabalhar sozinho. Comunicação é o principal valor dos Processos Ágeis 
e é a maneira mais rápida de se obter informações.
Além disso, as responsabilidades e decisões são compartilhadas por toda a equipe, mos-
trando que todos estão envolvidos no processo e trabalhando em grupo. Assim, para a 
seleção dos funcionários envolvidos, deve-se levar em consideração o perfil, a competência, 
o comportamento individual e em equipe, e o profissional deve ser comunicativo. Obviamente, 
uma organização em transição deve ser capaz de treinar os seus profissionais – no entanto, 
é fundamental que todos estejam motivados, seja com o apoio de outros membros da 
equipe ou com o material e equipamento.
Outra característica é a iteração. Após cada iteração, deve ser possível apresentar um pro-
tótipo para o cliente e coletar o seu retorno. Como já dito anteriormente, nas metodologias 
ágeis, é criada uma lista de prioridades de funcionalidades de acordo com o que o cliente 
julga como prioritário para ele. Tal lista é atualizada constantemente a cada iteração, permi-
tindo acrescentar novos requisitos e mudanças, ajustando as prioridades. Dessa maneira, 
o gerente de projeto pode garantir que a equipe de desenvolvimento esteja trabalhando de 
acordo com os aspectos que o cliente considera mais significativo.
qUm processo ágil consiste em entregas rápidas e constantes. Entrega-se no início do 
projeto o primeiro sistema, ou parte do sistema, já com algumas funcionalidades desen-
volvidas, sendo que novos pacotes de funcionalidades continuam sendo desenvolvidos e 
integrados ao módulo anterior no decorrer do tempo.
Responder à mudanças x planos detalhados
qAssumindo que mudanças de especificação sempre vão ocorrer em qualquer projeto, 
é possível afirmar que tais projetos terão mais sucesso quando se adaptarem a essas 
mudanças. Flexibilidade é fator fundamental para o sucesso em projetos, pois determina 
o quanto estes são adaptáveis. Processos ágeis são receptivos a mudanças, mesmo que 
elas apareçam durante o desenvolvimento e os testes. Os participantes não temem as 
mudanças, pois assumem que elas são indicadores de que a equipe está aprendendo 
sobre o sistema, tentando atingir a satisfação do cliente.
26
 
Fu
nd
am
en
to
s 
do
 S
cr
um
Acerca da existência de planos, o Manifesto Ágil não é contra. Ele defende que planos sejam 
esboçados, mas que, como não é possível prever o futuro, as visões desses não devem ir 
muito longe. 
qO planejamento, portanto, deve ser de curto prazo, em virtude das alterações que 
invariavelmente vão aparecer. Na verdade, é muito difícil seguir planos de longo prazo 
à risca, então faz pouco sentido concentrar muito esforço nisso. Uma dica importante 
quando se identifica que o projeto será muito extenso é dividi-lo em fases, tornando 
mais fácil gerenciá-lo e executá-lo.
Velocidade e qualidade
qOra, para garantir um desenvolvimento rápido, é necessário um software limpo e mais 
robusto possível. Isso porque as equipes de projetos ágeis são orientadas a desenvolver 
códigos com qualidade.
Assim, o que deve ser mantido nos Processos Ageis é a velocidade do desenvolvimento. 
De nada adianta iniciar um projeto desenvolvendo-o rapidamente se essa velocidade 
declinar com o tempo, pois isso pode iludir o cliente, causando a ele uma impressão de falsa 
velocidade, além de estressar os desenvolvedores e diminuir a qualidade final do produto, 
quebrando os principais valores dos Processos Ágeis.
Vantagens e desvantagens
qAs vantagens da Metodologia de Desenvolvimento Ágil são:
 1 Receptividade às mudanças;
 1 Orientada às pessoas, não aos processos;
 1 Complementada por checagens dinâmicas;
 1 Equipes de desenvolvimento menores;
 1 Com foco para o compartilhamento do conhecimento; 
 1 Feedback praticamente instantâneo;
 1 Versões úteis;
 1 Visão clara de riscos e incertezas na arquitetura do projeto;
 1 Poderá ser considerada uma solução de valor agregado;
 1 Uma versão poderá ser entregue ao cliente em um tempo menor do que uma versão 
desenvolvida com a metodologia pesada;
 1 São adaptáveis, favorecendo o aprendizado dos envolvidos, aprimorando o projeto e 
formando assim um ciclo de projeto.
O gerente do projeto não precisa desenvolver um projeto pesado de documentação – pelo 
contrário, ele só precisa ter foco no absoluto necessário, como a programação das tarefas.
No entanto, a grande limitação das metodologias ágeis é a maneira como elas manipulam 
grandes equipes. Metodologias pesadas e seus métodos pré-guiados se adaptam melhor às 
dificuldades de comunicação, algo extremamente complexo, entre pessoas em projetos que 
contam com mais de vinte desenvolvedores. 
27
 
C
ap
ítu
lo
 2
 - 
O
 S
cr
um
qComo a prioridade máxima das metodologias ágeis é satisfazer o cliente, fornecendo o mais 
rapidamente possível e continuamente novas funcionalidades para o seu software, em 
grandes sistemas essa filosofia pode resultar em retrabalho por falta de escala em sua arqui-
tetura. Tradicionalmente, os objetos da metodologia pesada como previsibilidade, repetição 
e otimização são características de um desenvolvimento seguro. Portanto, seria displicente a 
aplicação da modelagem ágil em sistemas críticos de manutenção vital, por exemplo.
Exercício de fixação e 
Você acredita que a sua organização e os seus clientes se beneficiariam da 
adoção de uma metodologia como o Scrum?
Histórico do Scrum
qO Scrum foi a princípio concebido como um estilo de gerenciamento de projetos em 
empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka, 
no artigo “The New Product Development Game” (Harvard Business