Aplicação do Sistema Toyota de Produção na Indústria de Software

Desde o seu surgimento, o Sistema Toyota de Produção tornou-se uma importante solução provedora de ferramentas para a melhoria da qualidade de diferentes segmentos de produção e serviços (WOMACK 1998). Isto em virtude do Sistema estar orientado a eliminação de desperdícios e a inexistência de defeitos. Nesse contexto, surge a questão: É possível aplicar o Sistema Toyota de Produção em empresas de software?

O Sistema em estudo apresenta-se como uma opção a ser seguida por empresas de software, visando uma maior qualidade dos seus entregáveis. Contudo são necessários estudos de viabilidade da aplicação nesse segmento. A partir dos resultados obtidos, será possível identificar se o Sistema pode ser utilizado na indústria de software e como obter melhores resultados de qualidade e redução de desperdício.

Assim sendo, esse trabalho tem o objetivo de identificar quais ferramentas do Sistema podem ser utilizadas na indústria de software. Além disso, o trabalho vislumbra identificar a relação do Sistema em estudo com ferramentas ágeis de desenvolvimento de software. E por fim, identificar os possíveis ganhos da sua aplicação, no que tange à qualidade e redução de desperdício.

1. Desenvolvimento

O Sistema Toyota de Produção foi idealizado com intuito de viabilizar a concorrência entre a empresa japonesa Toyota Motors Company, com as empresas americanas do ramo automotivo. Seu objetivo era suprir as carências do modelo de Produção em Massa utilizado pelos americanos, visto que esse não se aplicava no cenário econômico japonês (WOMACK 1998 e SHINGO 1996).

O sucesso do Sistema se deve a busca da eliminação absoluta de perdas (LIKER 2004). Para o segmento fabril, perdas são as atividades desnecessárias que geram custo e não agregam valor (OHNO 1988 e SHINGO 1996). Para combater as perdas, o Sistema disponibiliza o Just-in-time, Jidoka e o Heijünka. Sendo que, o Just-in-Time é composto pelas ferramentas “Fluxo contínuo”, “Takt Time” e “Kanban”. Já o Jidoka é composto pela “Separação Homem X máquina” e o “Poka Yoke”. E por fim, o Heijünka é composto pelo “Mizusumashi” e o “Kaisen” (SHINGO 1996).

1.1. Just-in-time

Ohno (1997) afirma que o conceito Just-in-time surgiu da idéia de Kiichiro Toyoda, cujo ideal seria ter todas as peças ao lado das linhas de produção no momento exato de sua utilização. Nesse contexto Just-in-time aparece como uma técnica de gestão que estabelece que o fornecedor atenda seu cliente produzindo exatamente o item certo, na quantidade certa, no momento certo (GHINATO 2004 e SHOOK 2000).

Uma das ferramentas do Just-in-Time é o Fluxo Contínuo. Este consiste na produção de peças de forma individual, progressiva e contínua. Isso significa que os produtos são desenvolvidos um de cada vez, passando por diferentes estágios do processo sem que ocorra intervalo entre eles. Assim sendo, o processo produtivo ocorre continuamente eliminando estagnações, produzindo somente o que é necessário (SHINGO 1996).

A ferramenta que mensura o tempo de produção se chama Takt time. Sua fórmula está baseada no tempo disponível para produção dividido pela demanda do mercado. Seu intuito é determinar uma meta de prazo para um determinado volume de fabricação (SHINGO 1996 e SHOOK 2000).

Já a comunicação flui através do Kanban, que são registros ou placas visuais (OHNO 1997). Sua finalidade é controlar os fluxos de produção ou transportes em uma indústria, provendo a conexão entre as diferentes operações (PACE 2003).

1.2. Jidoka

Os principais objetivos do Jidoka são evitar a geração e propagação de defeitos no fluxo de produção, paralisando a linha de produção sempre que um defeito for encontrado. Após a linha ser interrompida, o problema é alvo de estudo e sua causa raiz é eliminada para evitar futura reincidência (SHINGO 1996 e OHNO 1997).

O Jidoka é composto pelas ferramentas de Separação Homem-Máquina e o Poka Yoke(SHINGO 1996). O primeiro está relacionado com a capacidade que a máquina de trabalho possui para paralisar a linha de produção, de forma autônoma, em caso de falhas de processo ou produção (SHINGO 1996 e GUINATO 1999). Já o segundo, se refere à utilização de mecanismos acoplados a máquina de trabalho, também para paralisação da linha de produção em caso de falhas (GUINATO 1999).

1.3. Heijunka

É um conceito que tem a finalidade de estabilizar o processo de manufatura, através da programação da produção e do sequenciamento dos pedidos. Ele consolida a demanda dos clientes tornando o processo de manufatura previsível (WOMACK 1998 e SHINGO 1996). De forma resumida, significa produzir apenas o que for solicitado.

Os encarregados de estabilizar a produção são os Mizusumashi, que são pessoas responsáveis por abastecerem as linhas de produção com materiais. Isso ocorre em um período e quantidade previamente definidos. Após o abastecimento, eles coletam a quantidade produzida, liberando o ambiente de produção para receber novas levas de materiais (GUINATO 1999).

A estabilidade na produção é mantida, por meio do Kaizen. Esse é um processo de melhoria contínua ou gradual. Possui a finalidade de viabilizar a eliminação de perdas com base no bom senso e no uso de soluções baratas, através da motivação e criatividade dos trabalhadores. Ou seja, a melhoria dos processos ocorre por meio de experiências e sugestões de funcionários envolvidos na produção (WOMACK 1998 e OHNO 1997).

1.4. Desafios para alcançar a qualidade no desenvolvimento de software

Ao contrário de linhas de produção de outros segmentos, que produzem continuamente o mesmo item durante um longo período, o desenvolvimento de software se depara constantemente com a necessidade de criação de novos produtos (POPPENDIECK 2003). Assim sendo, dificuldades podem ser encontradas em diferentes estágios do processo, em virtude da constante instabilidade dos requisitos (GALIN 2003).

Para Galin (2003) os defeitos no software são os responsáveis por sua baixa qualidade. Eles ocorrem no código, nos procedimentos, na documentação e nos dados do software. A investigação da causa dos defeitos é decisiva para sua prevenção (GALIN 2003). Já para Poppendieck (2003) a mudança de requisitos, a tomada de decisão centralizada, práticas tradicionais de desenvolvimento, e pouco foco na qualidade do software produzido são os fatores que impactam na qualidade do software.

Poppendieck (2003) também enfatiza a necessidade de eliminar desperdícios no processo de desenvolvimento de software. Assim sendo, ele elencou sete grupos de desperdícios que impactam negativamente na qualidade desejada do software. Estes grupos são: Trabalho incompleto, Processos a mais, Funcionalidades a mais, Troca de tarefas, Handoffs, atrasos e defeitos.

Sendo o desenvolvimento de software uma questão de estudo antiga, e a busca pela eliminação de desperdício sua primazia, o Sistema Toyota se apresenta como uma solução na busca pela qualidade. Isso porque, o Sistema em estudo é um caso de sucesso na melhoria do desempenho de distintas unidades de produção (WOMACK 1998). Assim sendo, nos pontos em comum do software com o processo de manufatura de outros itens, o sistema pode ser utilizado para agregar valor.

1.5. Metodologia de pesquisa

O presente trabalho foi idealizado por meio de uma pesquisa aplicada de forma qualitativa através de um estudo de caso (PRODANOV 2006) em uma empresa de software. Para isso, foi observada a utilização do Sistema Toyota de Produção por um time de trabalho, durante dois períodos de desenvolvimento.

Por motivos de confidencialidade o nome da empresa que desenvolve o software não será divulgado, então utilizou-se um nome fictício intitulado empresa “X”. O nome do software também não pode ser revelado, então ele será chamado “Orion”. Atualmente o projeto deste software possui um Analista de Sistemas, um Desenvolvedor Senior C++/Qt, um Desenvolvedor Pleno C++, um Analista de Testes Pleno, um Testador/Desenvolvedor Pleno e um Gerente de Projetos. Todos envolvidos no projeto utilizam o método desenvolvimento Evolutivo com Scrum para o desenvolvimento do software.

Após o consentimento da empresa “X” para utilização do software, foram realizadas leituras de diferentes artigos, monografias e livros. Os alvos das pesquisas foram o Sistema Toyota de Produção e as perdas no processo de desenvolvimento de software. Logo ficou constatado que o Sistema em estudo é empregado em diferentes segmentos industriais e de prestação de serviço (OHNO 1997 e SHINGO 1996). Ficou evidenciado também que o desenvolvimento de software possui particularidades em relação à produção de outros produtos (GALIN 2003).

A pesquisa bibliográfica permitiu ainda, elencar as ferramentas disponíveis pelo Sistema. Assim sendo, iniciou-se a tentativa de aplicar as teorias adquiridas ao processo de desenvolvimento do Orion. Nos casos em que as ferramentas não eram compatíveis com o desenvolvimento de software, tentou-se adaptá-las para funcionarem.

Como conclusão do estudo, analisou-se a aplicabilidade do Sistema em uma linha de desenvolvimento de software. Além disso, foi definido um fluxo de trabalho que poderá auxiliar na implementação do sistema em outras empresas desse segmento.

1.6. Estudo de caso

Para realização desse trabalho, foram utilizados dois períodos de desenvolvimento de melhorias do projeto Orion, pertencente à empresa “X”. Esse é um software de entretenimento que atualmente não é comercializado, sendo considerado pela empresa como um software “conceito”. Isso significa que a partir das experiências aprendidas nesse projeto, será realizado um estudo de viabilidade para um futuro produto.

1.6.1. Atividades do Projeto

O projeto de melhorias no Orion foi o resultado de uma pesquisa realizada pelo Analista de Sistemas, a mando do Staff da empresa “X”. O mesmo identificou requisitos que poderiam ser incorporados ao software, para o mesmo se tornar mais atrativo ao usuário final e concorrer no mercado com produtos do mesmo gênero.

Após o Staff aprovar os resultados da pesquisa, os requisitos encontrados foram alvo de uma análise que deu origem a algumas User Stories (US). Essa atividade foi realizada pelo Analista de Sistemas, Analista de Testes e o Desenvolvedor Pleno C++/Qt, com intuito de definir os Critérios de Aceitação e o tempo necessário para o desenvolvimento do trabalho.

As atividades no projeto foram divididas em dois períodos de desenvolvimento em um Mapa de Produção. Nesse documento, constavam as atividades há serem efetuadas, para que cada integrante do projeto soubesse o que fazer. Os processos dos times de Desenvolvimento e Testes ocorreram em paralelo no intervalo de 15 dias, Nos itens a seguir, as atividades do Mapa de Produção serão descritas incluindo sua aderência ao Sistema Toyota de Produção.

1.6.2. Aplicação do Just-in-Time

O projeto iniciou com a aplicação do Just-in-Time e seus componentes. Assim sendo, foi definido que os requisitos iriam ser desenvolvidos de forma individual, progressiva e contínua, ou seja, através do Fluxo Contínuo (SHINGO 1996). Conforme a Figura 2, não existiu parada entre as atividades executadas pelos times de trabalho.

Até então, a empresa “X” utilizava um Modelo de desenvolvimento Evolutivo com Scrum. A adequação ao Just-in-Time foi percebida na maior interação entre os Times de trabalho e no crescimento de artefatos entregues para os testes. No Modelo Evolutivo o Time de Desenvolvimento fazia entregas após cada incremento. Já no Just-in-Time após o término de cada User Story, era realizada uma entrega. Essa entrega era alvo de uma validação, para garantir que seus critérios de aceitação eram atendidos. Nos casos em que os critérios não fossem atendidos, a User Story voltava para linha de produção.

O tempo para execução das atividades do projeto utilizou a técnica de Planning Poker(COHN 2005) e não o Takt-Time, fornecido pelo Sistema Toyota de Produção. A causa para isso é que o Takt-Time não se mostrou flexível o suficiente para o desenvolvimento de software. Sua fórmula é baseada na razão entre o tempo disponível para produção, pelo número de unidades de mesmo produto (SHOOK 2000). Ao contrário de outros segmentos que produzem centenas de unidade de um mesmo produto, os requisitos de um software apresentam características distintas e seu tempo de desenvolvimento varia de acordo com a sua complexidade. Assim sendo, o uso do Takt-Time foi inviável.

Em relação à comunicação entre os Times de trabalho durante o desenvolvimento, ela fluiu com o uso do Kanban. O uso de etiquetas como auxílio visual, permitiu que o Time de Testes identificasse o status das User Stories. O status alternava entre: Não Iniciado, Em desenvolvimento, Para Validação, Em Testes, Retorno e Entregue.

Durante a fase de Teste de Sistema a comunicação entre o time de trabalho foi realizada através da ferramenta de bug tracking (SELENIUM 2011). Nessa etapa do projeto todas User Stories foram testadas juntas, validando a funcionalidade como um todo. Essa atividade já era executada antes da aplicação do Sistema Toyota de produção, contudo, até então, o time de testes não manipulava os entregáveis antes que todos estivessem prontos.

1.6.3. Aplicação do Jidoka

O Jidoka foi aplicado com intuito de paralisar a linha de produção sempre que fosse encontrada alguma anomalia. Isso com intuito de evitar a propagação de defeitos e diminuir o retrabalho (OHNO 1997).

Diferente da Toyota Motors Company, que possui máquinas com funcionalidade de Separação Homem-Máquina, a empresa “X” possui apenas computadores pessoais. Assim sendo, foi realizada uma pesquisa no universo de ferramentas que a empresa “X” dispunha, para verificar se alguma atendia o quesito da Separação Homem-Máquina.

O resultado do esforço descrito acima, concluiu que o mais próximo que uma ferramenta de desenvolvimento chega da Separação Homem-Máquina, é prover falhas na sintaxe do código. Isso significa que o instrumento de trabalho informa falhas no processo produtivo de forma autônoma (SHINGO 1996 e GUINATO 1999).

Já a aplicação do Poka Yoke foi realizada por meio de um mecanismo de geração de Buildscontínuas. Quando o desenvolvedor fosse realizar alguma alteração no código, antes ele deveria atualizar seu repositório de dados. Após isso, ele efetuava a codificação necessária e atualizava o repositório com suas informações. Ao atualizar o repositório, automaticamente o sistema compilava o código e em caso de sucesso gerava uma Build. Além disso, um e-mail de sucesso era enviado. Nos casos de problema, era enviado um e-mail de falha informando a causa. Assim o desenvolvedor, podia dar manutenção no seu código para que a Build não apresentasse mais problemas. Todo esse esforço, possuía o intuito de evitar que a Build noturna apresentasse problemas, pois essa era utilizada pelo Time de Testes.

O Poka Yoke de controle foi aplicado também pelo Time de Testes, por meio de Testes Automatizados, utilizando a ferramenta QuickTest Professional 11 (QTP 2011). Scriptsforam executados para garantir que as User Stories de ciclos anteriores não fossem afetadas pelas novas entregas. Também foram desenvolvidos scripts para executar as User Storiesdo ciclo atual, quando o tempo permitiu.

1.6.4. Heijunka

A utilização do Heijunka não foi possível, visto que sua finalidade é normalizar linhas de produção de um mesmo produto (WOMACK 1998 e SHINGO 1996). Como em uma linha de produção de software não se produz sempre o mesmo produto várias vezes, o Heijunkanão possui aplicação. O mesmo acontece ao Mizusumashi, visto que não existe a necessidade de abastecimento de peças e coleta de itens finalizados na linha de produção de software (GUINATO 1999).

Em relação ao Kaizen, o mesmo foi executado pelos componentes do projeto, com intuito de identificar processos que poderiam ser removidos ou melhorados (WOMACK 1998). Sua utilização ocorreu após os períodos de desenvolvimento, através de reuniões entre os membros da equipe.

2. Conclusão

Neste trabalho foi realizada uma pesquisa que legitimou a aderência de algumas ferramentas do Sistema Toyota de Produção no desenvolvimento de software. Para isso utilizou-se dois períodos de um projeto, analisando a experiência obtida pelos Times de Desenvolvimento e de Testes.

Na Tabela 1 estão dispostas as ferramentas do Sistema, com a informação se sua aplicação foi viável. Constatou-se que as ferramentas Takt Time e Mizusumashi não são aderentes ao desenvolvimento de software. A explicação para isso é que sua utilização está condicionada a processos produtivos repetitivos de um mesmo produto (WOMACK 1998). As demais ferramentas foram utilizadas com sucesso no projeto, sem a necessidade de ajustes.

Tabela 1. Ferramentas do Sistema Toyota de Produção, aderentes ao desenvolvimento de software

2.1. Relação entre o Sistema Toyota de Produção e métodos ágeis

A relação entre o Sistema Toyota de Produção e a Metodologia Ágil inicia na entrega em pequenos lotes, que ditam o ritmo de desenvolvimento e testes e minimizam os riscos (BACK 2004). Outro ponto de relação entre ambos é o estímulo à interação entre os times de trabalho, para que o foco seja a qualidade do produto e entrega no menor prazo possível (COHEN 2004).

O desenvolvimento orientado aos testes é uma semelhança entre o Sistema e os Métodos Ágeis. Da mesma forma que o Test Driven Development inicia pelos testes, na linha de produção da Toyota Motors Company, antes das peças serem produzidas, a máquina já está configurada para execução dos testes.

Finalizando a comparação, ambos são orientados à melhoria contínua. O Sistema Toyota de Produção por meio do Kaisen e o método ágil por meio de refactoring, reuniões para revisão do sprint e de lições aprendidas (COHEN 2004).

2.2. Vantagens com a utilização do Sistema Toyota de produção

Além de validar o uso de ferramenta do Sistema Toyota de Produção no desenvolvimento de software, o presente trabalho identificou alguns benefícios de sua utilização. São eles:

• Entrega em lotes que atenda a necessidade do cliente. Só se desenvolve o que for utilizar;
• Foco no uso de soluções que encontrem defeitos de forma automática, do início ao fim do desenvolvimento. Tanto para o time de desenvolvimento como para o de testes;
• Os entregáveis são testados individualmente e em conjunto, provendo uma cobertura abrangente;
• Documentação deve ser clara e atualizada. Ela deve ser um guia tanto para o desenvolvimento do código, como para a confecção dos Casos de Teste.

A utilização do Sistema Toyota de Produção pode reduzir as perdas encontradas no desenvolvimento de software. A Tabela 2 apresenta a solução que o Sistema fornece para cada item do Grupo de desperdícios elencados por Poppendieck (2003).

Tabela 2. Solução do Sistema Toyota de Produção para os desperdícios de software

3. Trabalhos Futuros

O presente trabalho atingiu seu objetivo. Contudo observou-se a possibilidade de novas pesquisas relacionadas à aplicação do Sistema Toyota de Produção na indústria de software. Como trabalho futuro a este estudo, é sugerida a aplicação de mudança de requisitos durante o período de desenvolvimento para estudar o comportamento do Sistema Toyota de Produção nessas condições.

Propõem-se também a execução de Teste de Performance no projeto em estudo, além de ferramentas de Teste Estático e Dinâmico para atender o Jidoka. E para finalizar, sugere-se o estudo do retorno financeiro da aplicação do Sistema Toyota de Produção em uma empresa de software.

Referência

Back, Kent. Extreme Programming Explained: Embrace Change, Second Edition. Addison-Wesley Professional. 2004.

Cohen, D., LINDVALL, M., & COSTA, P. An introduction to agile methods. New York: Elsevier Science. 2004.

Cohn, Mike. Agile Estimating and Planning. Mountain Goat Software, 2005.

Galin, Daniel. Software Quality Assurance: From Theory to Implementation. Addison Wesley, 2003.

Ghinato, Paulo. (2004). Sistema Toyota de Produção: Mais do Que simplesmente Just-in-Time Disponível em <http://www.scielo.br/pdf/prod/v5n2/v5n2a04.pdf> Acessado em: 14/04/2011.

Humphrey, W. S. (1989). Managing the Software Process. Addison-Wesley Publishing Company.

ISTQB (2007). Base de Conhecimento para Certificação em Teste. ISTQB FundationLevel Syllabus. Versão 2007br. Disponível em: http://www.bstqb.org.br/uploads/docs/syllabus_2007br.pdf Acesso em: 01/07/2011.

Liker, Jeffrey. The Toyota Way. McGraw-Hill, 2004.

Ohno, Taiichi. Sistema Toyota de Produção — Além da Produção em Larga Escala, Porto Alegre, Editora Bookman, 1997.

Pace, João Henrique. O Kanban na prática. Rio de janeiro: Qualitymark, 2003.

Poppendieck, Mary; POPPENDIECK, Tom. Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003

QuickTest Professional (2011). Disponível em: https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24^1352_4000_210__ . Acessado em: 18/03/2011.

Womack, James P; JONES, Daniel T. A mentalidade enxuta nas empresas: elimine o desperdício e crie riqueza. 4. ed Rio de Janeiro: Campus, 1998.

Prodanov, C. Manual de metodologia cientifica. Novo Hamburgo. FEEVALE, 2006.

Selenium (2011). Disponível em: http://www.selenium.org. /Acesso em: 09/12/2011.

Shingo, Shigeo. O Sistema Toyota de produção: do ponto de vista da engenharia de produção. 2. ed Porto Alegre: Bookman, 1996.

Shook, John; ROTHER, Mike. Aprendendo a Enxergar. Lean Institute Brasil, 2000.

Denunciar