MODELOS DE PROCESSOS DE SOFTWARE 4

Prévia do material em texto

Modelos de Processos 
de Software
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Introdução aos Processos de Software Ágeis
• O Que é Ser Ágil;
• Gráfico de Sprint Burndown Scrum;
• XP – Extreme Programming com TDD (Teste)
– Desenvolvimento Dirigido por Testes;
• Histórias dos Usuários;
• Planning Game;
• Pequenos Lançamentos;
• Metáfora;
• Design Simples;
• Testes;
• Refatoração;
• Lean.
• Conhecer os diferentes Métodos Ágeis existentes e que estão em uso.
OBJETIVO DE APRENDIZADO
Introdução aos Processos
de Software Ágeis
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e de 
aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Introdução aos Processos de Software Ágeis
O Que é Ser Ágil
O desenvolvimento ágil de software refere-se a um grupo de metodologias de 
desenvolvimento de software baseadas no desenvolvimento iterativo, em que requi-
sitos e soluções evoluem por meio da colaboração entre Equipes multifuncionais 
auto-organizadas.
Processos/Metodologias Ágeis, geralmente, promovem um processo disciplina-
do de gerenciamento de projetos que incentiva a inspeção e a adaptação frequentes.
Além disso, é uma filosofia de liderança que incentiva o trabalho em Equipe, a 
auto-organização e a responsabilidade, tudo isso em um conjunto de práticas re-
comendadas de Engenharia de Software destinadas a permitir a entrega rápida de 
software de alta qualidade e uma abordagem de negócios que alinha o desenvolvi-
mento às necessidades do cliente e aos objetivos da Empresa.
Portanto, quando escrevemos ou nos referimos a Desenvolvimento Ágil, esta-
mos focados em qualquer processo de desenvolvimento que esteja alinhado aos 
conceitos do Manifesto Ágil.
O Manifesto foi desenvolvido por um grupo de 17 figuras de destaque na indús-
tria de software e reflete sua experiência sobre quais abordagens funcionam e não 
funcionam no desenvolvimento de software.
O Manifesto Ágil se resume a 4 grandes pilares:
• Indivíduos e interações mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
Como benefício notável ao cliente, estão os recursos de alto valor, que são de-
senvolvidos e entregues mais rapidamente em ciclos curtos do que nos ciclos mais 
longos favorecidos pelos processos clássicos como o Waterfall – Cascata.
Na lista a seguir, você encontrará os signatários do Manifesto Ágil e suas cola-
borações, a saber:
• Mike Beedle: Um dos primeiros no uso do SCRUM;
• Arie van Bennekum: Criador do DSDM;
• Alistair Cockburn: Criador do Crystal e Adaptative;
• Ward Cunningham: Entusiasta do XP e criador do design pattern CRC;
• Martin Fowler: Um dos criadores do XP e design patterns;
• Jim Highsmith: Criador do ASD (Desenvolvimento de Software Adaptável);
• Andrew Hunt: Co-criador da Programação Pragmática;
8
9
• Ron Jeffries: Um dos criadores do XP e primeiro Coach de XP;
• Jon Kern: Um dos criadores do Método Iterativo e co-criador do FDD – Mé-
todo orientado a recursos;
• Brian Marick: Trabalha com métodos de Testes Ágeis de Software;
• Robert C. Martin: Autor do livro Princípios, padrões e práticas de desen-
volvimento ágil de software;
• Ken Schwaber: Co-criador das versões iniciais do processo SCRUM;
• Jeff Sutherland: Criador principal do SCRUM;
• Dave Thomas: Co-criador do método de programação pragmática.
O que é notável nas Metodologias Ágeis diz respeito a que as Equipes ou times 
ágeis são (e precisam ser) multifuncionais. 
Essas Equipes não precisam ter funções específicas envolvidas. Quando você reú-
ne a Equipe, você garante que possui todas as habilidades certas nela. Apenas para 
dar certeza, a conclusão óbvia é que teremos membros plenos e sênior, sem dúvida.
Por fim, devemos obrigatoriamente ver o Ágil como uma mentalidade informada 
pelos valores contidos no Manifesto Ágil e em seus princípios.
Esses valores e princípios fornecem orientações sobre como criar e responder 
às mudanças e como lidar com a incerteza. Além disso, entenda que quando você 
ouvir alguém falando sobre Metodologias Ágeis, são as convenções que uma Equi-
pe escolhe seguir, de maneira que elas possam aplicar os valores e princípios ágeis.
É neles que você entenderá que os conceitos a seguir descritos não pertencem a 
SCRUM ou XP, por exemplo, mas ao Ágil como todo:
• Histórias de Usuários;
• Reunião Diária;
• Desenvolvimento Incremental;
• Desenvolvimento Iterativo;
• Equipe Ágil;
• Retrospectiva da Entrega (Marco);
• Personas (comportamento/papel do usuário).
SCRUM + Kanban
A origem do SCRUM é bastante debatida e bastante controversa apesar de ser 
uma das metodologias de Gerenciamento de Projetos Ágil mais populares, senão a 
mais popular do mundo, para desenvolvimento de software.
9
UNIDADE Introdução aos Processos de Software Ágeis
Krish argumenta quanto à origem que:
Mesmo que se diga que Ken Schwaber e Mike Beedle inventaram o 
Scrum, Beedle declara que ele aprendeu o método com Jeff Sutherland. 
Ao conectar os pontos acima, conclui-se que Hirotaka Takeuchi e 
Ikujiro Nonaka apresentaram os conceitos iniciais do Scrum, incluindo 
a própria palavra “Scrum” em seu famoso artigo, “The New Product 
Development Game”. Sutherland aplicou os conceitos e afinou-os. 
Schwaber e Sutherland apresentaram coletivamente suas experiências 
durante a conferência OOPSLA em 1995. Posteriormente, Schwaber e 
Beedle tentaram comunicar as novidades que envolviam o Scrum através 
do primeiro livro “Scrum Agile Software Development”.
À medida que a comunidade Scrum começou a crescer, foi decidido criar 
uma plataforma para reuni-los, o que, por sua vez, levou ao nascimento 
da certificação Scrum Alliance (SA) e Certified ScrumMaster (CSM).
No entanto, começaram a surgir controvérsias sobre a transparência e o 
motivo por trás do SA, resultando no nascimento da Scrum.org.
A Internet está repleta de várias teorias e proposições sobre o que é Scrum.
Sutherland acredita que o Scrum é um framework com um conjunto de 
melhores práticas aprendidas ao longo de cinquenta anos.
Ken concorda também com isso e dá uma boa analogia de comparar o 
Scrumcom o xadrez: (A palavra “framework” significa que muito não 
é especificado e deve ser inventado por aqueles que usam o framework. 
Eu penso no Scrum como o jogo de xadrez. Você pode ler o livro de 
regras oficial para o xadrez. Os movimentos, jogadores, sequências, pon-
tuação, etc. são todos especificados. Se você os aprender, então poderá 
jogar xadrez.
Existem pessoas que argumentam que o Scrum é um processo, mas com 
a diferença sutil de que o Scrum não é um processo definido, mas um 
processo empírico. (KRISH, 2012)
E é interessante sabermos disso, porque no Artigo original de Takeuchi e 
Nonaka, de 1986, especificamente, na abordagem ao jogo de rugby que, diga-se de 
passagem, teve apenas uma abordagem a esse jogo durante a escrita toda do artigo. 
Veja esse excerto demonstrando de onde partiu a ideia que levou ao nome Scrum:
As empresas estão percebendo cada vez mais que a abordagem antiga e 
sequencial para o desenvolvimento de novos produtos de software sim-
plesmente não fará o trabalho. Em vez disso, empresas no Japão e nos 
Estados Unidos estão usando um método holístico – como no rúgbi, a 
bola é passada dentro da Equipe à medida que se move como uma uni-
dade no campo.
Há 6 características para gerenciar o desenvolvimento:
10
11
1. Instabilidade interna (por exemplo, encorajando “tentativa e erro proposi-
talmente mantendo objetivos amplos e tolerando a ambiguidade”);
2. Equipes de projeto auto organizadas;
3. Sobreposição de fases de desenvolvimento;
4. Multi-aprendizagem (por exemplo, aprender como indivíduos, como Equi-
pes, como uma organização. Também “acumulando experiência em áreas 
diferentes da sua”);
5. Controle sutil (por exemplo, dar autonomia à Equipe, mas evitar o caos 
por atos como selecionar as pessoas certas para o projeto, criar um am-
biente aberto, incentivar as Equipes a ouvir os usuários, tolerar erros);
6. Transferência organizacional de aprendizado (por exemplo, compar-
tilhar sabedoria e “converter atividades de projeto em prática padrão 
(TAKEUCHI; NONAKA, 1986).
Se fossemos definir algo como o SCRUM de maneira muito, mas muito resu-
mida mesmo, diríamos que o Scrum é caracterizado por iterações de tempo fixo, 
chamadas sprints, que, geralmente, duram de 2 a 4 semanas.
No final do sprint, todos os membros da Equipe discutem planejamento adicio-
nal e partem para a próxima iteração.
Mas, infelizmente, não é só isso. O Scrum inclui funções, responsabilidades e reu-
niões que nunca são alteradas. Por exe mplo, o Scrum segue 4 componentes dentro 
de um sprint (são as iterações, ou seja, cada ciclo de desenvolvimento e entr ega):
• Reunião diária de Scrum (15 minutos);
• Revisão de sprint e retrospectiva; 
• A Equipe usa métodos visuais para mostrar o processo do trabalho;
• Recebe feedback do cliente.
O sprint é o coração do SCRUM.
Backlog do produto
Backlog do Sprint 
Sprint 
24 horas - Reunião diária 
2 - 4 semanas Incremento
Entregável do
Produto 
Figura 1 – Visão geral de um Sprint ou Iteração em SCRUM
Fonte: Adaptado de ARAUJO, 2012
O processo de desenvolvimento é dividido em ciclos regulares ao longo 
do tempo. A Sprint representa um ciclo de trabalho no Scrum. Esse ciclo 
pode ser de 2 semanas, 3 ou 4 semanas, que é o Timebox das Sprints.
11
UNIDADE Introdução aos Processos de Software Ágeis
As Sprints devem ter sempre a mesma duração. A cada Sprint, um conjun-
to de requisitos é implementado, tendo como resultado um incremento do 
produto que está sendo desenvolvido.
Em Scrum, só existem 3 tipos de papéis que são realizados pelos seguintes atores:
• Time de desenvolvimento Scrum: é uma coleção de pessoas trabalhando 
juntas para entregar os incrementos de produto solicitados e comprometidos. 
Esse time possui tipicamente de 5 a 9 membros, que devem possuir os conhe-
cimentos necessários para desenvolver um produto de software com qualida-
de. Para trabalhar efetivamente, é importante para um Time Scrum em que 
todos da Equipe:
 » Sigam um objetivo comum;
 » Sigam as mesmas normas e regras;
 » Mostrem respeito uns aos outros.
• Scrum Master: é frequentemente considerado um treinador para a Equipe, 
ajudando-a a fazer o melhor trabalho possível. Também pode ser considerado 
um proprietário do processo SCRUM para a Equipe, criando equilíbrio com a 
parte interessada principal do Projeto, que é referida como o proprietário do 
produto. O Scrum Master age como um líder, não como um gerente;
• Proprietário do produto Scrum: é a voz do cliente; representa as partes 
interessadas internas e é responsável por fornecer o maior valor possível ao 
negócio. Ao criar, ordenar e validar a lista de trabalhos a serem executados, o 
proprietário do produto tem autoridade para decidir o que será desenvolvido e 
quando. É importante que eles entendam Mercado, Produto, Negócios e quais-
quer restrições envolvidas.
Como qualquer processo, SCRUM possui práticas que devem ser seguidas e que 
requerem disciplina. Veja um resumo delas no quadro a seguir. 
Nas demais Unidades, veremos cada uma delas em profundidade e como criar 
um ciclo de desenvolvimento e gestão com as atividades básicas e os documentos.
Práticas do Scrum
Papéis
Fundamentais
Dono do produto
Scrum Master
Time Scrum
Planejamento do
Sprint
Reuniões diárias
Retrospectiva do
Sprint
Execução do 
Sprint
Backlog do 
Produto Grooming
Backlog do 
Produto
Backlog do Sprint
De�nição de
Pronto
Revisão do Sprint
Atividade
Básicas
Documentos
(Artefatos)
Figura 2 – Base Fundamentais do Framework SCRUM
Fonte: Adaptado de VIEIRA, 2014
12
13
O desenvolvimento usando SCRUM pode utilizar um ou vários times e cada 
um deles composto pelos 3 papéis fundamentais (dono do Produto, Scrum 
Master e Time de Desenvolvimento SCRUM).
A sequência de trabalhos que serão produzidos em SCRUM é priorizada por 
grau de importância pelo dono do produto junto o time SCRUM.
Esse artefato é conhecido como Product Backlog e é o reservatório de onde saem os 
Sprints, que nada mais são do que a decisão sobre uma iteração que será desenvolvida.
FUNCIONALIDADES
Backlog de
Produto
M
ai
or
 Pr
io
rid
ad
e
M
en
or
 Pr
io
rid
ad
e
Figura 3 – Exemplo da pilha de trabalho que compõe um Product Backlog típico
Fonte: Adaptada de VIEIRA, 2014 
O Product Owner, em conjunto com as demais partes interessadas no pro-
duto, define os itens do Product Backlog. Em seguida, ele garante que os 
itens do Backlog são colocados na sequência correta (usando fatores como 
valor, custo, conhecimento e risco), de modo que os itens de alto valor apa-
recerão no topo do backlog do produto e os itens de menor valor aparecem 
em direção ao fundo. É um documento que está constantemente evoluindo. 
Os itens podem ser adicionados, excluídos e revistos pelo Product Owner
por conta de mudanças nas condições de negócios, ou conforme a compre-
ensão da Equipe Scrum sobre o produto aumenta.
Como artefatos de controle de comunicação e evolução dos trabalhos, Scrum
empresta suas entregas de outras ferramentas como o quadro Kanban (quadro 
de acompanhamento visual de tarefas), o gráfico de BurnDown (histograma que 
demonstra o trabalho feito e quanto falta para encerrar o projeto), por exemplo, e 
quanto à produção de software, também se vale de ferramentas e práticas de outras 
metodologias, como XP e TDD.
Logo a seguir, você encontrará uma imagem contendo todo o quadro de um 
projeto SCRUM de forma bastante resumida, mas que será o suficiente para 
que você entenda como um processo ágil de gestão de projetos de software
funciona simplificadamente.
13
UNIDADE Introdução aos Processos de Software Ágeis
Processo SCRUM sumarizado. Disponível em: http://bit.ly/2RbqtfS
Ex
pl
or
No framework SCRUM, o Product Owner é quem dispara/idealiza os proces-
sos iniciais e a Equipe realizadora seria o Time Scrum, entre eles o Scrum Master. 
BLE descreve da seguinte maneira as interações entre documentos, atores e práticas:
Para agilidade nas reuniões (termo Sprint Planning Meeting) entre esses 
três grupos numeradosacima, os stakeholders acompanham a reunião 
em silêncio enquanto o Product Owner enumera e descreve as funcio-
nalidades do produto, constituindo uma lista de características cujo ter-
mo na metodologia é Product Backlog. O Scrum Team após receber o 
Product Backlog, decide quais características são mais importantes para 
começar a trabalhar em um período de duas a quatro semanas, conheci-
do como Sprint. As funcionalidades que serão trabalhadas nesse Sprint 
são organizadas em um conjunto de tarefas cuja a Scrum Team se com-
promete a realizar, sendo retiradas do Product Backlog para constituir o 
Sprint Backlog. A ideia do sprint é que o trabalho (realização do evento) 
seja dividido em períodos para sua realização, no caso, um determinado 
número de sprints.
Definido o planejamento na reunião, o Scrum Team se reúne em uma 
frequência diária ou ao menos três vezes por semana, geralmente defi-
nida pelo começo da manhã, para discutir sobre o que foi realizado no 
dia anterior, o que será realizado no dia atual e quais são os obstáculos 
encontrados para a realização do trabalho. Note que aqui a reunião (cha-
mada de Daily Scrum) não passa além desses três pontos, não sendo um 
espaço para procurar soluções sobre como resolver obstáculos, ficando 
isso a cargo do Scrum Master para resolver ao longo do dia após a reu-
nião. Isso garante que os encontros matutinos da Equipe sejam diretos e 
consumem pouco tempo.
Para controlar seu progresso, a Equipe atualiza ao final de cada Sprint 
um gráfico chamado Release Burndown Chart. É como se fosse uma lista 
de tarefas que são realizadas a cada sprint, podendo visualizar o trabalho 
que foi feito o que terá que ser realizado nas próximas iterações (sprints).
Ao final de uma Sprint, a Equipe apresenta as funcionalidades ou carac-
terísticas do evento em uma reunião chamada Sprint Review Meeting. 
Após isso é realizado uma Sprint Retrospective, ou seja, uma retrospec-
tiva para identificar os pontos que funcionaram bem ou não durante a 
execução da Sprint. O processo todo se repete até acabar o desenvolvi-
mento com a entrega final do produto em funcionamento. (BLE, 2016)
14
15
Gráfico de Sprint Burndown Scrum
É uma ferramenta de medição visual que mostra o trabalho concluído por dia em 
relação à taxa projetada de conclusão da versão atual do projeto. Sua finalidade é 
permitir que o projeto esteja no caminho para entregar a solução esperada dentro 
do cronograma desejado.
Segundo o Scrum Institute (2018), a taxa de progresso de um Time Scrum é 
chamada de “velocidade”. Ela expressa a quantidade de pontos de história, por 
exemplo, concluídos por iteração. Uma regra de importação para calcular a veloci-
dade é que apenas as histórias que são concluídas no final da iteração são contadas. 
Contar parcialmente o trabalho acabado é estritamente proibido.
Conforme os escritos de Kocurek (2011), de modo geral, o quadro Burndown
deve consistir em:
• Eixo X para exibir dias úteis;
• Eixo Y para exibir o esforço restante;
• Esforço ideal como diretriz;
• Real progresso de esforço.
24 Mai 26 Mai 28 Mai 30 Mai 01 Jun 03 Jun
Tendência Ideal
0
10
20Tr
ab
al
ho
 re
sta
nt
e (
ho
ra
s)
Ho
je
30
40
50
60
Em Progresso
A Fazer
Figura 4 – Exemplo de Sprint Burndown Chart
Fonte: Adaptado de Microsoft
Um gráfico de burndown da sprint exibe os seguintes dados: a linha Ten-
dência Ideal (ideal trend) indica uma situação ideal em que a Equipe conso-
me todo o esforço que permanece em uma taxa constante no final do sprint. 
A série Em Andamento (in progress) mostra quantas horas permanecem 
para tarefas marcadas como em andamento em uma sprint. A série A Fazer 
(to do) mostra quantas horas permanecem para tarefas marcadas como A 
fazer em um sprint.
15
UNIDADE Introdução aos Processos de Software Ágeis
Kanban
Agregar valor é um dos maiores objetivos de um Projeto Ágil com Scrum e mui-
tas técnicas são utilizadas para realizar essa missão.
Esse “fluxo para apresentar valor” começa com um conceito inicial e, lógico, a 
sua previsibilidade se move por vários estágios, incluindo o desenvolvimento, indo 
até a liberação final e a sustentação.
Uma das formas de agregar valor é a transparência e o Quadro Kanban é ideal 
para ser usado com Scrum.
Isso ocorre por meio da utilização de um quadro (físico Lousa ou virtual software 
Trello, por exemplo) para o gerenciamento visual do trabalho de uma Equipe Scrum 
e para melhorar a entrega de produtos e serviços em termos de previsibilidade, qua-
lidade e desempenho e time-to-market.
Em Kanbanize (2018), descreve-se que um quadro Kanban é uma ferramenta 
para mapear e visualizar seu fluxo de trabalho como auxiliar do framework Scrum, 
que ajuda a: 
• Visualizar os gargalos e os pontos fracos do fluxo de trabalho;
• Concentrar-se no trabalho atualmente disponível;
• Eliminar em parte a necessidade de reuniões básicas de atualização de status.
A palavra Kanban, de origem japonesa, quer dizer registro ou placa visível.
O Kanban foi originalmente construído usando um quadro branco. Ele é divi-
dido em colunas e raias. Cada coluna representa um estágio do fluxo de trabalho, 
enquanto as raias separam diferentes tipos de atividades. Quando uma tarefa entra 
em seu fluxo de trabalho, ela é colocada em um cartão Kanban, que passa por cada 
coluna do quadro.
Há várias formas de nomear as colunas, mas as preferidas em Scrum são:
• Requisitadas;
• Em progresso;
• Teste/Liberação;
• Feita.
16
17
Exemplos de quadros Kanban utilizados em projetos de sistemas no Scrum: O quadro Kanban
é uma ferramenta perfeita para visualizar problemas potenciais em seu processo. A lógi-
ca é simples: se você vir uma coluna na qual as tarefas chegam mais rápido do que elas 
saem, o trabalho começará a se acumular e o problema ficará visível para toda a Equipe. Isso 
pode ser causado por um problema temporário ou um gargalo no seu processo. Importante 
mencionar o conceito de Heap, que limita o volume de tarefas máxima suportada por cada 
coluna, portanto, se na coluna FAZENDO, como em nosso exemplo, houver 11 tarefas e esse 
coincidentemente for o número do HEAP, ninguém poderá pegar mais outra tarefa até que 
alguém passe ao menos uma para FEITO, e assim por diante. Para cada coluna, haverá um 
número para o HEAP.
Disponível em: http://bit.ly/2G3NV8z e http://bit.ly/2THUvtw
Ex
pl
or
Como você pode observar nas figuras, para um mapeamento mais detalhado 
do seu processo, há a liberdade de criar quantas subseções forem necessárias para 
visualizar seu fluxo de trabalho com a máxima precisão.
Para usar é simples: a cada sprint, coloque as tarefas no caixa A FAZER e o time 
scrum vai pegando esses cartões e movendo pelas colunas existentes. 
Você delimita quantos cartões cada um pode pegar e quanto o time pode pegar 
para evitar gargalos e concentração de trabalho em uma única pessoa. 
A partir daí, monitore e verifique os tempos que levam essas fichas para se 
deslocarem de uma coluna à outra, até sua liberação final em Feito. Faça as corre-
ções necessárias no fluxo, elimine os impeditivos e gargalos e mantenha o foco de 
aprendizagem de sua Equipe.
XP – Extreme Programming com
TDD (Teste) – Desenvolvimento
Dirigido por Testes
Extreme Programming – XP, em português: Programação Extrema, é uma me-
todologia para desenvolvimento de software ágil, cujos primeiros conceitos apare-
ceram no final da década de 80 do século XX. 
Porém, a partir de um trabalho escrito por Kent Beck (um dos 17 participantes 
do Manifesto Ágil, em 2001) nessa mesma época, o XP foi efetivamente criado e 
foi dado o seu corpo de práticas. 
Ademais, Beck, além de ser reconhecido como criado do XP, também criou o 
TDD – Test Driven Development ou Desenvolvimento Guiado por Testes, meto-
dologia muito eficaz utilizada atualmente por grandes Empresas, como a Microsoft.
17
UNIDADE Introdução aos Processos de Software Ágeis
Como grande parte das Metodologias Ágeis, XP utiliza orientação a objetos 
como base de seu desenvolvimento e criauma constelação de regras e práticas 
fundamentada em 4 alicerces:
• Planejamento;
• Projeto;
• Codificação;
• Testes.
soluções pontuais
protótipos
teste de unidades
 integração contínua
incremento de software
 velocidade de projeto calculada
teste de aceitação
Versão
teste
codi�cação
refatoração
projeto
planejamento
programação em pares
projeto simples
cartões CRChistórias de usuários
 valores
 critérios de teste de aceitação
plano de iteração
Figura 5 – Processo XP
Fonte: Adaptado de PRESSMAN e MAXIM, 2016
XP possui uma série de práticas que, como Telles nos ensina, pode ser dividida 
em 2 grandes grupos:
Práticas Primarias: São práticas que você pode começar a adotar ime-
diatamente de forma segura para melhorar seu esforço de desenvolvimen-
to de software. Qual você deve adotar primeiro depende inteiramente de 
seu ambiente e o que você entende como sendo sua maior oportunidade 
de melhoria. Algumas pessoas precisam de planejamento porque não 
sabem o que precisa ser feito. Outros precisam de práticas relacionadas à 
melhoria de qualidade porque estão criando defeitos demais para serem 
capazes de ver o que está acontecendo.
Práticas Corolárias: As práticas corolárias são difíceis ou perigosas de 
serem implementadas antes de se adotar as práticas primárias. Se você 
começar a implantar o software diariamente, por exemplo, sem baixar a 
taxa de defeitos para algo muito próximo de zero (com programação em 
par, integração contínua e desenvolvimento orientado a testes), você terá 
um desastre nas mãos. Confie na sua intuição sobre o que é a próxima 
coisa que precisa ser aprimorada. Se algumas das práticas a seguir pare-
cer apropriada, tente-a. Talvez funcione ou talvez você descubra que há 
mais trabalho a ser feito antes que você possa usá-las para aprimorar seu 
processo de desenvolvimento. (TELES, 2006, p. 1-2)
18
19
XP capacita os desenvolvedores a responder com confiança às mudanças nos re-
quisitos do cliente, mesmo no final do ciclo de vida do desenvolvimento do projeto. 
A filosofia da XP é o trabalho em Equipe, em outras palavras, gerentes, clientes 
e desenvolvedores são parceiros iguais em uma Equipe colaborativa.
Possui 4 valores:
• Simplicidade: manter o design simples e limpo;
• Feedback: obter feedback testando o software desde o primeiro dia do projeto;
• Coragem e Respeito: entregar o sistema aos clientes o mais cedo possível e 
implementar as mudanças conforme sugerido. Cada pequeno sucesso aprofun-
da o respeito pelas contribuições únicas de cada membro da Equipe.
A história do XP é bastante interessante e é apresentada por Cunningham (2008) 
com alguns eventos impactantes no tempo, que servem de balizamento para enten-
dermos desde a crise do software, da década de 70 do século XX, até a sequência 
de ações que proporcionaram o ambiente propício para o surgimento dos métodos 
ágeis e, em particular, da XP. 
A seguir, alguns eventos impactantes:
Kent escreve padrões de programação para um cliente. Eles são bem 
recebidos, mas não são totalmente eficazes. Se não a solução completa, 
eles são pelo menos uma parte importante. Os padrões crescem para se 
tornar Smalltalk Best Practice Patterns.
Kent trabalha no projeto Well Fleet para a Hewitt Associates. Aqui ele 
primeiro ensina consistentemente uma Equipe os Testes de Unidade, bem 
como as melhores práticas de Smalltalk com a Sistemática de Metáforas. 
O projeto entra em produção com muito pouco problemas em 1999.
Kent é contratado para executar o projeto de folha de pagamen-
to da Chrysler. Ele encontra problemas mais profundos, diz à alta 
administração para começar de novo e aceita o trabalho de treinar a 
Equipe. Este é o ponto em que Kent “gira os botões”, aproveitando sua 
experiência com Smalltalk, Patterns e Hillside.
Sue Unger, CIO da Chrysler, oferece sua mais brilhante Equipe de 
programação trabalhando em um importante problema do Y2K (bug
do milênio) para Kent fazer o que ele quiser. Uma visionária, ela 
acredita em Kent e apoia sua nova metodologia. O XP estava criado! 
(CUNNINGHAM, 2008, p. 2-3) 
XP é uma metodologia tão importante que foi um dos primeiros Métodos Ágeis. 
Na verdade, ele foi o método ágil dominante no final dos anos 1990 e início dos 
anos 2000, antes de Scrum se tornar dominante.
Muitas pessoas o consideram o principal catalisador, que chamou a atenção para 
Métodos Ágeis, e superior ao Scrum como base para iniciar um desenvolvimento 
19
UNIDADE Introdução aos Processos de Software Ágeis
ágil, já que SCRUM serve muito bem para gerir software, mas, internamente, pre-
cisa de Metodologia de Engenharia de Software consistente, que XP fornece.
Como todos sabem, é muito difícil um sistema ser desenvolvido em um ambiente 
calmo, tranquilo e sem mudança de requisitos.
Na realidade, é muito difícil que os projetos sigam o fluxo sequencial do modelo 
em cascata, por exemplo, bem como se percebe a dificuldade em se identificar to-
dos os requisitos e as metas no início dos projetos, pois os requisitos tendem a mu-
dar completamente durante o tempo e, por fim, se seguirmos métodos tradicionais, 
como o cascata, uma versão funcional só pode ser obtida no final do processo, o 
que vale dizer que, muitas vezes, o negócio mudou completamente, ou pior, deixou 
de existir e o projeto, por consequência, foi cancelado.
A palavra que diferencia um Método Tradicional de um Método Ágil é ADAP-
TAÇÃO.
XP é tremendamente adaptativo em frente aos métodos tradicionais e isso é 
verdadeiro, porque ele responde prontamente às mudanças.
A base disso são alguns Princípios Ágeis, como:
• Escrever o teste de maneira precoce, foco na automação, já que é provável que 
esse teste esteja errado de alguma forma até a entrega ocorrer;
• Design Incremental;
• Implantação diária;
• Alto nível de envolvimento do cliente;
• Integração contínua;
• Ciclos de desenvolvimento curtos;
• Planejamento incremental;
• Base de código único;
• Abraçar a mudança.
Importante, porém, ainda assim, insuficiente. 
Kent, quando trabalhou no Projeto da Chrysler, percebeu 4 dimensões importan-
tes, que não podem ser deixadas ao lado, pois definem rumos de sucesso ou fracasso. 
São elas:
• Você precisa melhorar a comunicação;
• Você precisa buscar simplicidade;
• Você precisa obter feedback sobre o quão bem você está fazendo as coisas;
• Você precisa sempre prosseguir com coragem.
20
21
Claro, para que você possa vivenciar isso, é necessário estar trabalhando num 
ambiente democrático de respeito às ideias e com gente de alto nível profissional 
e humano. Isso não existe se você estiver imerso numa Empresa autocrática ou 
baseada numa estrutura de cargos orientados a graus de parentesco ou amizade, 
e não em competência e mérito, como vemos fortemente ancorada nos países de 
origem anglo-saxônica, germânica, gaulesa ou asiática que, de uma forma ou de 
outra, também são os líderes em Educação e Desenvolvimento e em Engenharia 
de Software.
Creio que nós latinos ainda temos muito a aprender com eles, não é mesmo?!
XP tem fama de levar todas essas práticas ao extremo.
A seguir, na Tabela 1, você poderá ver uma referência direta dos extremos de XP.
Tabela 1 – Algumas práticas levadas ao extremo por XP
Boas práticas são Levadas ao extremo
Revisões de código Rever o código o tempo todo (programação em pares)
Testando Todo mundo vai testar o tempo todo (testes de unidade) até mesmo os clientes (teste funcional)
Desenhar Faça parte do negócio diário de todos (refatoração)
Simplicidade Sempre deixe o sistema com o design mais simples, que suporta a funcionalidade atual (a coisa mais simples que poderia funcionar)
Arquitetura Todo mundo vai trabalhar definindo e refinando a arquitetura o tempo todo (metáfora)
Teste de integração Integrar e testar várias vezes ao dia (integração contínua)
Iterações curtas Faça iterações realmente curtas: segundos, minutos, horas, não semanas, meses ou anos (o jogo de planejamento)
Fonte: Adaptado de umsl.edu
XP segue 4 atividadesconsideradas padrão para o processo de desenvolvimento 
de software, a saber:
• Codificação: é considerada o único produto importante do processo de de-
senvolvimento do Sistema. Começa-se a codificação no início do dia e se entre-
ga algo que funcione no fim do dia. Isso é impreterível. Isso também significa 
que os codificadores não podem ser juniores!;
• Teste: é muito enfático que se deve sempre verificar se uma função funciona, 
por meio do teste. XP se vale dos Testes de Unidade, que são testes automa-
tizados, e o programador trabalhará o maior número possível de vezes para 
tentar quebrar o código que ele está escrevendo;
21
UNIDADE Introdução aos Processos de Software Ágeis
• Ouvir: a habilidade e o conhecimento nos aspectos técnicos devem ser acom-
panhados pela capacidade de sermos bons ouvintes. Essa capacidade permiti-
rá que os desenvolvedores entendam o que os clientes querem e desenvolvam 
soluções que correspondam às necessidades e desejos desses clientes o mais 
próximo possível. Portanto, habilidades psicossociais e emocionais dos desen-
volvedores não são mais um requisito, mas uma necessidade. É um item obri-
gatório, um Programador/Analista sem essas habilidades, infelizmente, não é 
mais considerado para contratação, principalmente, para softwares comer-
ciais. É importante desenvolver essas habilidades;
• Projetando: a simplicidade do XP não significa que ele possa excluir o proces-
so de design. Sem um projeto adequado no longo prazo, o Sistema se torna 
muito complexo e os projetos podem parar. Importante criar uma estrutura de 
projeto que organize a lógica no Sistema, de modo que muitas dependências 
no Sistema possam ser evitadas.
Há 12 práticas definidas por Kent e descritas por Hutagalung que versam, resu-
midamente, o seguinte:
Histórias de usuários (planejamento): as histórias do usuário podem 
ser visualizadas como uma versão menor do caso de uso. Desta forma, o 
cliente define o mais breve possível a especificação da nova aplicação (ca-
racterísticas, valor, prioridade). Essas histórias serão a base para a Equipe 
de projeto fazer estimativa de custos e gerenciamento do projeto.
Pequenos lançamentos (blocos de construção): enfatiza atualizações 
de versões pequenas, simples, mas frequentes do aplicativo. Cada re-
quisito recém-adicionado será imediatamente incorporado e o sistema 
será relançado.
Metáfora (esquemas de nomeação padronizados): Desenvolvedores e 
programadores devem aderir aos padrões de nomes, nomes de classes 
e métodos.
Propriedade coletiva: todo o código é considerado de propriedade de 
toda a Equipe e não de um indivíduo. Portanto, todo o código é revisado 
e atualizado por todos.
Padrão de codificação: Estilos e formatos de codificação devem ser os 
mesmos para permitir a compatibilidade entre os membros da Equipe. 
Essa abordagem resulta em uma colaboração mais rápida.
Design simples: Sempre procure a implementação do sistema que seja 
tão fácil quanto possível.
Refatoração: O aplicativo deve ser continuamente ajustado e aprimora-
do por todos os membros da Equipe. Isso requer uma comunicação ex-
tremamente boa entre os membros para evitar a duplicação de trabalho.
Teste: Toda pequena liberação (chamada de bloco de construção) deve 
passar nos testes antes de ser liberada. A singularidade do XP nesse 
aspecto é que os testes são criados primeiro e, em seguida, o código do 
22
23
aplicativo é desenvolvido para atender e passar nos desafios dos testes 
pré-escritos.
Programação em par: os programadores XP trabalham em pares. Todo 
o código é desenvolvido por dois programadores que trabalham juntos em 
uma única máquina. A expectativa é que a programação em pares produza 
códigos de maior qualidade com o mesmo custo ou com menor custo.
Integração contínua: As compilações de software são concluídas várias 
vezes ao dia. Dessa forma, todos os desenvolvedores podem evitar frag-
mentações de trabalho, pois eles liberam e integram continuamente o 
código juntos.
Semana de trabalho de 40 horas: Mantenha as condições mentais e físicas 
de estar funcionando sem trabalhar mais do que o corpo pode suportar.
Cliente no local: o cliente deve ser visto como parte integrante do proje-
to. O cliente deve estar disposto a estar sempre disponível para garantir 
que o projeto esteja no caminho certo. (HUTAGALUNG, 2006)
Comunicação
Simplicidade
Coragem
Feedback
Valores Práticas
Jogo do Planejamento
Pequenos Releases
Metáfora
Design Simples
Teste
Refatoração
Programação em Pares
Código Coletivo
Integração Contínua
Semana de 40 horas de trabalho
Cliente Presente
Padrões de Codi�cação
XP
Figura 6 – XP Valores e Práticas
As práticas são as atividades diárias realizadas pelas Equipes e os valores 
são o conhecimento subjacente e a compreensão da abordagem.
Histórias dos Usuários
As histórias nas Metodologias Ágeis, em geral, e notadamente no XP, são a uni-
dade fundamental das atividades dos times de desenvolvimento.
As histórias de usuários são pequenas, muito menores do que outros artefatos de 
requisitos, como casos de uso ou cenários de uso. É importante reconhecer que todas 
as declarações feitas num Index Card representam uma única história de usuário.
23
UNIDADE Introdução aos Processos de Software Ágeis
Mas, como escrevemos histórias de usuários?
Aqui vai o exemplo do que encontramos num cartão de história do usuário:
• Os estudantes podem comprar passes de estacionamento mensais on-line;
• Os passes de estacionamento podem ser pagos por meio de cartões de crédito;
• Os passes de estacionamento podem ser pagos via PayPal;
• Professores podem inserir as notas dos alunos;
• Os estudantes podem obter o cronograma atual do seminário;
• Os alunos podem solicitar transcrições oficiais;
• Os alunos só podem se inscrever em seminários para os quais tenham 
pré-requisitos;
• Transcrições estarão disponíveis on-line por meio de um navegador padrão.
Ambler aproveita para elencar considerações importantes para as partes interes-
sadas ou a área de negócios escreverem histórias de usuários:
As partes interessadas escrevem histórias de usuários: Um concei-
to importante é que os envolvidos no projeto escrevem as histórias do 
usuário, não os desenvolvedores. As histórias de usuários são simples o 
suficiente para que as pessoas aprendam a escrevê-las em poucos mi-
nutos, por isso faz sentido que os especialistas do domínio (as partes 
interessadas) as escrevam.
Use a ferramenta mais simples: As histórias de usuários geralmente 
são escritas em fichas de índice. Os cartões de índice são muito fáceis de 
trabalhar e, portanto, são uma técnica de modelagem inclusiva.
Lembre-se dos requisitos não funcionais: As histórias podem ser usa-
das para descrever uma ampla variedade de tipos de requisitos.
Indique o tamanho estimado: Inclua uma estimativa para o esforço de 
implementar a história do usuário. Uma maneira de estimar é atribuir 
pontos de história do usuário (planning poker) a cada cartão, uma indi-
cação relativa de quanto esforço levará um par de programadores para 
implementar a história. A Equipe sabe então que, se atualmente, leva 
em média 2,5 horas por ponto da carta; portanto, a história do usuário 
fica muito mais fácil de estimar. Então 2,5h x uma carta com 5 pontos 
teremos uma atividade cuja duração seria de aproximadamente 12,5h.
Indique a prioridade: Os requisitos, incluindo os defeitos identificados 
como parte de suas atividades de testes paralelos independentes ou por 
suas operações e esforços de suporte, são priorizados pelos envolvidos 
no projeto e adicionado à pilha no local apropriado. Você pode facil-
mente manter uma pilha de requisitos priorizados movendo as cartas na 
pilha conforme apropriado. O cartão de história do usuário inclui uma 
indicação da prioridade. Podemos usar uma escala de um a dez, sendo 1 
a prioridade mais alta e 10 a mais baixa. 
24
25
Inclua um identificador exclusivo. O cartão também deverá possuir um 
identificador exclusivo para a história do usuário. A únicarazão para isso 
é manter a rastreabilidade entre a história do usuário e outros artefatos, 
em particular testes de aceitação. (AMBLER, 2009)
Podemos, ainda, ter histórias de usuários muito grandes, que chamamos de epo-
peias, e grupos de histórias que chamamos de tema.
Vejamos como são estruturadas:
• Epopeias: são grandes histórias de usuário, normalmente, aquelas que são 
grandes demais para serem implementadas em uma única iteração e, portanto, 
precisam ser desagregadas em histórias de usuários menores, em algum mo-
mento. Normalmente, possuem prioridade mais baixa. Não faz sentido desa-
gregar um épico de baixa prioridade porque você estaria investindo tempo em 
algo que nunca poderá abordar, a menos que uma parte do épico tenha alta 
prioridade e precise ser descartada. Lembre-se de adiar o comprometimento 
para aumentar sua produtividade geral;
• Tema: é uma coleção de histórias de usuários relacionadas. Por exemplo, para 
um sistema de registro universitário, pode haver temas em torno dos alunos, 
gerenciamento de cursos, geração de transcrição, administração de notas, pro-
cessamento financeiro. São usados para organizar histórias em lançamentos 
ou organizá-las para que várias subequipes possam trabalhar nelas.
As histórias de usuários são o alfa e o ômega do XP, e os desenvolvedores cos-
tumam escrever testes baseados nelas. As histórias são noções básicas perfeitas 
para testes, porque são breves e caracterizam os recursos mais importantes do 
produto final.
Geralmente, os testes são escritos antes de começar a criação do código do pro-
duto. Essa abordagem do desenvolvimento visa a economizar tempo e atender aos 
termos do projeto.
Planning Game
O Jogo de Planejamento permite-nos encontrar rapidamente um plano aproxi-
mado e depois refiná-lo à medida que o projeto avança. 
Poderíamos dizer que o Jogo do Planejamento é uma reunião, é um ponto vital 
de interação entre cliente e desenvolvedor.
A reunião acontece com a Equipe trabalhando em uma pilha de cartões de ín-
dice que contém as histórias do usuário. Os requisitos do usuário são escritos em 
fichas de índice e são tratados durante o Jogo de Planejamento.
Cartões de índice são uma ferramenta altamente eficaz. A utilidade simples dos 
cartões conecta clientes e programadores para atingir seu objetivo comum. O uso 
25
UNIDADE Introdução aos Processos de Software Ágeis
de cartões de índice não é obrigatório no Jogo de Planejamento, e você pode des-
cobrir que outras ferramentas, como aplicativos da Web, podem ser eficazes.
Quaisquer que sejam as ferramentas escolhidas, há uma clara separação de 
responsabilidades durante o Jogo de Planejamento.
Vejamos quem são os atores em XP, na Tabela 2, a seguir:
Tabela 2 – Responsabilidades durante o jogo de planejamento
O negócio Técnico
Definir o escopo do lançamento Estimar quanto tempo cada história do usuário levará
Definir a ordem de entrega (quais 
histórias são feitas primeiro)
Comunicas os impactos técnicos da 
implementação de requisitos
Definir datas e horários de lançamento Divida as histórias do usuário em tarefas e aloque o trabalho
Fonte: Adaptado de BAIRD, 2002
O planejamento do XP aborda duas questões-chave no desenvolvimento de 
software: prever o que será realizado até a data de vencimento e determinar o que 
fazer a seguir. A ênfase está em direcionar o projeto.
Duas etapas trabalham com esses conceitos, conforme Lacey:
• O Planejamento de Liberação é uma prática em que o Cliente apresenta os 
recursos desejados aos programadores e os programadores estimam sua difi-
culdade. Com as estimativas de custos em mãos e com o conhecimento da im-
portância dos recursos, o Cliente estabelece um plano para o projeto. Os pla-
nos de lançamento inicial são necessariamente imprecisos: nem as prioridades 
nem as estimativas são verdadeiramente sólidas e, até que a Equipe comece a 
trabalhar, não saberemos com que rapidez elas serão. Até mesmo o primeiro 
plano de lançamento é preciso o suficiente para a tomada de decisões, no en-
tanto, e as Equipes de XP revisam o plano de lançamento regularmente.
• Planejamento de Iteração é a prática pela qual a Equipe recebe orientação 
a cada duas semanas. As Equipes de XP criam softwares em “iterações” de 
duas semanas, entregando softwares úteis ao final de cada iteração. Durante 
o planejamento de iteração, o cliente apresenta os recursos desejados para as 
próximas duas semanas. Os programadores dividem-nas em tarefas e estimam 
seu custo (em um nível mais refinado de detalhes do que no Planejamento da 
Liberação). Com base na quantidade de trabalho realizado na iteração anterior, 
a Equipe se inscreve para o que será realizado na iteração atual (LACEY, 2018, 
p. 4-5).
Ademais:
O jogo de planejamento XP tem dois participantes no processo de plane-
jamento: Negócios e Desenvolvimento. Isso pode ajudar a remover parte 
do calor emocional inútil da discussão. Não há como um simples conjunto 
26
27
de regras existirem para lembrar a todos como eles gostaria de atuar, e 
eles fornecem uma referência comum quando as coisas não estão indo 
bem. (BECK, 1999)
• Desenvolvedores: são as pessoas que irão realizar a implementação do que 
foi definido no cartão;
• Negócio (Cliente): são as pessoas que vão dizer aos desenvolvedores o que 
eles querem que seja implementado. O cliente decide a prioridade do trabalho 
a ser feito e o que está dentro e fora do escopo. O cliente Agile garante a má-
xima satisfação do cliente do produto, e o valor das organizações, garantindo 
quais são as histórias nas quais as Equipes estão trabalhando, que são prioriza-
das para gerar o máximo valor.
XP possui pelo menos 22 práticas e, acredite, são necessárias. Assim como 
os valores, existe uma enorme lacuna entre valores e práticas, que é preenchida 
pelos princípios.
O jogo de planejamento, de maneira sumária, resume-se a: 
• Relacionar os itens de trabalho que talvez precisem ser feitos;
• Estimar os itens;
• Definir um orçamento para o ciclo de planejamento;
• Concordar com o trabalho que precisa ser feito dentro do orçamento. Ao ne-
gociar, não altere as estimativas ou o orçamento.
Pequenos Lançamentos
Baird (2002) diz que “[...] a única maneira de garantir que se esteja desenvolven-
do o software que o cliente espera é manter os ciclos de lançamento o mais curtos 
possível. Mesmo que o lançamento seja pequeno, ele ainda deve agregar valor 
comercial ao cliente”.
Como parte do planejamento de lançamentos, o cliente trabalha com a Equipe de 
desenvolvimento para definir as histórias do usuário e a ordem de implementação.
A Equipe de desenvolvimento pode usar cada lançamento como um ponto de 
verificação, no qual eles medem a precisão das estimativas.
Durante o estágio de planejamento, os desenvolvedores estimaram as histórias 
do usuário com base em sua taxa de transferência e dificuldade esperadas. Agora, 
podemos comparar o planejado X real, usando essas lições aprendidas para a pró-
xima iteração.
27
UNIDADE Introdução aos Processos de Software Ágeis
Ciclos de lançamento pequenos são viáveis porque estamos construindo as his-
tórias de usuários mais importantes primeiro, e nosso ambiente automatizado faci-
lita a integração frequente.
As Equipes XP praticam pequenos lançamentos de duas maneiras importantes:
• Primeiro: a Equipe libera software testado e em execução, entregando o valor 
comercial escolhido pelo Cliente, a cada iteração. O Cliente pode usar este 
software para qualquer finalidade, seja avaliação, seja mesmo a liberação para 
usuários finais, o que é altamente recomendado. O aspecto mais importante é 
que o software é visível e entregue ao cliente no final de cada iteração;
• Segundo: a Equipe também faz liberações para seus usuários finais com fre-
quência. Os projetos têm atualizações diárias, se for para projetos internos 
mensalmente ou com mais frequência.
Metáfora
A Metáfora do Sistema é uma das principais práticas do processo de desenvolvi-
mento de software conhecido como XP. 
A prática daMetáfora do Sistema ainda é mal compreendida e é a prática que as 
Equipes de XP mais comumente escolhem ignorar (BIDDLE, 2004).
Segundo NESS, 2014, para se usar metáforas eficazes:
Tente criar um sistema que seja fácil de explicar usando analogias da 
vida real. Seus sistemas são complexos, tente usar um design, onde o 
relacionamento e as interações entre os subcomponentes são claros e se 
assemelham a algo que as pessoas com bom senso já viram.
Use as analogias em todas as comunicações: código-fonte, planejamento 
de reuniões, falar com os usuários ou escrevendo a documentação. Se 
você achar que os conceitos que você usa não se encaixam em alguma 
área, tente encontrar uma metáfora melhor. (NESS, 2014, p. 1)
Design Simples
A Agile Alliance defende que uma Equipe que adota a prática do “design sim-
ples” baseia sua estratégia de design de software nos seguintes princípios:
Design é uma atividade contínua, que inclui refatoração e heurísticas.
A qualidade do design é avaliada com base nas regras de simplicidade de 
código;
28
29
Todos os elementos de design, como “padrões de projeto”, arquiteturas 
baseadas em plug-in, etc., são vistos como tendo custos e benefícios, e os 
custos de design devem ser justificados;
As decisões de projeto devem ser adiadas até o “último momento res-
ponsável”, de modo a coletar o máximo de informações possível sobre os 
benefícios da opção escolhida antes de incorrer em seus custos. (AGILE 
ALLIANCE, 2018, p. 6)
É enganoso invocar a prática de design simples para justificar decisões que têm 
a ver com os requisitos de um cliente ou proprietário do produto, ou considerações 
de usabilidade.
Essas práticas podem ser muito inconsistentes se o grupo de desenvolvedores for 
muito grande ou distribuído em vários locais.
Testes
Sabemos que a XP reinventou a forma de 
se escrever código de software, principalmen-
te, no quesito de aplicação de testes.
Em vez de testar após o desenvolvimen-
to, os desenvolvedores escrevem o teste an-
tes da codificação. Estamos nos referindo 
aos testes de unidade que trabalham sobre 
cada método e cada coisa que poderia que-
brar no software. 
Baird (2002) escreve que: “Quando eles 
escrevem todos os testes para esse compo-
nente, eles escrevem apenas código suficien-
te para passar no teste. Escrever testes nos 
fornece um conjunto completo para o nosso 
sistema e escrevemos a coisa mais simples 
que poderia funcionar”.
Fowler, um dos apoiadores e desenvolvedores do XP, junto com Kent Beck (cria-
dor do XP), que também fez o TDD – Test Driven Development, define o teste de 
unidade como sendo:
Apesar das variações, existem alguns elementos comuns. Em primei-
ro lugar, há uma noção de que os testes de unidade são de baixo ní-
vel, concentrando-se em uma pequena parte do sistema de software.
Em segundo lugar, os testes unitários geralmente são escritos hoje em 
dia pelos próprios programadores, usando suas ferramentas regulares – a 
única diferença é o uso de algum tipo de estrutura de testes unitários.
Implemente um
teste
Execute o teste
Realize
pequenos ajustes
Execute o teste
Desenvolvimento
continuafalhou
falhou
Desenvolvimento para
passou
Figura 7 – Processo de teste usando TDD em XP
Fonte: Adaptado de MEYER e LEITNER, 2006
29
UNIDADE Introdução aos Processos de Software Ágeis
Em terceiro lugar, espera-se que os testes unitários sejam significativa-
mente mais rápidos do que outros tipos de testes.
Portanto, há alguns elementos comuns, mas também existem diferenças. 
Uma diferença é o que as pessoas consideram uma unidade. O design 
orientado a objetos tende a tratar uma classe já que as abordagens unitá-
ria, processual ou funcional podem considerar uma única função como 
uma unidade. Mas, na verdade, é uma questão situacional – a Equipe de-
cide o que faz sentido ser uma unidade para fins de compreensão do sis-
tema e de seus testes. Embora se comece com a noção de que a unidade 
é uma classe, muitas vezes pegamos um monte de classes estreitamente 
relacionadas e podemos as tratar como uma única unidade. Raramente 
podemos pegar um subconjunto de métodos em uma classe como uma 
unidade. No entanto, o time deve definir o que realmente não importa. 
(FOWLER, 2014, p. 11-2)
Refatoração
Maniuk (2006) vem ao encontro dessa prescrição e define que: “A refatoração 
é uma prática de desenvolvimento de software que permite melhorar o código 
sem alterar ou interromper sua funcionalidade. O código deve ser o mais simples 
possível para encontrar todos os bugs e facilitar a mudança de algo no processo de 
desempenho do projeto”.
Os objetivos da refatoração são:
• Simplificação do código inicial;
• Integrar a refatoração na rotina diária dos desenvolvedores;
• A refatoração deve ser constante em todas as fases de produção de código e 
verificação e validação.
Lean
Desenvolvimento enxuto é a aplicação dos princípios Lean ao desenvolvimento 
de software. O Lean teve início na fabricação como uma maneira de otimizar a 
linha de produção para minimizar o desperdício e maximizar o valor para o cliente. 
Teve início em 2003, com o livro de Tom e Mary Poppendieck: Implementan-
do o desenvolvimento de software enxuto, e segue os seguintes pilares (elimine 
desperdícios, inclua qualidade no processo, crie conhecimento, adie comprometi-
mentos e decisões, entregue rápido, respeite as pessoas e otimize o todo).
30
31
Numa frase síntese importante, podemos resumir Lean em: devemos encontrar 
uma forma de entregar software tão rápido, que os clientes não tenham tempo de 
mudar qualquer coisa. 
Desafiador, não?!
Esses dois objetivos também são relevantes para o desenvolvimento de software, 
que também segue um processo repetível, requer padrões de qualidade específicos e 
conta com a colaboração de um grupo de trabalhadores especializados para concluir.
A aplicação dos princípios Lean ao trabalho do conhecimento (desenvolvimento 
de sistemas de software) exige uma mudança de mentalidade (de toda a Equipe, de 
seus gerentes até o estagiário).
Afinal, Lean é ser enxuto!
Mas você precisa entender o seguinte, o desenvolvimento ágil é um processo 
para entrega rápida de software, que está conectado a muitos princípios do Lean. 
Mas, são diferentes apesar de terem pontos de conexão!
O Desenvolvimento Ágil pode se referir a qualquer método de desenvolvi-
mento alinhado aos conceitos descritos no Manifesto Ágil (XP, Crystal, TDD, 
FDD, DSDM...) .
Lembrando que isso significa que a prática resultante, conhecida como Desen-
volvimento Ágil de Software, utiliza três conceitos principais: uma abordagem itera-
tiva ao desenvolvimento, breves ciclos de feedback e um processo disciplinado de 
Gerenciamento de Projetos.
A ideia central Lean é maximizar o valor do cliente e minimizar o desperdício. 
Simplesmente, lean significa criar mais valor para clientes com menos recursos.
Greycampus expõe a estrutura LEAN para software, que segue os 7 princípios 
fundamentais de quando foi desenvolvida pela Toyota, a saber:
Eliminar desperdício: Tudo o que não agrega valor ao cliente é desperdí-
cio, como um módulo insuficientemente testado, código e funcionalidade 
desnecessários.
Amplificar o aprendizado: A melhor abordagem para melhorar um 
ambiente de desenvolvimento de software é amplificar o aprendizado. 
O processo de aprendizado é acelerado pelo uso de ciclos curtos de ite-
ração - cada um deles associado a testes de refatoração e integração. O 
aumento do feedback por meio de breves sessões com os clientes ajuda a 
determinar a fase atual do desenvolvimento e a ajustar os esforços para 
melhorias futuras.
Decida o mais tarde possível: Como o desenvolvimento de software
está sempre associado a alguma incerteza, melhores resultados devem 
ser alcançados com uma abordagem baseada em opções, atrasando as 
decisões o máximo possível até que possam ser tomadas com base em 
fatos e não em suposições e previsões incertas
31
UNIDADE Introdução aos Processos de Software Ágeis
Entregue o mais rápido possível: não é o maiorque sobrevive, mas o 
mais rápido. Quanto mais cedo o produto final for entregue sem grandes 
defeitos, mais cedo o feedback poderá ser recebido e incorporado na 
próxima iteração.
Capacitar a Equipe: Equipes organizadas artificialmente - quando a es-
trutura de uma Equipe é fixada pela alta gerência com pouco conheci-
mento dos requisitos, do cliente ou das personalidades da própria Equipe 
– podem criar situações em que o pessoal é subutilizado. Na pior das 
hipóteses, os projetos falham simplesmente por causa de Equipes mal 
organizadas. Em um ambiente de desenvolvimento ágil, a Equipe tem o 
poder de se organizar de uma maneira que lhes permita ser mais eficazes 
e eficientes.
Integrar: o cliente precisa ter uma experiência geral do sistema - esta é 
a chamada integridade percebida: como está sendo anunciada, entregue, 
implementada, acessada, quão intuitivo é o seu uso, preço e quão bem 
ele resolve problemas. O fluxo de informações deve ser constante nas 
duas direções - do cliente para os desenvolvedores e vice-versa, evitando 
assim uma grande quantidade estressante de informações após um longo 
desenvolvimento isolado.
Defeitos no software tendem a se acumular durante o processo de 
desenvolvimento: decompondo as grandes tarefas em tarefas menores 
e padronizando diferentes estágios de desenvolvimento, as causas princi-
pais dos defeitos devem ser encontradas e eliminadas. (GREYCAMPUS, 
2019, p. 11-2)
PENSE DESTE JEITO
REALIZE ESTA TAREFA
APRENDA A MELHORAR
DISPONIBILIZE TUDO
Essências do 
Pensamento Enxuto
Promotores Lean
Aprendizado
Lean
Valor para o cliente
Fluxo de Valor
Eliminação de Desperdício
Melhoria Contínua
Empowerment
Suporte gerencial
Treinamento e Educação
Decisão descentralizada
Outros
A3
PDCA
UTILIZE ESTAS FERRAMENTAS
Ferramentas
Lean
VSM
Checklists
5S
Go and See
Outros
Solucionando Problemas
Método Lean
1. Identi�car o problema
 a. Aprenda a enxergar o problema
 b. Torne o problema visível
2. Entenda o problema
3. Identi�que e planeje a solução
4. Impante a solução 
5. Gerencie e melhore a solução
Figura 8 – Modelo Lean de Melhoria de Software
Fonte: SILVEIRA, et al., 2015
Mostra o modelo de melhoria Lean para a identificação das oportunidades 
de melhoria, partindo do como é necessário ser direcionado o pensamento 
até como executar as ações identificadas.
32
33
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Histórias de Usuário
https://youtu.be/sEtiCJfXTE8
3 formas de Quebrar Histórias de Usuário
https://youtu.be/OAVR9Zc5DeI
 Leitura
História do Scrum
http://bit.ly/37Q9PZj
Metodologia Scrum, o que são histórias e como elas influenciam o preço do projeto
http://bit.ly/3aOQMjT
33
UNIDADE Introdução aos Processos de Software Ágeis
Referências
AGILE ALLIANCE. Design simples. 2018. p.6 disponível em: <https://www.
agilealliance.org/glossary/simple-design/#q=~(infinite~false~filters~(postTy
pe~(~’page~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_
glossary~’aa_research_paper~’aa_video)~tags~(~’simple*20design))~searchTerm~’
~sort~false~sortDirection~’asc~page~1)>. Acesso em 09/10/2019.
AMBLER, S. W. Histórias de usuários: Uma introdução ágil. 2009. Pg 3. 
Disponível em: <http://www.agilemodeling.com/artifacts/userStory.htm>. Acesso 
em 9/8/2019.
ARAUJO, I. O que é Sprint? 2012. Disponível em: <http://blog.myscrumhalf.
com/2012/02/o-que-e-sprint-%E2%80%93-faq-scrum>. Acesso em: 20 jun. 2018.
BAIRD, S. Extreme Programming Practices in Action. 2002, p. 3. Disponível 
em: <http://www.informit.com/articles/article.aspx?p=30187&seqNum=4>. 
Acesso em: out. 2019.
BECK, K. Extreme Programming Explained: Embracing Change. Boston: 
Addison-Wesley USA 1999. 
BIDDLE, R. Metáfora de Sistema em “Programação Extrema”. Uma 
abordagem semiótica. 2004. Disponível em: <https://www.researchgate.net/
publication/228872890_System_Metaphor_in_Extreme_Programming_A_
Semiotic_Approach>. Acesso em 09/10/2019.
BLE, E. Metodologia Scrum aplicada em projetos. 2016. Disponível em: 
<https://medium.com/@Eduardo_Ble/metodologia-scrum-aplicada-em-projetos-
que-n%C3%A3o-sejam-software-1c9360904e6>. Acesso em: 20 jun. 2018.
CUNNINGHAM, W. History Of Extreme Programming. 2008. Disponível em: 
<http://wiki.c2.com/?HistoryOfExtremeProgramming>. Acesso em: 7 out. 2019.
FOWLER, M. UnitTest. 2014. Disponível em: <https://martinfowler.com/bliki/
UnitTest.html>. Acesso em: 7 out. 2019.
GREYCAMPUS. Estrutura Agile Lean. 2019. Disponível em: <https://www.
greycampus.com/opencampus/agile-certified-practitioner/agile-framework-lean>. 
Acesso em: 7 out. 2019.
HUTAGALUNG, W. Extreme Programming. 2006. Disponível em: <http://www.
umsl.edu/~sauterv/analysis/f06Papers/Hutagalung>. Acesso em: 7 out. 2019.
KANBANIZE. What Is a Kanban Board? 2018. Disponível em: <https://
kanbanize.com/kanban-resources/getting-started/what-is-kanban-board>. Acesso 
em 30 jul. out. 2019.
34
35
KOCUREK, D. Entendendo o Gráfico Brundown no SCRUM: Métodos e 
Ferramentas. 2011. Disponível em: <http://www.methodsandtools.com/archive/
scrumburndown.php>. Acesso em 8/10/2019.
KRISH, V. A Brief History of Scrum. 2012. Disponível em: <https://www.techwell.
com/techwell-insights/2012/10/brief-history-scrum>. Acesso em: 8 out. 2019.
LACEY, M. Planning Game 2018, Mitch Lacey & Associates Inc. EUA Disponível 
em: <https://www.mitchlacey.com/intro-to-agile/extreme-programming/planning-
game>. Acesso em: 7 out. 2019.
MANIUK, I. Refactoring in Extreme Programming. 2016. Disponível em: 
<https://hygger.io/blog/refactoring-in-extreme-programming>. Acesso em: 25 
maio 2019.
NESS, W. Eu poderia pedir analogias físicas ou metáforas para recursão?
2014. p 1. Disponível em: <https://stackoverflow.com/questions/46612470/could-
i-ask-for-physical-analogies-or-metaphors-for-recursion/46613542>. Acesso em 
09/10/2019.
PRESMAN, R.; MAXIM, B. R. Engenharia de Software: uma abordagem 
profissional. 8.ed. McGraw Hill Brasil, 2016. P. 72-85.
SCRUM INSTITUTE. Gráfico de Burndown Scrum. 2018. Disponível em: 
<https://www.scrum-institute.org/Burndown_Chart.php>. Acesso em: 20 jul. 2019.
SHORE, J. The Art of Agile. 2010 . Disponível em: <http://www.jamesshore.
com/Agile-Book/simple_design.html>. Acesso em: 7 out. 2019.
SILVEIRA, P. da C. T. et. al. Implantação do Pensamento Enxuto: Um Estudo de 
Caso Aplicado em Uma Grande Empresa de Software. Revista ESPACIOS, 2015. 
Venezuela - Caracas, v. 36, n. 2, p. 8. Disponível em: <http://www.revistaespacios.
com/a15v36n02/15360205.html>. Acesso em: 7 out. 2019.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. 
1986. Harvard Business Review Article. Disponível em: <https://hbr.org/1986/01/
the-new-new-product-development-game>. Acesso em: 8 out. 2019.
TELES, V. M. Práticas do XP 2006. Disponível em: <http://www.
desenvolvimentoagil.com.br/xp/praticas>. Acesso em: 7 out. 2019.
VIEIRA, D. Scrum: A Metodologia Ágil Explicada de forma Definitiva. 2014. 
MINDMASTER. Pg: 2, 4. Disponível em: <http://www.mindmaster.com.br/
scrum>. Acesso em 8/10/2019.
35