Núcleo de Educação a Distância

GESTÃO ÁGIL PROJETOS COM SCRUM

Módulo III – Práticas, Métodos e Frameworks

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Caro aluno,

Seja bem-vindo ao Módulo 3 do curso de Gestão Ágil de Projetos com SCRUM!

Por onde vamos começar?

Neste segundo módulo, falaremos sobre práticas, métodos e frameworks. Ao término deste
módulo, esperamos que você seja capaz de:

 Reduzir os desperdícios e melhorar a qualidade dos seus produtos, utilizando a

abordagem Lean.
 Reconhecer de que forma o uso do kanban pode contribuir para a melhoria dos
processos da equipe, através do aproveitamento das informações visuais.
 Entender os valores e princípios Extreme Programming e de que forma essa
metodologia pode melhorar a qualidade do software, bem como sua capacidade de
adaptação adequada às novas necessidades do cliente.
 Aplicar as práticas recomendadas pelo Feature Driven Development e reconhecer
seus processos básicos.

Bons estudos!

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

MÓDULO 3 – PRÁTICAS, MÉTODOS E FRAMEWORKS

Antes de conhecermos o framework SCRUM, vamos conhecer algumas práticas e

frameworks que também tem como base, a abordagem ágil.

Tópico 3.1 – Lean Development

A abordagem Lean defende a eliminação do desperdício e pode ser usada tanto no

desenvolvimento de novos produtos como na rotina de fabricação. Diversas empresas
utilizam este conceito para reduzir os desperdícios e melhorar a qualidade dos seus
produtos. Veja alguns exemplos de empresas que utilizam o Lean:

 Toyota – na produção, manufatura e desenvolvimento de produtos;

 Dell – na produção e manufatura;
 Zara – na cadeia de suprimentos;
 Google – no desenvolvimento de software;

Como é possível observar, os exemplos citados, tratam-se de empresas muito diferentes

que utilizam Lean em diversos segmentos.

O Lean nasceu a partir de uma metodologia de manufatura, que ganhou

popularidade por sua capacidade de ajudar as empresas a alcançarem
suas metas de uma maneira mais saudável, mais inteligente e mais
sustentável.

Ele permite que as organizações otimizem o fluxo de valor as suas entregas, melhorando a
velocidade, a qualidade e a integridade organizacional.

Essa abordagem originou-se com o Sistema Toyota de Produção, que revolucionou a

fabricação de bens físicos nos anos 50, 60, mas o termo Lean ainda não havia sido
utilizado. O Lean mantém seu domínio na manufatura, mas também encontrou novas
aplicações no trabalho do conhecimento, ajudando as empresas a eliminar o desperdício,
melhorar os processos e impulsionar a inovação.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Uma breve história do Lean

Foi em 1988 que o investigador John Krafcik utilizou pela primeira vez o conceito de “Lean
Production” para descrever o sistema de produ o da o ota mesmo termo foi utilizado
posteriormente por olmack 199 no famoso livro “ he achine hat hanged he
orld” de forma a salientar as diferen as entre o sistema de produ o da o ota o sistema
ocidental de produ o em massa e tam m da produ o artesanal voc ulo Lean surge
devido ao fato do mesmo sistema utilizar menores quantidades de tudo comparado com o
sistema de produ o em massa.

Muitas variações da abordagem Lean surgiram nos anos seguintes, incluindo o

Gerenciamento da Qualidade Total, Just-in-Time, Six Sigma e a Teoria das Restrições.
Cada um desses movimentos incorporou várias práticas do que os japoneses estavam
fazendo que os diferenciavam de sua concorrência, embora possamos afirmar com
segurança que o que eles estavam procurando agora é conhecido como Lean. Muitas
dessas estruturas populares de gest o “Lean” eram altamente prescritivas por natureza e
exigiam treinamento considerável para serem adotadas integralmente.

Em seus livros, Jim Womack e Dan Jones nos ajudaram a elevar nossa compreensão do
Lean, permitindo que passássemos de imitar as práticas da Toyota para entender
verdadeiramente os princípios que fizeram todo o sistema Toyota funcionar. Aproximar-se
do Lean como um conjunto de princípios orientadores, em vez de um conjunto específico de
práticas prescritivas, torna a implementação mais fácil, mais flexível e mais sustentável.

Hoje, as organizações estão buscando transformar a maneira como trabalham aplicando os

princípios do Lean, especificamente: melhoria contínua e respeito pelas pessoas.

Principais características do pensamento Lean

pensamento Lean caracteriza-se por ser uma filosofia de lideran a e gest o que tem por
o etivo a identifica o e redu o gradual do desperd cio presente em toda a organiza o
criando valor para todas as partes interessadas conseguido atrav s do desenvolvimento de
pessoas, processos e sistemas.

O Lean centra o seu principal foco nas pessoas, pois estas s o o elemento essencial numa
produ o e com o qual est relacionado o sucesso ou insucesso da mesma o os
oper rios que melhor conhecem cada etapa dos processos, o que faz com que sejam os
melhores a solucionarem qualquer problema que possa surgir. O objetivo conseguir
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

entregar ao cliente um produto ou servi o com a maior qualidade poss vel tendo um maior
valor incorporado sem haver a necessidade de perda por parte de qualquer outra entidade
ligada direta ou indiretamente atividade. O segredo reside no fato de que todo o valor que
acrescentado ao produto prov m da elimina o de tudo o que n o traz valor ao mesmo o
desperd cio.

Redução do
Desperdício

Redução dos
Redução do
tempos de
inventário
entrega

Benefícios

Melhor
Redução do
compreensão
Retrabalho
do processo

Melhoria na
rentabilidade

Os Pilares do Lean:

Melhoria Contínua e Respeito pelas Pessoas

Os dois pilares do Lean são a melhoria contínua e o respeito pelas pessoas. Quando esses
princípios são usados corretamente, as tomadas de decisão são mais inteligentes e
orientam as organizações a se tornarem sistemas mais produtivos e mais saudáveis.

Melhoria continua

A melhoria contínua é um método para identificar oportunidades de simplificar o trabalho e

reduzir o desperdício, a fim de melhorar a velocidade e a qualidade da entrega de valor.
Trabalhar para melhorar constantemente é a melhor maneira de reduzir o desperdício em
qualquer organização. Exemplos de desperdício conhecidos no trabalho são: tempos de

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

espera entre as etapas de um processo, alternação de tarefas, retrabalho e planejamento

excessivo. A eliminação desses tipos de resíduos por meio da melhoria contínua permite
que as organizações trabalhem com mais eficiência, reduzindo o desperdício de tempo e
esforço e, ao mesmo tempo, melhorando a velocidade da entrega de valor.

Melhoria contínua está enraizada em um compromisso com a aprendizagem.

Tradicionalmente, o Lean era sinônimo de corte: custos, desperdício, pessoas, etc. O Lean
de hoje foca em agregar valor, em vez de remover o desperdício. Eis o motivo:
concentrando-nos apenas em atividades que agregam valor, criamos sistemas que
produzem valor e, ao fazer isso, removemos práticas inúteis de nossos sistemas. Se nos
concentrarmos apenas no corte de resíduos, poderemos estar subotimizando o todo, sem
realmente beneficiar o cliente.

Simplificação Produtiva

A palavra “racionaliza o” pode ser entendida como ideia de demissões ou outras formas
dolorosas de redução de custos que são prejudiciais à saúde organizacional. Não é assim
que a simplificação é operacionalizada em organizações realmente Lean - simplificar em
melhoria contínua simplesmente se refere à maneira como as equipes trabalham juntas para
identificar formas de melhorar sua entrega de valor. Isto é distintamente diferente dos
tradicionais esforços de racionalização de cima para baixo vistos na fabricação Lean
décadas atrás. A melhoria contínua no Lean incentiva a racionalização produtiva de
processos e práticas, não pessoas, para melhorar a velocidade da entrega de valor.

O Ciclo de Melhoria Contínua

Embora empregado de maneira diferente nas organizações, esse ciclo de melhoria contínua
delineia as etapas básicas do processo de melhoria contínua: identificar, planejar, executar,
revisar.

Melhoria contínua no Lean é semelhante ao método científico, em que cada decisão é vista
como uma hipótese a ser testada. Usando esse método, quando se deparam com uma nova
oportunidade, as equipes trabalham para identificar uma hipótese, planejar uma solução,
implementar as mudanças e depois medir os resultados. A etapa final - revisão - é
fundamental para o processo de melhoria contínua. Sem uma maneira de medir e refletir
sobre o impacto de nossas decisões, não podemos melhorar continuamente.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Recentemente eu li o livro “A eta” de Eli ahu Goldratt Neste livro ele constrói a teoria das
restrições através do pensamento Lean. É um livro de leitura simples e nos dá a visão
perfeita sobre os desperdícios.

IDENTIFICAR
Oportunidades
no processo

REVISAR
Como foi a
O ciclo de PLANEJAR
Como melhorar
mudança para a
equipe?
melhoria o processo?

contínua

EXECUTAR
Implementar as
mudanças

Respeito pelas Pessoas

O respeito pelas pessoas é o segundo pilar do Lean. Esse pilar parte do pressuposto que
respeitar as pessoas é uma estratégia fundamental para eliminar o desperdício. As
organizações enxutas praticam o respeito pelas pessoas em todas as partes do fluxo de
valor.

Respeito pelos clientes: foco incansável na entrega de valor

As organizações Lean respeitam seus clientes limitando o desperdício, com o desperdício

definido como qualquer coisa que o cliente não queira pagar em uma fatura detalhada. Isso
significa não desperdiçar o tempo do cliente em um produto, serviço ou recurso que não
atende às necessidades dele. Isso também significa que os processos são continuamente
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

aprimorados para reduzir a ineficiência. Um processo ruim desperdiça esforços e recursos

em coisas que não beneficiam diretamente o cliente. As organizações lean respeitam seus
clientes concentrando esforços na melhoria dos processos para maximizar a entrega de
valor.

Significa também escutar a voz do cliente: em vez de confiar em palpites informados sobre
problemas do cliente, as organizações Lean respeitam os clientes fazendo um diálogo
significativo sobre como melhorar seus produtos e serviços para melhor atender às
necessidades dos clientes.

Respeito pelos funcionários: autonomia, domínio, propósito

Organizações Lean respeitam seus funcionários capacitando-as a serem solucionadores de

problemas e tomadores de decisão, dando-lhes autonomia, domínio e propósito para atuar
em alto nível.

Líderes Lean demonstram respeito por seus funcionários, fornecendo liderança clara, leve e
orientada. Isso ajuda os funcionários a manter o foco no fornecimento de valor ao cliente.

Respeitar os funcionários, por sua vez, ajuda as organizações Lean a demonstrar respeito
por seus clientes, porque tem como alvo o desperdício que o Lean pretende eliminar: as
camadas de despesas gerais entre o cliente e as pessoas que estão produzindo diretamente
o produto para esse cliente. Ao remover essa sobrecarga, podemos produzir produtos
melhores, a um custo menor, de maneira mais sustentável.

Respeito nas equipes: pensamento sistêmico e foco no processo

As equipes praticam o respeito pelas pessoas pensando e operando como um sistema.

As equipes enxutas trabalham para otimizar o sistema, visualizando e distribuindo o trabalho

de qualquer maneira que agregue valor ao cliente da maneira mais rápida e sustentável.
Eles demonstram respeito uns pelos outros, colaborando e distribuindo uniformemente o
trabalho em toda a equipe. Desencorajam o heroísmo ineficiente e insustentável ao limitar o
Work in Process (WIP) nos níveis de equipe e individual. Eles gerenciam o trabalho como
um sistema e não como um grupo de indivíduos, priorizando a entrega de valor a cada
decisão que tomam.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Um exemplo de pensamento sistêmico: Lean incentiva as equipes a documentar

processos eficazes, para que qualquer pessoa da equipe possa repeti-los. Isso permite que
a equipe trabalhe com mais rapidez, ensinando novas habilidades aos colegas de trabalho
em vez de depender muito de alguns funcionários especializados.

As equipes enxutas também praticam o respeito pelas pessoas mantendo o foco no

processo: em vez de apontar os dedos quando surge um problema, as equipes enxutas
demonstram respeito concentrando-se em melhorar o processo. A criação de qualidade no
sistema, através do desenvolvimento e otimização de processos padrão, permite que a
equipe se mova mais rapidamente e com melhor qualidade de trabalho.

Os sete princípios do Lean

1- Otimize o todo
Cada empresa representa um fluxo de valor - a sequência de atividades necessárias para
projetar, produzir e entregar um produto ou serviço aos clientes. Se nosso objetivo é
entregar o máximo de valor aos nossos clientes o mais rápido possível, temos que otimizar
nossos fluxos de valor para podermos fazer exatamente isso. Para entender como otimizar
nossos fluxos de valor, primeiro precisamos identificá-los corretamente.

 e a para cima:
 edidas no n vel mais alto que direcionam para o comportamento correto;
 edidas em n vel de time n o de indiv duos.

Cada empresa representa um fluxo de valor - a sequencia de atividades necessárias para

projetar, produzir e entregar um produto ou serviço aos clientes. Se nosso objetivo é
entregar o máximo de valor aos nossos clientes o mais rápido possível, temos que otimizar
nossos fluxos de valor para podermos fazer exatamente isso. Para entender como otimizar
nossos fluxos de valor, primeiro precisamos identificá-los corretamente.

2- Eliminar desperdício
Desperdício é:
 .
Para enxergar
cliente: Lucro = Valor do produto - Custo.
 .
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

 .
 r algo errado ou fazer errado algo.

 Trabalho parcialmente feito.

 Processos extras.
 Funcionalidades extras.
 Alternação de tarefas ou multitarefas.
 Espera.
 Esforços de comunicação.
 Defeitos.

Exemplos:
 ;
 ;
 Bugs;
 ;
 .

O pensamento enxuto estimula essa definição de desperdício: se seu cliente não pagasse
por ele, seria um desperdício. Desperdício, no trabalho de conhecimento, pode ser qualquer
coisa, desde troca de contexto, até muito trabalho em andamento, passando pelo tempo
gasto manualmente na conclusão de uma tarefa que pode ser automatizada.

3- Construa qualidade no processo

-- Shigeo Shingo.

À medida que as empresas crescem, as limitações dos sistemas internos se expõem. As

empresas lean se preparam para o crescimento sustentável praticando o princípio Lean de
Building Quality In. O conceito é bem simples: automatize e padronize qualquer processo
tedioso e repetitivo ou qualquer processo que seja propenso a erros humanos. Isso permite
que as empresas Lean protejam por erros partes significativas de seus fluxos de valor, para
que possam concentrar sua energia na criação de valor para seus clientes.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

4- Entregar rápido

Quando um trabalho chega ao seu cliente, é valioso. Até então, não é. O princípio Lean de
fornecimento rápido pelo gerenciamento do fluxo baseia-se na ideia de que quanto mais
rápido pudermos fornecer itens de valor a nossos clientes, mais cedo começaremos a
aprender com o feedback dos clientes. Quanto mais aprendemos com nossos clientes,
melhor conseguimos dar exatamente o que eles querem. Para oferecer rapidez, temos que
gerenciar o fluxo - limitando o trabalho em andamento e mantendo um foco implacável na
entrega de valor.

5- Crie conhecimento

O princípio Lean de Criar Conhecimento está relacionado ao conceito de Otimização do

Todo. Uma organização Lean é uma organização que aprende - cresce e se desenvolve
através da análise dos resultados de pequenos experimentos incrementais. Para reter essa
informação como uma organização, o aprendizado deve ser compartilhado. O princípio Lean
de Criar Conhecimento diz que as organizações Lean devem fornecer a infraestrutura para
documentar e reter adequadamente o aprendizado valioso.

6- Adiar compromisso

O pensamento enxuto é derivado da filosofia de manufatura da Toyota, que enfatizava um

sistema just-in-time de gerenciamento de estoque. O princípio Lean de Defer Commitment
diz que as organizações Lean também devem funcionar como sistemas just-in-time,
esperando o mais tarde possível para tomar decisões. Isso permite que as organizações
Lean tenham agilidade para tomar decisões com as informações mais relevantes e
atualizadas disponíveis.

7 - Respeite as pessoas

O sucesso de qualquer iniciativa Lean depende de um princípio Lean: Respeite as Pessoas.

Por respeito ao cliente, tomamos decisões que lhes trarão mais valor com o mínimo de
desperdício. Por respeito aos nossos funcionários, criamos ambientes que permitem que
todos façam seu melhor trabalho. Por respeito aos nossos colaboradores, esforçamo-nos
continuamente para otimizar nossos processos, permitindo que todos ofereçam o máximo de
valor que podem oferecer.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Tópico 3.2 - Kanban

O Kanban uma palavra aponesa para indicar “sinal visual” ou “cart o”

Vamos voltar novamente à Toyota, veja que muitas descobertas com relação
ao pensamento enxuto e melhoria de produção nos leva à linha de produção
da Toyota. Trabalhadores de linha da Toyota usavam um kanban (ou seja,
um cartão visual) para sinalizar etapas em seu processo de fabricação. A natureza
altamente visual do sistema permitiu que as equipes se comunicassem mais facilmente
sobre o trabalho necessário e quando. Também padronizou sugestões e processos
refinados, o que ajudou a reduzir o desperdício e maximizar o valor.

Em um dos congressos que fui, estava conversando com um conhecido dono de uma
construtora e ele me contou uma experiência com o Kanban muito interessante. Ele queria
utilizar uma prática ágil de toda forma no seu trabalho. Em uma das suas obras, ele decidiu
implantar o quadro kanban. Depois de entender o funcionamento do kanban, a equipe da
obra passou a colocar nesse quadro o trabalho da semana. Todos os dias faziam uma
reunião rápida para informar o que haviam feito, o que estavam fazendo e os impedimentos.
O resultado é que houve um aumento na produtividade da equipe e com o entendimento
sobre as atividades que cada pessoa estava realizando, eles conseguiram otimizar o
processo. Hoje, a empresa utiliza kanban em todas as suas obras. Na minha visão, o quadro
kanban é uma excelente forma de comunicação e incentiva o comprometimento da equipe.

Como funciona o Kanban

A força de trabalho de hoje pode estar armada com smartphones e tablets dignos de retina,
mas muitas informações ainda aparecem como palavras em uma tela. E-mails, planilhas,
listas de tarefas - o texto está em todo lugar. Enquanto se ajusta à certos cenários, a
informação textual não é um veículo de comunicação universal. Sua eficácia é menor do que
você imagina. Por quê? Tudo começa com o seu cérebro.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Uma imagem vale mais que mil palavras por razões científicas: o cérebro
processa informações visuais 60.000 vezes mais rápido que o texto. 40% de
todas as fibras nervosas conectadas ao cérebro estão ligadas à retina. A
informação visual compreende 90% dos dados que chegam ao nosso cérebro, sugerindo
que nossas vias neurológicas podem até preferir imagens em vez de texto.

O Kanban ajuda você a aproveitar o poder das informações visuais usando cartões em um
quadro ranco para criar uma “imagem” do seu tra alho Ao ver como o seu tra alho flui
dentro do processo da sua equipe, você não apenas comunica o status, mas também
fornece e recebe contexto para o trabalho. Kanban pega informações que normalmente
seriam comunicadas por meio de palavras e as transforma em imagens.

Quatro Princípios Núcleos Kanban

O Kanban está ganhando força como forma de implementar com suavidade métodos de
gerenciamento ágeis e enxutos em empresas de tecnologia e não tecnologia em todo o
mundo. Ao longo dessa nova abordagem do processo de fabricação da Toyota, os principais
elementos do Kanban permaneceram enraizados nos princípios que veremos a seguir.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Como funciona o Kanban

1. Visualize o trabalho

Criando um modelo visual de seu trabalho, você pode observar o fluxo de trabalho que
passa pelo sistema Kanban. Tornar o trabalho visível - junto com bloqueadores, gargalos e
filas - leva instantaneamente ao aumento da comunicação e da colaboração.

2. Limite de trabalho em processo

Ao limitar a quantidade de trabalho inacabado que está em andamento (WIP – Work in

Progress), você pode reduzir o tempo que leva um item para percorrer o sistema Kanban.
Você também pode evitar problemas causados pela troca de tarefas e reduzir a necessidade
de priorizar constantemente os itens.

3. Concentre-se no fluxo

Usando limites de trabalho em progresso (WIP) e desenvolvendo políticas direcionadas a

equipes, você pode otimizar seu sistema Kanban para melhorar o fluxo de trabalho, coletar
métricas para analisar o fluxo e até mesmo obter indicadores líderes de problemas futuros,
analisando o fluxo de trabalhos.

4. Melhoria Contínua

Uma vez que seu sistema Kanban esteja em vigor, ele se torna a base para uma cultura de
melhoria contínua. As equipes medem sua eficácia acompanhando o fluxo, a qualidade, a
produtividade, os prazos de entrega e muito mais. Experiências e análises podem alterar o
sistema para melhorar a eficácia da equipe.

Benefícios do Kanban:

 Tempos de ciclo mais curtos podem fornecer recursos mais rapidamente;

 Capacidade de resposta à mudança: quando as prioridades mudam com muita
frequência, o Kanban é ideal;
 O balanceamento da demanda e a taxa de transferência garante que a maioria dos
recursos centrados no cliente esteja sempre sendo trabalhada;
 Requer menos alterações de configuração de organização / sala para começar;
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

 Reduzindo o desperdício e removendo atividades que não agregam valor à equipe/

departamento/ organização;
 Loops de feedback rápido melhoram as chances de membros da equipe mais motivados,
capacitados e com melhor desempenho;
 Diferentemente de algumas abordagens/ frameworks, na metodologia Kanban não
existem papéis bem definidos. As entregas são contínuas, mas não existem eventos
“ imeBoxed” (falaremos sobre isso no próximo módulo).

Quais são os limites do WIP?

Como coloquei anteriormente, WIP ou Work In Progress é o trabalho que está sendo
realizado, isto é, em um quadro kanban a equipe irá colocar somente o trabalho que está
realizando em um período pré-definido, que pode ser semanal, quinzenal ou mensal.
Lembre que a filosofia ágil é fazer entregas constantes em períodos menores, então, não é
recomendado que se tenha um período muito grande para uma entrega.

Limitar a quantidade de trabalho em andamento facilita a identificação da ineficiência no

fluxo de trabalho de uma equipe. Gargalos no pipeline de entrega de uma equipe são
claramente visíveis antes que uma situação se torne terrível.

Por que os limites do WIP são importantes?

Os limites de WIP melhoram a taxa de transferência e reduzem a quantidade de trabalho

"quase concluída", forçando a equipe a se concentrar em um conjunto menor de tarefas. Em
um nível fundamental, os limites do WIP encorajam uma cultura de "feito". Mais importante,
os limites do WIP tornam os bloqueadores e gargalos visíveis. As equipes podem se
concentrar em torno do bloqueio de questões para que sejam compreendidas,
implementadas e resolvidas quando houver um indicador claro de qual trabalho existente
está causando um gargalo. Depois que os bloqueios são removidos, o trabalho em toda a
equipe começa a fluir novamente. Esses benefícios garantem que incrementos de valor
sejam entregues aos clientes mais rapidamente, fazendo com que o WIP seja uma
ferramenta valiosa no desenvolvimento ágil.

Durante o desenvolvimento, é fácil pensar: "Ah! Vou fazer uma pausa nesta questão
enquanto começo a trabalhar em outra". Ter dois problemas em aberto significa mudar o
contexto entre duas coisas diferentes ou transferir trabalho entre colegas de equipe.
Acelerar em um problema e em outro, leva tempo e degrada o foco. É quase sempre melhor
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

trabalhar com o problema original em vez de começar - e não completar - o novo trabalho.
Em outras palavras, os limites do WIP nos desencorajam a impedir nosso próprio fluxo.

Por fim, os limites do WIP apontam áreas de ociosidade ou sobrecarga crônica. Eles ajudam
a equipe a ver ineficiências em todo o processo e não apenas na área específica em que
trabalham.

Usando limites de WIP em equipes ágeis

Ao implantar um novo fluxo de trabalho, tome uma decisão da equipe para determinar os
limites de WIP para cada status.

Limitar o WIP significa que, no seu fluxo de trabalho, em todo ou em parte dele, você terá
um número-limite de itens que poderão trafegar por ele em concorrência, constituindo assim
o que chamamos de sistema puxado. O sistema ou fluxo só irá puxar trabalho caso ele
tenha capacidade para tal, evitando assim gerar filas de trabalho concorrentes e deixando
explícitos os gargalos que existem no seu fluxo.

4 objetivos para equipes ágeis usando limites de WIP

Como qualquer nova atividade, os limites do WIP podem parecer estranhos no começo. O
objetivo aqui é otimizar a equipe no médio prazo e o constrangimento de curto prazo é
realmente uma coisa boa. Faz com que a equipe sinta alguns pontos problemáticos em seu
processo. Depois que a equipe usar seus limites de WIP por algumas semanas, faça os
ajustes necessários. Resista à tentação de aumentar o limite de WIP apenas porque a
equipe continua batendo nela. Aproveite essa oportunidade para aumentar a capacidade -
idealmente, educando a equipe e dando a cada membro novas habilidades ou tornando
algum aspecto do processo de desenvolvimento mais eficiente.

Objetivo 1 - Dimensionar tarefas individuais de forma consistente. Ao dividir requisitos

e histórias de usuários, é importante manter as tarefas individuais em no máximo 16 horas
de trabalho. Isso aumenta a capacidade da equipe de estimar com confiança e ajuda a
evitar gargalos. Nada desacelera mais um time e agrava mais os limites do WIP, como um
grande item de trabalho entupindo o pipeline.

Objetivo 2 - Mapear os limites de WIP para as habilidades da equipe. Se sua equipe

tiver especialistas, os limites de trabalho em andamento podem variar quando o especialista
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

estiver envolvido. Crie um status específico para o trabalho do especialista. Se ocorrerem

gargalos nesse status, use a oportunidade de instruir outros membros da equipe para
adicionar capacidade adicional aos conjuntos de habilidades do especialista e aumentar o
fluxo em toda a equipe.

Objetivo 3 - Reduzir a ociosidade. Quando um membro da equipe tiver algum tempo de

inatividade, incentive-o a ajudar outro membro da equipe. Eles contribuirão para a
produtividade geral da equipe e aprenderão algo ao longo do caminho!

Objetivo 4 - Proteger uma cultura de engenharia sustentável. Os limites de trabalho em

andamento não significam que os desenvolvedores precisem se apressar no trabalho para
evitar sobrecarga de trabalho em um determinado status. Eles são destinados a apoiar
práticas de engenharia ágeis sólidas que protegem a qualidade do produto e a integridade
da base de código.

Tópico 3.3 - XP – Extreme Programming

Extreme Programming é uma metodologia de desenvolvimento de software projetada para

melhorar a qualidade do software e sua capacidade de se adaptar adequadamente às novas
necessidades do cliente. Durante meados e final dos anos noventa, enquanto trabalhava no
Sistema de Compensação Integral da Chrysler (C3) para ajudar a gerenciar a folha de
pagamento da empresa, o engenheiro de software Ken Beck desenvolveu a metodologia
Extreme Programming. Em outubro de 1999, ele publicou Extreme Programming Explained,
detalhando todo o método para outros e pouco depois o site oficial foi lançado também.

Semelhante a outros métodos ágeis de desenvolvimento, o Extreme Programming visa

fornecer pequenas e repetidas entregas ao longo do projeto, permitindo que os membros da
equipe e os clientes examinem e revisem o progresso do projeto em todo o seu ciclo de
vida.

Valores do XP

O XP possui 5 valores que permitem com que as pessoas envolvidas no projeto possam se
direcionar por eles.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Simplicidade - Fazer o que for necessário e solicitado, mas não mais. Isso maximizará o
valor criado para o investimento feito até o momento. A equipe deverá dar pequenos passos
e mitigar as falhas conforme elas acontecem.

Comunicação - Todos fazem parte da equipe e a comunicação deve ser cara a cara
diariamente. O trabalho deve ser em equipe desde os requisitos até o código.

Feedback - A equipe deve ter o comprometimento das entregas da iteração, fornecendo

software funcional. Fazendo a demonstração mais cedo, poderá receber os feedbacks e
realizar as alterações necessárias. O processo deve estar em constante adaptação para o
projeto e não o contrário.

Respeito - Deve existir um respeito mútuo, cada membro da equipe tem o seu valor. Todos
contribuem com valor, mesmo que seja simplesmente entusiasmo. Desenvolvedores
respeitam a expertise dos clientes e vice-versa. A gerência respeita o direito da equipe de
aceitar a responsabilidade e de receber autoridade sobre o seu próprio trabalho.

Coragem - Dizer a verdade sobre o progresso e estimativas, sem desculpas. O sucesso

depende do alinhamento contínuo da equipe, mesmo que os seus membros precisem de ter
coragem para pedir ajuda.

Os princípios do XP:

 Feedback rápido;
 Presumir simplicidade;
 Mudanças incrementais;
 Abraçar mudanças.

As práticas XP:

Jogo do Planejamento (planning games) - O desenvolvimento é feito em iterações

semanais.

Frequentemente, isso assume a forma de uma reunião em um intervalo frequente e bem

definido (a cada iteração), onde a maioria do planejamento do projeto ocorre. Dentro desse

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

procedimento existe o estágio Planejamento da Iteração, onde são feitas determinações

sobre o que é necessário para iterações iminentes.

As seções do Planejamento da Release incluem:

 Fase de exploração - Geralmente, utiliza-se o planning poker para detalhar os

requisitos mais valiosos dos clientes.
 Fase de compromisso - O planejamento e os compromissos da equipe são feitos para
atender às necessidades do próximo lançamento de cronograma e entregá-lo a tempo.
 Fase de Steering - Permite que os planos previamente desenvolvidos sejam ajustados
com base nas necessidades em evolução do projeto, semelhante a muitas outras
metodologias do Agile Model.

XP - Pequenas Versões (small releases): liberação de pequenas versões funcionais do

projeto.

Este conceito garante que o projeto contenha pequenos lançamentos repetidos e

frequentes, permitindo que o cliente também, como todos os membros da equipe, tenha
uma noção de como o projeto está se desenvolvendo.

Metáfora (Metaphor) - Facilitar a comunicação com o cliente se adaptando a realidade dele.

A metáfora é a ideia de que cada pessoa na equipe deve ser capaz de examinar a descrição
da entrega de alto nível e ter uma compreensão clara de qual funcionalidade esta entrega
está desempenhando.

Time Coeso (whole team) - Equipe de desenvolvimento formada pelo cliente e pela equipe.
Extreme Programming promove a inclusão de clientes em todo o processo, usando seus
comentários para ajudar a moldar o projeto em todos os momentos.

Ritmo sustentável (sustainable pace) - Trabalhar com qualidade, buscando ter ritmo de
trabalho saudável, sem horas extras.

Um conceito-chave para um melhor equilíbrio entre trabalho e vida pessoal com a equipe do
projeto. Ninguém deve ser obrigado a trabalhar além da semana normal de trabalho
programada As horas extras s o desaprovadas assim como o conceito de “tempo crunch”
em que os desenvolvedores devem trabalhar horas extremas perto do final de um
lançamento para que tudo seja concluído no prazo.
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Propriedade Coletiva (Collective Code Ownership) - O código fonte não tem dono. Essa
prática permite que qualquer desenvolvedor em toda a equipe altere qualquer seção do
código, conforme necessário. Embora essa prática possa parecer perigosa para alguns, ela
acelera o tempo de desenvolvimento e qualquer problema em potencial pode ser reprimido
com o teste de unidade adequado.

Teste de Aceitação (customer tests) - Testes construídos pelo cliente em conjunto de

analistas e testadores.

Reuniões de pé - Reuniões rápidas para que a equipe informe as atividades que já realizou,
quais estão em andamento e quais os impedimentos.

Programação em par (pair programming) - Em essência, a programação em par significa

que duas pessoas trabalham em conjunto no mesmo sistema ao desenvolver qualquer
código de produção. Ao alternar frequentemente os parceiros em toda a equipe, Extreme
Programming promove melhor comunicação e formação de equipes.

Refatoração (refactoring) - Melhoria contínua da programação. Outra prática muito

comum, a ideia por trás da refatoração de código é simplesmente melhorar e redesenhar a
estrutura do código já existente, sem modificar seu comportamento fundamental. Exemplos
simples de refatoração incluem a correção incorreta de variáveis ou métodos de nomes e a
redução do código repetido para um único método ou função.

TDD (test driven development) - Primeiro crie os testes automatizados e depois crie o
código para que os testes funcionem.

O núcleo do ciclo de desenvolvimento orientado à testes gira em torno de cinco etapas

simples, que são repetidas ao longo do ciclo de vida de desenvolvimento do produto. O
objetivo dessas etapas (e de todo o desenvolvimento orientado a testes em geral) é garantir
que o código seja simples e eficiente, enquanto cumpre todos os requisitos de negócios
funcionais.

1. Escreva um teste

Como o desenvolvimento é conduzido por testes, o primeiro passo óbvio é criar um novo
teste. Esse teste deve ser o mais sucinto e simples possível, testando um aspecto ou
componente muito específico de um recurso maior. Por exemplo, se você estiver criando um
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

recurso de registro de usuário, poderá criar um único teste que englobe todos os aspectos
do registro, da geração dos elementos do formulário à entrada do usuário, à conexão do
banco de dados, aos modelos de dados e assim por diante. No entanto, seria bastante difícil
criar um teste único que englobe todos esses aspectos, sem falar de um que o faça de
forma eficiente e eficaz desde o início.

Em vez disso, o desenvolvimento orientado à testes incentiva você a escrever o menor teste
possível, necessário para atender às necessidades do recurso desenvolvido ativamente.
Com o tempo, muitos testes são criados, até que existam testes suficientes para cobrir todos
os aspectos da funcionalidade muito maior.

Assim, um único teste relacionado ao recurso de registro do usuário pode ser algo tão
simples como: “o campo de e-mail n o est em ranco” Assim, nosso primeiro teste pode
ser intitulado “o campo de e-mail n o est em ranco” e seu objetivo é simplesmente testar
se o campo de e-mail não está vazio quando o formulário é enviado.

2. Confirme se o teste falhar

Depois que o teste é criado, a próxima etapa é confirmar se o teste falha. Todo o propósito
da metodologia de desenvolvimento orientada à testes é forçá-lo a pensar sobre os
requisitos de um recurso ou uma seção de código, de modo que um teste criado não seja
necessário apenas para confirmar quando a funcionalidade está finalmente funcionando
como esperado, mas também que o teste falhará antes de implementar o dito recurso. Ao
confirmar que o novo teste falha - e o faz pela(s) razão(ões) que você espera - você pode ter
certeza de que o teste é útil e será benéfico quando você escrever o código necessário para
passar no teste.

3. Escreva o código para passar no teste

Depois de confirmar que o teste falha, você agora deve escrever o código que permitirá que
o teste seja aprovado. Uma ideia chave aqui é que você não deve escrever nenhum código
adicional ou irrelevante que vá além do escopo do teste. Assim como nos concentramos em
criar o teste mais simples possível no Passo 1, aqui queremos escrever o código mais
simples possível que permita que nosso teste seja aprovado.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

O código escrito aqui provavelmente será áspero e não finalizado, mas tudo bem. Todo o
processo de desenvolvimento orientado a testes incentiva a refatoração constante, o que
significa que seu código atual provavelmente mudará inúmeras vezes no futuro.

4. Confirme os Passes de Teste

Depois que seu novo código for escrito, confirme se o teste já passou. Em nosso caso de
exemplo, confirmamos que enviar nosso formulário de registro com um campo de e-mail em
branco faz com que nosso teste falhe, enquanto a inserção de texto no campo de e-mail
permite que o teste seja aprovado. Acredite ou não, isso é tudo para o processo de
desenvolvimento baseado em testes básicos.

5. Refatore

Durante o quinto passo, mesmo que você tenha agora um teste, o processo de escrever o
código necessário para permitir que o teste seja aprovado pode ter introduzido algumas
duplicações ou inconsistências. Isso é perfeitamente normal e esperado, mas a importância
da etapa de refatoração é reservar um tempo para localizar essas áreas problemáticas e
focar na simplificação da base de código.

Esse processo também deve incluir a repetição frequente de todos os testes anteriores, para
confirmar que você não introduziu acidentalmente nenhum bug adicional ou alterou algo que
agora causa falha no teste que passou anteriormente. A maioria dos desenvolvedores
conhece essa prática como um teste de regressão, confirmando que o código funcional não
é interrompido devido a novas alterações.

Integração contínua (continuous integration) - Sempre que produzir uma nova

funcionalidade, nunca espere uma semana para integrar à versão atual do Sistema. A ideia
por trás da integração contínua é que todo o código desenvolvido em toda a equipe é
mesclado em um repositório comum várias vezes ao dia. Isso garante que quaisquer
problemas com a integração em todo o projeto sejam percebidos e tratados o mais rápido
possível.

Code standards (código padronizado) - O padrão de codificação é simplesmente um

conjunto de práticas recomendadas dentro do próprio código, como formatação e estilo, que
toda a equipe segue durante todo o ciclo de vida do projeto. Isso promove melhor

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

compreensão e legibilidade do código não apenas para os membros atuais, mas também
para futuros desenvolvedores.

Design simples - Concentrando-se em manter o design simples, mas adequado, as

equipes XP podem desenvolver código rapidamente e adaptá-lo conforme necessário. Há
poucas razões para complicar as coisas sempre que uma opção mais simples estiver
disponível. Essa prática básica de manter todos os componentes e códigos tão simples
quanto possível garante que toda a equipe esteja sempre avaliando se as coisas poderiam
ser feitas de maneira mais fácil.

Papéis

Coach
Se a equipe é nova na Extreme Programming, o papel de um Coach é crucial. As
responsabilidades do coach são:

 Entender, em profundidade, a aplicação da Extreme Programming no projeto;

 Identificar as práticas de Extreme Programming que ajudam no caso de qualquer
problema;
 Permanecer calmo mesmo quando todos os outros estiverem em pânico;
 Observar a equipe silenciosamente e intervir apenas quando um problema significativo
for previsto e fazer a equipe também ver o problema;
 Ver que a equipe é autossuficiente;
 Estar pronto para ajudar.

Cliente
Em Extreme Programming, a função do cliente é tão crucial quanto a função de
desenvolvedor, pois é o cliente quem deve saber o que programar, enquanto o
desenvolvedor deve saber programar. Isso desencadeia a necessidade de certas
habilidades para o papel do cliente:

 Definir as histórias exigidas para o detalhe necessário e suficiente;

 Desenvolver uma atitude para o sucesso do projeto;
 Influenciar um projeto sem poder controlá-lo;
 Tomar decisões que são necessárias de tempos em tempos sobre a extensão da
funcionalidade necessária;

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

 Disposto a mudar decisões conforme o produto evolui;

 Definir os testes funcionais.

Desenvolvedor
É o coração da XP, uma das principais habilidades que o programador XP deve aprender é
a programação em pares, a simplicidade e, acima de tudo, coragem.

Se alguém alterar o código que o desenvolvedor escreveu, em qualquer parte do sistema,

ele deve confiar nas mudanças e aprender. Caso as mudanças sejam equivocadas, o
desenvolvedor é responsável por melhorar as coisas, mas deve ter cuidado para não culpar
ninguém.

O desenvolvedor deve estar preparado para reconhecer seus medos. Lembrar sempre de
que faz parte de uma equipe e que a coragem é necessária para o sucesso da Extreme
Programming.

O desenvolvedor XP é responsável por definir e estimar o tamanho das histórias /

funcionalidades e as atividades ligadas a esta história, escrever os testes e os códigos que
devem passar nos testes, realizar os testes unitários, refatorar e estar sempre fazendo a
integração contínua.

Testador
O testador é o membro da equipe responsável pelo teste do produto. A qualidade do produto
final depende fortemente do seu trabalho.

Framework

Planejamento de Release - A equipe do projeto, juntamente com o cliente fazem o

planejamento da release ou versão e deve considerar neste planejamento, as atividades de
arquitetura e as ações para os riscos associados à release.

Planejamento de Iteração (feita depois que o plano da release) - Dentro da release, a

equipe irá realizar várias pequenas entregas que serão desenvolvidas em iterações.
Iterações são ciclos de atividades para realizar uma entrega, que podem durar de uma
semana até 2 meses, depende do tipo de projeto que está sendo realizado. Quanto menor a
iteração, melhor será para a equipe que a partir das entregas, já poderá receber os

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

feedbacks do cliente quanto à qualidade da entrega e, fazer os ajustes necessários para as

próximas entregas.

Durante o planejamento da iteração, o cliente irá explicar a funcionalidade e as atividades

relacionadas a esta funcionalidade serão definidas. Para definir essas atividades, a equipe
poderá usar as práticas de metáfora e design simples. A saída deste planejamento é o plano
da iteração, que será executado logo em seguida, dentro do prazo estipulado para as
entregas do projeto.

Tópico 3.4 - FDD | Feature Driven Development

Desenvolvimento Orientado a Funcionalidades

O Feature Driven Development (FDD) é uma metodologia de desenvolvimento orientada à

funcionalidades, é um processo de produção altamente orientado para a obtenção de
pequenas funcionalidades valiosas para o cliente. Isso leva os desenvolvedores a criar
recursos de trabalho uma vez a cada duas semanas podendo rastrear o andamento do
projeto com precisão. O FDD, que é um de vários processos de desenvolvimento ágil, é um
processo de desenvolvimento de software iterativo e incremental, com o objetivo principal de
fornecer software de trabalho repetidamente em tempo hábil.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

História

Se uma breve história for dada, o FDD foi inicialmente concebido por Jeff de Luca em 1997
para atender às necessidades específicas de um projeto de 15 meses e 50 pessoas em um
grande banco de Cingapura.

O FDD foi introduzido pela primeira vez em todo o mundo em "Java Modeling in colour with
UML" por Peter Coad, Eric Lefebver e Jeff De Luca.

Oito práticas recomendadas pelo FDD:

1. Equipes exploram o ambiente de negócio do problema a ser solucionado;
2. Desenvolvimento por funcionalidades (feature) com entregas curtas;
3. Propriedade individual do código;
4. Equipes montadas por funcionalidade;
5. Inspeção para garantia de qualidade;
6. Gerenciamento de configuração;
7. Compilação frequente;
8. Visibilidade de progresso e resultado.

Os cinco processos básicos:

1. Desenvolver o Modelo Geral;
2. Construir lista de funcionalidades;
3. Planejar por funcionalidade;
4. Design por funcionalidade e;
5. Construir pela funcionalidade.

1. Desenvolver o Modelo Geral

A equipe de modelagem inclui membros de desenvolvimento, especialistas em domínio e os

principais programadores. Os membros do desenvolvimento são guiados por um arquiteto
chefe experiente. Inicialmente, um passo a passo de alto nível é feito, seguido por uma
detalhada passagem que dá uma visão geral do domínio.

Resultado:
• Diagramas de classes com m todos e atri utos identificados;
• Diagramas de sequência.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

2. Construir lista de funcionalidades

A equipe precisa identificar as funcionalidades que são funções aproximadas expressas

em termos com valor de cliente usando este modelo de nomenclatura:
<ação> <resultado> <objeto>

Por exemplo: calcule a quantidade total vendida por um ponto de venda.

Uma funcionalidade não levará mais de duas semanas para ser concluída. Quando uma
etapa de atividade comercial parece maior que duas semanas, a etapa é dividida em etapas
menores que se tornam funcionalidades menores.

Resultado:
• Lista de funcionalidades;
• Uma lista de reas de assunto e listar as atividades de negócios correspondentes.

3. Planejar por funcionalidade

A equipe do projeto planeja a ordem de implementação das funcionalidades. É decidido

considerando as dependências entre ela, disponibilidade da equipe de desenvolvimento e
também na complexidade das funcionalidades a serem implementadas.

Resultado:
• Atividades de negócios com datas de conclus o;
• Desenvolvedores designados para atividades de negócios;
• Áreas de assunto com datas de conclus o;
• A lista de classes e as responsa ilidades.

4. Design por funcionalidade

As funcionalidades que precisam ser desenvolvidas podem ser atribuídas ao desenvolvedor

líder. O Chief Programmer seleciona as funcionalidades para desenvolvimento a partir dos
recursos designados. Ele pode escolher várias funcionalidades que usam as mesmas
classes.

Resultado:

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

• Pacote de Design inspecionado com sucesso (o pacote de projeto inclui um documento

que integra e descreve o pacote de design).

5. Construir por funcionalidade

Os proprietários da classe de desenvolvimento implementam os itens necessários para que

sua classe ofereça suporte ao design da funcionalidade. Uma vez que o código é
desenvolvido, realizar testes unitários e inspeção de código.

Resultado:
 Código realizado com sucesso/ ou métodos inspecionados.

Uso de FDD

 Ideal para sistemas em que seus negócios mudam tão rapidamente e para projetos de
longo prazo;
 Para projetos de webdesign e desenvolvimento;
 Para construir e projetar software;
 Para empresas que usam soluções do ALM (gerenciamento de ciclo de vida do
aplicativo).

SCRUM

SCRUM é também um framework com valores, princípios, papéis e responsabilidades e

artefatos que iremos ver no próximo módulo de forma mais detalhada.

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251
Núcleo de Educação a Distância

Chegamos ao final do Módulo 3!

Nesse módulo falamos sobre as principais abordagens ágeis. Veja que as práticas são
muito parecidas e o objetivo de todas elas é evitar o desperdício, entregar valor e acima de
tudo, valorizar as pessoas.

Quais são os próximos passos?

Retorne à sala virtual, participe do Fórum de Interação e responda as questões propostas na

Atividade Avaliativa da Etapa II.

Até o próximo módulo! Bons estudos!

Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251