material do curso de Lean para a pós em auditoria de sistemas

1. Pos em engenharia e qualidade de softwares
Leonardo A Alves

2.  Fordismo
 Toyotismo

3.  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.

4.  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 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.

5.  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 duas mil
pessoas trabalhando. Nesses 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.

6.  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.

7.  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.

8.  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.

9.  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.

10.  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.

11.  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.

12.  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.

13.  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.

14.  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 de prever sua situação futura após o
desenvolvimento da estória;

15.  • 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.

16.  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. Para acomodar as incertezas de
estórias de grande porte, costuma-se utilizar a escala

17.  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.

18.  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
levar o desenvolvimento a alcançar um nível de
produtividade

19.  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.

20.  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

22.  Planejamento e Controle da Produção
Uma vez tendo conhecimento sobre o que é
preciso ser desenvolvido e sua adequada
priorização, é preciso também compreender
como planejar e controlar a entrega dos
artefatos

23.  Ciclos: releases, iterações e entrega contínua
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.

24.  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 nos 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.

25.  Desta forma, os releases são entregas maiores
que 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.

26.  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 multitarefa, 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.

27.  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 sobrecarga 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.

28.  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 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;
 •

29.  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.

30.  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.

31.  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 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.

32.  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;
• 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.

33.  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.


34.  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.

35.  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 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.

36.  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.

37.  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.

39.  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 sutis, 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.


40.  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;

41.  • 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 medida em que explicita, por
exemplo, implementações fora da arquitetura
planejada;
•

42.  Lobo. Lobo é uma ferramenta opensource desenvolvida
pela OnCast, que estende a API de testes padrão para Java,
oferecendo 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.
 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.

43.  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.


44.  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.

45.  Apresentação da Pirâmide Lean na web
http://prezi.com/w6pjte9n4bsq/the-lean-
pyramid/
Blog da OnCast Technologies
http://onca.st/blog
Site da Agile Alliance (rico em artigos)
http://www.agilealliance.org
Site de Mary & Tom Poppendieck,
criadores do Lean Software Development
http://www.poppendieck.com/