Este documento discute a Pirâmide Lean, um conceito que visa equilibrar práticas ágeis, princípios e valores em toda organização para promover uma mudança segura na cultura e métodos de desenvolvimento. A pirâmide foca na transformação cultural, compreensão de valores e princípios, e aplicação de princípios como entregar valor contínuo, aprendizado e melhoria contínua.

1. Informações do Artigo – v1.0
Tipo: [Engenharia de Software, Cultura organizacional]
Título: [A Pirâmide Lean]
Sub Título: [O Equilíbrio das Forças Ágeis]
Samuel Crescêncio
samuel.crescencio@oncast.com.br Twitter: @screscencio
Samuel atua como engenheiro de software construindo sistemas de missão crítica desde
1994. Fundador e CEO da OnCast Technologies - empresa que tornou-se referência na
América Latina em metodologias ágeis - Samuel adquiriu uma grande experiência em
desenvolvimento ágil distribuído, fato que tornou-o apaixonado pela melhoria de
processos. Reconhecido como um líder na comunidade internacional, Samuel foi
presidente do Ágiles2009 - a segunda edição da Conferência Latino Americana de
Métodos Ágeis e também do Pensando Lean – Forum internacional para corporações
enxutas. Samuel é membro do comitê de organização do Agile Brazil - Conferência
Brasileira de Metodologias Ágeis e também possui um assento no Board of Directors da
Agile Alliance. Samuel é Lean Software Development Practitioner desde 2003, Certified
Scrum Master e profundo conhecedor de diversas tecnologias.
A velocidade com que ocorre o desenvolvimento tecnológico nos últimos 50 anos
é certamente impressionante. Em poucos anos podemos ver tecnologias surgindo e
evoluindo muito rápido, algumas vezes se tornando padrões da indústria. Outras, porém,
desaparecem com a mesma velocidade que vieram. Esta mesma evolução pode ser
também notada nos métodos que utilizamos para desenvolver software, mas
possivelmente de uma forma não tão rápida.
Por muito tempo a indústria se ancorou em métodos que buscavam maior
previsibilidade para o desenvolvimento de software, procurando entender de antemão e

2. geralmente fixar qual seria o escopo, o custo e o prazo de desenvolvimento. Ao longo dos
anos, contudo, percebeu-se que a tão esperada previsibilidade não se provou verdadeira,
especialmente para projetos nos quais se busca o desenvolvimento científico de
tecnologias que ainda não existem. Contudo, mesmo para projetos em que a tecnologia é
de certa forma trivial, a complexidade dos negócios envolvidos torna também o processo
imprevisível. É muito comum o mercado mudar suas necessidades, ou mesmo o próprio
cliente não saber o que quer, até que comece a ver partes disso funcionando. Quando o
conhecimento sobre a tecnologia e sobre os negócios é pouco, a gestão dos projetos
torna-se muito complexa, algumas vezes gerando caos e anarquia.
Figura 1. Intersecção do conhecimento entre tecnologia e negócio
Desta forma percebeu-se que os métodos tradicionais de desenvolvimento como o
Waterfall ou mesmo o RUP eram pesados demais em termos de documentação e
hierarquia entre os indivíduos e não permitiam o grau de aprendizado necessário para que
pudéssemos simplificar o desenvolvimento de software. Assim, no final dos anos 90,
alguns autores começaram a experimentar métodos mais leves, baseados em uma maior
interação entre os indivíduos e também na entrega incremental e constante de software
funcionando, que pudesse ser utilizado pelo cliente mesmo antes de ter seu escopo
completo. Algumas vertentes surgiam e estes pesquisadores observaram semelhanças
entre os experimentos. Assim, em 2001, 17 especialistas em Engenharia de Software se
reuniram na cidade de Salt Lake City nos Estados Unidos e assinaram o que hoje
conhecemos como Manifesto Ágil para o desenvolvimento de software.

3. Nesta mesma época, algumas metodologias começaram a se consolidar e então foi
fundada a Agile Alliance, uma organização sem fins lucrativos que tem por objetivo
disseminar o uso e o desenvolvimento de todas as metodologias que compartilham dos
mesmos princípios e valores do manifesto ágil. O grande objetivo do manifesto e da
Agile Alliance é fomentar o desenvolvimento de software para permitir uma entrega de
maior valor agregado mais rapidamente, buscando uma indústria de software mais
produtiva, humana e sustentável.
Com o advento dos métodos ágeis, podemos observar uma transição da indústria
de software. Hoje, 10 anos depois do evento em Salt Lake City, já falamos que o
desenvolvimento ágil é “main stream” na indústria e que as empresas que não se
adaptarem estão possivelmente fadadas ao fracasso, seja no curto, médio ou longo prazo.
Infelizmente, hoje é muito fácil observar que diversas empresas ainda sofrem com
ambientes improdutivos, de baixíssima qualidade e, em alguns casos, desumanos. Sendo
assim, encontrar uma maneira efetiva e menos dolorosa para a adoção de métodos ágeis
tornou-se vital. Em geral, as empresas iniciam este processo de adoção com Scrum, por
tratar-se de um framework simples e de fácil utilização. Apesar de ser um framework que
permite uma melhora significativa da produtividade e da gerenciabilidade, o Scrum peca
em não trazer nenhuma orientação sobre as práticas de engenharia. Ele permitirá maior
agilidade em responder às mudanças impostas pelo mercado, mas responder a estas
mudanças pode ser traumático caso não estejamos preparados com uma base de código
sólida e que nos permita real segurança na hora de mudarmos nosso software. Como a
maioria das empresas que querem adotar métodos ágeis não tiveram o uso de boas
práticas de engenharia adotar o Scrum sem dar a devida atenção ao código pode ser
realmente doloroso.
Por este motivo, criou-se na OnCast – empresa de desenvolvimento de software e
também de serviços de conhecimento que pratica o que há de mais moderno na indústria
de software global, um conceito que visa auxiliar as empresas a equilibrar corretamente o
uso de práticas, princípios e valores em todas os níveis de uma organização, com o
objetivo de promover uma mudança segura e sustentável na cultura interna e nos métodos
de desenvolvimento. Este conceito foi batizado por Samuel de “A Pirâmide Lean”.

4. Figura 2. Pirâmide Lean
O primeiro aspecto que precisamos trabalhar quando desejamos adotar o
desenvolvimento ágil com eficácia é a transformação cultural necessária para o sucesso
da empreitada.Um caso verídico ocorreu em uma das maiores empresas de ERP do
Brasil. Lá estavam presentes cerca de 35 pessoas, incluindo o presidente e todo o
conselho de administração, juntamente com o primeiro nível de gerências. Durante o
trabalho, o presidente isse: “esse método é realmente maravilhoso e acredito que pode
resolver nossos problemas, mas não posso simplesmente baixar um decreto e esperar que
seja usado”. Com toda razão, a mudança cultural não pode ser imposta, mas precisa ser
suportada. O suporte à mudança precisa ser geral, não somente da gerência executiva,
mas também do chão de fábrica. Normalmente, a primeira reação das pessoas é a
resistência - sendo assim, imposição nunca será o melhor caminho. É preciso abrir
espaço, dar as ferramentas adequadas e criar um ambiente que seja propício à mudança.
Uma das primeiras coisas necessárias para isso é uma boa definição e um claro
entendimento dos valores e princípios que a organização segue. Os valores não servem
apenas para estar num quadro bonito na recepção da empresa. Conhecer e exercitar os
valores precisa ser uma tarefa diária de todos os membros da organização. Na OnCast,
por exemplo, não trabalha-se como uma organização hierárquica e burocrática; assim não
há regras para tudo. Por este motivo, todos os colaboradores são orientados a refletirem
quando estão tomando uma decisão. Se esta decisão fere algum valor da empresa, eles
são encorajados a procurar uma alternativa.

5. Figura 3. Valores da Oncast
Além de definir adequadamente seus próprios valores, uma organização que
deseja ser efetivamente ágil precisa também entender e trabalhar com os valores e
princípios do manifesto ágil. O Manifesto Ágil costuma ser mal interpretado,
especialmente por pessoas que nunca tiveram contato e não conhecem o que significa ser
ágil. Por este motivo, é importante também refletir sobre seus princípios.
Depois de entender bem os valores da organização, é preciso então compreender
os seus princípios. Os princípios do manifesto ágil são uma excelente base, mas os
princípios do Lean são também utilizados na Pirâmide Lean como pilares para a criação
de uma cultura que possa permear toda a organização e assim criar uma empresa
efetivamente ágil e enxuta.
Neste conceito da Pirâmide Lean, foi criado um sumário dos princípios do Lean para
que assim possamos entender de forma simplificada como eles se aplicam na
organização. Vamos a eles:
▪ Entregar um fluxo contínuo de valor para os clientes;
▪ Criar uma organização que aprende;
▪ Criar um ambiente de melhoramento contínuo.
Ter uma mente pensando de forma enxuta não é tarefa muito simples. Às vezes
parece fácil, mas geralmente as pessoas estão habituadas - ou acomodadas - e ficam
praticamente cegas para os desperdícios existentes. O mesmo ocorre com a questão do
aprendizado. Quando se fala em uma organização que aprende, não fala-se apenas em
enviar os colaboradores para treinamentos ou contratar consultores externos. Deve-se
criar um processo de trabalho onde o aprendizado esteja implícito e seja reconhecido
como fundamental para o próximo passo, a melhoria contínua. Vamos observar também
que simplesmente aprender sobre o que precisa ser melhorado não é suficiente. É preciso
ter coragem para adaptar e mudar e, acima de tudo, disciplina e iniciativa para fazer isto
continuamente.

6. Além desses princípios, não se pode deixar de frisar alguns princípios do Lean
definidos por Mary e Tom Poppendieck que são também uma base sólida para a
construção do pensamento Lean:
▪ Construir com integridade;
▪ Respeitar as pessoas;
▪ Entregar rápido;
▪ Ver o todo.
Na indústria de software existem profissionais extraordinários, mas há também
muitos deprimentes. Só há dois motivos para alguém fazer um trabalho ruim: falta de
conhecimento ou má vontade. De qualquer forma, a todos os seres humanos viventes foi
dado uma coisa igual, o tempo. O tempo é igual para todos. Por isso, devemos aproveitar
as oportunidades para fazer bem feito e com integridade absoluta tudo o que nos foi
confiado.
Integridade
Mary e Tom Poppendieck definiram dois tipos de integridade: conceitual e
percebida. Integridade conceitual é aquela que só os construtores sabem que existe.
Exemplo: os engenheiros de um avião sabem se a aeronave pode suportar certa carga de
peso, pois fizeram uma série de cálculos para isto. Já a integridade percebida é aquela que
os usuários podem notar - por exemplo, o design do avião, o acabamento das poltronas,
etc. O mesmo ocorre em software, e para que se tenha integridade, é preciso uma
comunicação efetiva, afim de criar um fluxo contínuo de informações entre os
desenvolvedores , usuários e clientes (e vice-versa).

7. Figura 4. Integridade
Respeito
Seria ótimo se pudéssemos lidar somente com a complexidade envolvida no
desenvolvimento tecnológico e no mundo dos negócios. Porém, temos também que lidar
diariamente com o organismo mais complexo que existe na Terra: o ser humano.
Respeitar as pessoas do ponto de vista do Lean não significa apenas aplicarmos o bom
senso e a boa educação que aprendemos em casa. A forma como uma equipe se organiza
para efetuar o trabalho pode influenciar profundamente no respeito às pessoas. Coisas
simples - como dar visibilidade do seu trabalho, prover e aceitar feedback, errar o quanto
antes e deixar todo mundo saber - podem ser sim exemplos de respeito. Prover respeito é
uma ação tão complexa que muitas vezes magoamos as pessoas profundamente sem
mesmo perceber. Um ambiente Lean efetivo dá espaço para que possamos aprender
abertamente sobre este tipo de problema e assim resolvê-los de uma forma adequada.
Entregar rápido
Temos duas grandes razões para entregar rápido: para que o nosso cliente não mude de
ideia enquanto estamos construindo e para que nosso concorrente não entregue antes. Em
geral, as mudanças no mercado e a velocidade com que nosso concorrente consegue
entregar irão determinar o quão rápido precisamos ser na hora da entrega. Além disto,
entregar rápido e de forma incremental nos permite feedback e aprendizado sobre o que
estamos fazendo. As experimentações de nosso produto no mercado, ainda que
inacabado, proporcionarão um desenvolvimento muito mais assertivo.
Ver o todo
Refletindo um pouco sobre o último princípio enfatizado pelos Poppendieck,
pergunta-se: quantos em sua organização conhecem o que é valor para o cliente? Quantos
conhecem o impacto de suas decisões no negócio do cliente? Se as pessoas em sua
organização não compreendem as respostas a estas questões, elas devem estar
trabalhando simplesmente porque alguém disse a elas o que devem fazer. Isto caracteriza
um sistema “empurrado” de trabalho e certamente os resultados ficam muito aquém dos
que seriam possíveis em uma organização Lean de sistema “puxado”. Por isto, no
conceito da Pirâmide Lean, as pessoas precisam enxergar e compreender o todo. Mais do
que isto, precisam contribuir para melhoria da organização como um todo. Este princípio
aplica-se também na parte técnica. Se você tem especialistas em certas partes do código e
só eles conseguem mexer lá, certamente as demais pessoas da equipe não estão vendo o
todo. Mais adiante neste artigo vamos abordar como resolver este tipo de problema.

8. Entendendo Valor e Desperdício
Se o princípio mais importante do Lean é gerar um fluxo contínuo de valor,
precisamos aprender a identificar o que é desperdício. A mente humana não foi treinada
para identificar aspectos negativos com facilidade. Há uma tendência natural do homem a
olhar para aquilo que gosta e identificar mais claramente as coisas boas do que as ruins.
Por este motivo, precisamos exercitar a percepção sobre o que é desperdício. Aqui temos
uma boa definição do que é desperdício segundo a perspectiva Lean:
“Desperdício é tudo aquilo que esgota recursos de tempo, dinheiro e espaço sem
adicionar valor ao cliente”.
Taichi Ohno, um dos grandes criadores do Lean, tem uma citação famosa: “Tudo
o que estamos fazendo é olhar para a linha do tempo, desde o momento em que
recebemos uma ordem de compra até o momento em que coletamos o dinheiro. Estamos
reduzindo esta linha do tempo removendo tudo o que não gera valor para o cliente, o
desperdício.”.
É importante observar que ele citou “linha do tempo”. Há uma definição mais
concisa em inglês para esta linha do tempo: leadtime, o tempo decorrido entre o momento
que uma necessidade surge até o momento em que esta demanda é atendida. Há uma
ferramenta muito interessante no Lean chamada Value Stream Mapping, ou mapeamento
da cadeia de valor. O objetivo desta ferramenta, como o próprio nome diz, é mapear tudo
o que ocorre entre o surgimento e o completo atendimento de uma requisição. Este
mapeamento nos permite registrar o que é tempo gasto com tarefas que adicionam valor
ao processo e o que é desperdício. Ao final, dividimos o tempo de valor agregado pelo
tempo total do processo e teremos nosso coeficiente de eficiência operacional. Quando
aplicam esta ferramenta, normalmente as empresas se espantam em ver que seu
coeficiente operacional gira em torno de 5 a 10%. Ou seja, apenas 5 a 10% do tempo total
utilizado em um processo tem efetivamente valor para o negócio. Todo o resto é
desperdício.
Tipos de Desperdício
Quando começamos a identificar desperdício, criamos também uma oportunidade
para melhoria no processo. Ainda para entender um pouco mais sobre desperdício, vamos
ver os três tipos definidos pelo Lean:
Muda
Todo o tipo de atividade que não gera valor para o negócio. Aplicando a
ferramenta de mapeamento da cadeia de valor, podemos identificar como desperdício
alguns itens: filas, espera, processos ineficazes que geram retrabalho e outras coisas mais.
Um outro exercício que podemos fazer para identificar o muda é listar 15 atividades

9. comuns que executamos diariamente, incluindo ler e-mail, almoçar, conversar, fumar
(quando for o caso), codificar, desenhar, documentar, testar, etc. Depois classificamos
estes itens, dando um peso de 1 a 5, sendo 5 o que gera mais valor para o cliente e 1 o que
menos gera. Após isto, basta contar quantas atividades têm o valor 4 ou 5 e você verá o
grande número de coisas que faz diariamente que não geram valor direto.
Muri
Sobrecarga de processo. É comum empresas imporem períodos de rush, onde as
pessoas precisam trabalhar longas jornadas de trabalho, às vezes 12 ou 14 horas por dia,
durante dias seguidos. Ou seja, buscam ocupar seus funcionários em até 150% de sua
capacidade. Porém, o que acontece se carregarmos um avião com 110% de sua
capacidade? Possivelmente teremos um acidente aéreo. Se subirmos isto para 130% ou
150%, certamente teremos uma tragédia. O mesmo ocorre com o ser humano e com os
processos que utilizamos para desenvolver software. Se estivermos funcionando a 100%
de nossa capacidade, certamente não teremos espaço para absorver qualquer demanda
inesperada. Ainda assim, grande parte das empresas busca sacrificar seus recursos
impondo uma demanda muito grande. A teoria das filas nos mostra que, se tivermos uma
ocupação de cerca de 80% de nossa capacidade produtiva, seremos mais produtivos e
teremos espaço para absorver coisas inesperadas, oriundas de falhas no processo ou
mesmo de demandas externas.
Mura
Irregularidades. Todo o tipo de defeito existente é considerado Mura. Mura é tudo
aquilo que não é desejado, uma inconsistência ou, no jargão mais comum, um bug. O
Mura também pode ser oriundo do muri ou do muda. É comum observarmos a forma
como as pessoas tratam o mura e vermos que geralmente não há uma correção de fato,
mas apenas uma solução paliativa para o problema. Vamos pegar como exemplo um bug
em um sistema, que foi identificado em uma fase de homologação ou em produção. O
bug é relatado aos desenvolvedores que geralmente vão debugar o código até encontrar o
problema. Consertam-no, compilam e devolvem outra versão do binário para a produção.
Neste caso, é grande a probabilidade deste defeito voltar ou de algum efeito colateral ser
gerado a partir desta correção - sem considerar o tempo desperdiçado tentando achar o
problema através de debug.
Equipes um pouco mais preparadas utilizam testes automatizados e vão reduzir o
tempo com debug. Primeiro, irão criar um teste automatizado que reproduz o problema e
posteriormente vão direto ao ponto para corrigir o bug. Como utilizam testes
automatizados, esta equipe saberá imediatamente dos efeitos colaterais causados com a
alteração no código e terá maior segurança em devolver uma versão corrigida para a
produção. Esta equipe ainda terá o benefício de não ter regressão, ou seja, o problema
dificilmente irá aparecer novamente, pois está bem cercado pelos testes automatizados
que poderão ser facilmente reproduzidos a qualquer momento. Aos olhos da maioria das
pessoas este procedimento parece bom. De fato é, mas ainda falta algo para que seja
considerado excelente.

10. O pensamento Lean orienta à reflexão sobre a causa raiz cada vez que
encontramos um problema. Em outras palavras, qual foi a falha em nosso processo de
desenvolvimento que permitiu que este erro passasse para a produção? Por que nossos
métodos de testes não detectaram este erro antes? Trabalhar na causa raiz do problema
será sempre o meio mais eficaz de prevenção. E a prevenção, quando efetiva, será sempre
mais barata do que a cura.
Tipos de desperdício em software
O Lean foi originalmente concebido para gerenciar a linha de produção da Toyota. Na
manufatura, o maior desperdício existente é o estoque. Estoque alto significa dinheiro
parado, matéria prima ou produto que pode perecer e ser perdido. Na área de software
temos os seguintes tipos de desperdícios mais comuns:
▪ Estoque – Documentação não codificada código não sincronizado no ambiente de
controle de versões, não testado automaticamente, não documentado e que nunca
foi para produção;
▪ Funcionalidades extras - Um estudo do Standish Group mostra que 20% das
funcionalidades de um software são sempre ou frequentente utilizadas. Outros
35% são usadas algumas vezes ou raramente e 45% das funcionalidades de um
sistema típico nunca são utilizadas. Aplicando-se a Lei de Pareto temos 20% das
funcionalidades de um software respondendo por 80% do valor gerado pelo
mesmo;
▪ Processos extras – normalmente procedimentos que precisam ser executados
somente para adequação a uma regra ou norma;
▪ Espera – Todo tipo de espera entre uma atividade e outra;
▪ Defeitos;
▪ Complexidade.
No início deste artigo observamos a complexidade que pode ser gerada quando o
conhecimento é baixo sobre a tecnologia e os negócios. Agora podemos observar na
figura 5 que o custo do desenvolvimento de software sobe muito ao longo do tempo
quando não temos uma base de código limpa e simples.

11. Figura 5. Gráfico do custo da complexidade
Princípios do Lean
Vamos explorar um pouco mais a fundo os princípios que deram origem ao Lean
e que permeiam todo o conceito da Pirâmide Lean.
Jidoka
Também conhecido como Autonomation ou Inteligent Automation , é a
automação com um toque humano. Este foi um dos primeiros conceitos criados por
Sakichi Toyoda, fundador do Grupo Toyota. Ainda no século XIX, Sakichi observava sua
mãe trabalhar em teares manuais feitos de madeira e procurava maneiras de facilitar o
trabalho de tecelagem. Em 1890, Sakichi inventou um tear de madeira manual que
possibilitou um aumento de 50% na produtividade, fazendo com que sua mãe utilizasse
somente uma das mãos para fazer o trabalho que antes precisava das duas. Seguindo esta
ideia de automação, ele aprimorou seu invento e em 1906 criou o primeiro tear mecânico
automatizado. Implementando o conceito de melhoria contínua, em 1924, Sakichi e seu
filho Kiichiro chegaram ao Modelo G, um tear automatizado de alta velocidade que
detectava quando um fio arrebentava e parava automaticamente a máquina para que não
produzisse tecidos defeituosos. Suas inovações para parada automática e prevenção de
desperdícios foram extraordinárias.
Com o invento, Sakichi eliminou a necessidade de ter um operador monitorando
as máquinas de tear continuamente. Agora, um único operador poderia monitorar até 30
máquinas, possibilitando uma diminuição expressiva no custo, bem como um aumento da
qualidade e produtividade das máquinas de tear da época. Assim, com a automação,
Sakichi criou um meio para que as máquinas parassem automaticamente quando qualquer

12. problema ocorresse e, desta forma, nunca produzissem defeitos. Sobretudo, o Jidoka
eliminou a necessidade de monitoramento humano contínuo e deu origem a uma cultura
que é uma das bases do Lean, a Stop the Line.
Cultura Stop the Line
Na Toyota, qualquer operador de uma linha de produção tem o dever de parar a
linha ao sinal de qualquer problema. Estamos falando de uma linha de produção de fluxo
contínuo, integrada aos fornecedores e que geralmente contabiliza cerca de 2 mil pessoas
trabalhando. Nessses casos, todas as pessoas que trabalham param suas atividades e um
pequeno grupo, normalmente liderado pela pessoa que parou a linha, irá investigar o
problema e determinar sua causa raiz. A linha só tornará a ser ligada quando a causa raiz
do problema for solucionada. A produção nas fábricas da Toyota para diversas vezes ao
dia e assim, a empresa consegue produzir carros de altíssima qualidade e diminuir
drasticamente seus custos de correção de defeitos.
Poka-Yoke
Mecanismos a prova de erros. As linhas automatizadas de produção na Toyota são
dotadas de mecanismos de detecção de falhas que não permitem a inserção de erros no
processo. Nas máquinas de solda, por exemplo, um mecanismo verifica se a máquina está
apta a fazer a soldagem – se tudo estiver certo, a solda será realizada. Após o processo,
outro mecanismo faz uma verificação para ver se tudo ocorreu bem. Caso algum dos
testes falhe, a linha de produção para automaticamente. Para os procedimentos manuais,
existe uma série de checklists que permitem validar cada etapa do trabalho dos
funcionários. Novamente, quando uma etapa falha, a linha de produção é parada e o
problema solucionado a partir de sua causa raiz. Juntando a automação inteligente do
Jidoka com os mecanismos a prova de erros Poka-Yoke, e com uma cultura Stop the
Line, temos um processo produtivo maduro, padronizado e de alta qualidade. Quando
desenvolvemos software, precisamos também ter estas características inseridas no
processo - vamos discutir mais a frente como fazer isto.
Just in Time
Ter um processo just in time significa reduzir desperdício fazendo somente o que
é necessário, na quantidade necessária, no local necessário e quando é necessário. Em
uma linha de produção, o fluxo just in time permite diminuir estoques e aumentar o giro
de produtos. Associado a uma técnica de produção conhecida por sistema puxado, o just
in time possibilita também minimizar as perdas com produção excessiva e
consequentemente aumentar a produtividade da linha de produção. O just-in-time
também pode ser aplicado em software de diversas maneiras, que vamos explorar mais
adiante.

13. Sistema Puxado
Um sistema puxado de produção determina a carga de trabalho de acordo com o
consumo do cliente. Se não houver consumo não haverá produção, eliminando
completamente o desperdício com a produção excessiva. Diferentemente de um sistema
empurrado, onde há produção independentemente da demanda, o sistema puxado
gerencia toda a cadeia produtiva - desde a extração da matéria prima até a transformação
em um produto acabado. Para auxiliar neste processo, Taichi Ohno concebeu uma
ferramenta chamada Kanban, que permite um gerenciamento visual e colaborativo da
produção puxada. O Kanban tornou-se também uma ferramenta muito importante para
gerenciar o desenvolvimento de sistemas complexos. Veremos mais adiante como aplicá-
lo a software.
Heijunka
O Heijunka é uma técnica de análise da produção que auxilia no nivelamento da
produção e consequente eliminação do Muda, permitindo criar cadência na demanda e
nivelar a produção para potencializar a vazão do sistema e o fluxo de entrega de valor.
Para aplicar o Heijunka, é necessário entender o funcionamento do Kanban para
identificar como são distribuídas as cargas em um processo de desenvolvimento.
Pessoas
Uma vez que temos definidos claramente quais são os princípios e valores que
norteiam a cultura de uma organização, estamos prontos para definir a estratégia de
negócio e estabelecer a visão pela qual a empresa desenvolverá seus produtos. Esta visão
precisa ser claramente conhecida por todos os membros da organização, de modo que
cada um em seu trabalho possa direcionar suas atividades para maximizar o valor gerado
pela empresa. Desta forma, os objetivos desta visão precisam ser definidos e
comunicados em termos quantitativos e qualitativos, considerando-se os aspectos de
performance, custo e qualidade.
Antes de entrarmos em detalhes sobre como definir e comunicar a visão,
precisamos abordar um pouco o fator humano. Como observamos no manifesto ágil, é
importante termos sempre os melhores processos e ferramentas à disposição para que
uma equipe possa desenvolver de forma adequada as atividades. Porém, é ainda mais
importante maximizar a interação e colaboração entre os indivíduos. Tanto no Lean como
no desenvolvimento ágil de software busca-se o fortalecimento das pessoas através da
criação de equipes multidisciplinares e auto-responsáveis, de maneira que uma única
equipe seja formada de modo completo, compreendendo todos os conhecimentos e
habilidades necessárias para transformar a visão em produtos que gerem valor efetivo
para a organização. Equipes ágeis possuem a autonomia necessária para definir o que é
valor de negócio e também para determinar qual a tecnologia será necessária para
entregar tal valor. A figura 6 demonstra como uma equipe ágil pode ser formada.

14. Figura 6. Equipe ágil
De fato, todo processo de desenvolvimento ágil é adaptativo e o modelo de equipe
adequado deverá ser definido de acordo com o projeto em questão.
Aqui vamos explorar e estabelecer como base a diferença entre os modelos
propostos pelo Lean e pelo Scrum.
Na figura 6 há o modelo proposto pelo Lean, que de certa forma é bastante similar
ao proposto pelo Scrum, todavia com algumas importantes diferenças. A primeira delas
está no papel do Product Champion ou engenheiro chefe do produto. Como o próprio
nome já diz, o Engenheiro Chefe é o responsável final pela arquitetura e pelas principais
decisões técnicas do produto. Contudo, o Product Champion proposto pelo Lean é
também responsável por todas as decisões de marketing. Sendo assim, ele é responsável
por definir todo o processo de venda, suporte, precificação e a logística de entrega.
Como podemos observar, o Product Champion é o líder máximo, que conhece as
necessidades mercadológicas e detém o conhecimento tecnológico necessário para liderar
todo o processo de desenvolvimento e, consequentemente, guiar toda a equipe no
cumprimento de seus objetivos. Na Toyota, por exemplo, o Engenheiro Chefe é alguém
que tem muitos anos de prática, em geral de 15 a 20 anos de experiência com a cultura da
organização. Ademais, ele também procura viver as experiências dos clientes. Em alguns
casos, o Engenheiro Chefe realmente se muda para viver com uma família que tem o
perfil de seu cliente alvo, para vivenciar na prática seus hábitos e costumes. Só assim ele
terá subsídios suficientes para desenvolver produtos de sucesso.
Uma equipe Lean multidisciplinar completa será formada por subequipes que
contemplam expertise em negócios, marketing, vendas, engenharia, arquitetura, design e

15. produção. A comunicação entre estes experts deve sempre ser a mais direta e eficaz
possível. Logo, a figura 7 demonstra a efetividade da comunicação:
Figura 7. Efetividade da comunicação
O principal objetivo do trabalho conjunto e integrado de uma equipe Lean é
identificar com assertividade as necessidades de negócio e promover a entrega
incremental de valor efetivo.. É fundamental uma equipe saber identificar o que é valor e
qual a porção mínima de software necessária para entregar tal valor. Por isso, cita-se
propositadamente o termo entrega de valor, em vez de entrega de software.
Podemos observar ainda a presença de um outro papel de liderança, a do líder de
competências. Ele garante que a criação de competências esteja inserida implicitamente
no processo de desenvolvimento. Não precisamos necessariamente parar a equipe para
receber um treinamento, mas é fundamental garantir que o aprendizado ocorra durante o
desenvolvimento. Logo vamos abordar como as técnicas de engenharia que estão na base
da pirâmide e o desenvolvimento iterativo permitem a aquisição on-the-fly de
conhecimento.
Com relação ao Scrum, a principal diferença na formação da equipe é que o
Product Owner não possui conhecimento técnico suficiente para influenciar
profundamente nas decisões técnicas, bem como a equipe não conhece o negócio a ponto
de envolver-se nas decisões. Em geral, as decisões são tomadas de forma conjunta,
compartilhando-se conhecimento sobre negócio e tecnologia. Não podemos dizer que o
modelo de equipe do Lean é melhor do que o do Scrum e vice e versa. Ambos têm prós e
contras e serão mais apropriados de acordo com cada tipo de projeto.

16. Quebrando a Visão
Uma vez que a organização tenha definido adequadamente sua visão e estratégia
de negócios partimos para a implementação, aplicando os princípios e valores do Lean e
do desenvolvimento ágil nas demais camadas da organização. Dependendo do nível de
maturidade da empresa e das características dos projetos, ela poderá optar por usar Scrum
ou Kanban para criar um processo de entrega de valor. Antes disso, precisamos quebrar a
visão em objetivos menores que sejam específicos e mensuráveis. Tanto no Scrum quanto
no Kanban vamos utilizar uma ferramenta para isto – as estórias do usuário. Sendo assim,
vamos entender melhor como utilizar esta ferramenta antes de entrar em detalhes sobre
Scrum e Kanban.
Estórias
Uma estória, ou User Story, é uma frase simples que descreve uma necessidade
ou requisito de sistema. Estórias são utilizadas no desenvolvimento ágil para
especificação de requisitos, em conjunto com critérios de aceite devidamente elaborados.
Estórias são uma forma rápida e eficaz de coletar e manter requisitos sem a necessidade
de uma formalização burocrática, adicionando agilidade no processo e facilitando o
planejamento.
Uma estória pode ser considerada a funcionalidade em si dentro do ciclo de
desenvolvimento de software. A estória, em geral, é uma requisição do Product Owner
que, passada para o time de desenvolvimento, se transformará em uma porção do
software funcionando. Detalhes sobre a estória emergem durante as discussões nas
sessões de planejamento. Entretanto, algumas informações adicionais podem acompanhá-
la desde sua concepção, tais como: motivação do Product Owner para requisitá-la,
critérios que irão reger sua aceitação e descrições técnicas mais detalhadas, quando
necessário.
O time de desenvolvimento colabora com o ciclo de vida das estórias na medida
em que as transforma para que possam ser classificadas como SMART:
• eSpecífico: refere-se a uma intervenção pontual no software e não ao
desenvolvimento de um artefato muito grande ou complexo;
• Mensurável: deve ser possível mensurar o custo de desenvolvimento e o valor
gerado, além prever sua situação futura após o desenvolvimento da estória;
• Alcançável: na medida em que seu custo pode ser mensurado, uma estória deve
ser um objetivo possível de ser alcançado, cujo comprometimento com a entrega por
parte da equipe seja efetivo;
• Realista: A tecnologia escolhida deve contemplar de forma realista fatores como
custo, tempo disponível e capacidade técnica da equipe;
• Time-boxed (tempo fixo para o desenvolvimento): uma estória deve ser planejada
para ser entregue por inteira dentro de um ciclo de desenvolvimento. Porém, em um
eventual atraso, ela não deve ser motivo para atrasar ou adiantar a entrega do ciclo.

17. Vale lembrar que estórias não são especificações completas do que deve ser feito.
Na verdade, são apenas links de comunicação entre a equipe e o Product Owner a respeito
de um determinado assunto. Estórias são geralmente escritas em cartões (post-its) e
fixadas na parede (quadro de estórias), onde compõem uma lista chamada Product
Backlog. O Product Backlog é uma lista de estórias em constante priorização que
representa o escopo do produto. Esta lista é mutante, já que no desenvolvimento ágil as
mudanças de escopo são bem vindas a qualquer momento durante o desenvolvimento.
Figura 8. Backlog
Estimativas e velocidade de desenvolvimento
Estórias contêm estimativas e a responsabilidade por estimá-las é única e
exclusiva do time de desenvolvimento. Delegar esta responsabilidade ao time é uma
forma efetiva de garantir o comprometimento, já que nenhuma meta é imposta, mas sim
proposta pelos próprios engenheiros de software.
A experiência do desenvolvimento ágil de software mostra a ineficácia do uso de
uma medida de tempo (horas ou dias) para estimar o custo de uma estória. As estimativas
são feitas em story points (sp), medida exclusiva de esforço, que demonstra o tamanho de
uma estória comparada a outras. A tarefa de estimar em story points é livre da
preocupação sobre o tempo de duração do projeto. Story points liberam o time de
desenvolvimento da pressão por datas, possibilitando o foco na complexidade da estória.

18. Para acomodar as incertezas de estórias de grande porte, costuma-se utilizar a escala
Fibonacci para atribuição dos pontos, já que ela inicia com uma granularidade menor no
primeiros valores, partindo para apenas uma ordem de grandeza em escalas maiores: 1, 2,
3, 5, 8, 13, 21... A escala Fibonacci permite acomodar a incerteza do processo de
desenvolvimento nos intervalos entre um número e outro na escala.
A previsibilidade com a completude das estórias em datas específicas vem da
união das estimativas com o conceito de velocidade. A velocidade do time de
desenvolvimento é descoberta com a informação histórica sobre quantos story points
foram completados nas últimas iterações de desenvolvimento. A representação de
velocidade pode ser por iteração ou mesmo por dia: 20sp por iteração ou 2sp/dia, por
exemplo. Desta forma, quando o time inicia uma nova jornada com 10 dias de
desenvolvimento, pode se comprometer com a entrega de software funcionando com um
grupo de estórias que somam aproximadamente a sua velocidade média nas últimas
iterações.
Outro aspecto interessante é que a produtividade de uma equipe aumenta à
medida que vai agregando mais conhecimento sobre a tecnologia e o negócio em questão.
Consequentemente, as estimativas tornam-se também mais assertivas ao longo do tempo.
Em geral, uma equipe inicia com cerca de 30% de sua velocidade nominal e após três ou
quatro iterações a velocidade estabiliza em sua capacidade máxima. Entradas ou saídas
de integrantes da equipe podem também afetar a velocidade, mesmo depois do grupo ter
atingido uma estabilização da velocidade.
Vale salientar que o custo de uma estória varia de equipe para equipe e de época
de desenvolvimento para época de desenvolvimento. É correto utilizar velocidade e
número de estórias para comparar iterações consecutivas para uma mesma equipe.
Entretanto, a comparação de iterações muito distantes ou de diferentes equipes carece de
uma análise mais subjetiva. Além disso, a velocidade descoberta é uma média das últimas
iterações, sendo normal na iteração atual um resultado com desvio para mais ou para
menos. No caso de variação positiva da velocidade, mais estórias podem ser inseridas na
iteração. Quando a velocidade varia negativamente, as estórias de menor prioridade são
cortadas da iteração.
Priorização
Estórias de desenvolvimento normalmente são criadas pelo Product Owner, mas
outras pessoas podem exercer esta função. Estórias de manutenção corretiva podem ser
criadas por uma equipe de suporte. Estórias de refactoring criadas pelo time de
desenvolvimento e estórias de novas funcionalidades. em geral, podem ser criadas por
uma equipe de marketing ou até pelo usuário final. Independente da fonte, a estória será
obrigatoriamente priorizada pelo Product Owner.
Um Product Owner focado em maximizar o retorno do seu investimento
certamente realizará um bom trabalho de priorização. Uma priorização adequada pode

19. levar o desenvolvimento a alcançar um nível de produtividade representado pela Lei de
Pareto. A Lei de Pareto diz que, com 20% do esforço de desenvolvimento, pode-se gerar
80% do valor no software. O mesmo poderá ser observado durante a manutenção
corretiva do software, quando 80% dos problemas podem ser resolvidos atacando 20%
das causas. A figura 9 demonstra essa razão de esforço e resultado da Lei de Pareto:
Figura 9. Lei de Pareto
Diversas técnicas de priorização podem ser utilizadas, e dentre elas podemos citar o
cálculo do Retorno do Investimento (ROI), onde se mensura o custo do desenvolvimento
e o valor gerado, a técnica MoSCoW (Must, Should, Could, Won't) e a análise de Kano.
O cálculo do ROI é realizado elencando-se diversos fatores, como custo do
desenvolvimento, custo da estrutura física de desenvolvimento e produção, e aspectos
como capacidade de aumento nas vendas, conquista de novos clientes ou mesmo a
retenção de atuais clientes. Para tanto, uma análise mais aprofundada, reunindo
especialistas das áreas de finanças, marketing, vendas e desenvolvimento, é necessária.
A técnica MoSCoW é uma das mais utilizadas. Através dela e a partir da experiência do
Product Owner, é possível determinar quais estórias precisam (must), deveriam (should)
e poderiam (could) estar com prioridade mais alta, bem como quais estórias não irão de
fato ser priorizadas (won’t). Este último é um fator de priorização muito importante,
conhecido também como not list, geralmente esquecido ou não utilizado por equipes
menos experientes.
A Análise de Kano é um modelo de desenvolvimento de produtos criado nos anos 80
pelo professor Noriaki Kano, que classifica as preferências dos consumidores em cinco
categorias.

20. Figura 10. Análise de Kano
Planejamento e Controle da Produção
Uma vez tendo conhecimento sobre o que é preciso ser desnevovido e sua adequada
priorização, é preciso também compreender como planejar e controlar a entrega dos
artefatos. É isso que iremos explorar neste tópico.
Ciclos: releases, iterações e entrega contínua

21. Uma das principais características da complexa tarefa de criar produtos de
software que funcionem corretamente e atendam as expectativas do cliente é a
imprevisibilidade, o que dificulta muito o processo de planejamento e controle. Para
reduzir esta imprevisibilidade, processos tradicionais de desenvolvimento confiam em
planejamentos intensivos para longos períodos, tentando identificar e mitigar todos os
riscos possíveis logo de início. Ao longo dos anos descobriu-se que esta estratégia não
funciona devido à própria natureza incerta do desenvolvimento de software e dos
negócios onde normalmente são aplicados.
Através deste aprendizado, o Lean e as metodologias ágeis propõem ciclos curtos de
planejamento e entrega, nos quais uma parte do produto final é projetada, desenvolvida e
testada dentro de um período curto, chamado iteração ou Sprints no Scrum. Observem
que não estamos falando de protótipos, e sim de uma parte do produto final que pode ser
utilizada em produção e será continuamente melhorada e incrementada, iteração após
iteração, respondendo às mudanças impostas pelo mercado e pela tecnologia, até que
atinja o escopo necessário.
Figura 11. Esqueleto Scrum
Ciclos curtos de desenvolvimento proporcionam maior feedback e aprendizado
para todos os envolvidos no processo de desenvolvimento. Esta é uma das formas de
capacitação implícita no processos de desenvolvimento que citamos anteriormente,
essencial para um ambiente Lean maduro. Com mais conhecimento, as equipes passam a
diminuir a incerteza e trabalham ancoradas em um processo confiável de entregas de
produto de alta qualidade e valor agregado.
Com maior confiabilidade e previsibilidade é possível fazer um planejamento de
releases para o projeto, considerando as regras adequadas de priorização e a velocidade
da equipe de desenvolvimento. Desta forma, os releases são entregas maiores que

22. contemplam o que foi desenvolvido durante algumas iterações e, associado a um objetivo
bem definido, o planejamento passa a ser uma forma valiosa de satisfazer as necessidades
de mercado do cliente.
Como são priorizadas as funcionalidades que geram maior valor e têm maior risco
para o projeto, os ciclos curtos propiciam um produto de alto valor agregado, diminuindo
os riscos e o time-to-market. Consequentemente, a vantagem competitiva do cliente
torna-se indiscutível.
Entrega contínua com Kanban
Quando a equipe atinge um alto nível de maturidade, os ciclos de
desenvolvimento tornam-se cada vez mais curtos e eventualmente a parada para
planejamento das iterações pode se tornar um desperdício. O Kanban pode ser utilizado
para amadurecer o workflow e aumentar a eficiência do sistema, promovendo a entrega
contínua de software e o aumento da produtividade da equipe.
De forma simplificada, o Kanban é um processo de produção puxado que mapeia
as etapas de desenvolvimento. Para cada etapa identificada, ele estabelece limites para a
quantidade de trabalho sendo realizada simultaneamente. Os limites superiores auxiliam a
minimizar a multi-tarefa, neste caso nociva à produtividade da equipe. Limites inferiores
vão auxiliar a garantir que sempre haja demanda suficiente para que o trabalho não pare.
Ambos os limites ajudam a criar cadência no processo, nivelando a produção e
potencializando ao máximo a entrega e, consequentemente, vazão de valor. O
nivelamento da produção (Heijunka) é necessário para evitar os períodos em que ocorre
demanda excessiva, causando a sobrecarca de processo (Muri) ou pouca demanda,
causando ociosidade no processo (Muda).
Quando o limite de uma das etapas do Kanban é atingido, parte da equipe que está
atuando em outras etapas faz uma pausa em suas atividades e auxilia a remover o gargalo.
É como uma turma de jipeiros numa trilha. Se um jipe atola, todos os demais descem do
jipe para ajudar a desatolar o carro que atolou. Dentre outros benefícios, o Kanban auxilia
na gestão visual do fluxo de trabalho, melhorando a comunicação e os processos de
priorização. O Kanban também permite um foco grande na qualidade, através de seus
critérios “Definition of ready” e “Definition of done” para cada uma das etapas.
Visibilidade e Rastreabilidade
Processos ágeis proporcionam total visibilidade, controle e rastreabilidade de tudo
o que ocorre durante o ciclo de desenvolvimento. De fato, os métodos ágeis propiciam
uma oportunidade diária para análise de riscos e tomada de decisão de modo a corrigir o
mínimo desvio indevido de curso. Todas as ocorrências são disponibilizadas através das
ferramentas de gestão como dashboard e burndown charts para todos os membros do

23. projeto. Além disso, a comunicação direta entre equipes gera maior colaboração,
visibilidade e controle do projeto. O próprio processo de ciclos curtos proporciona maior
aprendizado e feedback concreto sobre o exato andamento do projeto, gerando maior
segurança e consequente aumento de auto-estima para todos os envolvidos.
Com base nas ferramentas e técnicas de metodologias ágeis, visibilidade e controle
são potencializados da seguinte forma:
• Dashboard – painel que contém as estórias e tarefas priorizadas no
backlog e que demonstra a evolução no ciclo de vida do desenvolvimento;
• Gráfico de evolução – burndown charts proporcionam visibilidade sobre a
velocidade de produção da equipe e se esta velocidade é adequada para os
objetivos;
• Aceites – o cliente aceita ou rejeita as estórias entregues ao final de cada
ciclo de desenvolvimento. Tudo é documentado, incluindo o planejamento, o que
foi realizado e eventuais diferenças;
• Software funcionando – sempre ao final de cada iteração o cliente recebe
um software pronto para uso, proporcionando feedback e retroalimentação da
visão do produto;
• Documentação embarcada – todo código é entregue com documentação
embarcada (javadoc), possibilitando o aumento do conhecimento;
• Software Intelligence – todas as técnicas de automatização, coleta de
métricas e testes utilizadas pela equipe proporcionam muita segurança e a certeza
de se estar desenvolvendo o produto correto.
A Base da Pirâmide Lean
A base da pirâmide é larga para poder sustentar o resto da estrutura. Por este
motivo, colocamos na base as práticas de Engenharia de Software que permitem uma
efetiva e segura adoção de métodos ágeis. A utilização de Scrum ou Kanban para gestão
dos projetos deixa mais fácil a tarefa de responder às mudanças e adequar o
planejamento. Entretanto, se não houver uma base de código sustentável, essa resposta
despreparada às mudanças pode significar um problema muito grande. Por este motivo é
importante implementar na Engenharia de Software os princípios e valores do Lean e do
Manifesto ágil.
Testes Automatizados
Testes automatizados são certamente uma das mais fundamentais técnicas de
desenvolvimento de software, que permite uma adição severa de qualidade ao código. O
grande objetivo é criar esta qualidade durante a construção do código, ao invés de testá-lo
mais tarde. Em geral, equipes que não investem na criação de testes automatizados
necessitam de um longo período de testes ao final de cada ciclo de desenvolvimento. Esse
investimento tardio na qualidade compromete o conhecimento da real situação do

24. software durante o desenvolvimento, o que gera atrasos, falta de visibilidade,
gerenciabilidade e assertividade do produto final.
O investimento em testes automatizados oferece a oportunidade de obter feedback
dos testes mesmo durante o desenvolvimento do software. A grande vantagem desta
abordagem, é o fato de se poder testar todo o sistema facilmente, a partir de apenas um
botão na IDE. A reprodutibilidade dos testes encoraja sua execução, minimizando a
necessidade e o custo de manutenção corretiva. A aplicação de testes automatizados é
também a criação de um ambiente que permita o aprendizado de forma implícita,
conforme mencionado no início destes artigo.
Os testes automatizados são blocos de código, chamados códigos de testes, que
exercitam o código de produção. Os testes confeccionados variam na sua abrangência e
no foco. Quanto à abrangência, podem ser:
• Testes unitários: testam cada menor trecho de código do sistema;
• Testes integrados: testam classes ou módulos do sistema de forma integrada;
• Testes funcionais: testam funções específicas do sistema de ponta a ponta,
abrangendo todo o fluxo da informação;
• Testes de aceitação: testes inspirados na condição de aceitação do cliente ou
usuário. Geralemente são aplicados diretamente na interface do sistema.
A figura 12 demonstra as camadas de um software e a abrangência dos testes:
Figura 12. Exemplo de Arquitetura de Testes Automatizados
Quanto ao foco dos testes:
• Corretude do funcionamento: são os testes mais comuns, utilizados para certificar
a aderência do sistema aos requisitos funcionais;
• Performance e consumo de memória: testes que certificam o desempenho do
sistema de acordo com requisitos não-funcionais;

25. • Usabilidade: estes testes normalmente não são automatizados. Envolvem
especialistas em usabilidade e podem contar com a participação do próprio
usuário.
Desenvolvedores utilizam testes automatizados na criação da tecnologia, auxiliando-os na
escrita de código limpo e habilitando o refactoring para melhoria contínua. Especialistas
de negócio podem usufruir de testes automatizados para certificarem-se de que seu
modelo de negócio segue efetivo e aceito, mesmo durante a contínua evolução da base de
código.
Automatização do Ambiente
A Engenharia de Software requer que processos repetitivos sejam executados
inúmeras vezes. Estas atividades envolvem, por exemplo, a execução da suíte de testes,
compilação do sistema, geração de versão de distribuição, configuração do ambiente de
execução (como base de dados), notificação dos responsáveis em caso de erros nos testes,
criação de relatórios de aderência aos padrões - enfim, a lista é bem extensa.
De maneira geral, estas atividades, se desempenhadas por pessoas, requerem uma
equipe dedicada e muito disciplinada. No entanto, a propensão a erros durante a execução
da rotina é bastante alta, o que invariavelmente configuraria desperdícios (Mura).
Para a redução destes desperdícios recomenda-se a automatização de tais processos.
Neste tópico serão discutidas ações que podem ser tomadas para automatizar seu
ambiente.
Builds Automatizados
Existem ferramentas que podem auxiliar a automatização dos processos
repetitivos de desenvolvimento. Tais ferramentas podem variar de acordo com a
tecnologia. Alguns exemplos são: Make, Ant e Maven. Para as tecnologias Java, os mais
utilizados são Ant e Maven, ambos da Apache Software Foundation. Tratam-se de
ferramentas para execução de rotinas descritas como instruções codificadas em arquivos
de configuração XML, comumente chamados de builds.
Devido às contribuições da comunidade de desenvolvimento, estas ferramentas
possuem várias extensões e recursos que envolvem compilação de código em várias
linguagens, execução de testes (incluindo, mas não se limitando ao padrão xUnit), envio
de e-mail, integração com servidores de aplicação e manipulação de banco de dados.
A maneira de utilização destas ferramentas depende muito dos propósitos do projeto em
que são utilizadas. Porém, de maneira geral, a compilação, empacotamento e testes do
artefato de software desenvolvido são os principais objetivos. A utilização intensa
propicia a coleta e a geração de artefatos para gestão da configuração que permitem a
análise do desenvolvimento, adesão aos padrões e tomada de decisão quanto à qualidade
dos artefatos gerados (veja o tópico Software Intelligence para mais informações dos
benefícios e meios).

26. Integração Contínua
Dispor de builds automatizados para seu projeto é um grande passo rumo à
automatização dos processos, suporte à decisão sobre investimentos em qualidade,
visibilidade, entre outros. Entretanto, para que estes benefícios sejam de fato gerados, é
necessário que estes processos automatizados sejam executados de maneira sistemática e
autônoma. Por exemplo, a suíte de testes e a rotina para executá-los não obterão os
benefícios desejados caso não sejam executados a cada contribuição dos desenvolvedores
sobre o código fonte do software objeto do projeto. O disparo do processo de execução
periódica poderia ser executado pelo pessoal responsável por qualidade. Entretanto, assim
como a execução de processos repetitivos, delegar esta responsabilidade comumente
resulta em falhas e consequente desperdício.
Para tal, ferramentas de monitoramento de contribuição e execução automática
estão disponíveis, dentre elas: Apache Continuum, Hudson, LuntBuild e CruiseControl.
Trata-se de um serviço disponibilizado na infraestrutura de desenvolvimento, geralmente
em um servidor dedicado para o fim de integração contínua.
Os servidores de integração contínua comumente são configurados com um
ambiente web, com suporte a ferramentas de comunicação (como e-mail e instant
messenger) e link com outros servidores como Servidor de Controle de Versões e
Servidor de Homologação. Estes recursos ampliam as capacidades dos builds
automatizados, que podem publicar os relatórios gerados no ambiente web, enviar
notificações aos desenvolvedores e outros interessados quanto ao status dos testes, entre
outras possibilidades.

27. Figura 13. Ambiente de Integração Contínua
A figura 13 mostra três servidores: Servidor de Controle de Versões (SCV), Servidor de
Homologação (SH) e Servidor de Integração Contínua (SIC). Note que os
desenvolvedores colocam suas contribuições ao projeto no SCV. O SIC, continuamente
monitora o SCV em busca de modificações. Dada uma modificação detectada, o SIC
atualiza sua cópia do projeto com as últimas atualizações detectadas, estando assim em
sincronia com o SCV, e então executa o build automatizado do projeto.
Este build executará todas as rotinas automatizadas e poderá se valer do ambiente
do SIC para fazer o deployment da nova versão do software em um servidor para
homologação (SH). É possível também gerar relatórios para acompanhamento e tomada
de decisões em um ambiente web disponibilizado no próprio SIC.

28. Software Intelligence
Software intelligence refere-se às habilidades, tecnologias, aplicações e práticas
utilizadas para ajudar a todos os envolvidos a entender melhor o contexto do negócio:
desenvolvimento de software. Para tal, existem ferramentas livres que possibilitam a
varredura do código fonte na busca por indícios de bugs no software, cobertura de testes,
métricas de qualidade, entre outras informações. Estas ferramentas, integradas ao sistema
de builds automatizados, podem ser consideradas inteligência de software quando são
combinadas com um processo que busca melhoria contínua. Na prática, nas reuniões de
retrospectiva e nas estórias de refactoring, os relatórios de inteligência do software são
fontes importantes de suporte a decisão. A seguir, são apresentadas algumas das
ferramentas que poderão ser empregadas na presente proposta:
• FindBugs. FindBugs é um programa que se propõe a achar bugs em
aplicações Java por meio da análise estática do código fonte. Este é um método
utilizado para achar bugs em um sistema, sem executá-lo. A possibilidade de
achar erros e vulnerabilidades sutís, antes que elas ocorram meses ou anos depois
no sistema em produção, é a principal vantagem desse programa
• CPD. Trata-se de um Detector de Copia e Cola (Copy/Paste Detector) para
o código fonte da aplicação. Sua sensibilidade pode ser configurada e costuma
apresentar algumas surpresas para seus usuários, principalmente em equipes de
desenvolvimento médias, grandes e distribuídas. O principal benefício do CPD é
reduzir a propagação de erros e o custo de todos os tipos de manutenção em
códigos duplicados. Ele também encoraja o uso de boas práticas de orientação a
objetos como DRY (Don’t Repeat Yourself), pois evita a recodificação de
entidades do sistema já implementadas;
• PMD. O PMD é um programa que analisa o código fonte na busca de uma
suite de situações: códigos que poderiam ser melhor implementados quanto a
performance, porções de código não utilizadas, tratamento deficiente de exceções
e sentenças desnecessariamente complexas;
• Relatório dos testes. Resultados da execução da suíte automatizada de
testes. Deve ser mantido sempre verde, passando. Em caso de erro, além da
possível notificação aos interessados, a cor no relatório será vermelha e as causas
serão apresentadas em detalhes;
• Doxygen. Através de engenharia reversa aplicada às classes e à
documentação embarcada no código fonte, o Doxygen pode gerar diagramas
UML com o estado real da aplicação, manuais e documentação online;
• Checkstyle. É uma ferramenta que auxilia o time de desenvolvimento a se
manter dentro de padrões de codificação. Assim como o CPD e o PMD, é ideal
para times médios, grandes ou distribuídos;
• Cobertura. Como o nome indica, esta ferramenta mensura a cobertura dos
testes automatizados no sistema. Ele gera relatórios que podem ser confrontados
no próprio código fonte, indicando as áreas que foram acionadas pelos testes
automatizados;
• Mensurar a complexidade ciclomática, apesar do nome complicado,
significa simplesmente mensurar a complexidade de códigos estruturados ou
cíclicos. Esta informação pode reduzir custos de manutenção, gerando valor na

29. medida em que explicita, por exemplo, implementações fora da arquitetura
planejada;
• Lobo. Lobo é uma ferramenta opensource desenvolvida pela OnCast, que
estende a API de testes padrão para Java, oferencendo opções avançadas para
testes de performance. Os relatórios gerados pelo Lobo mostram a evolução da
performance do sistema ao longo do tempo do projeto. Se uma nova
implementação compromete a performance de algum ponto isolado do sistema,
este problema é facilmente identificado e isolado com a ajuda desta ferramenta.
Vale salientar que são apresentadas algumas das ferramentas disponíveis no mercado.
O emprego de cada uma delas no processo de desenvolvimento será analisado
confrontando o custo de manutenção do ambiente de software intelligence, com o valor
gerado pelo mesmo. Uma escolha bem feita de um subconjunto destas ferramentas tem o
potencial de formar um relatório significativo sobre o estado do desenvolvimento de um
software.
Intercalando Tecnologia, Pessoas, Processos e Ferramentas
Em todos os níveis da Pirâmide Lean é possível encontrar elementos trabalhando
em conjunto para criação de valor na organização. Podemos observar que falamos sempre
de pessoas, processos e ferramentas - tudo isso para a criação da melhor tecnologia. O
Lean chama este processo de Systems Thinking, e orienta a olhar para a junção de
pessoas, processos e ferramentas como um sistema, que precisa ser afinado e regulado de
modo a gerar o seu melhor potencial.
A partir do momento que certas técnicas - testes automatizados, TDD, refactoring,
arquitetura emergente, simplicidade e integração contínua, por exemplo - são aplicadas
corretamente, formamos uma base sólida para que a visão da organização seja
rapidamente implementada e entregue com a mais alta qualidade. O correto equilíbrio na
definição de valores e princípios e na aplicação das técnicas do Lean, Scrum e Kanban,
conduz a organização para níveis de excelência ainda não alcançados. Esta excelência
permitirá a criação de uma cultura baseada em relacionamentos fortes e duradouros,
estimulando a criatividade e a inovação. Responsabilidade, disciplina, senso de
propriedade, capacidade de auto-gestão, respeito e colaboração permitirão a criação de
uma equipe extremamente ágil e coesa, que tenha prazer naquilo que faz e que,
principalmente, construa uma relação de confiança entre si e para com seus clientes.
Espera-se, pois, que a visão da Pirâmide Lean ajude a indústria de software a
tornar-se mais produtiva, humana e sustentável.
Leads:
Do que se trata o artigo:

30. Neste artigo veremos como equilibrar a aplicação de práticas, princípios e
valores no desenvolvimento de software afim de criar uma cultura
organizacional enxuta e ágil.
Para que serve:
O conceito abordado neste artigo serve para a criação, adoção e
disseminação da cultura Lean e Ágil de forma efetiva em uma organização que
desenvolve software.
Em que situação o tema útil:
Qualquer empresa que visa aprimorar seus métodos de desenvolvimento
vai usufruir do conhecimento descrito neste artigo.
Links
http://prezi.com/w6pjte9n4bsq/the-lean-pyramid/ - apresentação da Pirâmide Lean na web
http://onca.st/blog - blog da OnCast Technologies
http://www.agilealliance.org - site da Agile Alliance (rico em artigos)
http://www.poppendieck.com/ - site de Mary & Tom Poppendieck, criadores do Lean Software
Development