Título: [A Pirâmide Lean]

Transcrição

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 atua como engenheiro de software construindo sistemas de missão crítica desde 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 Ágiles 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 , 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, 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 , 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).