Artigo piramide lean final

1,591 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,591
On SlideShare
0
From Embeds
0
Number of Embeds
318
Actions
Shares
0
Downloads
27
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Artigo piramide lean final

  1. 1. Informações do Artigo – v1.0Tipo: [Engenharia de Software, Cultura organizacional]Título: [A Pirâmide Lean]Sub Título: [O Equilíbrio das Forças Ágeis]Samuel Crescênciosamuel.crescencio@oncast.com.br Twitter: @screscencioSamuel atua como engenheiro de software construindo sistemas de missão crítica desde1994. Fundador e CEO da OnCast Technologies - empresa que tornou-se referência naAmérica Latina em metodologias ágeis - Samuel adquiriu uma grande experiência emdesenvolvimento ágil distribuído, fato que tornou-o apaixonado pela melhoria deprocessos. Reconhecido como um líder na comunidade internacional, Samuel foipresidente do Ágiles2009 - a segunda edição da Conferência Latino Americana deMétodos Ágeis e também do Pensando Lean – Forum internacional para corporaçõesenxutas. Samuel é membro do comitê de organização do Agile Brazil - ConferênciaBrasileira de Metodologias Ágeis e também possui um assento no Board of Directors daAgile Alliance. Samuel é Lean Software Development Practitioner desde 2003, CertifiedScrum 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 eevoluindo 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 sertambém notada nos métodos que utilizamos para desenvolver software, maspossivelmente de uma forma não tão rápida. Por muito tempo a indústria se ancorou em métodos que buscavam maiorprevisibilidade para o desenvolvimento de software, procurando entender de antemão e
  2. 2. geralmente fixar qual seria o escopo, o custo e o prazo de desenvolvimento. Ao longo dosanos, 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 detecnologias 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 processoimprevisível. É muito comum o mercado mudar suas necessidades, ou mesmo o própriocliente não saber o que quer, até que comece a ver partes disso funcionando. Quando oconhecimento sobre a tecnologia e sobre os negócios é pouco, a gestão dos projetostorna-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 oWaterfall ou mesmo o RUP eram pesados demais em termos de documentação ehierarquia entre os indivíduos e não permitiam o grau de aprendizado necessário para quepudé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 maiorinteração entre os indivíduos e também na entrega incremental e constante de softwarefuncionando, que pudesse ser utilizado pelo cliente mesmo antes de ter seu escopocompleto. Algumas vertentes surgiam e estes pesquisadores observaram semelhançasentre os experimentos. Assim, em 2001, 17 especialistas em Engenharia de Software sereuniram na cidade de Salt Lake City nos Estados Unidos e assinaram o que hojeconhecemos como Manifesto Ágil para o desenvolvimento de software.
  3. 3. Nesta mesma época, algumas metodologias começaram a se consolidar e então foifundada a Agile Alliance, uma organização sem fins lucrativos que tem por objetivodisseminar o uso e o desenvolvimento de todas as metodologias que compartilham dosmesmos princípios e valores do manifesto ágil. O grande objetivo do manifesto e daAgile Alliance é fomentar o desenvolvimento de software para permitir uma entrega demaior valor agregado mais rapidamente, buscando uma indústria de software maisprodutiva, humana e sustentável. Com o advento dos métodos ágeis, podemos observar uma transição da indústriade software. Hoje, 10 anos depois do evento em Salt Lake City, já falamos que odesenvolvimento ágil é “main stream” na indústria e que as empresas que não seadaptarem 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 comambientes improdutivos, de baixíssima qualidade e, em alguns casos, desumanos. Sendoassim, encontrar uma maneira efetiva e menos dolorosa para a adoção de métodos ágeistornou-se vital. Em geral, as empresas iniciam este processo de adoção com Scrum, portratar-se de um framework simples e de fácil utilização. Apesar de ser um framework quepermite uma melhora significativa da produtividade e da gerenciabilidade, o Scrum pecaem não trazer nenhuma orientação sobre as práticas de engenharia. Ele permitirá maioragilidade em responder às mudanças impostas pelo mercado, mas responder a estasmudanças pode ser traumático caso não estejamos preparados com uma base de códigosólida e que nos permita real segurança na hora de mudarmos nosso software. Como amaioria das empresas que querem adotar métodos ágeis não tiveram o uso de boaspráticas de engenharia adotar o Scrum sem dar a devida atenção ao código pode serrealmente doloroso. Por este motivo, criou-se na OnCast – empresa de desenvolvimento de software etambém de serviços de conhecimento que pratica o que há de mais moderno na indústriade software global, um conceito que visa auxiliar as empresas a equilibrar corretamente ouso de práticas, princípios e valores em todas os níveis de uma organização, com oobjetivo de promover uma mudança segura e sustentável na cultura interna e nos métodosde desenvolvimento. Este conceito foi batizado por Samuel de “A Pirâmide Lean”.
  4. 4. Figura 2. Pirâmide Lean O primeiro aspecto que precisamos trabalhar quando desejamos adotar odesenvolvimento ágil com eficácia é a transformação cultural necessária para o sucessoda empreitada.Um caso verídico ocorreu em uma das maiores empresas de ERP doBrasil. Lá estavam presentes cerca de 35 pessoas, incluindo o presidente e todo oconselho de administração, juntamente com o primeiro nível de gerências. Durante otrabalho, o presidente isse: “esse método é realmente maravilhoso e acredito que poderesolver nossos problemas, mas não posso simplesmente baixar um decreto e esperar queseja usado”. Com toda razão, a mudança cultural não pode ser imposta, mas precisa sersuportada. 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 é aresistência - sendo assim, imposição nunca será o melhor caminho. É preciso abrirespaç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 claroentendimento dos valores e princípios que a organização segue. Os valores não servemapenas para estar num quadro bonito na recepção da empresa. Conhecer e exercitar osvalores 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ãohá regras para tudo. Por este motivo, todos os colaboradores são orientados a refletiremquando estão tomando uma decisão. Se esta decisão fere algum valor da empresa, elessão encorajados a procurar uma alternativa.
  5. 5. Figura 3. Valores da Oncast Além de definir adequadamente seus próprios valores, uma organização quedeseja ser efetivamente ágil precisa também entender e trabalhar com os valores eprincí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 compreenderos seus princípios. Os princípios do manifesto ágil são uma excelente base, mas osprincípios do Lean são também utilizados na Pirâmide Lean como pilares para a criaçãode uma cultura que possa permear toda a organização e assim criar uma empresaefetivamente ágil e enxuta. Neste conceito da Pirâmide Lean, foi criado um sumário dos princípios do Lean paraque assim possamos entender de forma simplificada como eles se aplicam naorganizaçã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 vezesparece fácil, mas geralmente as pessoas estão habituadas - ou acomodadas - e ficampraticamente cegas para os desperdícios existentes. O mesmo ocorre com a questão doaprendizado. Quando se fala em uma organização que aprende, não fala-se apenas emenviar os colaboradores para treinamentos ou contratar consultores externos. Deve-secriar um processo de trabalho onde o aprendizado esteja implícito e seja reconhecidocomo fundamental para o próximo passo, a melhoria contínua. Vamos observar tambémque simplesmente aprender sobre o que precisa ser melhorado não é suficiente. É precisoter coragem para adaptar e mudar e, acima de tudo, disciplina e iniciativa para fazer istocontinuamente.
  6. 6. Além desses princípios, não se pode deixar de frisar alguns princípios do Leandefinidos por Mary e Tom Poppendieck que são também uma base sólida para aconstruçã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émmuitos deprimentes. Só há dois motivos para alguém fazer um trabalho ruim: falta deconhecimento ou má vontade. De qualquer forma, a todos os seres humanos viventes foidado uma coisa igual, o tempo. O tempo é igual para todos. Por isso, devemos aproveitaras oportunidades para fazer bem feito e com integridade absoluta tudo o que nos foiconfiado.Integridade Mary e Tom Poppendieck definiram dois tipos de integridade: conceitual epercebida. 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 depeso, pois fizeram uma série de cálculos para isto. Já a integridade percebida é aquela queos 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 umacomunicação efetiva, afim de criar um fluxo contínuo de informações entre osdesenvolvedores , usuários e clientes (e vice-versa).
  7. 7. Figura 4. IntegridadeRespeito Seria ótimo se pudéssemos lidar somente com a complexidade envolvida nodesenvolvimento tecnológico e no mundo dos negócios. Porém, temos também que lidardiariamente 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 bomsenso e a boa educação que aprendemos em casa. A forma como uma equipe se organizapara efetuar o trabalho pode influenciar profundamente no respeito às pessoas. Coisassimples - como dar visibilidade do seu trabalho, prover e aceitar feedback, errar o quantoantes 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 semmesmo perceber. Um ambiente Lean efetivo dá espaço para que possamos aprenderabertamente sobre este tipo de problema e assim resolvê-los de uma forma adequada.Entregar rápidoTemos duas grandes razões para entregar rápido: para que o nosso cliente não mude deideia enquanto estamos construindo e para que nosso concorrente não entregue antes. Emgeral, as mudanças no mercado e a velocidade com que nosso concorrente consegueentregar 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 queestamos fazendo. As experimentações de nosso produto no mercado, ainda queinacabado, 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? Quantosconhecem o impacto de suas decisões no negócio do cliente? Se as pessoas em suaorganização não compreendem as respostas a estas questões, elas devem estartrabalhando simplesmente porque alguém disse a elas o que devem fazer. Isto caracterizaum sistema “empurrado” de trabalho e certamente os resultados ficam muito aquém dosque seriam possíveis em uma organização Lean de sistema “puxado”. Por isto, noconceito da Pirâmide Lean, as pessoas precisam enxergar e compreender o todo. Mais doque isto, precisam contribuir para melhoria da organização como um todo. Este princípioaplica-se também na parte técnica. Se você tem especialistas em certas partes do código esó eles conseguem mexer lá, certamente as demais pessoas da equipe não estão vendo otodo. Mais adiante neste artigo vamos abordar como resolver este tipo de problema.
  8. 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 treinadapara identificar aspectos negativos com facilidade. Há uma tendência natural do homem aolhar 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 temosuma boa definição do que é desperdício segundo a perspectiva Lean:“Desperdício é tudo aquilo que esgota recursos de tempo, dinheiro e espaço semadicionar valor ao cliente”. Taichi Ohno, um dos grandes criadores do Lean, tem uma citação famosa: “Tudoo que estamos fazendo é olhar para a linha do tempo, desde o momento em querecebemos uma ordem de compra até o momento em que coletamos o dinheiro. Estamosreduzindo esta linha do tempo removendo tudo o que não gera valor para o cliente, odesperdício.”. É importante observar que ele citou “linha do tempo”. Há uma definição maisconcisa em inglês para esta linha do tempo: leadtime, o tempo decorrido entre o momentoque uma necessidade surge até o momento em que esta demanda é atendida. Há umaferramenta muito interessante no Lean chamada Value Stream Mapping, ou mapeamentoda cadeia de valor. O objetivo desta ferramenta, como o próprio nome diz, é mapear tudoo que ocorre entre o surgimento e o completo atendimento de uma requisição. Estemapeamento nos permite registrar o que é tempo gasto com tarefas que adicionam valorao processo e o que é desperdício. Ao final, dividimos o tempo de valor agregado pelotempo total do processo e teremos nosso coeficiente de eficiência operacional. Quandoaplicam esta ferramenta, normalmente as empresas se espantam em ver que seucoeficiente operacional gira em torno de 5 a 10%. Ou seja, apenas 5 a 10% do tempo totalutilizado 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 oportunidadepara melhoria no processo. Ainda para entender um pouco mais sobre desperdício, vamosver os três tipos definidos pelo Lean:Muda Todo o tipo de atividade que não gera valor para o negócio. Aplicando aferramenta de mapeamento da cadeia de valor, podemos identificar como desperdícioalguns 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. 9. comuns que executamos diariamente, incluindo ler e-mail, almoçar, conversar, fumar(quando for o caso), codificar, desenhar, documentar, testar, etc. Depois classificamosestes itens, dando um peso de 1 a 5, sendo 5 o que gera mais valor para o cliente e 1 o quemenos gera. Após isto, basta contar quantas atividades têm o valor 4 ou 5 e você verá ogrande 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 aspessoas 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 suacapacidade. Porém, o que acontece se carregarmos um avião com 110% de suacapacidade? Possivelmente teremos um acidente aéreo. Se subirmos isto para 130% ou150%, certamente teremos uma tragédia. O mesmo ocorre com o ser humano e com osprocessos que utilizamos para desenvolver software. Se estivermos funcionando a 100%de nossa capacidade, certamente não teremos espaço para absorver qualquer demandainesperada. Ainda assim, grande parte das empresas busca sacrificar seus recursosimpondo uma demanda muito grande. A teoria das filas nos mostra que, se tivermos umaocupação de cerca de 80% de nossa capacidade produtiva, seremos mais produtivos eteremos espaço para absorver coisas inesperadas, oriundas de falhas no processo oumesmo de demandas externas.Mura Irregularidades. Todo o tipo de defeito existente é considerado Mura. Mura é tudoaquilo que não é desejado, uma inconsistência ou, no jargão mais comum, um bug. OMura também pode ser oriundo do muri ou do muda. É comum observarmos a formacomo 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 bugem um sistema, que foi identificado em uma fase de homologação ou em produção. Obug é relatado aos desenvolvedores que geralmente vão debugar o código até encontrar oproblema. 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 sergerado a partir desta correção - sem considerar o tempo desperdiçado tentando achar oproblema através de debug. Equipes um pouco mais preparadas utilizam testes automatizados e vão reduzir otempo com debug. Primeiro, irão criar um teste automatizado que reproduz o problema eposteriormente vão direto ao ponto para corrigir o bug. Como utilizam testesautomatizados, esta equipe saberá imediatamente dos efeitos colaterais causados com aalteração no código e terá maior segurança em devolver uma versão corrigida para aprodução. Esta equipe ainda terá o benefício de não ter regressão, ou seja, o problemadificilmente irá aparecer novamente, pois está bem cercado pelos testes automatizadosque poderão ser facilmente reproduzidos a qualquer momento. Aos olhos da maioria daspessoas este procedimento parece bom. De fato é, mas ainda falta algo para que sejaconsiderado excelente.
  10. 10. O pensamento Lean orienta à reflexão sobre a causa raiz cada vez queencontramos um problema. Em outras palavras, qual foi a falha em nosso processo dedesenvolvimento que permitiu que este erro passasse para a produção? Por que nossosmétodos de testes não detectaram este erro antes? Trabalhar na causa raiz do problemaserá sempre o meio mais eficaz de prevenção. E a prevenção, quando efetiva, será sempremais 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. Namanufatura, o maior desperdício existente é o estoque. Estoque alto significa dinheiroparado, matéria prima ou produto que pode perecer e ser perdido. Na área de softwaretemos 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 oconhecimento é baixo sobre a tecnologia e os negócios. Agora podemos observar nafigura 5 que o custo do desenvolvimento de software sobe muito ao longo do tempoquando não temos uma base de código limpa e simples.
  11. 11. Figura 5. Gráfico do custo da complexidadePrincípios do Lean Vamos explorar um pouco mais a fundo os princípios que deram origem ao Leane que permeiam todo o conceito da Pirâmide Lean.Jidoka Também conhecido como Autonomation ou Inteligent Automation , é aautomação com um toque humano. Este foi um dos primeiros conceitos criados porSakichi Toyoda, fundador do Grupo Toyota. Ainda no século XIX, Sakichi observava suamãe trabalhar em teares manuais feitos de madeira e procurava maneiras de facilitar otrabalho de tecelagem. Em 1890, Sakichi inventou um tear de madeira manual quepossibilitou um aumento de 50% na produtividade, fazendo com que sua mãe utilizassesomente uma das mãos para fazer o trabalho que antes precisava das duas. Seguindo estaideia de automação, ele aprimorou seu invento e em 1906 criou o primeiro tear mecânicoautomatizado. Implementando o conceito de melhoria contínua, em 1924, Sakichi e seufilho Kiichiro chegaram ao Modelo G, um tear automatizado de alta velocidade quedetectava quando um fio arrebentava e parava automaticamente a máquina para que nãoproduzisse tecidos defeituosos. Suas inovações para parada automática e prevenção dedesperdícios foram extraordinárias. Com o invento, Sakichi eliminou a necessidade de ter um operador monitorandoas máquinas de tear continuamente. Agora, um único operador poderia monitorar até 30máquinas, possibilitando uma diminuição expressiva no custo, bem como um aumento daqualidade 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. 12. problema ocorresse e, desta forma, nunca produzissem defeitos. Sobretudo, o Jidokaeliminou a necessidade de monitoramento humano contínuo e deu origem a uma culturaque é 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 alinha ao sinal de qualquer problema. Estamos falando de uma linha de produção de fluxocontínuo, integrada aos fornecedores e que geralmente contabiliza cerca de 2 mil pessoastrabalhando. Nessses casos, todas as pessoas que trabalham param suas atividades e umpequeno grupo, normalmente liderado pela pessoa que parou a linha, irá investigar oproblema e determinar sua causa raiz. A linha só tornará a ser ligada quando a causa raizdo problema for solucionada. A produção nas fábricas da Toyota para diversas vezes aodia e assim, a empresa consegue produzir carros de altíssima qualidade e diminuirdrasticamente seus custos de correção de defeitos.Poka-Yoke Mecanismos a prova de erros. As linhas automatizadas de produção na Toyota sãodotadas de mecanismos de detecção de falhas que não permitem a inserção de erros noprocesso. 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 dostestes 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 dosfuncionários. Novamente, quando uma etapa falha, a linha de produção é parada e oproblema solucionado a partir de sua causa raiz. Juntando a automação inteligente doJidoka com os mecanismos a prova de erros Poka-Yoke, e com uma cultura Stop theLine, temos um processo produtivo maduro, padronizado e de alta qualidade. Quandodesenvolvemos software, precisamos também ter estas características inseridas noprocesso - 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. Emuma linha de produção, o fluxo just in time permite diminuir estoques e aumentar o girode produtos. Associado a uma técnica de produção conhecida por sistema puxado, o justin time possibilita também minimizar as perdas com produção excessiva econsequentemente aumentar a produtividade da linha de produção. O just-in-timetambém pode ser aplicado em software de diversas maneiras, que vamos explorar maisadiante.
  13. 13. Sistema Puxado Um sistema puxado de produção determina a carga de trabalho de acordo com oconsumo do cliente. Se não houver consumo não haverá produção, eliminandocompletamente o desperdício com a produção excessiva. Diferentemente de um sistemaempurrado, onde há produção independentemente da demanda, o sistema puxadogerencia toda a cadeia produtiva - desde a extração da matéria prima até a transformaçãoem um produto acabado. Para auxiliar neste processo, Taichi Ohno concebeu umaferramenta chamada Kanban, que permite um gerenciamento visual e colaborativo daprodução puxada. O Kanban tornou-se também uma ferramenta muito importante paragerenciar 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 daprodução e consequente eliminação do Muda, permitindo criar cadência na demanda enivelar 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 paraidentificar 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 quenorteiam a cultura de uma organização, estamos prontos para definir a estratégia denegócio e estabelecer a visão pela qual a empresa desenvolverá seus produtos. Esta visãoprecisa ser claramente conhecida por todos os membros da organização, de modo quecada um em seu trabalho possa direcionar suas atividades para maximizar o valor geradopela empresa. Desta forma, os objetivos desta visão precisam ser definidos ecomunicados em termos quantitativos e qualitativos, considerando-se os aspectos deperformance, 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 queuma equipe possa desenvolver de forma adequada as atividades. Porém, é ainda maisimportante maximizar a interação e colaboração entre os indivíduos. Tanto no Lean comono desenvolvimento ágil de software busca-se o fortalecimento das pessoas através dacriação de equipes multidisciplinares e auto-responsáveis, de maneira que uma únicaequipe seja formada de modo completo, compreendendo todos os conhecimentos ehabilidades necessárias para transformar a visão em produtos que gerem valor efetivopara 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 paraentregar tal valor. A figura 6 demonstra como uma equipe ágil pode ser formada.
  14. 14. Figura 6. Equipe ágil De fato, todo processo de desenvolvimento ágil é adaptativo e o modelo de equipeadequado deverá ser definido de acordo com o projeto em questão. Aqui vamos explorar e estabelecer como base a diferença entre os modelospropostos pelo Lean e pelo Scrum. Na figura 6 há o modelo proposto pelo Lean, que de certa forma é bastante similarao proposto pelo Scrum, todavia com algumas importantes diferenças. A primeira delasestá no papel do Product Champion ou engenheiro chefe do produto. Como o próprionome já diz, o Engenheiro Chefe é o responsável final pela arquitetura e pelas principaisdecisõ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ávelpor 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 asnecessidades mercadológicas e detém o conhecimento tecnológico necessário para liderartodo o processo de desenvolvimento e, consequentemente, guiar toda a equipe nocumprimento de seus objetivos. Na Toyota, por exemplo, o Engenheiro Chefe é alguémque tem muitos anos de prática, em geral de 15 a 20 anos de experiência com a cultura daorganização. Ademais, ele também procura viver as experiências dos clientes. Em algunscasos, o Engenheiro Chefe realmente se muda para viver com uma família que tem operfil de seu cliente alvo, para vivenciar na prática seus hábitos e costumes. Só assim eleterá subsídios suficientes para desenvolver produtos de sucesso. Uma equipe Lean multidisciplinar completa será formada por subequipes quecontemplam expertise em negócios, marketing, vendas, engenharia, arquitetura, design e
  15. 15. produção. A comunicação entre estes experts deve sempre ser a mais direta e eficazpossí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 entregaincremental de valor efetivo.. É fundamental uma equipe saber identificar o que é valor equal a porção mínima de software necessária para entregar tal valor. Por isso, cita-sepropositadamente 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 decompetências. Ele garante que a criação de competências esteja inserida implicitamenteno processo de desenvolvimento. Não precisamos necessariamente parar a equipe parareceber um treinamento, mas é fundamental garantir que o aprendizado ocorra durante odesenvolvimento. Logo vamos abordar como as técnicas de engenharia que estão na baseda pirâmide e o desenvolvimento iterativo permitem a aquisição on-the-fly deconhecimento. Com relação ao Scrum, a principal diferença na formação da equipe é que oProduct Owner não possui conhecimento técnico suficiente para influenciarprofundamente nas decisões técnicas, bem como a equipe não conhece o negócio a pontode 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 omodelo de equipe do Lean é melhor do que o do Scrum e vice e versa. Ambos têm prós econtras e serão mais apropriados de acordo com cada tipo de projeto.
  16. 16. Quebrando a Visão Uma vez que a organização tenha definido adequadamente sua visão e estratégiade negócios partimos para a implementação, aplicando os princípios e valores do Lean edo desenvolvimento ágil nas demais camadas da organização. Dependendo do nível dematuridade da empresa e das características dos projetos, ela poderá optar por usar Scrumou Kanban para criar um processo de entrega de valor. Antes disso, precisamos quebrar avisão em objetivos menores que sejam específicos e mensuráveis. Tanto no Scrum quantono 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 sobreScrum e Kanban.Estórias Uma estória, ou User Story, é uma frase simples que descreve uma necessidadeou requisito de sistema. Estórias são utilizadas no desenvolvimento ágil paraespecificaçã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 necessidadede uma formalização burocrática, adicionando agilidade no processo e facilitando oplanejamento. Uma estória pode ser considerada a funcionalidade em si dentro do ciclo dedesenvolvimento de software. A estória, em geral, é uma requisição do Product Ownerque, passada para o time de desenvolvimento, se transformará em uma porção dosoftware funcionando. Detalhes sobre a estória emergem durante as discussões nassessõ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, quandonecessário. O time de desenvolvimento colabora com o ciclo de vida das estórias na medidaem que as transforma para que possam ser classificadas como SMART:• eSpecífico: refere-se a uma intervenção pontual no software e não aodesenvolvimento de um artefato muito grande ou complexo;• Mensurável: deve ser possível mensurar o custo de desenvolvimento e o valorgerado, 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 deveser um objetivo possível de ser alcançado, cujo comprometimento com a entrega porparte da equipe seja efetivo;• Realista: A tecnologia escolhida deve contemplar de forma realista fatores comocusto, tempo disponível e capacidade técnica da equipe;• Time-boxed (tempo fixo para o desenvolvimento): uma estória deve ser planejadapara ser entregue por inteira dentro de um ciclo de desenvolvimento. Porém, em umeventual atraso, ela não deve ser motivo para atrasar ou adiantar a entrega do ciclo.
  17. 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 respeitode um determinado assunto. Estórias são geralmente escritas em cartões (post-its) efixadas na parede (quadro de estórias), onde compõem uma lista chamada ProductBacklog. O Product Backlog é uma lista de estórias em constante priorização querepresenta o escopo do produto. Esta lista é mutante, já que no desenvolvimento ágil asmudanças de escopo são bem vindas a qualquer momento durante o desenvolvimento.Figura 8. BacklogEstimativas e velocidade de desenvolvimento Estórias contêm estimativas e a responsabilidade por estimá-las é única eexclusiva do time de desenvolvimento. Delegar esta responsabilidade ao time é umaforma efetiva de garantir o comprometimento, já que nenhuma meta é imposta, mas simproposta pelos próprios engenheiros de software. A experiência do desenvolvimento ágil de software mostra a ineficácia do uso deuma medida de tempo (horas ou dias) para estimar o custo de uma estória. As estimativassão feitas em story points (sp), medida exclusiva de esforço, que demonstra o tamanho deuma estória comparada a outras. A tarefa de estimar em story points é livre dapreocupação sobre o tempo de duração do projeto. Story points liberam o time dedesenvolvimento da pressão por datas, possibilitando o foco na complexidade da estória.
  18. 18. Para acomodar as incertezas de estórias de grande porte, costuma-se utilizar a escalaFibonacci para atribuição dos pontos, já que ela inicia com uma granularidade menor noprimeiros 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 dedesenvolvimento nos intervalos entre um número e outro na escala. A previsibilidade com a completude das estórias em datas específicas vem daunião das estimativas com o conceito de velocidade. A velocidade do time dedesenvolvimento é descoberta com a informação histórica sobre quantos story pointsforam completados nas últimas iterações de desenvolvimento. A representação develocidade pode ser por iteração ou mesmo por dia: 20sp por iteração ou 2sp/dia, porexemplo. Desta forma, quando o time inicia uma nova jornada com 10 dias dedesenvolvimento, pode se comprometer com a entrega de software funcionando com umgrupo de estórias que somam aproximadamente a sua velocidade média nas últimasiteraçõ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 ouquatro iterações a velocidade estabiliza em sua capacidade máxima. Entradas ou saídasde integrantes da equipe podem também afetar a velocidade, mesmo depois do grupo teratingido uma estabilização da velocidade. Vale salientar que o custo de uma estória varia de equipe para equipe e de épocade desenvolvimento para época de desenvolvimento. É correto utilizar velocidade enú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 deuma análise mais subjetiva. Além disso, a velocidade descoberta é uma média das últimasiterações, sendo normal na iteração atual um resultado com desvio para mais ou paramenos. No caso de variação positiva da velocidade, mais estórias podem ser inseridas naiteração. Quando a velocidade varia negativamente, as estórias de menor prioridade sãocortadas da iteração.Priorização Estórias de desenvolvimento normalmente são criadas pelo Product Owner, masoutras pessoas podem exercer esta função. Estórias de manutenção corretiva podem sercriadas por uma equipe de suporte. Estórias de refactoring criadas pelo time dedesenvolvimento e estórias de novas funcionalidades. em geral, podem ser criadas poruma 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 investimentocertamente realizará um bom trabalho de priorização. Uma priorização adequada pode
  19. 19. levar o desenvolvimento a alcançar um nível de produtividade representado pela Lei dePareto. A Lei de Pareto diz que, com 20% do esforço de desenvolvimento, pode-se gerar80% do valor no software. O mesmo poderá ser observado durante a manutençãocorretiva 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 ParetoDiversas técnicas de priorização podem ser utilizadas, e dentre elas podemos citar ocálculo do Retorno do Investimento (ROI), onde se mensura o custo do desenvolvimentoe o valor gerado, a técnica MoSCoW (Must, Should, Could, Wont) e a análise de Kano.O cálculo do ROI é realizado elencando-se diversos fatores, como custo dodesenvolvimento, custo da estrutura física de desenvolvimento e produção, e aspectoscomo capacidade de aumento nas vendas, conquista de novos clientes ou mesmo aretenção de atuais clientes. Para tanto, uma análise mais aprofundada, reunindoespecialistas 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 doProduct 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 defato 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 equipesmenos experientes.A Análise de Kano é um modelo de desenvolvimento de produtos criado nos anos 80pelo professor Noriaki Kano, que classifica as preferências dos consumidores em cincocategorias.
  20. 20. Figura 10. Análise de KanoPlanejamento e Controle da ProduçãoUma vez tendo conhecimento sobre o que é preciso ser desnevovido e sua adequadapriorização, é preciso também compreender como planejar e controlar a entrega dosartefatos. É isso que iremos explorar neste tópico.Ciclos: releases, iterações e entrega contínua
  21. 21. Uma das principais características da complexa tarefa de criar produtos desoftware que funcionem corretamente e atendam as expectativas do cliente é aimprevisibilidade, o que dificulta muito o processo de planejamento e controle. Parareduzir esta imprevisibilidade, processos tradicionais de desenvolvimento confiam emplanejamentos intensivos para longos períodos, tentando identificar e mitigar todos osriscos possíveis logo de início. Ao longo dos anos descobriu-se que esta estratégia nãofunciona devido à própria natureza incerta do desenvolvimento de software e dosnegócios onde normalmente são aplicados.Através deste aprendizado, o Lean e as metodologias ágeis propõem ciclos curtos deplanejamento e entrega, nos quais uma parte do produto final é projetada, desenvolvida etestada dentro de um período curto, chamado iteração ou Sprints no Scrum. Observemque não estamos falando de protótipos, e sim de uma parte do produto final que pode serutilizada em produção e será continuamente melhorada e incrementada, iteração apósiteração, respondendo às mudanças impostas pelo mercado e pela tecnologia, até queatinja o escopo necessário.Figura 11. Esqueleto Scrum Ciclos curtos de desenvolvimento proporcionam maior feedback e aprendizadopara todos os envolvidos no processo de desenvolvimento. Esta é uma das formas decapacitação implícita no processos de desenvolvimento que citamos anteriormente,essencial para um ambiente Lean maduro. Com mais conhecimento, as equipes passam adiminuir a incerteza e trabalham ancoradas em um processo confiável de entregas deproduto de alta qualidade e valor agregado. Com maior confiabilidade e previsibilidade é possível fazer um planejamento dereleases para o projeto, considerando as regras adequadas de priorização e a velocidadeda equipe de desenvolvimento. Desta forma, os releases são entregas maiores que
  22. 22. contemplam o que foi desenvolvido durante algumas iterações e, associado a um objetivobem definido, o planejamento passa a ser uma forma valiosa de satisfazer as necessidadesde mercado do cliente. Como são priorizadas as funcionalidades que geram maior valor e têm maior riscopara o projeto, os ciclos curtos propiciam um produto de alto valor agregado, diminuindoos riscos e o time-to-market. Consequentemente, a vantagem competitiva do clientetorna-se indiscutível.Entrega contínua com Kanban Quando a equipe atinge um alto nível de maturidade, os ciclos dedesenvolvimento tornam-se cada vez mais curtos e eventualmente a parada paraplanejamento das iterações pode se tornar um desperdício. O Kanban pode ser utilizadopara amadurecer o workflow e aumentar a eficiência do sistema, promovendo a entregacontínua de software e o aumento da produtividade da equipe. De forma simplificada, o Kanban é um processo de produção puxado que mapeiaas etapas de desenvolvimento. Para cada etapa identificada, ele estabelece limites para aquantidade de trabalho sendo realizada simultaneamente. Os limites superiores auxiliam aminimizar a multi-tarefa, neste caso nociva à produtividade da equipe. Limites inferioresvã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 epotencializando ao máximo a entrega e, consequentemente, vazão de valor. Onivelamento da produção (Heijunka) é necessário para evitar os períodos em que ocorredemanda 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 dojipe para ajudar a desatolar o carro que atolou. Dentre outros benefícios, o Kanban auxiliana gestão visual do fluxo de trabalho, melhorando a comunicação e os processos depriorização. O Kanban também permite um foco grande na qualidade, através de seuscrité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 tudoo que ocorre durante o ciclo de desenvolvimento. De fato, os métodos ágeis propiciamuma oportunidade diária para análise de riscos e tomada de decisão de modo a corrigir omínimo desvio indevido de curso. Todas as ocorrências são disponibilizadas através dasferramentas de gestão como dashboard e burndown charts para todos os membros do
  23. 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 maioraprendizado e feedback concreto sobre o exato andamento do projeto, gerando maiorsegurança e consequente aumento de auto-estima para todos os envolvidos. Com base nas ferramentas e técnicas de metodologias ágeis, visibilidade e controlesã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 estemotivo, colocamos na base as práticas de Engenharia de Software que permitem umaefetiva e segura adoção de métodos ágeis. A utilização de Scrum ou Kanban para gestãodos projetos deixa mais fácil a tarefa de responder às mudanças e adequar oplanejamento. Entretanto, se não houver uma base de código sustentável, essa respostadespreparada à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 doManifesto ágil.Testes Automatizados Testes automatizados são certamente uma das mais fundamentais técnicas dedesenvolvimento de software, que permite uma adição severa de qualidade ao código. Ogrande objetivo é criar esta qualidade durante a construção do código, ao invés de testá-lomais tarde. Em geral, equipes que não investem na criação de testes automatizadosnecessitam de um longo período de testes ao final de cada ciclo de desenvolvimento. Esseinvestimento tardio na qualidade compromete o conhecimento da real situação do
  24. 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 feedbackdos testes mesmo durante o desenvolvimento do software. A grande vantagem destaabordagem, é o fato de se poder testar todo o sistema facilmente, a partir de apenas umbotão na IDE. A reprodutibilidade dos testes encoraja sua execução, minimizando anecessidade 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, queexercitam o código de produção. Os testes confeccionados variam na sua abrangência eno 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 AutomatizadosQuanto 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. 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 naescrita de código limpo e habilitando o refactoring para melhoria contínua. Especialistasde negócio podem usufruir de testes automatizados para certificarem-se de que seumodelo de negócio segue efetivo e aceito, mesmo durante a contínua evolução da base decódigo.Automatização do Ambiente A Engenharia de Software requer que processos repetitivos sejam executadosinú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 deexecuçã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 umaequipe dedicada e muito disciplinada. No entanto, a propensão a erros durante a execuçãoda 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 seuambiente.Builds Automatizados Existem ferramentas que podem auxiliar a automatização dos processosrepetitivos de desenvolvimento. Tais ferramentas podem variar de acordo com atecnologia. Alguns exemplos são: Make, Ant e Maven. Para as tecnologias Java, os maisutilizados são Ant e Maven, ambos da Apache Software Foundation. Tratam-se deferramentas para execução de rotinas descritas como instruções codificadas em arquivosde configuração XML, comumente chamados de builds. Devido às contribuições da comunidade de desenvolvimento, estas ferramentaspossuem várias extensões e recursos que envolvem compilação de código em váriaslinguagens, execução de testes (incluindo, mas não se limitando ao padrão xUnit), enviode 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 emque são utilizadas. Porém, de maneira geral, a compilação, empacotamento e testes doartefato de software desenvolvido são os principais objetivos. A utilização intensapropicia a coleta e a geração de artefatos para gestão da configuração que permitem aanálise do desenvolvimento, adesão aos padrões e tomada de decisão quanto à qualidadedos artefatos gerados (veja o tópico Software Intelligence para mais informações dosbenefícios e meios).
  26. 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 eautônoma. Por exemplo, a suíte de testes e a rotina para executá-los não obterão osbenefícios desejados caso não sejam executados a cada contribuição dos desenvolvedoressobre o código fonte do software objeto do projeto. O disparo do processo de execuçãoperiódica poderia ser executado pelo pessoal responsável por qualidade. Entretanto, assimcomo a execução de processos repetitivos, delegar esta responsabilidade comumenteresulta em falhas e consequente desperdício. Para tal, ferramentas de monitoramento de contribuição e execução automáticaestão disponíveis, dentre elas: Apache Continuum, Hudson, LuntBuild e CruiseControl.Trata-se de um serviço disponibilizado na infraestrutura de desenvolvimento, geralmenteem um servidor dedicado para o fim de integração contínua. Os servidores de integração contínua comumente são configurados com umambiente web, com suporte a ferramentas de comunicação (como e-mail e instantmessenger) e link com outros servidores como Servidor de Controle de Versões eServidor de Homologação. Estes recursos ampliam as capacidades dos buildsautomatizados, que podem publicar os relatórios gerados no ambiente web, enviarnotificações aos desenvolvedores e outros interessados quanto ao status dos testes, entreoutras possibilidades.
  27. 27. Figura 13. Ambiente de Integração ContínuaA figura 13 mostra três servidores: Servidor de Controle de Versões (SCV), Servidor deHomologação (SH) e Servidor de Integração Contínua (SIC). Note que osdesenvolvedores colocam suas contribuições ao projeto no SCV. O SIC, continuamentemonitora o SCV em busca de modificações. Dada uma modificação detectada, o SICatualiza sua cópia do projeto com as últimas atualizações detectadas, estando assim emsincronia com o SCV, e então executa o build automatizado do projeto. Este build executará todas as rotinas automatizadas e poderá se valer do ambientedo SIC para fazer o deployment da nova versão do software em um servidor parahomologação (SH). É possível também gerar relatórios para acompanhamento e tomadade decisões em um ambiente web disponibilizado no próprio SIC.
  28. 28. Software Intelligence Software intelligence refere-se às habilidades, tecnologias, aplicações e práticasutilizadas para ajudar a todos os envolvidos a entender melhor o contexto do negócio:desenvolvimento de software. Para tal, existem ferramentas livres que possibilitam avarredura 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 sistemade builds automatizados, podem ser consideradas inteligência de software quando sãocombinadas com um processo que busca melhoria contínua. Na prática, nas reuniões deretrospectiva e nas estórias de refactoring, os relatórios de inteligência do software sãofontes importantes de suporte a decisão. A seguir, são apresentadas algumas dasferramentas 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. 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á analisadoconfrontando o custo de manutenção do ambiente de software intelligence, com o valorgerado pelo mesmo. Uma escolha bem feita de um subconjunto destas ferramentas tem opotencial de formar um relatório significativo sobre o estado do desenvolvimento de umsoftware.Intercalando Tecnologia, Pessoas, Processos e Ferramentas Em todos os níveis da Pirâmide Lean é possível encontrar elementos trabalhandoem conjunto para criação de valor na organização. Podemos observar que falamos semprede pessoas, processos e ferramentas - tudo isso para a criação da melhor tecnologia. OLean chama este processo de Systems Thinking, e orienta a olhar para a junção depessoas, processos e ferramentas como um sistema, que precisa ser afinado e regulado demodo 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 aplicadascorretamente, formamos uma base sólida para que a visão da organização sejarapidamente implementada e entregue com a mais alta qualidade. O correto equilíbrio nadefiniçã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ênciapermitirá a criação de uma cultura baseada em relacionamentos fortes e duradouros,estimulando a criatividade e a inovação. Responsabilidade, disciplina, senso depropriedade, capacidade de auto-gestão, respeito e colaboração permitirão a criação deuma 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 atornar-se mais produtiva, humana e sustentável.Leads:Do que se trata o artigo:
  30. 30. Neste artigo veremos como equilibrar a aplicação de práticas, princípios evalores no desenvolvimento de software afim de criar uma culturaorganizacional enxuta e ágil.Para que serve: O conceito abordado neste artigo serve para a criação, adoção edisseminação da cultura Lean e Ágil de forma efetiva em uma organização quedesenvolve software.Em que situação o tema útil: Qualquer empresa que visa aprimorar seus métodos de desenvolvimentovai usufruir do conhecimento descrito neste artigo.Linkshttp://prezi.com/w6pjte9n4bsq/the-lean-pyramid/ - apresentação da Pirâmide Lean na webhttp://onca.st/blog - blog da OnCast Technologieshttp://www.agilealliance.org - site da Agile Alliance (rico em artigos)http://www.poppendieck.com/ - site de Mary & Tom Poppendieck, criadores do Lean SoftwareDevelopment

×