Aula 3: Lean, KanBan e eXtreme Programming ............................................................................

2
Introduo ............................................................................................................................. 2
Contedo................................................................................................................................ 3
Desenvolvimento de software enxuto .......................................................................... 3
Conceitos do Lean............................................................................................................. 3
KanBan ................................................................................................................................. 5
Utilidades do quadro KanBan .......................................................................................... 6
eXtreming Programming.................................................................................................. 7
Feedback.............................................................................................................................. 8
Coragem .............................................................................................................................. 8
Simplicidade e propriedade coletiva do cdigo .......................................................... 8
Programao pareada....................................................................................................... 9
Testes automatizados e refatorao.............................................................................. 9
Funes dos testes automatizados .............................................................................. 10
Atividade proposta .......................................................................................................... 10
Referncias........................................................................................................................... 11
Exerccios de fixao ......................................................................................................... 11
Chaves de resposta ..................................................................................................................... 13
Aula 3 ..................................................................................................................................... 13
Exerccios de fixao ....................................................................................................... 13

GERENCIAMENTO DE PROJETOS 1
Introduo
Com o gerenciamento de projetos, muito se fez necessrio encontrar
mecanismos que auxiliassem a exercer as tarefas pertinentes a essa rea. Por
isso, foram desenvolvidas uma srie de programas e formas de trabalho que
torna mais simples as prticas de gerenciamento. Esses programas e tcnicas
criados podem ser aplicados tanto no mbito pessoal quanto no coletivo.

Objetivo:
1. Conhecer o Lean, KanBan, eXtreme Programming e suas filosofias para
auxiliar no gerenciamento de projetos.

GERENCIAMENTO DE PROJETOS 2
Contedo
Desenvolvimento de software enxuto
O Lean no especificamente uma metodologia gil, porm muitos de seus
valores esto presentes em valores geis e sua adoo pode agregar muitos
valores em diversas outras metodologias e boas prticas. Baseado na
metodologia desenvolvida pela Toyota conhecida como Lean Manufacturing.

O Lean est diretamente ligado reduo do desperdcio. Para o Lean,

desperdcio tudo que no feito para o cliente, e no caso dos softwares
podemos ter: espera (tempo de desenvolvimento parado por falta de
informaes), documentao excessiva, funcionalidades e rotinas no
solicitadas pelo cliente.

Conceitos do Lean
O Lean Software Development identifica sete conceitos principais, so eles:

Eliminar o desperdcio: Para maximizar o valor, precisamos minimizar o

desperdcio. O Lean classifica o desperdcio em 3 categorias:

MURA: Desperdcio gerado por antecipar possveis necessidades do cliente

(desenvolver o que no foi solicitado pelo cliente acreditando que um dia
poder ser til. Esse conceito est muito prximo ao de Gold Plating, do
gerenciamento de projetos). Podemos diminuir a MURA evitando desenvolver o
que no foi solicitado e evitando paradas em trabalhos ainda no terminados;
MURI: Desperdcio gerado pela falta de planejamento (ou planejamento
malfeito). Na MURI tambm classificamos o desperdcio causado pelo excesso
de burocracia; MUDA: Desperdcio gerado pela cultura de trabalho,
desperdcios do dia a dia, como: espera, superprocessamento, defeitos,
locomoo, inventrio, transporte desnecessrio e superproduo.

Empoderar o time: Em vez da abordagem de microgesto, devemos

respeitar o conhecimento superior dos membros do time e deixar que eles

GERENCIAMENTO DE PROJETOS 3
sejam responsveis pelas decises tcnicas (locais) necessrias, para tornarem-
se mais produtivos e bem-sucedidos, aumentando as chances de sucesso do
projeto.

Entregar rapidamente: Podemos aumentar o Retorno sobre Investimento

(return on investment) ROI com entregas de valor rpidas. Com entregas
rpidas e frequentes o cliente j pode iniciar o uso do software (das
funcionalidades j desenvolvidas) gerando valor mais rapidamente para o
investimento realizado no desenvolvimento. Como o cliente prioriza o que deve
ser feito primeiro, funcionalidades mais importantes (e as de maior risco,
assunto que ser tratado mais adiante) geralmente so produzidas mais cedo, e
consequentemente, entram em uso mais cedo, gerando maior retorno.

Otimizar o todo: Para o Lean o sistema no apenas a soma de suas partes,

devemos observar alm de cada parte e como todas esto alinhadas aos
interesses de negcio da empresa e como otimiz-las da melhor forma possvel.

Construir com qualidade: O Lean no testa a qualidade no final do processo.

A qualidade do produto final deve ser assegurada com a qualidade de cada
etapa/parte do processo utilizando tcnicas como refatorao, integrao
contnua e muitas outras que veremos mais adiante.

Adiar decises: Parece estranho esse conceito, mas, a mensagem aqui

equilibrar o planejamento antecipado com a tomada de decises e decidir o
mais tarde possvel. Veja que no se est defendendo a procrastinao, mas
sim esperar o mximo possvel antes de decidir. Em muitos projetos na fase
inicial estamos decidindo baseado em vrias premissas (lembrando, premissa -
eventos incertos que para fins de planejamento consideramos como
verdadeiros, o que na execuo do projeto no necessariamente ser
verdadeira), o que sempre traz riscos ao projeto, como estar restrito a uma
soluo limitada por uma tecnologia disponvel at o momento.

GERENCIAMENTO DE PROJETOS 4
Amplificar aprendizagem: Esse conceito envolve facilitar a comunicao
cedo e sempre, promovendo o feedback o mais rpido possvel, e aprendizado
contnuo com base no que aprendemos sobre projetos, softwares e negcios.

KanBan
Antes de iniciarmos o tpico sobre o KanBan, conhea uma histria sobre os
jardins do palcio imperial Japons. Em Abril, centenas de visitantes vo aos
jardins do palcio para apreciarem as flores de Sakura (flor de cerejeira). Como
os jardins, apesar de grandes, so limitados fisicamente, existe um controle de
cartes de entrada e sada. Um visitante, para entrar nos jardins, precisa de um
carto, esse carto retirado na entrada e devolvido na sada. Um novo
visitante s entra se tiver cartes disponveis. O que esse carto controla? O
nmero de atividades (pessoas) que os jardins so capazes de atender. Um
controle simples e eficiente garante o atendimento sem prejudicar a qualidade
do servio.

O KanBan possui a mesma filosofia dos cartes, uma ferramenta visual que
auxilia o acompanhamento do fluxo de trabalho e controle do WIP (Work in
progress, Trabalho em progresso).

O quadro KanBan permite visualizar o trabalho que est em andamento e

limitar o WIP. Tradicionalmente (mas no uma regra), o quadro KanBan
dividido em quadros ou status como Do (A Fazer) Doing (Fazendo) Done
(Feito), as tarefas que preciso ser realizadas so listadas (ou coladas) na
parte A Fazer, quando elas comeam a ser feitas, elas mudam para o status
Fazendo e quando esto (totalmente) prontas, vo para o status Feito. Os
status podem ser completamente diferentes, por exemplo, no caso de

GERENCIAMENTO DE PROJETOS 5
desenvolvimento de software poderamos ter Modelado, Em Desenvolvimento,
Desenvolvido, Em Implantao, Pronto. Ou qualquer outro estado que faa
sentido para o trabalho e para a equipe.

Exemplo de quadro KanBan com tarefas em andamento.

Utilidades do quadro KanBan

O Quadro KanBan possui quatro caractersticas que se agregam execuo do
trabalho. Observe:

Visualizar o fluxo de trabalho

O quadro KanBan uma excelente ferramenta Low-Tech, High Touch.

Quando inserimos a tarefa (ou funcionalidade) no quadro, tornamos o trabalho
tangvel, o que um desafio para gerentes de projetos de softwares e servios.
A visualizao nos permite identificar onde esto ocorrendo os gargalos no
fluxo de trabalho e assim melhorar os processos redesenhando-os ou
redimensionando a equipe em cada tarefa.

GERENCIAMENTO DE PROJETOS 6
Limitar o WIP (Trabalho em Progresso)

O trabalho, at estar pronto para o uso, custo, por exemplo, uma

funcionalidade em desenvolvimento que ainda no utilizada agrega algum
valor para a empresa? Um servio que est sendo desenhado agrega? NO! S
temos valor quando a funcionalidade ou servio podem ser utilizados pela
empresa. Uma das regras mais importantes para qualquer metodologia ou
framework gil entregar mais que iniciar.

Tornar regras e processos explcitos

Com o quadro mais fcil discutir os trabalhos que esto em andamento, que
precisaro ser feitos e como um trabalho em andamento poder impactar
outro.

Colaborao

A percepo visual do trabalho facilita o debate aberto do time sobre como

resolver atividades que esto engarrafando o fluxo, alm de dar a percepo
do todo (do conjunto de atividades feitas, fazendo e a fazer).

eXtreming Programming
Para entendermos o XP, inicialmente devemos compreender seus valores. Esses
so conceitos no tangveis que acredita-se fazer uma grande diferena na
qualidade final do produto e na motivao dos times. O primeiro deles a
Comunicao. O valor da comunicao visto dentro do time, entre seus
membros, e entre o time e o cliente. Ambos tm igual importncia.

A comunicao deve ser:

Direta;
Eficaz;
Esclarecedora.

GERENCIAMENTO DE PROJETOS 7
Feedback
um valor que engloba as relaes interpessoais, mas tambm se refere ao
feedback que o prprio cdigo do projeto devolve aos membros do time. Para
que o feedback do cdigo funcione bem, so necessrios testes automatizados
de unidade e um servidor de integrao contnua para que os testes mais
longos sejam rodados com frequncia e, se quebrarem, sinalizem uma
inconsistncia. Com o feedback o cliente pode:

Identificar erros rapidamente;

Definir prioridades.

Coragem
O XP prega que os desenvolvedores precisam ter coragem para refatorar o
cdigo em prol de melhorias em clareza e design e nada melhor para dar
coragem do que testes automatizados.

Coragem tambm apagar o cdigo, mesmo funcionalidades inteiras, no

importa o trabalho que tenha sido empregado para desenvolv-la.

Coragem para no tentar prever o futuro, mas sim focar no que realmente
necessrio no momento. XP associa a essa ideia a sigla YAGNI (you aint gonna
need it voc no vai precisar disso).

Simplicidade e propriedade coletiva do cdigo

Considere que, na mdia, o tempo de construo de um software cerca de
30% do tempo investido nele. Os outros 70% so dedicados a manuteno do
sistema. Neste tipo de cenrio, a simplicidade essencial para tornar esse
perodo maior muito agradvel.

Alm disso, comum que desenvolvedores trabalhem em partes independentes

do cdigo. A consequncia dessa abordagem que cada desenvolvedor se
sente responsvel apenas por sua parte. O ideal o sentimento de time onde

GERENCIAMENTO DE PROJETOS 8
todos so responsveis pelo cdigo. Assim, um desenvolvedor livre para
interferir em qualquer parte do cdigo sem irritar o dono do cdigo.

Programao pareada
A programao em par uma forma eficaz de reduzir a incidncia de bugs em
um sistema. Quem trabalha continuamente com programao em par se
habitua a corrigir e ter seu trabalho corrigido dezenas de vezes ao dia.

A incidncia de erros identificados pelo colega costuma ser to elevada que

surpreende quem no est acostumado ao uso da tcnica e as equipes que
trabalham em par conseguem reduzir drasticamente a insero de defeitos em
seus cdigos.

A programao em par ajuda os desenvolvedores a criarem solues mais

simples, mais rpidas de implementar e mais fceis de manter. A programao
em par tambm uma forma de fazer com que o desenvolvedor tenha mais
confiana no cdigo que produz. Observe que todas essas caractersticas fazem
com que a programao em par acelere o desenvolvimento significativamente,
embora primeira vista parea o contrrio.

Programar em par exige que as pessoas envolvidas sejam receptivas,

compreensivas umas com as outras, engajadas e, sobretudo, humildes.
necessrio aceitar que somos falveis para que possamos programar em par.
Jerry Weinberg, no livro The Psychology of Computer Programming, apresenta
o termo egoless programming, ou seja, programao sem ego.

Testes automatizados e refatorao

Um dos grandes desafios trabalhar em cdigos antigos. O XP prega a
refatorao constante. Mas, quanto maior o projeto, maior a quantidade de
cdigo no escrita por ns ou antigo, o que aumenta a insegurana de refatorar
o cdigo, impedindo a evoluo do projeto.

GERENCIAMENTO DE PROJETOS 9
Com o aumento do projeto comum que pequenas partes de cdigo mal
escrito se acumulem e, quando menos se esperar, compromete todo o projeto.
Esse conceito foi nomeado por Joe Yoder como Big Ball of Mud. A melhor
forma de evitar esse problema atravs de pequenas refatoraes constantes.

O autor Martin Fowler define refatorao como uma tcnica controlada para
reestruturar um trecho de cdigo existente, alterando sua estrutura interna sem
modificar seu comportamento externo.

Funes dos testes automatizados

O XP prega o uso extensivo de testes automatizados que descrevem o
comportamento de uma funcionalidade, preferencialmente escritos antes
mesmo do cdigo que eles testam, prtica que recebe o nome de
desenvolvimento dirigido por testes (test Driven Development - TDD). Os testes
automatizados tem duas funes importantes:

Permitir refatorao: Podemos refatorar o cdigo com mais segurana. Isto

, podemos alterar o cdigo e verificar automaticamente se o software continua
funcionando.

Documentar: Os testes devem ter nomes que explicam quais funcionalidades

eles testam, assim, ao executar o cdigo, o desenvolvedor sabe quais
funcionalidades foram implementadas e qual o comportamento esperado pelo
cdigo.

Atividade proposta
Nesta aula conhecemos o conceito de Programao Pareada (pair
programming) e o conceito de propriedade coletiva de cdigo. Esses conceitos
esto fortemente associados a programao sem ego. Em sua empresa voc
e sua equipe praticam esse conceito? Voc saberia identificar os maiores
desafios para a programao sem ego junto de sua equipe?

GERENCIAMENTO DE PROJETOS 10
Chave de resposta: O objetivo desta atividade que voc faa uma anlise
em sua organizao e identifique caractersticas relacionadas ao
comportamento e processos dos desenvolvedores de sistemas. Os
desenvolvedores compartilham o cdigo fonte ou trabalham em par? Veja que
j identificamos durante a aula os benefcios destas prticas que alem de
melhorar a qualidade do cdigo e compartilhar conhecimento, diminui o risco
no caso da ausncia de algum dos membros do time de desenvolvimento. Logo,
se voc no identificou em sua empresa estas caractersticas, est na hora de
comear a pratic-las.

Referncias
RIBEIRO, Rafael Dias; CUNHA, Horcio da; RIBEIRO, Sousa. Gerenciamento
de Projetos com Mtodos geis. Rio de Janeiro: [s.n.], 2015. ISBN:
9788591910212. Disponvel em: http://www.saraiva.com.br/gerenciamento-de-
projetos-com-metodos-ageis-8890292.html.

Exerccios de fixao
Questo 1
Marque a opo que NO representa um dos conceitos defendidos pelo Lean:
a) Antecipar as decises
b) Empoderar o time
c) Reduzir desperdcios
d) Amplificar a aprendizagem
e) Construir com qualidade

Questo 2
Marque a opo que NO representa desperdcio classificado como MUDA,
desperdcio gerado pela cultura de trabalho, desperdcios do dia a dia.
a) Espera
b) Superprocessamento
c) Defeitos
d) Transporte desnecessrio

GERENCIAMENTO DE PROJETOS 11
 e) Erros por falta de planejamento

Questo 3
Marque a opo que NO representa um dos benefcios do uso do KanBan:
a) Eliminar o planejamento
b) Visualizar o fluxo de trabalho
c) Limitar o WIP (trabalho em progresso)
d) Tornar regras e processos explcitos
e) Colaborao

Questo 4
Com o aumento do projeto comum que pequenas partes de cdigo mal
escrito se acumulem e, quando menos se esperar, compromete todo o projeto.
Esse conceito foi nomeado por Joe Yoder como Big Ball of Mud. uma
tcnica controlada para reestruturar um trecho de cdigo existente, alterando
sua estrutura interna sem modificar seu comportamento externo. O trecho
acima refere-se:
a) refatorao
b) A limitar o WIP (trabalho em progresso)
c) programao estruturada
d) propriedade individual de cdigo
e) Ao feedback

Questo 5
Marque V (Verdadeiro) ou F (Falso):
Quando refatoramos constantemente, nosso dbito perceptivelmente menor
do que quando refatoramos com intervalos maiores.
2. Feedback um valor que engloba as relaes interpessoais, mas tambm se
refere ao feedback que o prprio cdigo do projeto devolve aos membros do
time.
3. O XP prega que os desenvolvedores precisam ter coragem para refatorar o
cdigo em prol de melhorias em clareza e design e coragem para no tentar

GERENCIAMENTO DE PROJETOS 12
prever o futuro, mas focar no que realmente necessrio no momento. XP
associa a essa ideia a sigla YAGNI (you aint gonna need it - voc no vai
precisar disso).
a) V-V-V
b) V-F-F
c) F-V-V
d) V-F-V
e) F-F-V

Aula 3
Exerccios de fixao
Questo 1 - A
Justificativa: Adiar decises: Parece estranho esse conceito mas a mensagem
aqui equilibrar o planejamento antecipado com a tomada de decises e
decidir o mais tarde possvel. Veja que no se est defendendo a
procrastinao, mas sim esperar o mximo possvel antes de decidir. Em muitos
projetos na fase inicial estamos decidindo baseado em vrias premissas
(lembrando, premissa - eventos incertos que para fins de planejamento
consideramos como verdadeiros, o que na execuo do projeto no
necessariamente ser verdadeira), o que sempre traz riscos ao projeto, como
estar restrito a uma soluo limitada por uma tecnologia disponvel at o
momento.

Questo 2 - E
Justificativa: O desperdcio com erros por falta de planejamento tambm
combatido pelo Lean, porm classificado como MURI, desperdcio gerado pela
falta de planejamento (ou planejamento malfeito). Na MURI tambm
classificamos o desperdcio causado pelo excesso de burocracia.

GERENCIAMENTO DE PROJETOS 13
Questo 3 - A
Justificativa: O KanBan no elimina o planejamento. As atividades/itens que so
inseridos no quadro na rea que representa trabalhos no iniciados so frutos
de planejamentos prvios, o KanBan torna visuais esses itens e o fluxo de
acompanhamento at que eles estejam prontos.

Questo 4 - A
Justificativa: Questo autoexplicativa

Questo 5 - A
Justificativa: Opo correta letra A

GERENCIAMENTO DE PROJETOS 14