sistema de produção fordismo e toyotismo

LeanPos em engenharia e qualidade de

softwaresLeonardo A Alves

Fordismo Toyotismo

Sistema de Produção

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.

JIDOKA

Suas inovações para parada automática e prevenção de desperdícios foram extraordinárias. Com o invento, Sakichi eliminou a necessidade de ter um operador monitorando as máquinas de tear continuamente. Agora, um único operador poderia monitorar até 30 máquinas, possibilitando uma diminuição expressiva no custo, bem como um aumento da qualidade e produtividade das máquinas de tear da época. Assim, com a automação, Sakichi criou um meio para que as máquinas parassem automaticamente quando qualquer problema ocorresse e, desta forma, nunca produzissem defeitos. Sobretudo, o Jidoka eliminou a necessidade de monitoramento humano contínuo e deu origem a uma cultura que é uma das bases do Lean, a Stop the Line.

JIDOKA

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 duas mil pessoas trabalhando. Nesses 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.

Cultura Stop the Line

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.

Poka-Yoke

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.

Just in Time

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.

Sistema Puxado

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.

Heijunka

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.

Pessoas

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.

Pessoas

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.

Quebrando a Visão

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.

Estórias

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 de prever sua situação futura após o desenvolvimento da estória;

Estórias

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.

Estórias

Estimativas e velocidade de desenvolvimento Estórias contêm estimativas e a responsabilidade por estimá-las é única e exclusiva do time de desenvolvimento. Delegar esta responsabilidade ao time é uma forma efetiva de garantir o comprometimento, já que nenhuma meta é imposta, mas sim proposta pelos próprios engenheiros de software. A experiência do desenvolvimento ágil de software mostra a ineficácia do uso de uma medida de tempo (horas ou dias) para estimar o custo de uma estória. As estimativas são feitas em story points (sp), medida exclusiva de esforço, que demonstra o tamanho de uma estória comparada a outras. A tarefa de estimar em story points é livre da preocupação sobre o tempo de duração do projeto. Story points liberam o time de desenvolvimento da pressão por datas, possibilitando o foco na complexidade da estória. Para acomodar as incertezas de estórias de grande porte, costuma-se utilizar a escala

Estimativas e velocidade de desenvolvimento

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.

Priorização

Estórias de refactoring criadas pelo time de desenvolvimento e estórias de novas funcionalidades, em geral, podem ser criadas por uma equipe de marketing ou até pelo usuário final. Independente da fonte, a estória será obrigatoriamente priorizada pelo Product Owner. Um Product Owner focado em maximizar o retorno do seu investimento certamente realizará um bom trabalho de priorização. Uma priorização adequada pode levar o desenvolvimento a alcançar um nível de produtividade

Priorização

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.

Priorização

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

Priorização

Priorização

Planejamento e Controle da Produção Uma vez tendo conhecimento sobre o que é preciso ser desenvolvido e sua adequada priorização, é preciso também compreender como planejar e controlar a entrega dos artefatos

Planejamento e Controle da Produção

Ciclos: releases, iterações e entrega contínua Uma das principais características da complexa tarefa de criar produtos de software que funcionem corretamente e atendam as expectativas do cliente é a imprevisibilidade, o que dificulta muito o processo de planejamento e controle. Para reduzir esta imprevisibilidade, processos tradicionais de desenvolvimento confiam em planejamentos intensivos para longos períodos, tentando identificar e mitigar todos os riscos possíveis logo de início. Ao longo dos anos descobriu-se que esta estratégia não funciona devido à própria natureza incerta do desenvolvimento de software e dos negócios onde normalmente são aplicados.

Ciclos: releases, iterações e entrega contínua

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 nos processos de desenvolvimento que citamos anteriormente, essencial para um ambiente Lean maduro.

Com mais conhecimento, as equipes passam a diminuir a incerteza e trabalham ancoradas em um processo confiável de entregas de produto de alta qualidade e valor agregado. Com maior confiabilidade e previsibilidade é possível fazer um planejamento de releases para o projeto, considerando as regras adequadas de priorização e a velocidade da equipe de desenvolvimento.


Desta forma, os releases são entregas maiores que contemplam o que foi desenvolvido durante algumas iterações e, associado a um objetivo bem definido, o planejamento passa a ser uma forma valiosa de satisfazer as necessidades de mercado do cliente. Como são priorizadas as funcionalidades que geram maior valor e têm maior risco para o projeto, os ciclos curtos propiciam um produto de alto valor agregado, diminuindo os riscos e o time-to-market. Consequentemente, a vantagem competitiva do cliente torna-se indiscutível.


Entrega contínua com Kanban Quando a equipe atinge um alto nível de maturidade, os ciclos de desenvolvimento tornam-se cada vez mais curtos e eventualmente a parada para planejamento das iterações pode se tornar um desperdício. O Kanban pode ser utilizado para amadurecer o workflow e aumentar a eficiência do sistema, promovendo a entrega contínua de software e o aumento da produtividade da equipe.

De forma simplificada, o Kanban é um processo de produção puxado que mapeia as etapas de desenvolvimento. Para cada etapa identificada, ele estabelece limites para a quantidade de trabalho sendo realizada simultaneamente. Os limites superiores auxiliam a minimizar a multitarefa, 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.

Entrega contínua com Kanban

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 sobrecarga 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.

Entrega contínua com Kanban

Visibilidade e Rastreabilidade Processos ágeis proporcionam total visibilidade, controle e rastreabilidade de tudo o que ocorre durante o ciclo de desenvolvimento. De fato, os métodos ágeis propiciam uma oportunidade diária para análise de riscos e tomada de decisão de modo a corrigir o mínimo desvio indevido de curso. Todas as ocorrências são disponibilizadas através das ferramentas de gestão como dashboard e burndown charts para todos os membros do projeto. Além disso, a comunicação direta entre equipes gera maior colaboração, visibilidade e controle do projeto. O próprio processo de ciclos curtos proporciona maior aprendizado e feedback concreto sobre o exato andamento do projeto, gerando maior segurança e consequente aumento de auto-estima para todos os envolvidos. Com base nas ferramentas e técnicas de metodologias ágeis, visibilidade e controle são potencializados da seguinte forma: Dashboard - painel que contém as estórias e tarefas priorizadas no backlog �e que demonstra a evolução no ciclo de vida do desenvolvimento;

�

Visibilidade e Rastreabilidade

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.

Visibilidade e Rastreabilidade

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.

A base da pirâmide Lean

Testes Automatizados Testes automatizados são certamente uma das mais fundamentais técnicas de desenvolvimento de software, que permite uma adição severa de qualidade ao código. O grande objetivo é criar esta qualidade durante a construção do código, ao invés de testá-lo mais tarde. Em geral, equipes que não investem na criação de testes automatizados necessitam de um longo período de testes ao final de cada ciclo de desenvolvimento. Esse investimento tardio na qualidade compromete o conhecimento da real situação do software durante o desenvolvimento, o que gera atrasos, falta de visibilidade, gerenciabilidade e assertividade do produto final. O investimento em testes automatizados oferece a oportunidade de obter feedback dos testes mesmo durante o desenvolvimento do software. A grande vantagem desta abordagem é o fato de se poder testar todo o sistema facilmente, a partir de apenas um botão na IDE.

Testes Automatizados

Quanto ao foco dos testes: Corretude do funcionamento: são os testes mais comuns, utilizados �para certificar a aderência do sistema aos requisitos funcionais; Performance e consumo de memória: testes que certificam o �desempenho do sistema de acordo com requisitos não-funcionais; Usabilidade: estes testes normalmente não são automatizados. �Envolvem especialistas em usabilidade e podem contar com a participação do próprio usuário.

Desenvolvedores utilizam testes automatizados na criação da tecnologia, auxiliando-os na escrita de código limpo e habilitando o refactoring para melhoria contínua. Especialistas de negócio podem usufruir de testes automatizados para certificarem-se de que seu modelo de negócio segue efetivo e aceito, mesmo durante a contínua evolução da base de código.

Quanto ao foco dos testes

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.

Automatização do 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.

Builds Automatizados

Integração Contínua Dispor de builds automatizados para seu projeto é um grande passo rumo à automatização dos processos, suporte à decisão sobre investimentos em qualidade, visibilidade, entre outros. Entretanto, para que estes benefícios sejam de fato gerados, é necessário que estes processos automatizados sejam executados de maneira sistemática e autônoma. Por exemplo, a suíte de testes e a rotina para executá-los não obterão os benefícios desejados caso não sejam executados a cada contribuição dos desenvolvedores sobre o código fonte do software do projeto.

O disparo do processo de execução periódica poderia ser executado pelo pessoal responsável por qualidade. Entretanto, assim como a execução de processos repetitivos, delegar esta responsabilidade comumente resulta em falhas e consequente desperdício. Para tal, ferramentas de monitoramento de contribuição e execução automática estão disponíveis, dentre elas: Apache Continuum, Hudson, LuntBuild e CruiseControl. Trata-se de um serviço disponibilizado na infraestrutura de desenvolvimento, geralmente em um servidor dedicado para o fim de integração contínua.

Integração Contínua

Os servidores de integração contínua comumente são configurados com um ambiente web, com suporte a ferramentas de comunicação (como e-mail e instant messenger) e link com outros servidores como Servidor de Controle de Versões e Servidor de Homologação. Estes recursos ampliam as capacidades dos builds automatizados, que podem publicar os relatórios gerados no ambiente web, enviar notificações aos desenvolvedores e outros interessados quanto ao status dos testes, entre outras possibilidades.


mostra três servidores: Servidor de Controle de Versões (SCV), Servidor de Homologação (SH) e Servidor de Integração Contínua (SIC). Note que os desenvolvedores colocam suas contribuições ao projeto no SCV. O SIC, continuamente monitora o SCV em busca de modificações.

Dada uma modificação detectada, o SIC atualiza sua cópia do projeto com as últimas atualizações detectadas, estando assim em sincronia com o SCV, e então executa o build automatizado do projeto. Este build executará todas as rotinas automatizadas e poderá se valer do ambiente do SIC para fazer o deployment da nova versão do software em um servidor para homologação (SH). É possível também gerar relatórios para acompanhamento e tomada de decisões em um ambiente web disponibilizado no próprio SIC.


Software Intelligence Software Intelligence refere-se às habilidades, tecnologias, aplicações e práticas utilizadas para ajudar a todos os envolvidos a entender melhor o contexto do negócio: desenvolvimento de software. Para tal, existem ferramentas livres que possibilitam a varredura do código fonte na busca por indícios de bugs no software, cobertura de testes, métricas de qualidade, entre outras informações. Estas ferramentas, integradas ao sistema de builds automatizados, podem ser consideradas inteligência de software quando são combinadas com um processo que busca melhoria contínua. Na prática, nas reuniões de retrospectiva e nas estórias de refactoring, os relatórios de inteligência do software são fontes importantes de suporte a decisão. A seguir, são apresentadas algumas das ferramentas que poderão ser empregadas na presente proposta: FindBugs. FindBugs é um programa que se propõe a achar bugs em aplicações Java por �meio da análise estática do código fonte. Este é um método utilizado para achar bugs em um sistema, sem executá-lo. A possibilidade de achar erros e vulnerabilidades sutis, antes que elas ocorram meses ou anos depois no sistema em produção, é a principal vantagem desse programa; CPD. Trata-se de um Detector de Copia e Cola (Copy/Paste Detector) para o código �fonte da aplicação.

Software Intelligence

Sua sensibilidade pode ser configurada e costuma apresentar algumas surpresas para seus usuários, principalmente em equipes de desenvolvimento médias, grandes e distribuídas. O principal benefício do CPD é reduzir a propagação de erros e o custo de todos os tipos de manutenção em códigos duplicados. Ele também encoraja o uso de boas práticas de orientação a objetos como DRY (Don´t Repeat Yourself), pois evita a recodificação de entidades do sistema já implementadas; PMD. O PMD é um programa que analisa o código fonte na busca de uma suite de �situações: códigos que poderiam ser melhor implementados quanto a performance, porções de código não utilizadas, tratamento deficiente de exceções e sentenças desnecessariamente complexas; Relatório dos testes. Resultados da execução da suíte automatizada de testes. Deve �ser mantido sempre verde, passando. Em caso de erro, além da possível notificação aos interessados, a cor no relatório será vermelha e as causas serão apresentadas em detalhes; Doxygen. Através de engenharia reversa aplicada às classes e à documentação �embarcada no código fonte, o Doxygen pode gerar diagramas UML com o estado real da aplicação, manuais e documentação online; Checkstyle. É uma ferramenta que auxilia o time de desenvolvimento a se manter �dentro de padrões de codificação. Assim como o CPD e o PMD, é ideal para times médios, grandes ou distribuídos;


Cobertura. Como o nome indica, esta ferramenta �mensura a cobertura dos testes automatizados no sistema. Ele gera relatórios que podem ser confrontados no próprio código fonte, indicando as áreas que foram acionadas pelos testes automatizados;

Mensurar a complexidade ciclomática, apesar do nome �complicado, significa simplesmente mensurar a complexidade de códigos estruturados ou cíclicos. Esta informação pode reduzir custos de manutenção, gerando valor na medida em que explicita, por exemplo, implementações fora da arquitetura planejada;�


Lobo. Lobo é uma ferramenta opensource desenvolvida pela OnCast, que estende a API de testes padrão para Java, oferecendo opções avançadas para testes de performance. Os relatórios gerados pelo Lobo mostram a evolução da performance do sistema ao longo do tempo do projeto. Se uma nova implementação compromete a performance de algum ponto isolado do sistema, este problema é facilmente identificado e isolado com a ajuda desta ferramenta.

O emprego de cada uma delas no processo de desenvolvimento será analisado confrontando o custo de manutenção do ambiente de software intelligence, com o valor gerado pelo mesmo. Uma escolha bem feita de um subconjunto destas ferramentas tem o potencial de formar um relatório significativo sobre o estado do desenvolvimento de um software.


Em todos os níveis da Pirâmide Lean é possível encontrar elementos trabalhando em conjunto para criação de valor na organização. Podemos observar que falamos sempre de pessoas, processos e ferramentas - tudo isso para a criação da melhor tecnologia. O Lean chama este processo de Systems Thinking, e orienta a olhar para a junção de pessoas, processos e ferramentas como um sistema, que precisa ser afinado e regulado de modo a gerar o seu melhor potencial. A partir do momento que certas técnicas - testes automatizados, TDD, refactoring, arquitetura emergente, simplicidade e integração contínua, por exemplo - são aplicadas corretamente, formamos uma base sólida para que a visão da organização seja rapidamente implementada e entregue com a mais alta qualidade.

conclusao

O correto equilíbrio na definição de valores e princípios e na aplicação das técnicas do Lean, Scrum e Kanban, conduz a organização para níveis de excelência ainda não alcançados. Esta excelência permitirá a criação de uma cultura baseada em relacionamentos fortes e duradouros, estimulando a criatividade e a inovação. Responsabilidade, disciplina, senso de propriedade, capacidade de auto-gestão, respeito e colaboração permitirão a criação de uma equipe extremamente ágil e coesa, que tenha prazer naquilo que faz e que, principalmente, construa uma relação de confiança entre si e para com seus clientes. Espera-se, pois, que a visão da Pirâmide Lean ajude a indústria de software a tornar-se mais produtiva, humana e sustentável.

conclusao

Apresentação da Pirâmide Lean na webhttp://prezi.com/w6pjte9n4bsq/the-lean-pyramid/

Blog da OnCast Technologieshttp://onca.st/blog

Site da Agile Alliance (rico em artigos)http://www.agilealliance.org

Site de Mary & Tom Poppendieck, criadores do Lean Software Developmenthttp://www.poppendieck.com/

bibliografia

sistema de produção fordismo e toyotismo

Documents