GAP_Unidade 02

Prévia do material em texto

METODOLOGIAS DE 
GESTÃO ÁGIL DE PROJETOS
Professor:
Me. Reginaldo Aparecido Carneiro
Diretoria Executiva Pedagógica Janes Fidelis Tomelin
Diretoria Operacional de Ensino Kátia Coelho 
Diretoria de Planejamento de Ensino Fabrício Lazilha
Head de Projetos Educacionais Camilla Barreto Rodrigues Cochia Caetano
Head de Produção de Conteúdos Celso Luiz Braga de Souza Filho
Gerência de Produção de Conteúdos Diogo Ribeiro Garcia
Gerência de Projetos Especiais Daniel Fuverki Hey
Supervisão do Núcleo de Produção de Materiais Nádila de Almeida Toledo
Projeto Gráfico Thayla Guimarães 
Designer Educacional Nayara Garcia Valenciano 
Editoração Flávia Thaís Pedroso
DIREÇÃO
Reitor Wilson de Matos Silva 
Vice-Reitor Wilson de Matos Silva Filho 
Pró-Reitor de Administração Wilson de Matos Silva Filho 
Pró-Reitor de EAD William Victor Kendrick de Matos Silva 
Presidente da Mantenedora Cláudio Ferdinandi
NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
NEAD - Núcleo de Educação a Distância
Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900 
Maringá - Paraná | unicesumar.edu.br | 0800 600 6360
As imagens utilizadas neste livro foram 
obtidas a partir do site shutterstock.com
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação 
a Distância; CARNEIRO, Reginaldo Aparecido.
 
 Gerenciamento Ágil de Projetos. Reginaldo Aparecido 
Carneiro.
 Maringá-Pr.: UniCesumar, 2017. 
 60 p.
“Pós-graduação Universo - EaD”.
 1. Gerenciamento 2. Projeto 3. EaD. I. Título.
 ISBN 978-85-459-0046-7
CDD - 22 ed. 350
CIP - NBR 12899 - AACR/2
01
02
03
sumário
07| O FRAMEWORK SCRUM
24| O FRAMEWORK EXTREME PROGRAMMING (XP)
36| O SISTEMA KANBAN E OUTRAS METODOLOGIAS ÁGEIS
OBJETIVOS DE APRENDIZAGEM
 • Delinear as características do framework Scrum, destacando aspectos que 
melhoram o ambiente de desenvolvimento nas empresas, tornando os 
times mais efetivos e produtivos.
 • Relatar sobre o framework eXtreme Programming (XP), apresentando os 
seus princípios básicos, bem como as suas principais práticas e valores, 
com enfoque na sua aplicabilidade como forma de garantir evolução nos 
negócios.
 • Apresentar uma breve abordagem sobre Kanban, explicando sobre o seu 
conceito de visualização, bem como o porquê da simplicidade e efetividade 
nos resultados a partir de sua aplicação.
 • Relatar brevemente sobre outras metodologias ágeis aplicadas nas empresas, 
destacando algumas de suas particularidades quando da sua aplicação.
PLANO DE ESTUDO
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 • O Framework Scrum
 • O Framework eXtreme Programming (XP)
 • O Sistema Kanban e Outras Metodologias Ágeis
METODOLOGIAS DE GESTÃO ÁGIL DE PROJETOS
INTRODUÇÃO
introdução
Prezado(a) aluno(a),
Quais métodos ágeis eu posso utilizar na minha empresa? Antes de 
qualquer tipo de decisão quanto a esse assunto, faz-se necessário (e isso é de 
grande importância) compreender como se dá o funcionamento de algumas 
metodologias, pois cada uma delas tem as suas particularidades.
Como você poderá perceber, as entregas na metodologia ágil são realizadas 
dentro de ciclos, onde há prevalência de iterações, permitindo que um conjunto 
mínimo de funcionalidades seja suficiente para entregar o seu valor. Um cliente 
pode saber exatamente quanto custa o projeto, pois pode ter um montante 
específico para investir naquele produto. Entretanto ainda podemos destacar 
que alguns clientes nem sempre fazem ideia do custo total do projeto, bem 
como do escopo de abrangência do mesmo. É exatamente por esse motivo que 
ele participa de forma efetiva de todo o processo, possibilitando a alteração do 
plano conforme o surgimento das necessidades mais importantes.
Ao se analisar uma metodologia, outro item com que nos deparamos é a 
cultural empresarial. Esta, sem dúvida, influenciará muito no ato da escolha da 
metodologia que você escolherá para uma empresa. Ressalto aqui que, mesmo 
em se tratando da aplicação de uma abordagem ágil em um projeto, a sua 
empresa poderá passar por dificuldades em função da resistência ao processo 
de mudança. Ninguém aprecia uma mudança em sua zona de conforto, o que 
pode contribuir como forte adversária. Logo, o fator cultural deve ser bem 
trabalhado nesse sentido, principalmente em um mercado de muitas mudanças 
e altamente competitivo.
No entanto a questão das mudanças, apesar de ser um ponto extremamente 
importante, não é o único em comum entre os métodos que você poderá 
escolher. Siqueira et al. (2002) destacam outros seguintes, tais como: a busca 
pelo mínimo necessário e suficiente de documentação e processo, a importância 
das pessoas e da comunicação entre elas, o foco no cliente e também na sua 
participação direta, a entrega frequente e com valor ao cliente.
INTRODUÇÃO
introdução
Uma coisa é certa: as metodologias ágeis devem ser utilizadas quando 
há grande incerteza sobre uma solução que o cliente busca. Elas instigam as 
entregas em ciclos curtos, em que o cliente já pode (no curto prazo) testar 
algumas das funcionalidades que estavam no escopo de seu projeto.
Na sequência, serão demonstradas algumas das principais metodologias 
ágeis aplicadas no mercado, quais sejam: Scrum, eXtreme Programming e o 
Kanban. Ainda serão apenas citadas, de forma bem rápida, outras metodologias 
ágeis presentes no mercado. Caso tenha pretensão de realizar alguma pesquisa 
mais profunda, são elas: Crystal Family, FDD (Feature-Driven Development) e 
DSDM (Dynamic Systems Development Method).
Com isso, desejo uma ótima leitura para você!
Pós-Universo 7
O FRAMEWORK 
SCRUM
Pós-Universo 8
Olá! Vamos dar continuidade em nossos estudos, desta vez falando sobre o framework 
Scrum. Há algum tempo que muitos profissionais da área de TI têm buscado novas 
formas de desenvolvimento de softwares de maior qualidade. Por sua vez, o framework 
de desenvolvimento ágil Scrum traz boas práticas ágeis que contribuem para tal 
desenvolvimento. O primeiro ponto a se ressaltar é que o Scrum não é uma metodologia, 
mas, sim, um framework. As metodologias são prescritivas, pois detalham tudo o que 
deve ser realizado de forma detalhada, e isso não ocorre no Scrum.
Definição realizada, partimos efetivamente agora para uma explanação sobre o 
framework Scrum. Esse framework foi criado por Ken Schwaber e Jeff Sutherland, no 
ano de 1995, cujo nome tem origem do jogo de Rugby. Aliás, destaca-se que diversos 
termos utilizados no Scrum foram extraídos exatamente desse jogo. Inicialmente, foi 
baseado no sistema de gerenciamento de projetos, criado por Takeuchi e Nonaka, 
no artigo “The new product development game”. Nesse artigo, Takeuchi e Nonaka 
(1986, p. 137) afirmam:
 “
No mundo altamente competitivo de desenvolvimento comercial de novos 
produtos em que velocidade e flexibilidade são essenciais, as empresas 
estão cada vez mais percebendo que a antiga abordagem, sequencial ao 
desenvolvimento de novos produtos simplesmente não possui um retorno 
aceitável. Em vez disso, as empresas no Japão e nos Estados Unidos estão 
usando um método holístico, como em rugby, a bola é passada dentro da 
equipe como ela se move como uma unidade até o campo.
Scrum é o nome de uma das jogadas mais conhecidas do esporte conhecido como 
Rugby. Nesse esporte, os jogadores disputam a reposição de bola e onde é necessária 
a participação de todos os jogadores do time atuando em conjunto no mesmo 
objetivo, sendo que, se um deles falhar, todos falham. Esse trabalho em equipe é 
bem caracterizado no framework do Scrum, por isso leva o seu nome.
A base disso se deu com a produção enxuta (lean) iniciada pela empresa Toyota e, 
posteriormente, ampliada para diversas outras organizações. Tendo tais informações 
como referência, Schwaber e Sutherland notaram que os projetos que utilizavam 
equipes menores e multidisciplinares produziam melhores resultados, como ocorre 
com uma formação Scrum, do Rugby. Dessa forma, Jeff Sutherland, John Scumniotales 
e Jeff conceberam, documentarame implementaram o Scrum.
Pós-Universo 9
Em linhas gerais, Scrum é um framework utilizado por empresas nas quais as 
pessoas podem tratar e resolver problemas complexos e adaptativos, sendo produtivos 
e criativos diante da entrega de produtos com o mais alto valor possível para o cliente. 
Pode-se dizer que o Scrum é leve, simples de entender e extremamente difícil de 
dominar. Esse framework deixa claro a eficácia relativa das práticas de gerenciamento 
e desenvolvimento de produtos, de modo que você possa melhorá-las.
Uma vez que a empresa pratica o Scrum, este se torna muito objetivo, ostentando 
papéis bem definidos, com muita facilidade em sua adaptação e com uma curva de 
aprendizado relativamente baixa. Entretanto, para uma organização que pretenda 
implementar o Scrum, faz-se necessário destacar que não é nada fácil fazer a transição 
para esse framework. 
Segundo o autor Schwaber (2004), o Scrum não é um processo previsível, ele 
não define o que fazer em toda circunstância. Ele pode ser utilizado em trabalhos 
complexos nos quais não é possível prever tudo o que irá ocorrer e oferece um 
framework e um conjunto de práticas que torna tudo visível. Com isso, ele permite 
aos envolvidos no Scrum saber o que está ocorrendo ao longo do projeto e fazer os 
ajustes necessários para manter o projeto se movendo ao longo do tempo, sempre 
com vistas ao alcance dos objetivos.
Em geral, o framework Scrum se baseia no desenvolvimento incremental de 
aplicações centrada na equipe, permitindo um maior controle do processo pelo fato 
de ter ciclos de iterações relativamente curtos. Por levar em consideração a equipe, isso 
promove melhorias na comunicação, além de maximizar a cooperação, permitindo 
que cada um faça o seu melhor e se sinta bem com o que faz. Como reflexo, temos 
um aumento de produtividade no desenvolvimento do projeto.
Conforme Ferreira (2005, p. 4), as principais características do Scrum são:
 “
Trata-se um projeto ágil para gerenciar e controlar o desenvolvimento de 
projetos; é um processo que controla o caos resultante de necessidades e 
interesses conflitantes; é uma forma de aumentar a comunicação e maximizar 
a cooperação; é uma forma de detectar e remover qualquer impedimento que 
atrapalhe o desenvolvimento de um produto; e é escalável desde projetos 
pequenos até grandes projetos em toda empresa.
Pós-Universo 10
Com base nesta citação, é importante reforçar que o framework Scrum pode ser 
aplicado tanto em projetos pequenos quanto em projetos grandes. Tendo como 
necessidade um esforço na liberação do processo de quaisquer barreiras, a sua principal 
intenção é conseguir uma avaliação correta do ambiente em evolução, adaptando-
se constantemente às mudanças de necessidades, em um ambiente complexo, onde 
os requisitos mudam com frequência.
Então, a partir da apresentação da origem do Scrum, bem como dos seus principais 
objetivos e as suas características, surge o seguinte questionamento: como se dá o 
funcionamento desse framework? É exatamente essa informação que será explanada 
na sequência para você. Vamos, então, a este detalhamento?
De acordo com o Guia do Scrum, escrito por Schwaber & Sutherland (2015), o 
framework Scrum consiste nos times do Scrum associados a papéis, eventos, artefatos 
e regras. Cada componente dentro do framework serve a um propósito específico 
e é essencial para o uso e sucesso do Scrum. Ainda de acordo com os autores, as 
regras do Scrum integram os eventos, papéis e artefatos, administrando as relações 
e interações entre eles.
De acordo com Massari (2014), bem como o Guia do Scrum, o framework é regido 
por três pilares bem caracterizados, sendo eles: a transparência (todo acontecimento 
atrelado ao procedimento de entrega que pode impactar no resultado final do 
projeto deverá ter visibilidade e ser do conhecimento da equipe envolvida, inclusive 
do próprio cliente), a inspeção (todos os processos atinentes à entrega do produto 
ao cliente final devem ser inspecionados com frequência, para que todo e qualquer 
desvio possa ser percebido e corrigido o mais rápido possível), e a adaptação (todo 
momento em que uma situação prejudicial é identificada, o processo deverá ser 
ajustado no mesmo instante, a fim de se evitar outros desvios e comprometer a 
entrega do projeto).
Qualquer método ágil possui papéis, processos e artefatos. Da mesma forma, 
não se esqueça de que qualquer um dos métodos ágeis deve ser considerado 
como processos empíricos (complexos, caóticos ou com muita incerteza, 
têm mudança ao longo do processo, não são repetitivos e são imprevisíveis).
Fonte: o autor (2015).
atenção
Pós-Universo 11
O Time Scrum
O time Scrum é composto basicamente por três papéis bem característicos: pelo 
Product Owner, o Time de Desenvolvimento e o Scrum Master. A Figura 01 deixa essa 
composição muito clara para você:
Figura 01: Visão Geral dos Papéis do Scrum 
Fonte: Guia SBOK (2013, p. 42).
Uma informação importante condiz com o fato de o time Scrum ser auto-organizável 
e multifuncional. Mas o que significa isso? Um time auto-organizável escolhe a melhor 
forma para realizar o seu trabalho, sem a necessidade de outra direção que esteja fora 
desse time. Por sua vez, a equipe é multifuncional, pois detém todas as competências 
necessárias para a execução do trabalho, sem a dependência de outras pessoas que 
não fazem parte da equipe. Com isso, você pode perceber que um time Scrum é 
projetado para ser flexível, criativo e, consequentemente, produtivo naquilo que faz.
Pós-Universo 12
Retornando aos papéis do time Scrum, o Product Owner (ou dono do produto, 
que é representado por uma pessoa) é o responsável pela maximização do valor do 
produto, assim como de todo o trabalho do Time de Desenvolvimento. É ele quem 
elabora a visão do produto, gerenciando o Backlog do Produto, com as devidas 
prioridades, ordenação, para garantir valor, compreensão e visibilidade do processo.
De acordo com o Guia Scrum, de Schwaber & Sutherland (2015, p. 5),
 “
o Product Owner é a única pessoa responsável por gerenciar o Backlog 
do Produto. O gerenciamento do Backlog do Produto inclui: a) expressar 
claramente os itens do Backlog do Produto; b) ordenar os itens do Backlog 
do Produto para alcançar melhor as metas e missões; c) garantir o valor do 
trabalho realizado pelo Time de Desenvolvimento; d) garantir que o Backlog 
do Produto seja visível, transparente, claro para todos, e mostrar o que o Time 
Scrum vai trabalhar a seguir; e, f ) garantir que o Time de Desenvolvimento 
entenda os itens do Backlog do Produto no nível necessário.
O Product Owner é responsável por todos esses trabalhos elencados. É importante 
ressaltar que, para que o seu papel surte efeitos positivos, toda a empresa deve 
respeitar as suas decisões.
O outro papel condiz com o Time de Desenvolvimento: trata-se de todo pessoal 
que, de forma auto-organizada e multifuncional (conforme explicado anteriormente), 
trabalha no desenvolvimento dos incrementos do produto. Para o Scrum, esse time 
é composto pelos desenvolvedores, sendo eles os responsáveis absolutos, mesmo 
que cada um tenha suas especializações.
De acordo com Schwaber & Sutherland (2015), os Times de Desenvolvimento são 
estruturados e autorizados pela organização para organizar e gerenciar seu próprio 
trabalho. Logo, a sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de 
Desenvolvimento como um todo.
Pós-Universo 13
Em se tratando de tamanho, o Guia Scrum sugere equipes não menores a três 
integrantes (pela dificuldade no que diz respeito às interações e pouco ganho de 
produtividade entre os participantes) e não superiores a nove (pois isso exigiria maior 
coordenação da equipe, em função da maior complexidade nesse processo).
O último papel no time Scrum (não significa dizer que é o menos importante) 
condiz ao Scrum Master. Trata-se do líder da equipe, cujo objetivo é o de facilitar e 
garantir que todos os integrantes compreendame sigam as teorias, as práticas e as 
regras do Scrum.
O papel do Scrum Master é assumido por um gerente de projeto ou qualquer 
membro da equipe que possa assumir o papel. Destaca-se que essa pessoa é responsável 
por muitas coisas. Talvez seja a mais importante em função de seu envolvimento na 
aprovação dos valores e práticas do Scrum, além de ter papel fundamental na remoção 
de eventuais impedimentos que possam aparecer.
O Scrum Master pode auxiliar tanto o Product Owner quanto o Time de 
Desenvolvimento. No caso do primeiro, ele pode encontrar técnicas para o 
gerenciamento efetivo do Backlog do Produto ou, então, compreender e praticar a 
agilidade, ou ainda facilitar os eventos Scrum conforme exigidos ou necessários. Por 
sua vez, o Scrum Master pode auxiliar o time ao remover impedimentos para o seu 
progresso, liderar o Time de Desenvolvimento na criação de produtos de alto valor, 
assim como treiná-lo para o autogerenciamento e interdisciplinaridade.
Em linhas gerais, o Scrum Master ainda pode dar suporte para a organização como 
um todo: desde uma situação de treinamento sobre o Scrum para os colaboradores 
de uma empresa, até na promoção de mudanças para aumentar a produtividade 
do time Scrum. Além disso, ele ainda pode planejar implementações Scrum dentro 
da organização e até mesmo entrar em contato com outros Scrum Masters para 
aumentar a eficácia da aplicação do Scrum nas empresas.
Pós-Universo 14
Eventos Scrum
Podemos destacar que os eventos são estruturados no sentido de criar uma rotina, 
sendo todos eles caracterizados como time-boxed, isto é, todo evento tem uma 
duração máxima. Toda vez, por exemplo, que uma Sprint começa a sua duração, é 
previamente fixada, não podendo ser reduzida ou expandida. Importante ressaltar 
que cada evento proporciona a possibilidade de inspecionar e adaptar alguma coisa.
A Sprint pode ser caracterizada como sendo o coração do Scrum. Trata-se de 
uma iteração com tempo determinado, com um time-boxed com duração de um 
mês (ou menos). Destaca-se que uma Sprint finalizada dará automaticamente início 
a outra e assim sucessivamente, até que o produto seja finalizado. Na verdade, uma 
Sprint até pode ser cancelada antes do time-boxed da Sprint terminar. Entretanto, 
apesar de influências advindas das partes interessadas do Time de Desenvolvimento 
ou do Scrum Master, apenas o Product Owner tem a autoridade para proceder com 
tal cancelamento. Esses cancelamentos são extremamente traumáticos para o Time 
Scrum e são práticas pouco comuns.
Segundo o Guia Scrum, de Schwaber & Sutherland (2015, p. 8),
 “
durante a Sprint não são feitas mudanças que possam por em perigo o 
objetivo da Sprint; as metas de qualidade não diminuem; e o escopo pode ser 
clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento 
quanto mais for aprendido.
As Sprints são compostas pela reunião de planejamento da Sprint, pelas reuniões 
diárias, pelo trabalho de desenvolvimento, por uma revisão da Sprint e por uma 
retrospectiva da Sprint. Façamos uma breve descrição sobre essa composição:
A Reunião de Planejamento da Sprint condiz com uma reunião realizada no 
1º dia da Sprint, definindo o que e como será feito, ou seja, trata-se de identificar o 
trabalho que será realizado na Sprint. Nesse momento, o Product Owner apresenta 
o Product Backlog ordenado e alinha com o Time de Desenvolvimento quais itens 
deverão ser entregues, de acordo com a capacidade da equipe.
O time-boxed dessa reunião deve ter uma duração não superior a oito horas. 
Aqui, o Scrum Master deve garantir que o evento ocorra de forma natural e que os 
participantes entendam efetivamente o seu propósito.
Pós-Universo 15
Destacamos que os desenvolvedores (time) são os responsáveis pela identificação 
das funcionalidades que serão desenvolvidas durante a Sprint. Pode-se dizer que todo 
o Time Scrum promove um trabalho colaborativo para compreender o trabalho da 
Sprint.
A partir da definição do objetivo da Sprint, a próxima etapa condiz com as decisões 
acerca de como serão construídas as funcionalidades durante a Sprint: esse trabalho é 
realizado pelo Time de Desenvolvimento. Os itens de Backlog do Produto, selecionados 
para a Sprint, junto com o plano de entrega deles, são denominados de Backlog da 
Sprint.
No final do planejamento da Sprint, você deve compreender que o Time de 
Desenvolvimento deve ser capaz de explicar tanto ao Product Owner quanto ao 
Scrum Master sobre como se pretende trabalhar como equipe auto-organizada para 
completar o objetivo da Sprint e criar o incremento previsto. Isto é, tudo deve estar 
muito bem explicado e compreendido.
Ainda em relação a informações extraídas do Guia Scrum, de Schwaber & Sutherland 
(2015, p. 11),
 “
[...] conforme o Time de Desenvolvimento trabalha, ele mantém o objetivo 
da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementam 
a funcionalidade e a tecnologia. Caso o trabalho acabe por ser diferente do 
esperado pelo Time de Desenvolvimento, então eles colaboram com o Product 
Owner para negociar o escopo do Backlog da Sprint dentro da Sprint.
A chamada Reunião Diária, via de regra mantida no mesmo horário e local, tem uma 
duração média de quinze minutos. Trata-se de uma ocasião onde a equipe compartilha 
o conhecimento entre si, de tal forma que o Scrum Master é o responsável pela 
realização da reunião que ocorre mediante três questionamentos básicos: 1) O que eu 
fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint? 2) O 
que eu farei hoje para ajudar o Time de Desenvolvimento a atender a meta da Sprint? 
3) Eu vejo algum obstáculo que impeça a mim ou ao Time de Desenvolvimento no 
atendimento da meta da Sprint? Perceba que a função básica dessa reunião é fazer 
com que o Time de Desenvolvimento sincronize as atividades e crie um plano para 
as próximas 24 horas.
Pós-Universo 16
A reunião promove condições para o Time de Desenvolvimento no sentido de ele 
ter a percepção do progresso em direção ao objetivo da Sprint. Além disso, também 
é utilizada para inspecionar se o progresso tende a completar o trabalho do Backlog 
da Sprint.
Fica muito evidente que as reuniões diárias promovem melhorias nas comunicações 
entre os integrantes da equipe, eliminam outras supostas reuniões, identificam 
potenciais impedimentos para o desenvolvimento, oferecem condições para tomadas 
de decisões rápidas, além de promover melhorias no nível de conhecimento do 
Time de Desenvolvimento. Trata-se de uma reunião que dá suporte para os pilares, 
inspeção e adaptação no Scrum.
A Revisão da Sprint é representada por uma reunião com duração máxima de 
quatro horas, que ocorre ao término da Sprint em que há uma demonstração do que 
foi realizado; e o Product Owner, consequentemente, aprova ou rejeita tal entrega. 
Trata-se de uma reunião informal, de modo que a apresentação do incremento 
destina-se a motivar, obter comentários e promover a colaboração dos envolvidos.
De acordo com Schwaber & Sutherland (2015), a reunião de revisão inclui alguns 
elementos, tais como: os participantes são representados pelo Time Scrum e os 
stakeholders (partes interessadas); o Scrum Master destaca os itens do Backlog do 
Produto que ficaram e os que não ficaram “prontos”; o Time aponta as ocorrências 
durante a Sprint; o Product Owner discute sobre informações atinentes ao Backlog 
do Produto; todo o grupo aponta para as ações da próxima Sprint, entre outros 
elementos.
Essa reunião tem uma importância vital para verificar o que ocorreu e dar um 
direcionamento para novas ações, as quais estão ligadas diretamente com a próxima 
Sprint. Com isso, certamente o Backlog do Produto pode ser readequado para o 
atendimento de novas oportunidades.
A Retrospectiva da Sprint é uma reunião com duração máxima de três horas, 
em que toda equipe faz uma reflexão sobre o andamento da Sprint, identificando 
potenciais melhorias a partir de questões chaves: o que correu bem durante a Sprint?O que precisa ser melhorado? E o que precisa ser diferente nas próximas Sprints? 
Trata-se de uma reunião em que o Time Scrum pode utilizar para fazer uma avaliação 
de tudo aquilo que ocorreu, promovendo melhorias como um todo.
Pós-Universo 17
Com referência ao Guia Scrum, de Schwaber & Sutherland (2015, p. 13),
 “
o propósito da Retrospectiva da Sprint é inspecionar como a última Sprint foi 
em relação às pessoas, aos relacionamentos, aos processos e às ferramentas; 
identificar e ordenar os principais itens que foram bem e as potenciais 
melhorias; e criar um plano para implementar melhorias no modo que o 
Time Scrum faz seu trabalho.
Importante destacar a importância do Scrum Master nessa etapa como um encorajador 
do Time Scrum para analisar e averiguar as melhorias potenciais em relação aos 
trabalhos realizados. Isso, com certeza, tem um impacto positivo sobre a qualidade 
resultante do produto. Essa reunião oferece um evento focado na inspeção e na 
adaptação, deixando claro que todas as melhorias evidenciadas poderão ser adotadas 
a qualquer momento.
Artefatos do Scrum
Podemos destacar que os artefatos do Scrum são representados pelo trabalho para 
o fornecimento de transparência e oportunidades para inspeção e adaptação. Tais 
artefatos são projetados para maximizar a transparência das informações chave, de 
forma que todos os envolvidos tenham a mesma compreensão dos artefatos.
Um dos aspectos fundamentais do Scrum é ter uma visão do produto bem 
definida, pois é considerada a base para a definição do Backlog do Produto. 
Então, surge o seguinte questionamento: o que é visão do produto? E o que 
seria esse tal de Backlog do Produto?
Fonte: o autor (2015).
reflita
Pós-Universo 18
Em se tratando de artefatos, temos a visão (trata-se de um meio para um fim maior 
com o objetivo de atender a necessidade de um cliente), o Backlog do Produto 
(uma lista de itens daquilo que precisa ser desenvolvido no produto, em uma visão 
ordenada por prioridade, sendo mantidos e refinados constantemente pelo Product 
Owner), o Backlog da Sprint (está relacionado com uma listagem que acusa as tarefas 
que deverão ser realizadas na Sprint, cujo objetivo sempre está relacionado com 
o atingimento da meta), e a definição de “pronto” (neste caso, todos os envolvidos 
deverão ter entendimentos alinhados com o requisito pronto). Vamos detalhar um 
pouco mais a seguir.
O Backlog do Produto pode ser caracterizado como uma lista que contempla 
tudo aquilo que deve ser necessário para a produção do produto, sendo que o 
Product Owner é o responsável por ele. O Backlog do Produto é bastante dinâmico, 
de tal forma que muda constantemente para identificar o que o produto necessita 
para ser mais apropriado, competitivo e útil. Logo, ele pode ser considerado como 
um artefato vivo. De acordo com Schwaber & Sutherland (2015), mudanças nos 
requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças 
no Backlog do Produto. Dessa forma, o Backlog do Produto existirá enquanto o 
produto também existir.
Um monitoramento atinente ao Backlog do Produto pode ocorrer para averiguar 
se ele está de acordo com o seu objetivo. Para tal, algumas práticas de estimativa 
têm sido utilizadas para esse fim, tais como o Gráfico de Burndown ou Gráfico de 
Consumo (gráfico que oferece uma estatística do progresso e velocidade da equipe) 
e o Planning Poker (de acordo com Kninberg (2007), cada membro da equipe recebe 
um baralho com 13 cartas; quando uma história é estimada, cada membro escolhe 
sua carta, identificando sua estimativa de tempo e dificuldade, em seguida, a carta é 
colocada virada para baixo sobre a mesa e quando todos tiverem feito sua escolha, 
as mesmas são reveladas simultaneamente, de forma que cada membro é forçado a 
pensar em sua estimativa, não sendo influenciado pelos outros elementos).
A partir do momento que o Backlog do Produto foi identificado, resta-nos 
saber quais itens foram selecionados para a Sprint junto do plano para entregar o 
incremento do produto e, consequentemente, atingir o objetivo da Sprint. Significa 
dizer que o Backlog da Sprint condiz exatamente com as funcionalidades que foram 
definidas para serem executadas dentro de uma Sprint.
Pós-Universo 19
No Guia Scrum, Schwaber & Sutherland (2015, p. 15) destacam que:
 “
o Backlog da Sprint é um plano com detalhes suficientes para que as 
mudanças no progresso sejam entendidas durante a Reunião Diária. O Time 
de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, 
e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre 
quando o Time de Desenvolvimento trabalha segundo o plano e aprende 
mais sobre o trabalho necessário para alcançar o objetivo da Sprint.
A partir do momento em que um novo trabalho surge, destacamos que apenas o Time 
de Desenvolvimento pode adicionar ele ao novo Backlog da Sprint. Obviamente que, 
quando algum elemento do plano não é mais importante, ele poderá ser descartado. 
Uma informação importante incide sobre a possibilidade de alteração do Backlog 
da Sprint: neste caso, apenas o Time de Desenvolvimento pode fazê-lo (a alteração 
pertence exclusivamente a esse Time).
Para finalizar sobre os artefatos do Scrum, temos que destacar sobre a importância 
de se ter transparência. Ou seja, todo acontecimento atrelado ao procedimento de 
entrega que pode impactar no resultado final do projeto deverá ter visibilidade e 
ser do conhecimento da equipe envolvida, inclusive o próprio cliente. Logo, a partir 
do momento em que os artefatos não forem transparentes, as decisões poderão ser 
falhas, os valores poderão diminuir e, consequentemente, os riscos poderão aumentar.
Dessa forma, ao final dos trabalhos atinentes as Sprints, os integrantes devem ter 
um entendimento conjunto a respeito do significado de o trabalho estar completo e/
ou finalizado (para assegurar a transparência). Para o Time Scrum, isso é denominado 
Definição de Pronto, sendo utilizado para assegurar quando o trabalho está completo 
no incremento do produto. A definição orienta o Time de Desenvolvimento no 
conhecimento da quantidade de itens do Backlog do Produto que podem ser 
selecionados durante a Reunião de Planejamento da Sprint.
Pós-Universo 20
Figura 02: Descrição do processo Scrum
Fonte: Santos (2014, on-line).
Sumariando o contexto explicitado anteriormente e, conforme destacado na Figura 
02, o processo Scrum tem cinco atividades principais: o pontapé inicial, a Reunião de 
Planejamento da Sprint, a Sprint, a Reunião Diária e a Revisão da Sprint. A Reunião 
de Planejamento da Sprint é uma reunião do Time de Desenvolvimento, do Scrum 
Master, e do Product Owner no início de cada Sprint (iteração). Esses encontros, que 
podem levar até um dia, consistem em duas partes. Na primeira parte da reunião, 
duas atividades principais ocorrem. Primeiro, o grupo define o Product Backlog, que 
é basicamente uma lista dos requisitos do projeto; depois disso, o grupo determina 
o objetivo da Sprint. Na segunda parte da reunião, o foco do trabalho está na criação 
do Backlog da Sprint.
Pós-Universo 21
O propósito do Guia do Scrum 
Scrum é um framework para desenvolver e manter produtos complexos. 
Este guia contém a definição do Scrum. Esta definição consiste em papéis, 
eventos, artefatos e as regras do Scrum que unem os demais e os mantém 
integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia 
do Scrum é escrito e fornecido por eles. Juntos, eles apoiam o Guia do Scrum.
Fonte: Schwaber e Sutherland (2013, on-line).
saiba mais 
Pode-se dizer que o framework Scrum é muito utilizado nas empresas. Basta realizar 
uma busca do tema em artigos científicos da área para comprovar isso.
Em uma pesquisa realizada em 2011, pela VersionOne, empresa pioneira no 
mercado de ferramentas de gestão ágil, 60% dos entrevistados afirmaram que mais 
de 50% dos projetos realizados em suas respectivas empresas já utilizaram métodos 
ágeis.Por sua vez, o Scrum foi o método ágil mais citado pelas empresas, sendo 
utilizado por 52% das empresas respondentes. A figura a seguir deixa bem claro que 
o framework Scrum (com suas combinações) lidera no ranking geral.
Figura 03: Metodologia Ágil mais usada
Fonte: Bridge (2012, on-line).
Pós-Universo 22
Você pode verificar que o processo Scrum é um dos métodos mais utilizados. Ele 
permite que você forneça iterações regulares (Sprints) com valor para o cliente. O 
processo é construído sobre o trabalho em equipe, recebendo feedback frequente e 
uma comunicação transparente dentro da equipe e da empresa, mas também para 
o cliente. O processo ocorre em ciclos regulares, o que geralmente não deve ser 
superior a trinta dias. A vantagem das Sprints é a regularidade. Cada equipe apresenta 
seu trabalho e, consequentemente, os resultados. Em seguida, o trabalho é sempre 
verificado e, se necessário, será ajustado no final do processo.
Sumariando o contexto, o Scrum é um framework ágil utilizado para o 
estabelecimento de conjuntos de regras de gestão, para obtenção do sucesso de um 
projeto. A partir do trabalho com enfoque na equipe, há uma promoção na melhoria 
da comunicação e o fato de maximizar o apoio de todos, fazendo com que todos 
do time se esforcem e se sintam bem com o que estão fazendo. Isso acaba gerando, 
mais para frente, um aumento de produtividade.
De acordo com Cervone (2011), as vantagens de uma abordagem baseada em 
Scrum estão em sua simplicidade. Dentro de um projeto ágil, os papéis são claramente 
definidos. Os recursos podem ser desenvolvidos e testados em ciclos curtos de iteração. 
Cada um dos membros da equipe possui grande responsabilidade pela sua parte 
do projeto. Os métodos de gerenciamento ágil de projetos impõem comunicação 
extensiva, que ajuda as equipes a se organizarem de forma mais eficaz. Isso pode 
levar maior produtividade a todos os envolvidos.
Pós-Universo 23
O framework Scrum nasceu da TI, mas hoje é também utilizado e aplicado 
em outras áreas de atuação, tais como: gestão de mudanças (IBM), call center 
(Total Attorneys), gestão de conferências (Trifork), consultoria e finanças 
(OpenView Venture) e marketing (GPE).
Para saber mais a respeito do SCRUM, acesse o link disponível em: <https://
www.youtube.com/watch?v=7Aj5HT4BilQ>. Acesso em: 18 jan. 2016.
Fonte: o autor.
saiba mais 
Também, como forma de concretizar seu aprendizado sobre Scrum, assista 
ao vídeo sobre esse framework, pontuando na prática o seu funcionamento. 
O vídeo, intitulado Metodologia Ágil para Gestão e Planejamento 
de Projetos (Scrum), está disponível em: <https://www.youtube.com/
watch?v=_3Ya3g7wg40>. Acesso em: 18 jan. 2016. 
Fonte: o autor.
saiba mais 
Pós-Universo 24
O FRAMEWORK EXTREME 
PROGRAMMING (XP)
Pós-Universo 25
Podemos destacar que a metodologia XP é considerada uma metodologia “leve” de 
desenvolvimento de software. De acordo com Loddi et al. (2012), ela é classificada 
como um “sistema de práticas que a comunidade de desenvolvedores de software vem 
evoluindo para resolver os problemas de entregar software de qualidade rapidamente, 
e então alcançar as necessidades de negócio que sempre mudam”. Essa metodologia 
surgiu a partir de ideias de Kent Beck e Ward Cunningham, sendo utilizada pela 
primeira vez em um projeto piloto, no mês de março do ano de 1996. Segundo Beck 
et al. (1999), a justificativa do “Extreme”, do nome, se deve ao fato de ela empregar ao 
“extremo” as boas práticas da Engenharia de Software.
De acordo com os autores Schwaber & Beedle (2002), o eXtreme Programming 
(XP) é uma metodologia ágil para equipes pequenas e médias que desenvolvem 
software baseado em requisitos vagos e que se modificam rapidamente, sendo assim, 
é importante ressaltar que ela não se aplica a todos os tipos de projetos. Entretanto 
alguns autores defendem seu uso mesmo em grandes projetos, desde que haja uma 
divisão em subprojetos independentes. Para Beck et al. (1999), projetos longos devem 
ser quebrados em uma sequência de mini projetos auto contidos, com duração de 
uma a três semanas.
Adaptado de: www.XProgramming.com
Pós-Universo 26
A prática da XP visa garantir a satisfação do cliente, bem como o favorecimento 
no cumprimento das estimativas. Por sua vez, as regras, práticas e valores da XP 
proporcionam um agradável ambiente para os seus seguidores, que são conduzidos 
por alguns valores. Na verdade, trata-se de uma metodologia que ostenta 5 (cinco) 
valores, 13 (treze) práticas e 5 (cinco) princípios que estão devidamente alinhados 
com os valores ágeis.
Conforme Massari (2014), os cinco valores da XP são:
1. Comunicação: promover a comunicação entre toda a equipe envolvida 
com o projeto: refere-se a relação direta entre cliente e programador, assim 
como a relação direta entre o programador e o testador. Isto é, a atenção 
deve ser dada a toda a equipe, e não apenas a uma parte dela. Além disso, 
deve ser enfatizada a relação junto ao Manifesto Ágil em que prevalece os 
“indivíduos e interações sobre processos e ferramentas”. Ela busca aproximar 
todos os envolvidos do projeto de modo que todos possam ter um diálogo 
presencial (TELES, 2004).
Essa comunicação não é limitada por procedimentos formais, sendo possível 
fazer uso do melhor meio possível, como uma conversa ou reunião informal, 
e-mail, bate-papo ou até mesmo um simples telefonema, por exemplo. A 
preferência aqui é pela comunicação mais ágil.
2. Simplicidade: fazer algo da forma mais simples possível e de modo funcional 
para se alcançar os objetivos esperados. Significa, por exemplo, utilizar as 
tecnologias e as técnicas mais simples que permitirão atender aos requisitos 
do usuário final. A utilização da regra 80/20 é bem vinda (20% dos esforços 
produzem 80% dos resultados). Claro que isso não é uma regra, apenas 
uma sugestão para se pôr em prática. Esse valor nos ensina a implementar 
apenas aquilo que é suficiente para atender a cada necessidade do cliente, 
ou seja, ao codificar uma funcionalidade, o foco deve estar nos problemas 
atuais e deixar os problemas do futuro para o futuro (TELES, 2004). Ao evitar 
a especulação sobre o futuro, se ganha tempo no presente, permitindo que 
o cliente tenha acesso à funcionalidade rapidamente.
Pós-Universo 27
3. Retroalimentação: refere-se ao feedback, que consiste em permitir a 
retroalimentação de informação de forma rápida e frequente. Isso promove 
grande oportunidade no processo de aprendizagem e identificação de 
potenciais melhorias. O feedback é o mecanismo que permite que o cliente 
conduza o desenvolvimento diariamente e garanta que a equipe direcione 
as suas atenções para aquilo que irá gerar mais valor (TELES, 2004). Essa 
maior agilidade permite com que erros sejam detectados e corrigidos no 
mesmo instante, faz com que os requisitos e prazos sejam reavaliados mais 
cedo, facilita o processo de tomada de decisão, permite que as estimativas 
sejam mais precisas e promove maior segurança e menor risco para os 
investidores.
4. Coragem: está relacionada com a capacidade de assumir riscos e desafios 
em favor do projeto. Isso promove a união e confiança da equipe, em função 
da ausência do medo de exposição de opiniões ou então do resultado do 
trabalho realizado. A equipe precisa ser corajosa e acreditar que, utilizando 
as práticas e valores da XP, será capaz de fazer o software evoluir com 
segurança e agilidade (TELES, 2004).
É pertinente destacar que os testes, a programação em pares e outras práticas 
aplicadas pelo XP promovem a confiança do programador, ajudando-o a 
ter coragem para, por exemplo, descartar o código desnecessário, tornar o 
design de código mais simples, solicitar auxílio aos que sabem mais, anunciar 
ao cliente que um determinado requisito não será implementado dentro 
do prazo prometido, entre outros.
5. Respeito: trata-se da busca de um ambiente de respeito entre os diversos 
colaboradores envolvidos com o projeto.Dessa forma, ouvir, compreender e 
respeitar a opinião de todos os integrantes da equipe é fundamental. Todos 
os valores apresentados são alicerces da XP, pois eles oferecem sustentação 
às boas práticas adotadas na metodologia (TELES, 2004).
Por sua vez, ainda de acordo com o mesmo autor, segue as 13 práticas elencadas 
pela XP para criar um processo eficaz na gestão de um projeto ágil:
Pós-Universo 28
1. Equipe unida: refere-se ao cliente, equipe e coach, cujo trabalho deve ser 
desempenhado em proximidade, como membros de uma única equipe. 
O que se quer dizer neste caso é que todos tem que trabalhar de forma 
coesa (como um time coeso), inclusive o cliente, e que a equipe deve ser 
multidisciplinar, incluindo pessoas que tenham cada uma das habilidades 
necessárias para construir o projeto.
2. Jogos de planejamento (the planning game): trata-se do planejamento das 
iterações, definindo-se como planejar, além da combinação de prioridades 
de negócio e estimativas técnicas. Trata-se de uma prática XP em que se 
define tanto as estimativas de prazo para cada uma das tarefas, quanto as 
prioridades (ou seja, as tarefas que são mais importantes).
3. Entregas curtas (small releases): entregas de valor ao cliente em curtos 
períodos de tempo para obtenção de feedback.
4. Testes de cliente: neste princípio, o cliente final deverá descrever os testes 
que são necessários para sua aceitação, de tal forma que a equipe construirá 
ferramentas para automação dos testes. É pertinente ressaltar que não 
necessariamente os testes terão de ser automatizados. A questão é ter claro 
qual o critério de aceitação.
5. Propriedade coletiva de código (collective ownership): o código não possui 
um “dono”, podendo o mesmo ser alterado por qualquer desenvolvedor. Dessa 
forma, todos os colaboradores da equipe podem trabalhar nele, tornando-
os responsáveis pelo código do sistema. Muito bom no compartilhamento 
de conhecimentos, além de suavizar riscos de ausência de conhecimento 
em casos do abando de integrantes de uma equipe do projeto.
Pós-Universo 29
6. Padronização de código: está relacionado com a definição de um padrão 
para codificação a fim de que o código possa ser compreendido de forma 
mais fácil por seus desenvolvedores.
7. Ritmo sustentável: neste caso, deve-se evitar muitas horas extras, além da 
necessidade de descanso aos desenvolvedores para executar suas tarefas 
com mais atenção e vontade. Perceba que o trabalho com qualidade significa 
buscar ter um ritmo de trabalho saudável. Significa, por exemplo, trabalhar 
40 horas/semana (8 horas/dia), evitando as horas extras. Na verdade, as 
horas extras somente deverão ser permitidas quando as mesmas trouxerem 
produtividade para a execução do projeto. Destaca-se, ainda, que outra 
prática condiz com o trabalho energizado, isto é, busca-se um trabalho 
motivado sempre. É claro que, para isto, o ambiente de trabalho e a própria 
motivação da equipe sempre deverá estar em harmonia.
8. Metáfora: trata-se da criação de algo que seja utilizado de forma mais 
simples para expressar a ideia do sistema que será construído (como é o 
caso de um acrônimo). Exemplo: ao invés de se referir ao Sistema Integrado 
de Estudo para a Certificação Project Management Institute Agile Certified 
Practitioner, a equipe poderá simplesmente utilizar o acrônimo SIE-ACP. A 
ideia aqui é bastante simples: significa facilitar a comunicação junto com 
o cliente, compreendendo a sua realidade. Faz-se necessário traduzir as 
palavras do cliente para o significado que ele aguarda dentro de um projeto.
9. Integração contínua: as tarefas terminadas devem ser integradas aquilo 
que já foi construído, executando os testes automatizados para verificar a 
correção do sistema.
Pós-Universo 30
10. Desenvolvimento orientado a teste: refere-se a uma técnica onde 
em primeiro lugar o teste é escrito e testado para somente depois ser 
desenvolvido. Isto é, o desenvolvimento do software é guiado por testes. 
Na verdade, os testes puxam o desenvolvimento. Logo, os programadores 
XP escrevem primeiramente os testes, depois o código, e rodam testes 
para, consequentemente, validar o código escrito. Desta forma, pode-se 
destacar que cada unidade de código somente tem valor se o seu teste 
funcionar 100%. Você deve ter percebido que estes testes são utilizados 
com o objetivo de dar maior segurança no processo.
11. Refatoração (refactoring): em linhas gerais, condiz com a melhoria da 
qualidade do código existente, a fim de torná-lo mais elegante e legível. 
Isto é, trata-se da necessidade contínua de sua reestruturação junto dos 
desenvolvedores, tirando a duplicação de código e tornando-o mais 
simples após uma modificação. É um processo que permite a melhoria 
continua da programação, com o mínimo de introdução de erros e 
mantendo a compatibilidade com o código já existente. Refabricar melhora 
a clareza (leitura) do código, divide-o em módulos mais coesos e de maior 
reaproveitamento, evitando a duplicação de código-fonte.
12. Design simples: o design deve ser realizado de modo simples, dando 
enfoque na tarefa atual e não nas possibilidades futuras. Logo, o projeto 
começa de forma simples e se mantém da mesma forma ao logo dos testes 
e refinamento do design (refatoração). Enfim, destaca-se que aquilo que 
não é necessário neste momento, então não deverá ser implementado.
Pós-Universo 31
13. Programação em par (pair programming): a produção do código deve 
ser realizada em pares, de tal forma que uma delas escreve o código, enquanto 
a outra auxilia e pensa de forma estratégica. É perceptível a utilização desta 
técnica como forma de compartilhar conhecimento, garantir um nível de 
qualidade, identificação de riscos, assim como auxilia na formatação de uma 
equipe de alto desempenho. Existe também a possibilidade da programação 
em par num único computador. Em geral, a dupla é formada por um iniciante 
na linguagem e outra pessoa funcionando como um instrutor. Como é 
apenas um computador, o novato é que fica à frente fazendo a codificação, 
e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta 
forma, o programa sempre é revisto por duas pessoas, evitando e diminuindo 
assim a possibilidade de defeitos. Com isto, busca-se sempre a evolução da 
equipe, melhorando a qualidade do código fonte gerado. 
Complementando e reforçando o conteúdo exposto até aqui sobre os princípios 
do XP, o autor Siqueira (2003) também faz menção de tais princípios do Extreme 
Programming, conforme destacado no Quadro 01:
Quadro 01: Os princípios do Extreme Programming
Princípios Centrais Outros Princípios
• Retroalimentação rápida;
• Simplicidade assumida;
• Mudança incremental;
• Abraçar as mudanças;
• Trabalho com qualidade.
• Ensinar aprendendo;
• Pequeno investimento inicial;
• Jogar para ganhar;
• Experimentos concretos;
• Comunicação aberta e honesta;
• Trabalhar com o instinto das pessoas e 
não contra eles;
• Responsabilidade aceitada;
• Adaptação local;
• Viagem leve;
• Medir honestamente.
Fonte: Siqueira (2003).
Para finalizar esta parte, segue rapidamente os 5 (cinco) princípios básicos de XP: 
feedback rápido; simplicidade é o melhor negócio; mudanças incrementais; carregue 
a bandeira das mudanças/não valorize o medo; e a alta qualidade do código.
Pós-Universo 32
A Locaweb é considerada a maior empresa de hospedagens de sites 
da América Latina. No final de 2006, Daniel Cukier começou a utilizar a 
Programação Extrema (XP) na sua equipe de desenvolvimento de serviços de 
voz. A partir da utilização desta metodologia ágil, percebeu-se que a equipe 
conseguiu entregar funcionalidades rapidamente e com baixo índice de 
defeitos. Com a percepção das vantagens dos métodos ágeis por parte da 
diretoria da empresa, decidiu-se realizar um treinamento envolvendo a área 
de tecnologia. Em meados de 2007, realizaram um curso para 85 pessoas das 
áreas de desenvolvimento e produtos da empresa. A partirdesse episódio, 
a empresa começou a fazer uso do Scrum e de algumas práticas XP. A alta 
cúpula ficou muito satisfeita com o resultado. Atualmente, pode-se dizer 
que a organização é muito mais eficiente no que diz respeito a entrega de 
software de qualidade para a sua clientela.
Além desse, conheça outros casos de sucesso no site disponível em: <http://
ccsl.ime.usp.br/agilcoop/casos_de_sucesso>. Acesso em: 18 jan. 2016.
Fonte: AgilCoop (on-line).
minicaso
A equipe XP compreende os seguintes colaboradores: tem-se um desenvolvedor 
(que é a pessoa que constrói o software, bem como realiza uma análise, projeção e 
codificação do sistema), um redator técnico (aquele que auxilia a equipe na parte 
de documentação do projeto) e um analista de teste (é quem ajuda o cliente a 
definir os requerimentos e busca fazer com que eventuais defeitos do sistema sejam 
identificados o quanto antes). Além disso, ainda apresenta um gerente (pessoa 
responsável pela parte administrativa e relacionamento com o cliente, garantindo os 
recursos necessários para o projeto) e o coach (pessoa que tem a responsabilidade 
técnica do projeto, onde orienta a equipe e controla a aplicação da XP).
Em linhas gerais, você pode estar se perguntando: tendo como referência o 
conteúdo supracitado neste item, como se dá o funcionamento da metodologia 
XP? Na verdade, o XP estabelece um conjunto de regras e contexto que ocorrem em 
quatro atividades, conforme descritas na Figura 04, e relatadas na sequência, com 
base em um trabalho de Silva e Mello Junior (2014).
Pós-Universo 33
De forma breve, os parágrafos posteriores farão uma rápida apresentação sobre 
o funcionamento da metodologia XP como forma de complementar a aplicação dos 
conceitos expostos anteriormente. Na sequência, está disponibilizado um vídeo que o 
auxiliará na assimilação deste conteúdo, pois apresentará na prática o funcionamento 
de uma equipe de desenvolvimento que faz uso das práticas XP em uma organização. 
Seguem as etapas:
codi�ca
ção
teste
projeto
planeja
mento
valores das histórias
de usuários
critérios de teste de aceitação
plano de iteração
projeto simples
cartões CRC
soluções pontuais
protótipos
programação em dupla
teste de unidades
integração contínua
versão
teste de aceitação
refabricação
incremento de software
velocidade de projeto registrada
(computada)
Figura 04: Etapas do Processo Extreme Programming 
Fonte: adaptado de Pressman (2006, p. 64).
Na fase de planejamento, o cliente descreve um conjunto de histórias (vide saiba mais, 
a seguir) e exemplifica as características e funcionalidades do sistema. É importante 
destacar que esse cliente tem total liberdade de modificar e adicionar elementos na 
história, conforme sua necessidade.
Pós-Universo 34
Equipes XP planejam utilizando estórias escritas em pequenos cartões. 
As estórias normalmente são escritas pelo próprio cliente. Os cartões não 
têm a pretensão de armazenar todas as informações sobre uma história. 
Desenvolvedores em uma equipe XP utilizam o diálogo presencial com o 
cliente para aprender o máximo possível sobre os detalhes de cada estória. 
Dessa forma, o registro da estória feito no cartão acaba servindo basicamente 
como um lembrete do diálogo.
Fonte: Teles (2006, on-line).
saiba mais 
Na fase de projeto, o XP estabelece com muito rigor a simplicidade, pois o mais 
apropriado é trabalhar com artefatos simples. Para tal, defende o uso de cartões, pois 
encoraja as discussões entre os desenvolvedores, com possibilidades de todos os 
envolvidos apresentarem suas opiniões. Importante ressaltar que, no início de cada 
iteração, a equipe de desenvolvimento estimula o cliente a descrever as funcionalidades 
que deseja em pequenos cartões denominados user stories. Mas o que significa isso? 
Trata-se da menor quantidade de informação que o cliente pode definir para uma 
determinada funcionalidade do projeto que ele deseja. De acordo com a sua 
complexidade, a referida equipe determina o tempo e o custo que aquela funcionalidade 
irá custar para esse cliente. Levando em consideração o fator tempo e custo, o cliente 
determinará as prioridades sobre as funcionalidades, sabendo exatamente o tempo 
e quanto irá lhe custar.
Na fase seguinte (codificação), após o levantamento da história, será realizada uma 
série de testes unitários. Nesse caso, o desenvolvedor focará no que será implementado 
na codificação e passará um breve feedback para o cliente. Salienta-se que, nesta fase, 
os programadores desenvolvem suas atividades em pares. Dessa forma, à medida que 
eles finalizam o trabalho, o código é integrado aos outros, que é uma responsabilidade 
da equipe.
Pós-Universo 35
Para finalizar, a etapa de testes fornece segurança e progresso, garantindo equilíbrio 
e minimizando o problema. Como consequência, promove a redução do retrabalho 
dos programadores.
Como vantagens, o XP promove eficiência e eficácia no desenvolvimento de 
sistema. Ainda, essa metodologia é capaz de suportar mudanças contínuas de mercado 
e também oferecer ao cliente maneiras para verificar de forma rápida o retorno que 
o projeto de software dará para a organização. Em contrapartida, a metodologia XP 
exige muito dos seus funcionários de tal forma que eles devem ter um bom grau de 
maturidade, principalmente da alta direção.
Importante ressaltar que muitas das regras declaradas pela XP causam polêmica 
em um primeiro momento e muitas delas não fazem sentido quando aplicadas de 
forma isolada. Na verdade, é a sinergia de todo o conjunto que dá sustentabilidade no 
sucesso da XP, o que promove uma revolução no desenvolvimento de um software.
Entretanto, apesar de ser um dos métodos mais utilizados na atualidade, a utilização 
da XP tem suas restrições (Quadro 02).
Quadro 02: Quando não utilizar a XP
Situação Descrição
Contratos de 
escopo fechado
Dada à natureza flexível da XP, o fato de o cliente esperar um 
produto final no prazo gera um desconforto entre as partes. Em 
suma, o cliente não será parte do time.
Política de 
premiações
Prêmios individuais não são recomendados, pois a metodologia 
dá ênfase à coletividade.
Clientes exigem 
documentação
XP é baseada em agilidade e flexibilidade, e não recomendada em 
projetos onde o cliente quer o processo minuciosamente descrito. 
A XP utiliza a documentação de forma moderada.
Equipe alheia a 
mudanças
A XP é inviável caso a equipe seja resistente a mudanças, visto 
que adotar a metodologia exige dedicação.
Desenvolvedores 
de baixa qualidade
Se os membros da equipe responsável pelo desenvolvimento não 
forem capacitados, a adoção da XP é dificultada.
Fonte: Loddi (2012, p. 173).
Pós-Universo 36
A XP é uma metodologia dinâmica que dá liberdade para cada programador 
modelar sua própria forma de trabalho. Como relatado há pouco, existe uma grande 
possibilidade de não se conseguir aplicar todas essas práticas em um projeto, havendo 
a possibilidade de se fazer uma combinação de XP com outras práticas.
Ficou muito claro que essa metodologia aproxima bastante o cliente da equipe de 
desenvolvimento, garantindo uma relativa integração na construção de um software. 
Por todos esses benefícios que humanizam a produção de um software, pode-se 
concluir que a XP tem muitas vantagens sobre outras metodologias.
Para extrair o melhor de uma abordagem ágil, deve existir um tênue equilíbrio 
entre flexibilidade e estabilidade, nunca se esquecendo da medida principal 
de sucesso de um projeto que está acondicionado na entrega de valor e 
qualidade.
Fonte: o autor (2015).
reflita
Pós-Universo 37
O SISTEMA 
KANBAN E OUTRAS 
METODOLOGIAS ÁGEIS
Pós-Universo 38
Este estudo é contemplado por duas partes, cada qual com suas características 
específicas. Na primeira delas, será abordado o sistema Kanban, com apresentações 
de suas principais particularidades e demais informações importantes para você.
No segundo momento, serão apenas mencionadas, de forma bem rápida, outras 
metodologiaságeis ofertadas pelo mercado. Importante ressaltar que esse conteúdo 
apenas citará e/ou dará alguns direcionamentos sobre outras metodologias, por isso 
é importante que você realize pesquisas mais profundas e detalhadas.
O Sistema Kanban
Afinal, o que é Kanban? Trata-se de uma palavra 
de origem japonesa que significa “tabuleta” 
ou “cartão sinalizador”, sendo adotada como 
uma metodologia inspirada no sistema de 
fabricação da Toyota, para controlar a produção 
de automóveis. O Kanban foi desenvolvido por 
Taichi Ono, na Toyota, em meados da década 
de 50, para organizar a comunicação entre os 
departamentos da fábrica e controlar a produção 
e a movimentação do material dentro do processo 
produtivo. Com isso, buscava reduzir os custos 
de produção, evitar desperdícios e eliminar a 
ocorrência de erros na execução do trabalho, 
visando à qualidade final dos produtos.
O Kanban vem sendo utilizado para projetos sem demanda prevista com muita 
antecedência, com o objetivo de eliminar filas e gargalos no processo (vide explicação 
a seguir). É uma metodologia Lean, que tem como filosofia uma estratégia de negócios 
para aumentar a satisfação dos clientes por meio da melhor utilização dos recursos, por 
isso, prega a produção enxuta, resultando em processos mais assertivos e eficientes. 
Lean significa eliminar desperdícios que não agregam valores em uma linha de 
produção ou então em qualquer outro processo.
K A N B A N
A SIMPLICIDADE DO
CONTROLE DA PRODUÇÃO
Pós-Universo 39
Em 2008, uma pesquisa da VersionOne demonstrou que 6% dos participantes 
utilizavam Kanban em suas práticas. Por sua vez, outra pesquisa de 2015 
mostrou que 31% utilizavam o mesmo sistema, ou seja, houve um acréscimo 
muito significativo na utilização dessa metodologia ágil.
Silva et al. (2010) também deixaram claro que a utilização do método Kanban 
no gerenciamento de equipes de desenvolvimento de software registrou 
um aumento significativo a partir de 2007, quando Rick Garber e David J. 
Anderson publicaram nas conferências “Lean New Product Development” e 
“Agile 2007” os resultados obtidos no uso desse método no desenvolvimento 
de software.
A VersionOne é uma pesquisa conhecida e respeitada, com quase 4.000 
empresas participantes em 2015, as quais podem ser encontradas no link 
disponível em: <http://info.versionone.com/9th-state-of-agile-thank-you-
web.html?aliId=6413986>. Acesso em: 18 jan. 2016.
Fonte: o autor.
fatos e dados
Um gargalo, ponto de estrangulamento ou restrição é uma designação 
do componente que limita o desempenho ou a capacidade de todo um 
sistema. Ele nada mais é do que um recurso dentro do sistema de produção 
cuja capacidade é menor ou igual à demanda alocada para esse recurso. 
Em outras palavras, um gargalo é uma máquina ou processo de fabricação 
incapaz de atender a demanda que lhe é requisitada; uma máquina parada 
devido a algum defeito é temporariamente um gargalo, pois é incapaz de 
produzir qualquer coisa (sua capacidade é nula).
Fonte: Natucci (2013, on-line).
atenção
Pós-Universo 40
Via de regra, com a adoção desse método, a empresa passa a contar com processos 
mais rápidos e funcionais, o que promove algumas vantagens. Para quem realiza 
o trabalho, ele auxilia na organização com um fluxo bem efetuado, assim como 
na comunicação visual, que é caracterizada como um dos princípios básicos da 
metodologia Kanban. Por sua vez, isso acaba proporcionando a todos que estão 
envolvidos no processo perceber a situação real mediante um quadro com vários 
itens visuais que permitem identificar (de forma rápida) os gargalos, assim como os 
pontos de intervenção que devem ser realizados.
Conforme o Quadro 03, considere um quadro branco em que as tarefas são 
descritas em post-its, migrando por vários estágios que estão em destaque neste 
quadro.
Quadro 03: Exemplo de um quadro Kanban
Fonte: KANBAN... (on-line).
O Quadro 03 apresenta os pontos de gargalos (sobrecarga de atividades) no processo, 
o que promove uma diminuição do tempo que é despendido para identificar o 
problema. Pode-se dizer que a principal função do Kanban é a de gerenciar o fluxo 
de trabalho, e não organizar estimativas sobre o trabalho que está sendo realizado.
Pós-Universo 41
O método Kanban para desenvolvimento de software e processos ágeis 
tem como ênfase não sobrecarregar os membros que compõem a equipe 
de criação do produto. Por isso, o método contém princípios básicos como: 
a equipe ou membro deve iniciar uma nova tarefa quando é capaz de 
realizá-la agora, a equipe deve aceitar mudanças incrementais e evolutivas 
estimuladas pelo método Kanban, e respeitar os atuais processos, papéis 
e responsabilidades.
Fonte: Mariotti (on-line).
atenção
No passado, as indústrias utilizavam o sistema de “produção empurrada”, em que uma 
atividade era realizada a partir dos estoques. Isto é, uma vez que os níveis de estoques 
estivessem diminuindo, acionava-se a linha de produção para reposição imediata 
(tudo dentro de uma programação). Logo, o que se percebe é que não existia relação 
entre as atividades produzidas e a demanda do cliente.
Para deixar isso mais claro a você, imagine a produção ocorrendo antes da 
solicitação de um produto pelo cliente. É o caso, por exemplo, de uma montadora 
que fabrica um veículo e o encaminha para uma concessionária na qual o carro ficará 
exposto à espera de um comprador. Perceba que a produção não ocorreu a partir da 
solicitação pelo cliente na concessionária. Na verdade, o que houve foi que o veículo 
foi fabricado e “empurrado” para o mercado, que está à espera de um comprador.
Com o advento do Sistema Toyota de produção, o processo tornou-se diferente, 
sendo caracterizado a partir da “produção puxada”. Tubino (2000) deixa claro que, na 
produção puxada, o planejamento é realizado de acordo com o fluxo de materiais, 
não havendo a necessidade do “estoque em processo” do produto. Dessa forma, a 
demanda oferecida pelo cliente é o ponto crucial do negócio, pois todo o controle 
é realizado a partir desse cliente. A operação observa a quantidade de produtos 
vendidos a ele e, posteriormente, determina a quantidade que deve ser produzida 
a partir desse momento. Isto é, ao contrário da “produção empurrada”, a produção 
ocorre a partir de uma solicitação (compra) de um produto/serviço por parte de 
um cliente. Então, espera-se a solicitação para, a partir daí, dar início ao processo de 
transformação rumo ao produto acabado.
Pós-Universo 42
Com isso, perceba que é a demanda quem dita o ritmo de produção da fábrica, 
fazendo com que a indústria adapte sua velocidade de produção, em função do nível 
de consumo de seus clientes. Tomando como referência novamente uma fábrica 
de carros, o cliente vai até a concessionária e solicita o carro que deseja comprar. 
A concessionária envia a ordem de produção para a fábrica e, somente a partir de 
então, o carro começa a ser fabricado, ou seja, o cliente “puxa” a produção da fábrica. 
Cada etapa do processo vai produzir apenas o necessário para atender a solicitação 
do cliente, sendo que cada etapa “puxa” as peças fabricadas no processo anterior. 
Essa mesma ideia também pode ser aplicada em uma prestação de serviço, como é 
o caso, por exemplo, de um restaurante à la carte.
Figura 05: Empurrar a Produção X Puxar a Produção
Fonte: Souza (2015, on-line).
Fica evidente que esse sistema tem como princípio a eliminação de todo e qualquer 
tipo de desperdício. Logo, nada deve ser feito sem que esteja no tempo apropriado 
e que não seja necessário. A Figura 05 esclarece as diferenças entre empurrar e puxar 
uma produção.
Pós-Universo 43
Em um artigo elaborado por Ahmad et al. (2013), fica evidente a utilização da 
abordagem Kanban como sendo uma das ferramentas Lean para gestão de operações 
de produção. O artigo deixa claro que, nos últimos anos, o Kanban tornou-se bastante 
popular no desenvolvimento de software, sendo essa abordagem a mais recente na 
área depesquisa ágil e enxuta de desenvolvimento de software. Ainda destaca que um 
forte movimento de práticas dirigidas e orientadas de suporte e apoio à ideia de usar 
Kanban em engenharia de software tem emergido. Em se tratando de publicação, os 
estudos desses mesmos autores indicaram que o Kanban está ganhando impulso no 
domínio da engenharia de software. Uma parcela significativa dos estudos Kanban 
no desenvolvimento de software foi publicada no ano de 2011. Logo, essa tendência 
pode ser considerada como um indicador no crescente interesse no uso de método 
Kanban para o desenvolvimento de software.
Em outro artigo, Ikonen et al. (2011) realizaram estudos cuja investigação indicou 
benefícios consideráveis do modelo de processo Kanban, incluindo motivação 
e controle sobre as atividades do projeto. Para a indústria, segundo o estudo, o 
grande valor do Kanban reside na sua visualização em tempo real. Entretanto é 
importante lembrar que a visualização por si só não substitui ações concretas. Sendo 
uma ferramenta de controle relativamente básica, o Kanban deve ser apoiado com 
outras práticas adicionais (combinações).
De acordo com Arruda (2012) e resgatando esses conceitos para o processo de 
desenvolvimento de software, o trabalho de construção de uma nova funcionalidade 
para um sistema somente é gerado a partir do instante em que uma funcionalidade 
anterior já fora implementada (é a ideia de “uma coisa por vez”). Nesse contexto, o 
Kanban procura aperfeiçoar os processos, bem como as equipes e o os projetos 
envolvidos. Como consequência, perceba que se trata de uma metodologia útil 
para as organizações que procuram melhorias constantes, que corrobora também 
na produtividade e em uma boa relação junto de seus clientes.
Pós-Universo 44
De acordo com Massari (2014), o Lean é um conjunto de princípios da 
manufatura que foca na eliminação de desperdícios. Ao longo do tempo, 
alguns desses princípios começaram a ser introduzidos no processo de 
desenvolvimento de software. Importante destacar que o Lean não é 
caracterizado como uma metodologia ágil, mas seus sete princípios estão 
alinhados com os valores ágeis de uma empresa. Segue um breve relato 
sobre eles:
1. Eliminação do desperdício: destaco que um desperdício é tudo aquilo 
que não agrega valor no produto final. No Lean, estes desperdícios estão 
associados com os seguintes itens: realização parcial de um trabalho, 
existência de processos extras, desenvolvimento de funcionalidades não 
requeridas pelo cliente (gold plating), a presença das multitarefas (quando 
se tenta fazer de tudo um pouco, na verdade nada está sendo feito com 
foco direcionado), o tempo de espera, os esforços de comunicação 
(necessidade de boa gestão para lidar com este desperdício), e os defeitos 
(necessidade de evitar bugs para o cliente).
2. Fortalecimento da equipe: busca de uma equipe auto organizada e 
autodirigida.
3. Entregas rápidas: aplicar o conceito do triângulo ágil – entregar valor 
para o cliente, com um produto de qualidade, e promover rápido retorno 
sobre o investimento.
4. Otimização do todo: é a questão da sinergia, isto é, quando o todo 
(software pronto) é maior que a simples soma das partes.
5. Construção com qualidade: busca de uma qualidade aceitável do 
produto final a partir da utilização de algumas técnicas, tais como: teste 
unitário através de desenvolvimento orientado a testes (TDD), refatoração 
e integração contínua (essas três técnicas também são utilizadas na 
metodologia eXtreme Programming).
6. Adiar decisões: deixar as decisões e os comprometimentos para o 
último instante.
7. Amplificar o conhecimento: dar prioridade na comunicação, bem 
como no feedback constante entre equipes e usuários no tocante ao 
desenvolvimento do software.
Fonte: Massari (2014, p. 24).
saiba mais 
Pós-Universo 45
Da mesma forma que outras metodologias ágeis, o Kanban também se baseia em 
cinco princípios básicos, segundo Massari (2014), sendo eles:
1. Fluxo de trabalho deve ser visível: a visibilidade aqui é a palavra chave, 
de tal forma que esse fluxo possa ser organizado, otimizado e rastreado.
2. Restringir o WIP (Work In Progress): condiz com o volume de tarefas 
existentes nas colunas do Kanban, havendo a necessidade de restringir essa 
quantidade de trabalho em andamento, em função dos riscos de geração 
de gargalo (restrição ao sistema) no processo.
3. Gerenciamento do fluxo: importância no que tange ao gerenciamento 
do fluxo, com o intuito de identificar problemas e propor melhorias.
4. Garantia de clareza nas políticas do processo: esta clareza permite que 
todos os envolvidos saibam com exatidão sobre as regras do jogo, evitando, 
assim, algum mal entendido.
5. Colaboração na melhoria do processo: refere-se ao trabalho em equipe, 
sempre na busca constante de itens para melhoria.
Reforçando o conteúdo, o Kanban se baseia em cinco pilares bem caracterizados, 
conforme Anderson (2010), quais sejam: a) foco na qualidade; b) redução do trabalho 
em progresso, permitindo entregas frequentes; c) redução da variação do fluxo de 
processo; d) priorização de demandas; e) processo Puxado (Pull Process). Para o autor, 
esses pilares constituem a base para definir a adoção dos processos e dos artefatos 
que serão empregados para alcançar o objetivo principal, isto é, a otimização do fluxo 
de trabalho a partir da exposição do processo de desenvolvimento e identificação 
dos gargalos.
Pós-Universo 46
RUP XP SCRUM Kanban Faça qualquer
coisa
Mais prescritivo Mais adaptativo
Figura 06: Métodos Prescritivos X Métodos Adaptativos
Fonte: o autor
Das metodologias para desenvolvimento de software, podemos destacar que o 
Kanban é a menos prescritiva (Figura 06). Consoante Kniberg (2009), o Kanban tem 
apenas três prescrições, sendo elas: a) visualize o fluxo de trabalho atual (análise 
sobre como o fluxo ocorre hoje); b) limite o fluxo de trabalho (até onde o referido 
fluxo pode ir); c) acompanhe e gerencie o fluxo de trabalho (relação com medida de 
controle). Sendo pouco prescritivo, o Kanban acaba tornando-se mais adaptativo. 
Com isso, as equipes que o adotam necessitam estar atentas ao processo aplicado 
para visualizar os locais de melhoria e as possíveis adaptações para que o processo 
possa fluir de modo satisfatório.
O IBM Rational Unified Process (RUP) é um framework de processo de 
engenharia de software que fornece um conjunto de práticas testadas 
na indústria para o desenvolvimento de software e gerência de projetos. 
Trata-se de um processo proprietário, desenvolvido pela Rational Software, 
atualmente subsidiária da IBM, que usa abordagem orientada a objetos e 
preconiza a utilização da notação UML (Unified Modeling Language) para 
documentação.
Fonte: ESLP – Engenharia de Software e Linguagens de Programação (2011, 
on-line).
atenção
Pós-Universo 47
Pelo fato de ser mais adaptativo do que prescritivo, o Kanban torna-se bastante 
empírico. Perceba que o Kanban se baseia em um processo no qual o fluxo de 
trabalho é contínuo. Diferentemente da metodologia Scrum, não há um ciclo de 
trabalho definido, em que, a partir do conhecimento de uma atividade, ela é estimada 
e colocada nesse ciclo. No caso do Kanban, há um controle das entradas de itens de 
trabalho e a vazão que é dada de acordo com o WIP (estoque em processo) definido. 
Essa vazão é compreendida pelo termo leadtime, que é representado pelo tempo 
de um item de trabalho desde a sua entrada no processo até a sua saída.
É necessário entender a diferença entre Work In Progress (WIP), leadtime e 
vazão. WIP é a quantidade de trabalho sendo executado ao mesmo tempo. 
Nos métodos ágeis, o WIP é utilizado para evitar que muitas tarefas sejam 
abertas ao mesmo tempo e que o prazo encerre com várias tarefas a 90%, 
porém nenhuma a 100%. Ao se limitar a quantidade, se a pessoa tem duas 
tarefas abertas e está com um impedimento, ela será “forçada” a remover o 
impedimento e assim finalizar a tarefa antes de começar outra. Leadtimese 
refere ao tempo compreendido entre o início de uma atividade produtiva e 
o fim. Por exemplo, um carro leva três horas para ser produzido, sendo uma 
hora para lataria, uma para equipamentos e uma para pintura. Esse é meu 
leadtime, todavia eu não preciso esperar que a pintura termine para que 
eu comece o próximo, então, depois que eu fizer a lataria, passo ela para 
os equipamentos e começo uma nova lataria. Desse modo, cada carro leva 
três horas para ser produzido, entretanto eu tenho uma vazão de um carro 
por hora, pois as atividades são feitas simultaneamente.
Fonte: o autor (2015).
saiba mais 
Pós-Universo 48
Como em toda metodologia ágil, aqui também podemos identificar algumas vantagens 
na utilização do Kanban: aumento da satisfação do consumidor (a equipe pode fazer 
entregas a qualquer instante para esse cliente); aumento da produtividade; redução 
dos custos; e o aumento da capacidade de resposta a mudanças. Logo, perceba 
que o desenvolvimento fica mais transparente, pois é possível visualizar o fluxo de 
trabalho, sem preocupações relacionadas com as iterações e as estimativas (como 
geralmente acontece com outros métodos). É possível controlar o fluxo de trabalho 
dentro de uma iteração, sem qualquer problema.
Na verdade, é isso que ocorre quando se utiliza o Kanban junto com o Scrum. 
Cada atividade executada em uma linha de produção ou projeto tem um tempo 
estimado de execução. Se a data de início de cada etapa for marcada no Kanban, 
pode-se facilmente controlar o fato de a atividade ter sido executada dentro do 
tempo esperado. Então, um dos objetivos do Kanban também é reduzir o leadtime. 
Se o Kanban está colocado no quadro dentro de uma etapa, então sabemos qual 
é o papel que está executando a tarefa no momento e se o nome da pessoa for 
escrito nele, compreendemos exatamente qual papel a pessoa está desempenhando 
naquele momento.
Enfim, a partir da apresentação das metodologias Scrum, XP e Kanban, destacamos 
que a grande competição no mercado faz com que as organizações busquem 
constantemente um aperfeiçoamento para vencer a concorrência. Obviamente existem 
outras metodologias disponíveis no mercado, cada qual com suas particularidades, 
tais como: a Crystal Family, FDD (Feature-Driven Development) e DSDM (Dynamic 
Systems Development Method).
Fatores como prazo, qualidade, aceitação e adaptação a mudanças são importantes 
diferenciais que podem ser atingidos fazendo uso das metodologias ágeis. Embora 
não possamos confirmar que elas são a solução de todos os problemas, fica muito 
evidente que as metodologias ágeis mostrem uma forma de trabalhar bem organizada 
e iterativa, contribuindo inclusive para um ambiente de trabalho mais amigável. Com 
certeza, uma boa opção rumo à obtenção de diferenciais desejados.
Pós-Universo 49
Segue o vocabulário utilizado no framework Scrum. Faça uma leitura destas 
informações para auxiliar na compreensão deste framework:
• Backlog: Lista de todas as funcionalidades a serem desenvolvidas durante 
o projeto;
• Sprint: Período inferior a 30 dias, onde o projeto (ou funcionalidades) é 
desenvolvido;
• Sprint Planning Meeting: Reunião de planejamento;
• Sprint Goal: Disparo dos objetivos/metas;
• Sprint Review Meeting: Revisão da reunião;
• Sprint Backlog: Trabalho a ser desenvolvido numa Sprint de modo a 
criar um produto a apresentar ao cliente;
• SCRUM: Reunião diária onde são avaliados os progressos do projeto e 
as barreiras encontradas durante o desenvolvimento;
• SCRUM Meeting: Protocolo a seguir de modo a realizar uma reunião 
Scrum;
• SCRUM Team: A equipe de desenvolvimento de um Sprint;
• SCRUM Master: Elemento da equipe responsável pela gestão do projeto 
e por liderar as reuniões de Scrum;
• Product Backlog: Produção do trabalho executado;
• Product Owner: Proprietário do produto.
Fonte: Bissi (2007, p. 4).
saiba mais 
atividades de estudo
1. Dentro dos papéis do Time Scrum, temos a figura do Scrum, sendo ela responsável 
por muitas coisas. Talvez a mais importante em função de seu envolvimento na 
aprovação dos valores e práticas do Scrum, além de ter papel fundamental na remoção 
de impedimentos. Qual das seguintes opções define corretamente o papel do Scrum 
Master?
a) Responsável por manter o Product Backlog.
b) Responsável por gerenciar as alocações de trabalho e garantir que aconteça uma 
otimização no uso dos recursos disponíveis.
c) Responsável pelo processo Scrum, garantindo que todos os envolvidos no projeto 
compreendam e sigam as regras e práticas do Scrum.
d) Trata-se da equipe de desenvolvimento de um Sprint.
e) Todas as alternativas supracitadas estão corretas.
2. Assim como todos os frameworks e métodos ágeis, o Scrum pode ser caracterizado 
como um processo empírico. Nesse sentido, a seguir, destaque quais são os três 
pilares de todo e qualquer processo empírico:
a) Transparência, inspeção e adaptação.
b) Qualidade, risco e valor ao cliente.
c) Planejar, verificar e adaptar.
d) Inspeção, análise de causa-raiz e melhoria contínua.
e) Todas as alternativas supracitadas estão incorretas.
atividades de estudo
3. O Product Owner tem muitas responsabilidades dentro do Time Scrum. Ele tem 
a incumbência de maximizar o valor do produto, bem como todo o trabalho dos 
desenvolvedores (Time de Desenvolvimento). Em linhas gerais, ele é designado 
como o proprietário do produto. Enfim, dadas as suas atribuições, qual das seguintes 
opções não é uma responsabilidade do Product Owner?
a) Criar visão inicial do produto.
b) Assegurar a rentabilidade do produto (ROI).
c) Garantir que a reunião diária aconteça.
d) Aceitar ou rejeitar os resultados do trabalho.
e) Todas as alternativas supracitadas estão incorretas.
4. As regras, práticas e valores da XP proporcionam um agradável ambiente de 
desenvolvimento de software para os seus seguidores (SOARES, 2004). Todas elas 
são conduzidas por cinco valores, sendo elas: comunicação, simplicidade, feedback, 
coragem e respeito (novo valor). O valor comunicação condiz com a busca do melhor 
relacionamento entre o cliente e o desenvolvedor, com o intuito de promover confiança 
em toda a equipe. Nesse sentido, responda qual das seguintes opções a seguir é uma 
estratégia para criar confiança na equipe XP?
a) Empatia cliente-programador.
b) Empatia programador-testador.
c) Continuidade da equipe.
d) Todas as alternativas anteriores estão corretas.
e) Todas as alternativas anteriores estão incorretas.
atividades de estudo
5. Pode-se dizer que o eXtreme Programming é direcionado para equipes de pequeno a 
médio tamanho, desenvolvendo software em face a requisitos em constante mudança. 
Por sua vez, para que o sucesso seja atingido nesse tipo de projeto, o XP apregoa 5 
valores, 13 princípios e 5 práticas. Nesse sentido, responda ao questionamento: qual 
das seguintes opções representa uma lista correta de práticas do XP?
a) Refatoração, integração contínua e programação em par.
b) Programação em duplas, refatoração e integração contínua.
c) Design orientado a teste, refatoração e programação em par.
d) Desenvolvimento orientado a testes, previsão e qualidade contínua.
e) Todas as alternativas anteriores estão corretas.
6. Conforme evidenciado no texto, o Kanban é um termo de origem japonesa que 
significa sinal visual. Sabe-se que uma das grandes características desse método 
é evidenciar os problemas existentes no processo. Tendo como referência essas 
informações, identifique qual das seguintes opções é a correta sobre Kanban.
a) Ele se concentra em um fluxo contínuo de trabalho, e não com tarefas de tempo 
limitado (timed box).
b) O Kanban pode ser utilizado como fila de controle para os projetos de 
desenvolvimento de software.
c) Não é necessário fazer estimativa no Kanban.
d) Todas as alternativas anteriores estão corretas
e) Todas as alternativas anteriores estão incorretas.
atividades de estudo
7. O Kanban permite a combinação de ferramentas de diversos métodos até se obter