ANÁLISE DA APLICAÇÃO DO LEAN THINKING NA PERSPECTIVA DA TECNOLOGIA DA INFORMAÇÃO COM ÊNFASE EM PROCESSOS DE SOFTWARE Rafael Brito dos Santos1 Professor(a) orientador(a): Prof. MSc. Eder Junior Alves MBA em Análise de Processos de Negócios
RESUMO Este artigo abordará a filosofia Lean Thinking, sua tradução é “Pensamento Enxuto” ou “Mentalidade Enxuta”. O Lean Thinking ou apenas Lean, originado do Sistema Toyota de Produção, é uma filosofia consolidada na área produtiva, que tem como principais objetivos, o aumento da produtividade e eficiência, e a eliminação de desperdícios. Nos últimos anos, o Lean tem sido utilizado em diversos setores tais como: financeiro, serviço, saúde, agronegócio, entre outros. A TI (Tecnologia da Informação), por sua vez, não poderia ficar de fora e nos dias de hoje tem adotado o Lean em sua estrutura. A TI tem presença em todos os setores e sua participação no desempenho produtivo e administrativo das organizações é uma realidade, contribuindo de forma significativa na geração de valor ao cliente, seja ele interno ou externo. Sendo assim, o Lean será exposto segundo uma perspectiva voltada à TI, objetivando explanar e analisar as maneiras como esta poderá tirar proveito do mesmo, para um melhor desempenho das organizações e seus processos de software. E identificar consequentemente, como a TI pode gerar resultado para a empresa, bem como agregar valor para o principal agente, o cliente. A pesquisa é de natureza aplicada exploratória, objetivando o levantamento de conteúdo acerca do tema em questão. Destacar-se-á a importância dada aos princípios Lean e a eliminação de desperdícios, assim como alguns métodos pesquisados para auxiliar na avaliação da efetividade do Lean. Concluindo-se, com a ênfase sobre a necessidade de se buscar a mudança de cultura nas organizações e a ciência de que uma implementação Lean, não deve ser vista como algo trivial, e que existirão desafios, tal como qualquer outra iniciativa que envolva pessoas e mudanças de hábitos e comportamentos humanos. Palavras-chave: Lean. Tecnologia da Informação. TI. Desenvolvimento de Software.
1
Rafael Brito dos Santos é graduado em Engenharia da Computação pela UEA (Universidade do Estado do Amazonas).
ABSTRACT This article aims to broach the philosophy Lean Thinking, its translation is “Pensamento Enxuto” or “Mentalidade Enxuta”. Lean Thinking or just Lean, originated from the Toyota Produtcion System, is a consolidated philosophy in the production área, which has as main objectives, of increasing productivity and efficiency, and waste disposal. In the last years, Lean has been used in various sectors such as: financial, service, health, agribusiness, among others.The IT (Information Technology) in turn, could not stay out and today has adopted Lean in its structure. IT has a presence in all sectors and their participation in the productive and administrative performance of organizations is a reality, contributing significantly in generating customer value, whether internal or external. So, Lean will be exposed according to a focused on IT perspective, aiming to explain and analyze the ways in which it can take advantage of it, for a better performance of of organizations and their software processes. And identify consequently how IT can generate income for the company, as well as add value to the principal agent, the customer. The research is nature applied exploratory, aiming the gathering content on the subject in question. It will highlights the importance placed on the Lean principles and waste disposal, as well as some methods researched to aid in assessing the Lean effectiveness. Concluding, with the emphasis on the need to seek change of culture in organizations and the science that a Lean implementation, should not be seen as something trivial, and that there will be challenges, as any other initiative involving people and changes in human habits and behavior. Keywords: Information Technology. IT. Software Development.
1
INTRODUÇÃO
Uma das palavras de ordem, bastante em voga na atualidade é “produtividade”. Com a crise econômica que assola o país e o mundo, este tema se intensificou sobremaneira. Empresas buscam de inúmeras maneiras, meios que a tornem mais eficientes e produtivas, tendo em vista, a batalha contra a concorrência e assim, continuação de sua existência no mercado. Contudo, o foco em ganho de produtividade comumente é direcionado à área produtiva das Empresas, principalmente quando nos referimos às indústrias. Deixando-se normalmente de lado os demais setores administrativos e a TI (Tecnologia da Informação), ou como Bell e Orzen (2013) definem, “Organização de TI”. A organização de TI atual enfrenta um claro imperativo: reduzir custos e aperfeiçoar o serviço. Ao mesmo tempo, deve assumir o papel ativo de liderança para promover as mudanças – melhoria contínua, inovação e agilidade – em toda a empresa, de modo a garantir processos eficientes e flexíveis que criem valor e estabeleçam a preferência aos olhos de cada cliente (BELL; ORZEN, 2013, p. xxi).
Bell e Orzen (2013, p.3) descrevem ainda alguns dados relevantes: Em 2008, bancos e financeiras gastaram em média 6,9% de suas receitas em TI; Em assistência médica foi 4,7%; Tomando por base uma pressuposição conservadora de que 20% desses investimentos não acrescentam valor para o cliente, os números são ainda mais altos. Diante de cenários como estes, surge a dúvida, é possível a TI mudar essa sua imagem negativa? Como a mesma pode melhorar, frente aos seus processos e geração de valor à uma organização e seus clientes? Estudiosos voltaram seus olhares para o lean, filosofia que se originou do Sistema Toyota de Produção, focada em aumento de produtividade e redução de desperdícios. “O lean se expandiu para além das fronteiras da produção automobilística, chegando a outros ramos de produção incluindo a área de serviços. Essa expansão para várias áreas de aplicação foi denominada lean thinking” (CANTANHEDE, 2014, p. 19). Nessa expansão, a filosofia chegou à TI, intitulada como Lean IT ou Lean TI. Propondo e adequando uma série de princípios e práticas a serem adotadas, com o intuito de melhorar a TI quanto a seus processos e geração de valor às organizações e ao cliente. “Uma das áreas de aplicação do lean em TI é a área de desenvolvimento de software. O desenvolvimento de software enfrenta os desafios de entregar produtos com qualidade, de forma rápida e com a necessidade de constantes ajustes (mudanças)” (CANTANHEDE, 2014, p. 19).
1.1
OBJETIVOS
Mediante contextualização acima este trabalho tem por objetivos: 1.2
Identificar como a TI pode gerar valor ao cliente (interno/externo); Explanar como a TI pode melhorar seu desempenho, utilizando-se de uma filosofia consolidade na área operacional (produtiva); Analisar a aplicação dos princípios e ferramentas Lean dentro da TI, sobretudo na área de desenvolvimento de software. PLANO DE ASSUNTO
Este trabalho visa discorrer a respeito do lean aplicado à TI, detalhando um pouco mais sua aplicação frente aos processos de software e está organizado da seguinte maneira: a seção 2 aborda a metodologia utilizada para desenvolvimento da pesquisa, na seção 3 encontra-se o referencial teórico que fundamentou este trabalho, a seção 4 aborda sobre a implementação do Lean IT, a seção 5 descreve desafios enfrentados em implementações de Lean IT, a seção 6 contém uma análise e discussão dos resultados e por fim a seção 7 contém a conclusão e comentários referentes à pesquisa realizada. 2
METODOLOGIA DE PESQUISA
A metodologia adotada constou de uma pesquisa de natureza aplicada exploratória, tendo “como finalidade proporcionar mais informações sobre o assunto” (PRODANOV; FREITAS, 2013, p. 51), abordando temas pertinentes à filosofia Lean, aplicadas à Tecnologia da Informação com ênfase em processos de software. Dentre os métodos e procedimentos técnicos utilizados, deram-se por meio de uma pesquisa bibliográfica, como define Prodanov e Freitas (2013, p. 52), elaborada a partir de material já publicado, extraídos de livros, internet, artigos, teses e e-books que abordam os princípios e práticas da filosofia Lean, direcionada à TI. Findando com a análise e discussão dos resultados, onde são elencados alguns métodos propostos por alguns dos autores de obras pesquisadas, demonstrando estudos que têm sido feitos e aplicados no meio Lean IT, observando assim ações mais práticas envolvendo o Lean IT que podem vir a ser adotadas e até mesmo aprimoradas. 3 3.1
REFERENCIAL TEÓRICO BREVE HISTÓRIA DA MELHORIA CONTÍNUA
A melhoria de processos sempre buscou concentrar-se em sanar problemas para melhorar eficiência, produtividade e qualidade. Na visão de Bell e Orzen (2013) a evolução da melhoria dos processos se deu em três etapas: administração científica, engajamento e integração.
3.1.1 A era da administração científica: 1890-1940 Através de Frederick Taylor, Frank e Lilian Gilbreth, Henry Ford e outros, no final do século XIX, foi inaugurado um período de eficiência e produtividade, com a introdução de métodos padronizados de fabricação, simplificação e divisão do trabalho. Seguido por Walter Shewhart que em 1918 foi o primeiro a usar controle estatístico para aperfeiçoar a qualidade. Nesta era de ênfase na produção, registraram-se ganhos superiores a 300% em termos de produtividade. Contudo, neste período, os operários eram vistos apenas como meros executores que poderiam ser trocados a bel-prazer e deveriam seguir as ordens dos patrões, cabendo aos cargos administrativos o pensar em soluções de problemas, operários sentiam-se entediados e eram pagos para atingir as metas de produção. 3.1.2 A era do engajamento: 1940-1995 Durante a Segunda Guerra Mundial, o Ministério de Guerra dos Estados Unidos lançou um programa inovador intitulado Training Within Industry – TWI (Treinamento dentro da Indústria), onde era incentivada a participação do trabalhador, a solução de problemas direcionada à produtividade, o treinamento de supervisores, a documentação dos processos de trabalho e os programas de melhoria contínua que acelerassem a produção e aumentassem a qualidade. Neste período, W. Edwards Deming, Joseph Juran e Armand Feigenbaum introduziram o Movimento pela Qualidade pregando respeito pelos operários, qualidade na fonte, capacitação dos funcionários, resolução de problemas em equipe, e ouvir os clientes para definir valor, transferindo assim, a ênfase na produtividade, para a agregação de valor para o cliente. Após a guerra, Taiichi Ohno e Shigeo Shingo, na Toyota, entre outros profissionais no Japão adotaram as ideias de qualidade e melhoria contínua e desenvolveram o Sistema Toyota de Produção, iniciando as bases para a filosofia lean dos dias atuais. Na década de 1980, surgiu o Seis Sigma, que consistia na aplicação de estatística rigorosa aos processos de melhoria. Posteriormente surgiu a Teoria das Restrições, com Eliyahu Goldratt, após sua publicação de “A Meta” em 1984, que demonstrava que restrições (gargalos) limitavam a produtividade. Em 1990 finalmente, com a publicação de “A Máquina que Mudou o Mundo”, de Womack, Jones e Roos do MIT, que analisava o Sistema Toyota de Produção, introduziu-se o termo lean. “Embora a Era do Engajamento testasse a ideia de envolver as pessoas para estimular a melhoria contínua, ainda havia um longo caminho a percorrer para atingir a visão de Deming, pois muitas empresas não conseguiam atrair o coração e a mente de seus funcionários” (BELL; ORZEN, 2013, p. 15). 3.1.3 A era da integração: 1996 até o presente De acordo com Bell e Orzen (2013) em meados da década de 90, empresas de todo o mundo começavam a aplicar conceitos lean, seis sigma, entre outros métodos de melhoria contínua, não mais somente no chão de fábrica, como também em escritórios, cadeia de suprimento, desenvolvimento de software. Setores não ligados à manufatura perceberam que as técnicas lean
podiam gerar resultados significativos. Parcerias foram formadas com intuito de desenvolver integração entre processos. Avanços na computação como velocidade, funcionalidade e custos auxiliaram na integração de sistemas e comunicação das empresas. Em 1996, com a publicação do livro “A Mentalidade Enxuta nas Empresas”, enfatizavase a incorporação da melhoria aos fluxos de valor, disseminando a atual era de integração dos métodos de melhoria a todas as funções da empresa e a todos os setores da economia, inclusive assistência médica, seguros, instituições financeiras e organizações não governamentais (BELL; ORZEN, 2013, p. 16).
Vide Figura 1 para observar a evolução da melhoria contínua ao longo do tempo. Figura 1 – Evolução da melhoria contínua
Fonte: Bell e Orzen (2013, p. 17)
3.2
LEAN E SEUS PRINCÍPIOS
“O pensamento Lean é um modelo de gestão, que se preocupa com o desenvolvimento das pessoas, processos, e sistemas com o objetivo de reduzir ou eliminar o desperdício das atividades produtivas, proporcionando desta forma mais valor para a organização” (SOFT EXPERT). O Lean “também pode ser entendido como um sistema de gestão e também uma estratégia de negócios voltada exclusivamente para aumentar a satisfação dos clientes” (LEAN TI). O termo Lean ou Lean Thinking possui cinco princípios que devem ser considerados na seguinte sequência: Valor (definir o que é valor sob a ótica do cliente), Fluxo de Valor (identificar o fluxo de valor e redefinir os processos, restando apenas o que gera valor ao cliente), Fluxo Contínuo (estabelecer um fluxo para os processos que restaram), Produção Puxada (fazer apenas quando o cliente solicitar) e Perfeição (ou Kaizen – melhoria contínua de tudo que está envolvido no fluxo de valor) (LEAN TI, grifo do autor). Vide Figura 2.
Figura 2 – Os cinco princípios do Lean
Fonte: EXIN (2014)
Assim, pode-se observar que a essência do Lean está em procurar fazer mais com menos, buscando ao máximo, zerar desperdícios, ou seja, acabar com tudo aquilo que não agrega valor ao cliente, transformando o cliente no foco, maximizando valor ao mesmo. 3.2.1 Identificar os clientes e especificar valor Apenas uma pequena fração do tempo total e esforço em qualquer organização realmente agrega valor ao cliente final. Ao definir claramente os valores de produtos específicos e/ou serviços do ponto de vista do cliente, todos os desperdícios podem ser eliminados (TECHEXCEL, tradução nossa). 3.2.2 Identificar e mapear o fluxo de valor Um fluxo de valor são as atividades através de todas as áreas de uma organização envolvidas na entrega de um produto ou serviço. Isto representa o processo ponta a ponta que oferece valor para o cliente. Após ter definido a exigência do cliente, o próximo passo é identificar como está sendo entregue ao mesmo (TECHEXCEL, tradução nossa).
3.2.3 Criar fluxo contínuo eliminando desperdício Quando se está mapeando o fluxo de valor se percebe que apenas 5% a 50% das atividades efetivamente agregam valor. Eliminando tais desperdícios garante que o produto ou serviço “flua” para o cliente sem interrupções, desvios ou atrasos (TECHEXCEL, tradução nossa). 3.2.4 Responder à puxada do cliente Puxada seria entender a demanda do cliente e ir adaptando o processo para responder à mesma. Essencialmente isso significa que se deve produzir apenas o que o cliente quer, quando o cliente quiser (TECHEXCEL, tradução nossa). 3.2.5 Perseguir a perfeição Criando um fluxo contínuo juntamente com a puxada, encontrar-se-ão mais e mais camadas de desperdício que se tornarão visíveis. Esse processo contínuo, permanece em direção à perfeição, onde cada recurso e cada ação agrega valor para o cliente (TECHEXCEL, tradução nossa). 3.3
LEAN EM PROCESSOS DE SOFTWARE
De acordo com Bell e Orzen (2013) investimentos em tecnologia só têm aumentado, nas empresas brasileiras, sobretudo em serviços, o problema em questão, é que em matéria de prazo e qualidade (na visão dos clientes) os produtos gerados têm ficado aquém do esperado. “Para piorar, para a alta administração, isso tem se caracterizado apenas como despesa, e a TI como uma grande caixa preta de desperdícios. Essa relação da TI com os departamentos aos quais ela serve e depende está carregada de estresse” (BELL; ORZEN, 2013, p. xix). Se olharmos para dados do CHAOS Report, do Standish Group, observamos que no ano passado, apenas 29% dos projetos de TI conseguiram ser bem sucedidos, enquanto 52% foram completados com algum ou alguns tipos de alterações tais como, atrasos, aumento no orçamento ou algum nível de insatisfação e 19% simplesmente falharam. Vide Figura 3.
Figura 3 – Sucesso de projetos de software
Fonte: Hastie e Wojewoda (2015)
E mais, mesmo projetos entregues, apresentam índices críticos com relação ao uso de suas funcionalidades. Segundo dados também do Standish Group, Ventura (2015) enfatiza que 45 por cento das funcionalidades nunca são utilizadas e 19 por cento raramente são utilizadas. E ainda complementa dizendo que, se generalizarmos e considerarmos a soma dos números acima – 64 por cento – é escopo inútil, não gera valor, não é necessário existir. Logo, teoricamente, pode-se concluir que 64 por cento do que é gasto com funcionalidades num software vai para o lixo, é desperdício de recursos. Vide Figura 4. Figura 4 – Frequência de utilização das funcionalidades nos softwares
Fonte: Mariotti (2013)
Diante deste cenário, a filosofia Lean vem para contribuir na melhora destes resultados e da imagem da TI frente às organizações, influenciando práticas de software, surgindo assim a abordagem Lean Software Development. “A utilização do Lean, em projetos de desenvolvimento de software, tem elevado as organizações de tecnologia a um novo patamar de qualidade e valor agregado ao produto entregue” (ARAMUNI, 2015, p. 84). 3.4
PRINCÍPIOS LEAN EM PROCESSOS DE SOFTWARE
“Os princípios Lean apontam meios para aumentar a qualidade do processo e do produto pela aplicação de práticas que afetam o modo de tratar ou executar tarefas e fluxo de trabalho com foco na otimização dos resultados gerais do processo de produção” (POPPENDIECK, M.; POPPENDIECK, T., 2006 apud BASSI FILHO, 2008, p. 72). “Para o desenvolvimento de software, o modelo Lean possui 7 princípios” (POPPENDIECK, M.; POPPENDIECK, T., 2003 apud BASSI FILHO, 2008, p. 71), dos quais a eliminação de desperdício é o principal deles. Em síntese, pode-se afirmar que o foco do Lean “é cortar a “gordura” do processo de software, focando na eliminação de desperdícios” (Steffen 2011). Poppendieck, M. e Poppendieck, T. (2006, tradução nossa) descreve os sete princípios Lean aplicados ao sofyware: 1. Elimine desperdícios; 2. Inclua a qualidade no processo; 3. Crie conhecimento; 4. Adie comprometimentos; 5. Entregue rápido; 6. Respeite as pessoas; 7. Otimize o todo. 3.4.1 Elimine desperdícios Guedes (2011) descreve que da mesma forma que na indústria e demais serviços, para uma mudança Lean é preciso focar na eliminação de todo e qualquer tipo de desperdício em busca da maximização e otimização do rendimento. Já Steffen (2011), destaca que tudo o que não agrega valor para o cliente final e que não é percebido por tal é considerado um desperdício. Quando uma planta de uma fábrica produz mais do que é necessário imediatamente, isto corresponde ao desperdício. Quando um desenvolvedor implementa mais funcionalidades do que são necessárias, isto também corresponde a perdas. O ideal é descobrir o que o cliente deseja e entregar somente o necessário, no menor intervalor de tempo possível. Qualquer obstáculo à rápida satisfação das necessidades do cliente é considerado uma perda (FRANCO, 2007, p. 46-47).
Portanto, os desperdícios podem estar relacionados a dinheiro, recurso, tempo, esforço, espaço. Vale ressaltar que identificá-los não é uma tarefa fácil e que uma forma de auxiliar nesta tarefa é procurar observar o processo e identificar o que gera valor na perspectiva do cliente. Mais à frente, no tópico 3.5 será abordado acerca dos tipos de desperdícios de software. 3.4.2 Inclua a qualidade no processo A ideia deste princípio é não permitir a continuidade de defeitos, corrigindo-os logo que identificados, parando assim a produção (desenvolvimento) para evitar a perpetuação dos mesmos. Busca-se desta forma, fazer o possível para que estes defeitos não sejam detectados somente por parte do controle de qualidade, ou seja, times de testes, por exemplo, sendo sanados imediatamente (Guedes 2011). A equipe deve implementar soluções que a deixem segura de que estão construindo um produto de qualidade. Utilizando uma arquitetura adequada, mantendo uma alta cobertura de testes automatizados e preservando a flexibilidade para mudanças, adaptações e extensões são meios de trazer segurança e motivação para alcançar níveis mais elevados de qualidade. Ao invés de gastar tempo para encontrar e corrigir defeitos, invista os esforços prevenindo-os através de vários tipos de teste (BASSI FILHO, 2008, p. 75).
Algumas dicas sugeridas: Refactoring; Integração contínua; Testes contínuos e automatizados. 3.4.3 Crie conhecimento Também conhecido como Amplificar o Aprendizado. Desenvolvimento é um exercício constante de aprendizagem de descobertas. Existe uma expectativa de que os erros serão feitos, porém aprendemos com os mesmos e fazemos os ajustes. Este aprendizado deve ser compartilhado em um mostruário (ZDUNIĆ, 2015, tradução nossa). Guedes (2011) menciona a importância de se criar conhecimento e partilhá-lo sempre que houver alguma lição aprendida. De tal maneira que não somente a pessoa que cometeu o erro, não torne a cometê-lo, como outras pessoas evitem repetir o feito, uma vez que o conhecimento foi compartilhado. Desta forma, não apenas erros e defeitos são evitados, mas há também contribuição na formação dos colaboradores. Steffen (2011) descreve uma metáfora interessante: Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de reduzir a variação. Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas por chefes de cozinha experientes que de certa forma desenvolveram habilidades e capacidade de combinar os ingredientes disponíveis para produzir o prato desejado. Desenvolver uma receita é um processo de descoberta, até os chefes mais experientes produzem diversas variações de um novo prato, fazem iterações, experimentações, até encontrar a melhor combinação de ingredientes que resulte em um prato rápido e sabor agradável. Não se espera que os chefes obtenham uma receita perfeita de primeira; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é melhor concebido se este fizer parte de um processo de aprendizado similar ao de criar uma
nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pela expansão do conhecimento (Steffen, 2011).
Algumas dicas sugeridas: Incentivar o compartilhamento de conhecimento tácito; Desenvolvimento iterativo; Treinamentos e Mentoring; Wiki. 3.4.4 Adie comprometimentos Bassi Filho (2008) sugere que deve-se adiar comprometimentos, mantendo uma flexibilidade para adaptações a mudanças. Afirma também, que em ambientes com muitas incertezas, fazer previsões se torna uma atividade dificultosa. E enfatiza que adiar decisões permite que estas sejam tomadas fundamentadas em experiências e conhecimentos adquiridos no decorrer do processo. Conforme Aramuni (2015, p. 85), “é recomendado diminuir as incertezas ao longo do processo. Para isso, pode ser que seja necessário adiar decisões e compromissos, até que as decisões possam ser tomadas dentro de um ambiente firme, previsível e conhecido”. Práticas de desenvolvimento que suportam tomadas de decisões tardias são eficientes em domínios que envolvem incertezas, porque elas dão suporte a uma abordagem baseada em opções. Num cenário de incertezas, muitos mercados econômicos desenvolvem opções como uma forma dos investidores evitarem tomadas de decisões errôneas e precipitadas, até o futuro estar próximo o suficiente e mais facilmente previsível. É de grande valor retardar as tomadas de decisões, uma vez que as melhores decisões são tomadas baseadas em fatos, não em especulações. Uma estratégia chave para retardar as tomadas de decisões ao desenvolver sistemas complexos é projetá-los e construí-los de forma a facilitar mudanças futuras (FRANCO, 2007, p. 47).
Algumas dicas sugeridas: Na incerteza, experimente diversas soluções; Iterações; Planning meetings. 3.4.5 Entregue rápido “Rapidez entre um pedido e uma entrega e entre a entrega e as percepções de quem o solicitou permite que o cliente e desenvolvedores aprendam e melhorem através de feedback veloz, atualizado e confiável” (BASSI FILHO, 2008, p. 74). Anteriormente, a entrega de software de maneira rápida era preterida, comparada à estratégia de não cometimento de erros, à qual era dada maior relevância (FRANCO, 2007). Para Guedes (2011), é preferível fazer entregas rápidas, ou seja, entregar logo que possível o trabalho completo, mesmo que não seja o produto final. Aramuni (2015) complementa: entregas rápidas
são fundamentais para colher feedbacks, onde, através destes, pode-se aprender com os erros e garantir que o cliente está recebendo a tempo o que ele necessita. Steffen (2011) sintetiza: “Sem entregas rápidas não é possível colher feedback. Sem entregas rápidas não é possível aprender com erros. Velocidade na entrega garante que o cliente receberá o que ele precisa hoje e não o que ele precisava ontem”. Algumas dicas sugeridas: Pull system - Kanban; Iterações; Seja simples. 3.4.6 Respeite as pessoas Franco (2007, p. 48) diz que “envolver os desenvolvedores nas decisões de detalhes técnicos é fundamental para atingir a excelência. Quando dotados com a experiência necessária e guiados por um líder, eles tomarão decisões técnicas e de processos, melhores que qualquer outra pessoa”. Valorize a equipe de desenvolvimento. A equipe de desenvolvimento é a responsável pela confecção do produto que é entregue ou usado pelo cliente, o software. O conhecimento dos detalhes técnicos deve ser levado em consideração na tomada de decisões e na definição de processos. Não trate as pessoas simplesmente como recursos. Quanto mais a equipe tiver seu trabalho reconhecido, mais motivada e interessada na melhoria de processo ela ficará. Quanto mais a equipe puder contribuir e aprender, mais comprometida ela ficará (BASSI FILHO, 2008, p. 75).
Guedes (2011) apresenta como vantagens deste princípio, ao se respeitar e envolver os colaboradores: maior produtividade, maior pró-atividade e empenho. E quando da transferência de responsabilidade: a detecção de oportunidades de melhoria e a qualidade do produto desenvolvido. Algumas dicas sugeridas: Trabalho em equipe; Feedback; Auto-gestão. 3.4.7 Otimize o todo Poppendieck, M. e Poppendieck, T. (2006, p. 38, tradução nossa) comentam que o “desenvolvimento de software é lendário por sua tendência em subotimizar” e citam dois casos como exemplos:
Círculo vicioso nº 1 (claro, isso nunca aconteceria na sua empresa): o Cliente quer uma nova funcionalidade, “pra ontem”; o Desenvolvedor ouve: faça isso rápido, a todo custo; o Resultado: mudanças feitas de qualquer jeito no código base;
o Resultado: Complexidade do código base aumenta; o Resultado: Número de defeitos no código base aumenta; o Resultado: Há um aumento exponencial no tempo para adicionar funcionalidades.
Círculo vicioso nº 2 (isso também não aconteceria na sua empresa): o Equipe de testes sobrecarregada; o Resultado: Testes ocorrem muito depois da codificação; o Resultado: Desenvolvedores não recebem feedback imediato; o Resultado: Desenvolvedores criam mais defeitos; o Resultado: Equipe de testes tem mais trabalho; o Resultado: O feedback para os desenvolvedores é atrasado mais ainda. Repita o ciclo;
Bassi Filho (2008) é enfático ao descrever que: Otimizações macro canalizam os esforços para aumentar a satisfação dos usuários finais através de um produto consistente. Otimizações pontuais nem sempre são enérgicas quando precisam funcionar simultaneamente. Para resolver problemas, busque e elimine as suas causas, não os seus sintomas. Lean ainda recomenda a escolha de métricas de alto nível que sejam representativas para identificar a evolução. Essas métricas devem levar em consideração também a qualidade e a satisfação do cliente, pois a partir delas será possível avaliar quais trocas são vantajosas (BASSI FILHO, 2008, p. 75).
Outro aspecto recorrente é destacado a seguir: Para obter a integridade nos sistemas de grande complexidade é preciso um conhecimento profundo de diversas áreas. Um dos problemas não tradados no desenvolvimento de produtos é que especialistas de cada área têm a tendência de maximizar o desempenho na parte do produto onde são especialistas, ao invés de focar no desempenho do produto como um todo (FRANCO, 2007, p. 52).
Algumas dicas sugeridas: Olhar para o processo todo, não adianta resolver sintomas, é preciso resolver a causa; Utilize métricas; Diminua o número de métricas de desempenho individual, mas valorize o desempenho da equipe; Satisfação do cliente. 3.5
DESPERDÍCIOS EM PROCESSOS DE SOFTWARE
Como comentado anteriormente, “Eliminar desperdícios”, é considerado um dos principais princípios do Lean em processos de software. “O primeiro passo para aplicar o desenvolvimento de software Lean é executar um trabalho intenso de identificação dos focos de desperdícios e tratar de eliminá-los. Os processos de
desenvolvimento de software e a forma como eles são gerenciados são repletos de desperdícios” (LIMA, 2012, p. 3). “Em meados da década de 1950, Taiichi Ohno introduziu o conceito de eliminação sistemática de desperdícios na Toyota, que resultou no conceito dos Sete Desperdícios observados no Sistema Toyota de Produção:” (BELL; ORZEN, 2013, p. 36). 1. Estoque: ter mais que os níveis mínimos de matéria-prima, estoque em processo e produtos acabados necessários para dar suporte ao fluxo e sistema puxado (o excesso de estoque camufla outros desperdícios). 2. Excesso de produção: produzir mais do que o cliente precisa ou antes do prazo necessário (contribui para outros desperdícios). 3. Superprocessamento: trabalho excessivo ou desnecessário. 4. Transporte: movimentação do produto, informações e materiais de trabalho. 5. Movimentação: movimentação física desnecessária. 6. Espera: interromper ou reduzir a velocidade enquanto espera o trabalho chegar. 7. Correções: retrabalho devido a defeitos e erros, inspeção e refugo. “Quando se abordam os tipos de desperdício no contexto de produção Lean, é possível traçar um paralelo entre a produção e o desenvolvimento de software, de maneira que se podem traduzir os desperdícios para a realidade de tecnologia da informação” (ARAMUNI, 2015, p. 87) conforme exibido no Quadro 1. Quadro 1 – Comparação dos sete desperdícios Produção
Desenvolvimento de Software
Estoques no processo
Trabalho inacabado
Superprodução
Funcionalidades extras
Processamento adicional
Reaprendizagem
Transporte
Transferência de controle
Movimentação
Troca de tarefas
Esperar
Atrasos
Defeitos
Defeitos
Fonte: Poppendieck M., e Poppendieck T. (2011, p. 93 apud Aramuni, 2015, p. 87)
3.5.1 Trabalho inacabado De acordo com Franco (2007), trabalhos inacabados tendem a se tornar obsoletos e até mesmo impedir o desenvolvimento de outros trabalhos que precisam ser realizados. Complementando, “funcionalidades incompletas são desperdício porque despendem esforços para serem iniciadas e não adicionam valor ao software. [...] Por estarem inacabadas, foi um desperdício começá-las” (BASSI FILHO, 2008, p. 72). “Minimizar a quantidade de desenvolvimentos parcialmente
realizados é uma estratégia de redução de riscos, bem como de redução de fontes de desperdícios” (FRANCO, 2007, p. 54). Exemplos: Backlog acumulando nas filas de desenvolvimento, apoio ou melhoria de Software; Software comprado e nunca implantado; Trabalho de desenvolvimento parcialmente concluído – documentação não codificada, código dessincronizado, código não testado, código não documentado, código não utilizado; Diversos códigos-objetos de Software que executam a mesma função. 3.5.2 Funcionalidades extras Para Hugo (2011) este é o desperdício mais sério. Mais funcionalidades, significa: mais código a ser mantido, mais testes a serem realizados, mais documentos a serem criados, mais bugs para aparecerem no sistema, enfim: jogar dinheiro no lixo, sobretudo, se lembrarmos que 80% do total de funcionalidades de um sistema simplesmente não são utilizadas. O pior desperdício seja em TI, manufatura ou escritório é a produção em excesso, pois com ele se carrega todos os outros. Entender claramente os desperdícios e focar em sua redução, começando pela produção em excesso, é o primeiro passo para a conscientização das pessoas e a evolução da organização. Foi dessa maneira que Taiichi Ohno iniciou o Sistema Toyota de Produção (AQUINO, 2013)
Exemplos: Requisitos de Software especificados muito antes da codificação; Desenvolver algo que o cliente não utilizará; Reescrever funções que já estão prontas para um projeto. 3.5.3 Reaprendizagem “O aprendizado é um processo importante que ocorre em todas as etapas do processo de desenvolvimento de um software [...]. O problema é quando esse aprendizado não é absorvido e a equipe precisa reaprender algo que já havia sido apresentado anteriormente” (INFORMANT, 2013). “A reaprendizagem é um desperdício comum e a abordagem de capturar e armazenar o conhecimento são, na maioria das vezes, uma atividade demasiadamente longa e muito menos rígida do que deveria ser” (ARAMUNI, 2015, p. 88). Ter que aprender novamente algo que já foi vivenciado é o que pode se chamar de reaprendizado e de fato é um desperdício. Comumente criar um documento em que se registram os conhecimentos obtidos em um projeto de desenvolvimento de software é a solução adotada por muitas empresas. O problema é que este documento nunca ou raramente é lido (LIMA, 2012, p. 5).
Exemplos: Quando desenvolvedores fazem correções no código e não registram a solução encontrada para utilização posterior; Códigos mal escritos e documentados também costumam causar o reaprendizado, pois nessas situações o comportamento e objetivo das aplicações não ficam claros; Pensar alternativas melhores para manter o conhecimento na empresa pode ser interessante para evitar este desperdício. 3.5.4 Transferência de controle Hugo (2011) descreve que o desenvolvimento de software é uma atividade que exige bastante concentração, e interrupções podem ser desastrosas no trabalho realizado. E levanta um questionamento: quanto tempo um desenvolvedor leva para encontrar uma informação? “O desenvolvedor pode levar mais tempo para retomar a concentração na atividade inicial do que para resolver uma dúvida” (FRANCO, 2007, p. 57). Exemplos: Documentos que transitam entre setores; Requisito passa do analista, para o projetista, os documentos de projetos depois são enviados para os programadores, o código depois é entregue aos testadores e assim por diante; Transferência de uma atividade, de um desenvolvedor para outro; Dificuldades de comunicação também provocam desperdício porque exigem mais esforços para a troca de informações. 3.5.5 Troca de tarefas Lima (2012) afirma que o desenvolvimento de software é uma atividade que exige concentração e que por sua vez, realizar mais de uma tarefa de maneira alternada prejudica o raciocínio e a velocidade na execução das tarefas. Trocar muitas vezes de atividade reduz a produtividade porque exige muitas mudanças do contexto mental. Alocar desenvolvedores em mais de um projeto também é um desperdício porque as necessidades de um projeto não levam em conta a situação dos outros. Isso causa troca de contexto em momentos de necessidade de um dos projetos, deixando tarefas incompletas e podendo causar efeitos em cadeia ao obrigar que outros programadores também mudem suas tarefas para compensar a ausência daqueles que mudaram primeiro (BASSI FILHO, 2008, p. 73).
Exemplos: Quando se aloca mais de uma tarefa para apenas um recurso, corre-se mais risco de que nenhuma tarefa fique pronta no prazo definido; Interrupções por diversas razões tais como: leitura/envio de e-mail, telefonemas, reuniões.
3.5.6 Atrasos “Esperar pessoas de outras áreas estarem disponíveis para que se possa realizar o seu trabalho é uma grande causa de desperdícios providos pelos atrasos” (ARAMUNI, 2015, p. 88). E “qualquer atraso na entrega de uma das etapas do desenvolvimento de software pode gerar aumentos consideráveis de custo e prazo, gerando desperdícios ao longo do processo” (INFORMANT, 2013). Espera por informações, bem como a falta de disponibilidade das mesmas exige que desenvolvedores sigam por três caminhos possíveis: “1) pesquisar para tentar descobrir a resposta; 2) trocar de tarefa (que é uma forma de desperdício); ou 3) fazer suposições e prosseguir, aumentando a chance de gerar funcionalidades erradas” (BASSI FILHO, 2008, p. 73). Exemplos: Espera de pessoal adequado para estar disponível, para começar a trabalhar em um projeto; Revisão ou aprovação de processos que funcionam como portas entre fases do processo de desenvolvimento e que exigem a atenção de um indivíduo pouco disponível; Intervalos entre a conclusão do trabalho de desenvolvimento e o início do trabalho de teste e entre o de teste e a implantação. 3.5.7 Defeitos Lima (2012) é enfático ao afirmar que “defeito provoca automaticamente um retrabalho. Quanto mais tarde detectado mais difícil será corrigi-lo”. Hugo (2011) vai mais além ao chamar atenção para o fato de que defeitos no sistema não agregam valor, não satisfazem o cliente, e definitivamente não são baratos. Qualquer tipo de retrabalho por problemas de implementação de requisitos, interpretação de necessidades e correção de documentação deve ser combatido. No entanto, Bassi Filho (2008) faz uma ressalva: Algumas vezes corrigir defeitos também é uma forma de desperdício pois novos defeitos aparecerão e isso pode causar um ciclo vicioso que consome tempo e os recursos do projeto. Portanto, tão importante quanto corrigir defeitos rapidamente é identificar a sua causa para evitar que novos erros sejam introduzidos pela mesma razão, seja ela uma falha na comunicação ou um problema no processo (BASSI FILHO, 2008, p. 74).
Exemplos: Aplicativos com erros e defeitos no projeto; Correções de Software aplicadas simplesmente para corrigir erros causados por correções anteriores.
4
IMPLEMENTANDO LEAN NA TI
A TECHEXCEL (tradução nossa) descreve que a introdução do Lean em uma empresa é conhecida como Lean Transformation Programming (Programa de Transformação Enxuta) e é tanto uma mudança organizacional quanto cultural. Em seguida aborda alguns passos deste processo. 4.1
Realize uma avaliação inicial
O propósito de uma avaliação lean é identificar pontos fortes e fracos da organização e determinar quão “lean” a organização está incialmente em diferentes áreas. Nesta, deve-se incluir análises financeiras e operacionais. É importante selecionar um consultor com experiência significativa em lean para conduzir a avaliação. 4.2
Iniciar rastreamento de métricas
A avaliação lean irá fornecer a base e responder a pergunta “onde estamos agora?”. Rastreando e postando métricas, irá mostrar onde se está indo durante toda a transformação lean e irá determinar quão bem sucedido o programa está. Desenvolver um conjunto de métricas que serão usadas para acompanhar os esforços da implementação. É importante selecionar um número razoavelmente pequeno de métricas e publicá-las. As métricas precisam ser transparentes e disponíveis para todo mundo ver. 4.3
Desenvolver um plano de implementação de um ano, bem como um de 3 a 5 anos
Desenvolver um cronograma baseado na avaliação lean e métricas selecionadas, que inclua objetivos e metas. O plano precisa ser adaptado às circunstâncias específicas da organização. 4.4
Desenvolver um plano de treinamento
Os dois erros mais comuns relacionados ao treinamento lean são, treinamento muito cedo ou falhar em treinar em tudo. Ambos os erros podem ser onerosos. É importante desenvolver um plano de treinamento que coincida com o plano de implementação. Deve-se identificar quem deve ser treinado, quando deve ser treinado, e em que disciplinas devem ser treinadas. 4.5
Desenvolver uma comunicação e um plano de performance/recompensa
Comunicar o plano para se tornar lean para todos na organização e deixá-los saber como serão afetados é crítico para o sucesso. Parte do plano de comunicação deve incluir um plano para recompensar tanto times quanto indivíduos para o sucesso da participação destes na implementação lean.
5
DESAFIOS DO LEAN IT
Por praxe, implementações de novos processos tendem a gerar desconforto em uma organização. Com a implementação do lean na TI não se poderia esperar que fosse diferente. Por sua vez, também possui desafios a serem enfrentados. Ribeiro (s.d.) relata alguns destes. 5.1
Visualização do fluxo de valor
Ao contrário do Lean Manufacturing de onde os métodos e princípios do Lean IT derivam, Lean IT depende de fluxos de valor que são digitais e intangíveis, invés de físicos e tangíveis. Isto torna difícil a visualização de fluxos de valor de TI e consequentemente, a aplicação do Lean IT. 5.2
Referência de implementações
Como uma área emergente na gestão de TI, o Lean IT possui relativamente poucas referências de implementações. Além disso, enquanto a maior parte da teoria de apoio e metodologia está fundamentada no campo mais estabelecido do Lean Manufacturing, a adaptação de tal teoria e metodologia para o processo de TI orientado a serviço, da mesma forma, está apenas começando. 5.3
Resistência à mudança
As conclusões ou recomendações de iniciativas Lean IT são suscetíveis de exigir mudanças organizacional, operacional e/ou comportamental que podem ir de encontro com a resistência de trabalhadores, gerentes, e até mesmo executivos seniores. Se conduzido por um medo de perdas de emprego, uma crença de que as práticas de trabalho existentes são superiores, ou alguma outra preocupação, estas mudanças podem causar resistência. 5.4
Departamentos de TI fragmentados
As organizações de TI são comumente estruturadas em silos de operação ou tecnologia, cada um destes com suas próprias ferramentas e métodos de gestão para lidar talvez com apenas um aspecto particular de desperdício. Infelizmente esforços fragmentados contribuem muito pouco, pois lhes falta a integração necessária para gerir desperdícios acumulados através da cadeia de valor.
6
ANÁLISE E DISCUSSÃO DOS RESULTADOS
Ao se observar o conjunto de obras referenciadas, em sua maioria, sobretudo, as dissertações de mestrado, é evidente a existência da abordagem acerca dos princípios lean em processos de software, mudando apenas uma ou outra nomenclatura eventualmente, e a ênfase dada em um destes princípios, a eliminação de desperdícios. A busca pela eliminação de desperdícios deve ser encarada como foco e como o caminho de entrada para a adoção do lean. É enfático também a importância que se deve dar, às práticas e princípios do lean comparado ao uso de ferramentas. Sendo observado que um fator de insucesso em iniciativas lean, por vezes, está associado ao fato de se destacar a utilização das diversas ferramentas existentes, esquecendose de buscar a implantação da cultura lean nas organizações, de tal maneira que se torne algo inerente às pessoas envolvidas, fazendo disso um hábito. Diante disto, a seguir, serão elencadas algumas abordagens de trabalhos feitos no meio lean, baseadas nas obras de dissertação utilizadas nesta pesquisa. 6.1
Ferramenta para avaliação do lean em software
No trabalho de Cantanhede é discorrido sobre a “carência” ou menor número considerável de publicações relacionadas ao Lean Software Development (LSD) frente às publicações relacionadas ao Lean na manufatura. Levando o autor a se questionar de como o lean tem sido aplicado no Desenvolvimento de Software (DS) e se existe algum modelo para aplicação do lean em DS. É mencionado também acerca de outro trabalho, desenvolvido por outros autores, que por sua vez, fizeram um estudo identificando os principais conceitos e definições do LSD e proposto um modelo conceitual detalhado deste. Tais autores inclusive propõem que outros pesquisadores o utilizem para sua evolução e provável desenvolvimento de um instrumento de avaliação. Pensando neste cenário e na existência do LESAT (Lean Enterprise Self-Assessment Tool), uma ferramenta do MIT (Massachusetts Institute of Technology) para autoavaliação do nível lean nas indústrias, guiando-as na implantação do lean, avaliando o estado atual das capacidades lean, bem como os próximos passos a serem definidos, o autor sugere a adaptação do LESAT para software e sua respectiva aplicação para definir o nível lean de uma organização em seus processos de software. 6.2
Questionário para avaliar a cultura lean
Na dissertação de Aramuni, por vezes o autor reforça a importância da cultura lean versus o foco em utilização de ferramentas, destacando, por exemplo, que o lean no desenvolvimento de software está mais ligado a uma estratégia de negócio e gerenciamento de projetos que um processo de desenvolvimento efetivamente, uma vez que o mesmo apenas descreve uma série de princípios, valores e ferramentas a serem utilizados, para tornar o desenvolvimento de software enxuto, de acordo com conceitos definidos pela Toyota na manufatura.
Assim, o autor se prevalece de outros dois trabalhos, o primeiro que trata de um estudo sobre 14 princípios de gestão da Toyota, fortemente embasado na cultura por trás do sistema de produção enxuta, e o segundo que propõe um método de análise da cultura Lean, para o processo de fabricação de arames para agropecuária, no qual havia sido iniciado alguns conceitos de produção Lean. Com isso, cria uma adaptação deste método, criando um questionário com 23 questões, adaptado para o escopo da TI, com o propósito de se verificar como as pessoas enxergam a aplicação dos conceitos lean em sua área, se compreendem a filosofia por detrás das práticas, se estão engajadas com a mudança e a efetividade da adoção e/ou implantação do lean. 6.3
Lean Ágil
Franco, em seu trabalho, traz a proposta da adoção do lean concomitantemente às metodologias ágeis, na gestão de projetos. Considerando que princípios são definidos como ideias, que guiam uma estrutura de trabalho e discernimentos sobre uma disciplina, enquanto que as práticas são definidas como ações necessárias para executar princípios. Assim, o autor propõe um modelo onde o lean age mais do lado teórico, através de seus princípios e valores, enquanto as metodologias ágeis propostas (Scrum e Extreme Programming) em conjunto, atuam no lado mais prático do desenvolvimento, especialmente em se tratando do Extreme Programming. A grosso modo, o modelo proposto pelo autor, mapeia os princípios do desenvolvimento lean às práticas das metodologias ágeis, com o intuito de tirar melhor proveito de cada um dos conceitos envolvidos neste “casamento”, gerando valor ao cliente, ganho de produtividade da equipe e melhoria na qualidade do produto final. 7
CONCLUSÃO
Ao se ater apenas a olhar para os dados do CHAOS Report, já se pode ter uma visão que no decorrer do tempo, o histórico dos resultados da TI, não têm sido nada bons com relação aos processos de software. Contudo, ao percorrer o conteúdo exposto neste trabalho, pode-se vislumbrar com otimismo, uma mudança por vir, para melhor, da imagem negativa carregada pela TI, com o advento e utilização dos princípios e práticas pregadas pelo Lean IT e sua adequação nos processos de software, sobretudo no aspecto de eliminação de desperdícios. Ou seja, as organizações de TI, se quiserem melhorar seus processos, juntamente com a geração de valor ao cliente final, podem se valer da busca pela adoção de meios e/ou métodos de gestão, fundamentados na filosofia Lean, que incutem uma mudança de cultura tanto na equipe de TI, quanto nos demais colaboradores, gestores e direção das empresas, podendo iniciar tal iniciativa, pela análise daquilo que no momento não gera valor ao cliente, que por sua vez, deve ser eliminado, reduzindo desperdícios. Todavia, vale ressaltar que a implementação do Lean, não deve ser considerada como algo trivial, uma vez que exige a mudança cultural e de hábitos na organização, algo que pode ser contornado através de uma transformação gradual.
É interessante também observar, que metodologias de cunho mais práticos, estão sendo pesquisadas e desenvolvidas, para avaliar mais assertivamente implementações e progressos do Lean nas organizações. Este trabalho “limitou-se” a priorizar a discussão acerca de princípios e práticas inerentes à filosofia Lean, mas existem diversas ferramentas de apoio que também podem ser utilizadas simultaneamente, tais como Kanban, Jidoka, Kaizen, entre outras para a melhoria nos processos da TI e no auxílio da geração de valor ao cliente. Como trabalho futuro, é possível se aprofundar em pesquisas acerca dos estudos destacados na seção de análise e discussão de resultados, bem como nas mais variadas ferramentas existentes para auxílio no processo de melhoria da TI, desenvolvimento de software e organizações, em prol de se tornarem enxutos.
REFERÊNCIAS BIBLIOGRÁFICAS AQUINO, R. S. P. Como Lean TI descreve os desperdícios?. 2013. Disponível em: <http://www.leanti.com.br/artigos/3/como-lean-ti-descreve-os-desperdicios.aspx>. Acesso em: 08 abr. 2016. ARAMUNI, J. P. C. Análise da Adoção do Lean Manufacturing na Gestão de Projetos de Tecnologia da Informação: Estudo de Caso em uma Multinacional desse Segmento. 2015. Dissertação (Mestrado) - Universidade FUMEC, Faculdade de Ciências Empresariais, Belo Horizonte, MG, 2015. BASSI FILHO, D. L. Experiências com desenvolvimento ágil. 2008. Dissertação (Mestrado) Universidade de São Paulo, Instituto de Matemática e Estatística, São Paulo, SP, 2008. BELL, S. C.; ORZEN, M. A. TI Lean: Capacitando e sustentando sua transformação lean. Tradução BTS Traduções. Revisão técnica Rodrigo S. P. de Aquino e Christopher G. Thompson. Revisão de português Tamiris M. Manzano. São Paulo, SP: Lean Institute Brasil, 2013. 360 p. CANTANHEDE, M. A. D. Lean thinking em desenvolvimento de software: estudo e aplicação de ferramenta para avaliação do lean em software. 2014. Dissertação (Mestrado) - Universidade Estadual de Campinas, Faculdade de Tecnologia, Limeira, SP, 2014. EXIN. Lean na TI - Introdução aos principais conceitos e aplicação. 2014. Disponível em: <https://www.youtube.com/watch?v=nLgemHuvCUs>. Acesso em: 08 abr. 2016. FRANCO, E. F. Um Modelo de Gerenciamento de Projetos Baseado nas Metodologias Ágeis de Desenvolvimento de Software e nos Princípios da Produção Enxuta. 2007. Dissertação (Mestrado) - Universidade de São Paulo, Escola Politécnica, São Paulo, SP, 2008. GUEDES, J. F. A. Introdução de conceitos lean às tecnologias de informação: um caso de estudo em Banca. 2011. Dissertação (Mestrado) - Universidade do Porto, Faculdade de Engenharia, Porto, Portugal, 2012. HASTIE, S.; WOJEWODA, S. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. INFOQ, out. 2015. Disponível em: <http://www.infoq.com/articles/standish-chaos-2015>. Acesso em: 08 abr. 2016. HUGO, V. Lean: Elimine o Desperdício!. 2011. Disponível em: <https://blog.lambda3.com.br/2011/02/lean-elimine-o-desperdicio/>. Acesso em: 10 abr. 2016. INFORMANT. Software ágil os 7 princípios do desenvolvimento - Princípio 01. 2013. Disponível em: <http://www.informant.com.br/blog/2013/10/29/os-7-principios-dodesenvolvimento-agil-de-software-principio-01/>. Acesso em: 10 abr. 2016. LEAN TI. O que é Lean Thinking?. Disponível em: <http://www.leanti.com.br/conceitos/4/Oque-e-Lean-Thinking.aspx>. Acesso em: 11 abr. 2016.
LIMA, H. S. Lean Software: Eliminação de Desperdícios no Processo de Desenvolvimento. Revista Clique. Universidade Estadual de Montes Claros, Centro de Ciências Exatas e Tecnológicas, Montes Claros, MG, v. 1, n. 1, 31 ago. 2012. MARIOTTI, F. S. Introdução ao Desenvolvimento Ágil com Scrum. 2013. Disponível em: <http://pt.slideshare.net/FlvioSecchieriMariot/scrum-v-final>. Acesso em: 08 abr. 2016. POPPENDIECK, M.; POPPENDIECK, T. Implementing Lean Software Development: From Concept to Cash. Boston, MA: Addison-Wesley, 2006. 304 p. PRODANOV, C. C.; FREITAS, E. C. de. Metodologia do trabalho científico: Métodos e Técnicas da Pesquisa e do Trabalho Acadêmico. 2. ed. Novo Hamburgo, RS: Universidade FEEVALE, 2013. 276 p. RIBEIRO, R. D. Lean IT. [20--] Disponível em: <http://www.rafaeldiasribeiro.com.br/downloads/LeanIT.pdf>. Acesso em: 08 abr. 2016. SOFT EXPERT. Lean IT - A busca pela eficiência máxima na TI. Webinar. [2014]. Disponível em: <https://www.softexpert.com.br/downloads/webinar/gravado/Lean_IT_A_Busca_Pela_Eficiencia _Maxima_na_TI/Lean_IT_A_Busca_Pela_Eficiencia_Maxima_na_TI.html>. Acesso em: 09 abr. 2016. STEFFEN, J. B. Lean para desenvolvimento de Software. Afinal, o que é isto?. 2011. Disponível em: <https://www.ibm.com/developerworks/mydeveloperworks/blogs/rationalbrasil/entry/lean_para_ desenvolvimento_de_sw_o_que__c3_a9_isso_afinal12?lang=en>. Acesso em: 08 abr. 2016. TECHEXCEL. Lean IT. Disponível em: <https://www.techexcel.com/resources/whitepapers/Lean_IT.PDF>. Acesso em: 08 abr. 2016. VENTURA, P. Funcionalidades do sistema - o que realmente é utilizado?. 2015. Disponível em: <http://www.ateomomento.com.br/funcionalidades-do-sistema-o-que-realmente-e-utilizado/>. Acesso em: 08 abr. 2016. ZDUNIĆ, N. Mary and Tom Poppendieck on the Seven Principles of Lean Software Development. 2015. Disponível em: <https://nzdunic.info/2015/05/12/mary-and-tompoppendieck-on-the-seven-principles-of-lean-software-development/>. Acesso em: 08 abr. 2016.