SlideShare uma empresa Scribd logo
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
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.
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”.
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.
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.
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).
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.
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
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.
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.
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
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.
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.
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
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.
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.
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.
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
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.
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
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
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
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
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;
•   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).
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.
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.
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
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:
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

Mais conteúdo relacionado

Mais procurados

Implementando o Desenvolvimento Lean de Software - Do conceito ao dinheiro
Implementando o Desenvolvimento Lean de Software - Do conceito ao dinheiroImplementando o Desenvolvimento Lean de Software - Do conceito ao dinheiro
Implementando o Desenvolvimento Lean de Software - Do conceito ao dinheiro
Taller Negócio Digitais
 
Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018
Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018
Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018
Jonas Beto Rompkovski
 
Desmistificando Agile & Scrum
Desmistificando Agile & ScrumDesmistificando Agile & Scrum
Desmistificando Agile & Scrum
Teamware do Brasil
 
Dorsey rocha metodologia-change_management
Dorsey rocha metodologia-change_managementDorsey rocha metodologia-change_management
Dorsey rocha metodologia-change_management
elybisso
 
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
EloGroup
 
10 dicas para escalar Agile usando SAFe
10 dicas para escalar Agile usando SAFe10 dicas para escalar Agile usando SAFe
10 dicas para escalar Agile usando SAFe
Manoel Pimentel Medeiros
 
Os segredos para dominar OKRs
Os segredos para  dominar OKRsOs segredos para  dominar OKRs
Os segredos para dominar OKRs
DiegoMannes1
 
Aula 1 Modelagem De Processos
Aula 1   Modelagem De ProcessosAula 1   Modelagem De Processos
Aula 1 Modelagem De Processos
Marcos Barato
 
Metodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareMetodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de software
Universidade Tiradentes
 
Metodologia para gestão de mudanças organizacionais - Change Management
Metodologia para gestão de mudanças organizacionais - Change ManagementMetodologia para gestão de mudanças organizacionais - Change Management
Metodologia para gestão de mudanças organizacionais - Change Management
Edson Carli
 
Lean Office Management
Lean Office ManagementLean Office Management
Lean Office Management
CLT Valuebased Services
 
Agile42 Artigo De Especialidade
Agile42 Artigo De EspecialidadeAgile42 Artigo De Especialidade
Agile42 Artigo De Especialidade
Hugo Lourenco
 
Gestao de-mudancas
Gestao de-mudancasGestao de-mudancas
Gestao de-mudancas
Mary Menezes
 
Aula gratuita sobre change management - veja a aula aqui: www.avaliarh.com.b...
Aula gratuita sobre change management  - veja a aula aqui: www.avaliarh.com.b...Aula gratuita sobre change management  - veja a aula aqui: www.avaliarh.com.b...
Aula gratuita sobre change management - veja a aula aqui: www.avaliarh.com.b...
Edson Carli
 
RH em Tempos de Grandes Desafios
RH em Tempos de Grandes DesafiosRH em Tempos de Grandes Desafios
RH em Tempos de Grandes Desafios
Daniel de Carvalho Luz
 
Desenvolvimento de software LEAN
Desenvolvimento de software LEAN Desenvolvimento de software LEAN
Desenvolvimento de software LEAN
Venícios Gustavo
 
Ferramentas e ritos
Ferramentas e ritosFerramentas e ritos
Ferramentas e ritos
Davidson Sales
 
Administrador 5.0: Protagonista da Transformação Digital no Brasil
Administrador 5.0: Protagonista da Transformação Digital no BrasilAdministrador 5.0: Protagonista da Transformação Digital no Brasil
Administrador 5.0: Protagonista da Transformação Digital no Brasil
Conselho Regional de Administração de São Paulo
 
Pesquisa qualitativa
Pesquisa qualitativaPesquisa qualitativa
Pesquisa qualitativa
Patricia de Oliveira Neves
 
Lean manufacturing 4-implementação
Lean manufacturing   4-implementaçãoLean manufacturing   4-implementação
Lean manufacturing 4-implementação
jparsilva
 

Mais procurados (20)

Implementando o Desenvolvimento Lean de Software - Do conceito ao dinheiro
Implementando o Desenvolvimento Lean de Software - Do conceito ao dinheiroImplementando o Desenvolvimento Lean de Software - Do conceito ao dinheiro
Implementando o Desenvolvimento Lean de Software - Do conceito ao dinheiro
 
Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018
Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018
Palestra sobre Design Sprint for Process no Agile Curitiba Conference 2018
 
Desmistificando Agile & Scrum
Desmistificando Agile & ScrumDesmistificando Agile & Scrum
Desmistificando Agile & Scrum
 
Dorsey rocha metodologia-change_management
Dorsey rocha metodologia-change_managementDorsey rocha metodologia-change_management
Dorsey rocha metodologia-change_management
 
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
 
10 dicas para escalar Agile usando SAFe
10 dicas para escalar Agile usando SAFe10 dicas para escalar Agile usando SAFe
10 dicas para escalar Agile usando SAFe
 
Os segredos para dominar OKRs
Os segredos para  dominar OKRsOs segredos para  dominar OKRs
Os segredos para dominar OKRs
 
Aula 1 Modelagem De Processos
Aula 1   Modelagem De ProcessosAula 1   Modelagem De Processos
Aula 1 Modelagem De Processos
 
Metodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareMetodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de software
 
Metodologia para gestão de mudanças organizacionais - Change Management
Metodologia para gestão de mudanças organizacionais - Change ManagementMetodologia para gestão de mudanças organizacionais - Change Management
Metodologia para gestão de mudanças organizacionais - Change Management
 
Lean Office Management
Lean Office ManagementLean Office Management
Lean Office Management
 
Agile42 Artigo De Especialidade
Agile42 Artigo De EspecialidadeAgile42 Artigo De Especialidade
Agile42 Artigo De Especialidade
 
Gestao de-mudancas
Gestao de-mudancasGestao de-mudancas
Gestao de-mudancas
 
Aula gratuita sobre change management - veja a aula aqui: www.avaliarh.com.b...
Aula gratuita sobre change management  - veja a aula aqui: www.avaliarh.com.b...Aula gratuita sobre change management  - veja a aula aqui: www.avaliarh.com.b...
Aula gratuita sobre change management - veja a aula aqui: www.avaliarh.com.b...
 
RH em Tempos de Grandes Desafios
RH em Tempos de Grandes DesafiosRH em Tempos de Grandes Desafios
RH em Tempos de Grandes Desafios
 
Desenvolvimento de software LEAN
Desenvolvimento de software LEAN Desenvolvimento de software LEAN
Desenvolvimento de software LEAN
 
Ferramentas e ritos
Ferramentas e ritosFerramentas e ritos
Ferramentas e ritos
 
Administrador 5.0: Protagonista da Transformação Digital no Brasil
Administrador 5.0: Protagonista da Transformação Digital no BrasilAdministrador 5.0: Protagonista da Transformação Digital no Brasil
Administrador 5.0: Protagonista da Transformação Digital no Brasil
 
Pesquisa qualitativa
Pesquisa qualitativaPesquisa qualitativa
Pesquisa qualitativa
 
Lean manufacturing 4-implementação
Lean manufacturing   4-implementaçãoLean manufacturing   4-implementação
Lean manufacturing 4-implementação
 

Semelhante a Artigo piramide lean final

1MA5591D-desenvolvimento agil_alunos.pdf
1MA5591D-desenvolvimento agil_alunos.pdf1MA5591D-desenvolvimento agil_alunos.pdf
1MA5591D-desenvolvimento agil_alunos.pdf
suporteredework1
 
Entrevista galp
Entrevista galpEntrevista galp
Entrevista galp
CLT Valuebased Services
 
Paloma costa mba gestao de projetos
Paloma costa   mba gestao de projetosPaloma costa   mba gestao de projetos
Paloma costa mba gestao de projetos
Paloma Costa
 
Agile no RH: Oportunidade ou ameaça?
Agile no RH: Oportunidade ou ameaça?Agile no RH: Oportunidade ou ameaça?
Agile no RH: Oportunidade ou ameaça?
Fabio Jascone
 
Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
Ricardo Antunes Fernandes
 
RH Ágil
RH ÁgilRH Ágil
RH Ágil
UNIMEP
 
Introdução Metodologias áGeis Para Desenvolvimento De Software
Introdução  Metodologias áGeis Para Desenvolvimento De SoftwareIntrodução  Metodologias áGeis Para Desenvolvimento De Software
Introdução Metodologias áGeis Para Desenvolvimento De Software
Marcos Cardoso
 
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
Conselho Regional de Administração de São Paulo
 
MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...
MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...
MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...
Suzyanne Oliveira
 
Lean nos Servicos 2013
Lean nos Servicos 2013Lean nos Servicos 2013
Lean nos Servicos 2013
CLT Valuebased Services
 
Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...
Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...
Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...
Jaffer Veronezi
 
Agile Think Business Agility Series
Agile Think Business Agility SeriesAgile Think Business Agility Series
Agile Think Business Agility Series
André Vidal
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
Caroline Seara
 
Entrevista a João Paulo Pinto
Entrevista a João Paulo PintoEntrevista a João Paulo Pinto
Entrevista a João Paulo Pinto
CLT Valuebased Services
 
Manifesto Ágil.pdf
Manifesto Ágil.pdfManifesto Ágil.pdf
Manifesto Ágil.pdf
LeonardoCristianoQui
 
Análise das metodologias para definição de escopo em Lean Startups
Análise das metodologias para definição de escopo em Lean StartupsAnálise das metodologias para definição de escopo em Lean Startups
Análise das metodologias para definição de escopo em Lean Startups
Alexandre Rocha Lima e Marcondes
 
Trabalho de - Gestão da Qualidade e Sistemas Normalizados
Trabalho de - Gestão da Qualidade e Sistemas NormalizadosTrabalho de - Gestão da Qualidade e Sistemas Normalizados
Trabalho de - Gestão da Qualidade e Sistemas Normalizados
Wilson Rodrigues
 
Valores e principios das metodologias ágeis
Valores e principios das metodologias ágeisValores e principios das metodologias ágeis
Valores e principios das metodologias ágeis
Karol Oliveira
 
O Pensamento Lean-Agile nos Negócios do Século XXI
O Pensamento Lean-Agile nos Negócios do Século XXIO Pensamento Lean-Agile nos Negócios do Século XXI
O Pensamento Lean-Agile nos Negócios do Século XXI
Luiz C. Parzianello
 
Hbr 7-questions-ask-before-next-transformation-ptbr
Hbr 7-questions-ask-before-next-transformation-ptbrHbr 7-questions-ask-before-next-transformation-ptbr
Hbr 7-questions-ask-before-next-transformation-ptbr
job Titri company
 

Semelhante a Artigo piramide lean final (20)

1MA5591D-desenvolvimento agil_alunos.pdf
1MA5591D-desenvolvimento agil_alunos.pdf1MA5591D-desenvolvimento agil_alunos.pdf
1MA5591D-desenvolvimento agil_alunos.pdf
 
Entrevista galp
Entrevista galpEntrevista galp
Entrevista galp
 
Paloma costa mba gestao de projetos
Paloma costa   mba gestao de projetosPaloma costa   mba gestao de projetos
Paloma costa mba gestao de projetos
 
Agile no RH: Oportunidade ou ameaça?
Agile no RH: Oportunidade ou ameaça?Agile no RH: Oportunidade ou ameaça?
Agile no RH: Oportunidade ou ameaça?
 
Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
 
RH Ágil
RH ÁgilRH Ágil
RH Ágil
 
Introdução Metodologias áGeis Para Desenvolvimento De Software
Introdução  Metodologias áGeis Para Desenvolvimento De SoftwareIntrodução  Metodologias áGeis Para Desenvolvimento De Software
Introdução Metodologias áGeis Para Desenvolvimento De Software
 
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
 
MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...
MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...
MyStartup: Agile, Lean e Design Thinking integrados dando dinâmica a um model...
 
Lean nos Servicos 2013
Lean nos Servicos 2013Lean nos Servicos 2013
Lean nos Servicos 2013
 
Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...
Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...
Proposta de um modelo de escalonamento de metodologia ágil para grandes organ...
 
Agile Think Business Agility Series
Agile Think Business Agility SeriesAgile Think Business Agility Series
Agile Think Business Agility Series
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
 
Entrevista a João Paulo Pinto
Entrevista a João Paulo PintoEntrevista a João Paulo Pinto
Entrevista a João Paulo Pinto
 
Manifesto Ágil.pdf
Manifesto Ágil.pdfManifesto Ágil.pdf
Manifesto Ágil.pdf
 
Análise das metodologias para definição de escopo em Lean Startups
Análise das metodologias para definição de escopo em Lean StartupsAnálise das metodologias para definição de escopo em Lean Startups
Análise das metodologias para definição de escopo em Lean Startups
 
Trabalho de - Gestão da Qualidade e Sistemas Normalizados
Trabalho de - Gestão da Qualidade e Sistemas NormalizadosTrabalho de - Gestão da Qualidade e Sistemas Normalizados
Trabalho de - Gestão da Qualidade e Sistemas Normalizados
 
Valores e principios das metodologias ágeis
Valores e principios das metodologias ágeisValores e principios das metodologias ágeis
Valores e principios das metodologias ágeis
 
O Pensamento Lean-Agile nos Negócios do Século XXI
O Pensamento Lean-Agile nos Negócios do Século XXIO Pensamento Lean-Agile nos Negócios do Século XXI
O Pensamento Lean-Agile nos Negócios do Século XXI
 
Hbr 7-questions-ask-before-next-transformation-ptbr
Hbr 7-questions-ask-before-next-transformation-ptbrHbr 7-questions-ask-before-next-transformation-ptbr
Hbr 7-questions-ask-before-next-transformation-ptbr
 

Mais de Startupi

[Livro] Startup & Makers CPBR8
[Livro] Startup & Makers CPBR8[Livro] Startup & Makers CPBR8
[Livro] Startup & Makers CPBR8
Startupi
 
Scale-Up Manifesto
Scale-Up ManifestoScale-Up Manifesto
Scale-Up Manifesto
Startupi
 
Up Global - Fostering a startup ecosystem (full report)
Up Global - Fostering a startup ecosystem (full report)Up Global - Fostering a startup ecosystem (full report)
Up Global - Fostering a startup ecosystem (full report)
Startupi
 
Up global - fomentando ecossistema de startups
Up global - fomentando ecossistema de startupsUp global - fomentando ecossistema de startups
Up global - fomentando ecossistema de startups
Startupi
 
Perfil Investimento Anjo, Julho 2014
Perfil Investimento Anjo, Julho 2014Perfil Investimento Anjo, Julho 2014
Perfil Investimento Anjo, Julho 2014
Startupi
 
PIB dos pequenos negócios no Brasil
PIB dos pequenos negócios no BrasilPIB dos pequenos negócios no Brasil
PIB dos pequenos negócios no Brasil
Startupi
 
Shobeir - Pebble
Shobeir - PebbleShobeir - Pebble
Shobeir - Pebble
Startupi
 
Appies app360 wearable devices
Appies app360 wearable devicesAppies app360 wearable devices
Appies app360 wearable devices
Startupi
 
Barbie Entrepreneur
Barbie EntrepreneurBarbie Entrepreneur
Barbie Entrepreneur
Startupi
 
Memorando Marco Civil da Internet (Baptista Luz Advogados)
Memorando Marco Civil da Internet (Baptista Luz Advogados)Memorando Marco Civil da Internet (Baptista Luz Advogados)
Memorando Marco Civil da Internet (Baptista Luz Advogados)
Startupi
 
Relatório Webshoppers E-bit - 2013
Relatório Webshoppers E-bit - 2013Relatório Webshoppers E-bit - 2013
Relatório Webshoppers E-bit - 2013
Startupi
 
Value of connectivity
Value of connectivityValue of connectivity
Value of connectivity
Startupi
 
Mercado Livre 19 de fevereiro de 2014
Mercado Livre 19 de fevereiro de 2014Mercado Livre 19 de fevereiro de 2014
Mercado Livre 19 de fevereiro de 2014
Startupi
 
As novas leis de Kepler para investimento anjo em startup
As novas leis de Kepler para investimento anjo em startupAs novas leis de Kepler para investimento anjo em startup
As novas leis de Kepler para investimento anjo em startup
Startupi
 
Startup walking-cpbr7
Startup walking-cpbr7Startup walking-cpbr7
Startup walking-cpbr7
Startupi
 
Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...
Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...
Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...
Startupi
 
Texto final com assinaturas
Texto final com assinaturasTexto final com assinaturas
Texto final com assinaturas
Startupi
 
Justificação inicial da lei SisTENET de isenção para startups
Justificação inicial da lei SisTENET de isenção para startupsJustificação inicial da lei SisTENET de isenção para startups
Justificação inicial da lei SisTENET de isenção para startups
Startupi
 
Relatório com parecer favorável à lei de isenção para startups
Relatório com parecer favorável à lei de isenção para startupsRelatório com parecer favorável à lei de isenção para startups
Relatório com parecer favorável à lei de isenção para startups
Startupi
 
Apresentação resultado Start-Up Brasil atualizado
Apresentação resultado Start-Up Brasil atualizadoApresentação resultado Start-Up Brasil atualizado
Apresentação resultado Start-Up Brasil atualizado
Startupi
 

Mais de Startupi (20)

[Livro] Startup & Makers CPBR8
[Livro] Startup & Makers CPBR8[Livro] Startup & Makers CPBR8
[Livro] Startup & Makers CPBR8
 
Scale-Up Manifesto
Scale-Up ManifestoScale-Up Manifesto
Scale-Up Manifesto
 
Up Global - Fostering a startup ecosystem (full report)
Up Global - Fostering a startup ecosystem (full report)Up Global - Fostering a startup ecosystem (full report)
Up Global - Fostering a startup ecosystem (full report)
 
Up global - fomentando ecossistema de startups
Up global - fomentando ecossistema de startupsUp global - fomentando ecossistema de startups
Up global - fomentando ecossistema de startups
 
Perfil Investimento Anjo, Julho 2014
Perfil Investimento Anjo, Julho 2014Perfil Investimento Anjo, Julho 2014
Perfil Investimento Anjo, Julho 2014
 
PIB dos pequenos negócios no Brasil
PIB dos pequenos negócios no BrasilPIB dos pequenos negócios no Brasil
PIB dos pequenos negócios no Brasil
 
Shobeir - Pebble
Shobeir - PebbleShobeir - Pebble
Shobeir - Pebble
 
Appies app360 wearable devices
Appies app360 wearable devicesAppies app360 wearable devices
Appies app360 wearable devices
 
Barbie Entrepreneur
Barbie EntrepreneurBarbie Entrepreneur
Barbie Entrepreneur
 
Memorando Marco Civil da Internet (Baptista Luz Advogados)
Memorando Marco Civil da Internet (Baptista Luz Advogados)Memorando Marco Civil da Internet (Baptista Luz Advogados)
Memorando Marco Civil da Internet (Baptista Luz Advogados)
 
Relatório Webshoppers E-bit - 2013
Relatório Webshoppers E-bit - 2013Relatório Webshoppers E-bit - 2013
Relatório Webshoppers E-bit - 2013
 
Value of connectivity
Value of connectivityValue of connectivity
Value of connectivity
 
Mercado Livre 19 de fevereiro de 2014
Mercado Livre 19 de fevereiro de 2014Mercado Livre 19 de fevereiro de 2014
Mercado Livre 19 de fevereiro de 2014
 
As novas leis de Kepler para investimento anjo em startup
As novas leis de Kepler para investimento anjo em startupAs novas leis de Kepler para investimento anjo em startup
As novas leis de Kepler para investimento anjo em startup
 
Startup walking-cpbr7
Startup walking-cpbr7Startup walking-cpbr7
Startup walking-cpbr7
 
Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...
Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...
Cultura do Fracasso: apresentação de Romero Rodrigues na final do Desafio B...
 
Texto final com assinaturas
Texto final com assinaturasTexto final com assinaturas
Texto final com assinaturas
 
Justificação inicial da lei SisTENET de isenção para startups
Justificação inicial da lei SisTENET de isenção para startupsJustificação inicial da lei SisTENET de isenção para startups
Justificação inicial da lei SisTENET de isenção para startups
 
Relatório com parecer favorável à lei de isenção para startups
Relatório com parecer favorável à lei de isenção para startupsRelatório com parecer favorável à lei de isenção para startups
Relatório com parecer favorável à lei de isenção para startups
 
Apresentação resultado Start-Up Brasil atualizado
Apresentação resultado Start-Up Brasil atualizadoApresentação resultado Start-Up Brasil atualizado
Apresentação resultado Start-Up Brasil atualizado
 

Artigo piramide lean final

  • 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