lean software development

Prévia do material em texto

CENTRO UNIVERSITÁRIO CATÓLICA DE SANTA CATARINA 
 
 
 
 
 
 
 
GABRIEL ZANGHELINI 
JEFERSON GUESSER 
 
 
 
 
 
 
Lean Software Development 
 
 
 
 
 
 
 
 
 
 
 
JARAGUÁ DO SUL 
2019 
1. AS ORIGENS DO ​LEAN THINKING 
 
No final dos anos 40, uma pequena empresa chamada Toyota decidiu fabricar carros para o 
Japão, porém havia um problema. Como as pessoas não tinham muito dinheiro, os carros 
precisavam ser baratos. A produção em massa era a forma mais barata de fabricar carros, 
mas isso significava construir milhares de carros iguais, e o mercado japonês não era 
grande suficiente para essa quantidade de carros. O desafio, então, era fazer carros em 
pequenas quantidades, mas manter o baixo custo da produção em massa. 
 
A partir desse dilema surgiu o ​Toyota Production System​, um sistema que trazia uma nova 
forma de pensar na fabricação, logística e, eventualmente, desenvolvimento de produtos. O 
mentor desse sistema foi Taiichi Ohno, conhecido como o pai do ​Toyota Production System​. 
No núcleo do conceito de Ohno estava o principal princípio ​lean​: eliminar desperdício. 
 
Desperdício pode parecer um termo simples, mas Ohno deu um novo significado à palavra. 
Na sua mente, qualquer coisa que não cria valor para o cliente é considerado desperdício. 
Um peça esperando para ser usada é desperdício. Fazer algo que não é necessário no 
momento é desperdício. Transporte é desperdício. Espera é desperdício. Qualquer etapa 
extra de processamento é desperdício. Além disso, defeitos são desperdícios. 
 
2. PRINCÍPIOS ​LEAN 
 
Os princípios ​lean tiveram seu início na produção, como forma de otimizar a produção 
minimizando o desperdício e maximizando o valor para o cliente. Esses princípios já estão 
estabelecidos há muito tempo na produção e sua aplicação já é muito bem definida, tendo 
transformado o mundo do trabalho e gestão do conhecimento. Esses dois objetivos também 
são relevantes para o desenvolvimento de software, que também contém processos 
repetitivos, requer padrões de qualidades específicos e conta com a colaboração de um 
grupo de trabalhadores especializados a fim concluir os projetos. 
 
Entretanto, o desenvolvimento de software tem suas particularidades que o diferem da 
produção. Com isso em mente, Mary e Tom Poppendieck, no livro Lean Software 
Development, apresentam sete princípios ​lean ​para o desenvolvimento de software, além 
de dar dicas e ferramentas para ajudar a aplicá-los nas empresas. 
 
Abaixo, seguem os cinco princípios clássicos: 
 
1. Valor: especificar valor sob a ótica do cliente 
2. Fluxo de valor: alinhar na melhor sequência as atividades que criam valor 
3. Fluxo Contínuo: realizar essas atividades sem interrupção 
4. Produção Puxada: sempre que alguém as solicita 
5. Perfeição: de maneira cada vez mais eficaz 
 
 
 
 
2.1. ELIMINAR DESPERDÍCIO 
 
Eliminar desperdício é o princípio ​lean fundamental. é de onde partem todos os outros 
princípios. Dessa forma, o primeiro passo para implementar o ​lean development é aprender 
a ver o desperdício. O segundo passo é descobrir quais são as principais fontes de 
desperdício e eliminá-las. O próximo passo é descobrir quais são as fontes de desperdício 
restantes e eliminá-las. O próximo passo é fazer isso novamente. Depois de um tempo, até 
coisas que pareciam necessárias são eliminadas gradualmente. 
 
Outro membro do ​Toyota Production System​, Shigeo Shingo, foi o responsável por 
identificar sete tipos de desperdício da produção. Essa lista auxiliou as pessoas a 
identificarem o desperdício mais precisamente. Mas para o desenvolvimento de software, 
essa lista precisou ser traduzida para os sete desperdícios do desenvolvimento de software. 
A tabela 1.1 mostra lista os sete desperdícios e suas respectivas traduções: 
 
Os Sete Desperdícios da Produção Os Sete Desperdícios do Desenvolvimento 
de Software 
Estoque Trabalho Parcialmente Feito 
Processamento Extra Processos Extras 
Superprodução Funcionalidades Extras 
Transporte Troca de Tarefas 
Espera Espera 
Movimento Movimento 
Defeitos Defeitos 
Tabela 1.1: Os Sete Desperdícios 
 
2.2 AMPLIFICAR CONHECIMENTO 
 
O desenvolvimento é um exercício de descoberta, enquanto a produção é um exercício de 
redução da variação e, por esta razão, uma abordagem ​lean ​para o desenvolvimento resulta 
em práticas que são bastante diferentes das práticas de produção ​lean​. O desenvolvimento 
de software é melhor concebido como um processo de aprendizagem semelhante com o 
desafio adicional de que as equipes de desenvolvimento são grandes e os resultados são 
muito mais complexos. A melhor abordagem para melhorar um ambiente de 
desenvolvimento de software é ampliar a aprendizagem. 
 
2.3 DECIDIR O MAIS TARDE POSSÍVEL 
 
Práticas de desenvolvimento que prevêem decisões tardias são eficazes em 
domínios que envolvem incerteza, porque fornecem uma abordagem baseada em opções. 
Diante da incerteza, a maioria dos mercados econômicos desenvolvem opções para 
fornecer aos investidores uma maneira de evitar tomar as decisões até que o futuro esteja 
mais próximo e mais fácil de prever. Adiar decisões, dentro do possível, é uma importante 
prática uma vez que melhores decisões podem ser tomadas quando baseadas em fatos, 
não em especulações. 
Em um mercado em constante evolução, manter as opções de design abertas é 
mais valioso do que comprometer cedo. Uma estratégia-chave para adiar decisões ao 
desenvolver um complexo sistema é criar uma capacidade de mudança no sistema. 
 
2.4 ENTREGAR O MAIS RÁPIDO POSSÍVEL 
 
Até recentemente, o rápido desenvolvimento de software não costumava ser 
valorizado e/ou considerado, pois adotar uma abordagem cuidadosa que evitasse erros era 
mais importante. Atualmente, devemos considerar o “velocidade custa mais” tanto quanto o 
“qualidade custa mais”, em conjunto, pois ambos são pontos a serem considerados, e o 
desenvolvimento rápido tem diversas vantagens. 
Sem velocidade, você não pode atrasar as decisões. Sem velocidade, você não tem 
feedback confiável. No desenvolvimento, o ciclo de descoberta é fundamental para o 
aprendizado: Projetar, implementar, feedback, melhorar. Quanto mais curtos forem esses 
ciclos, mais ser poderá ser aprendido. 
A velocidade no desenvolvimento, ​​garante que os clientes obtenham o que precisam 
no hoje, não o que julgavam necessário ontem. Também lhes permite adiar a decisão sobre 
o que eles realmente querem até que tenham mais certeza quanto a isso. Comprimir o fluxo 
de valor tanto quanto possível é uma estratégia enxuta fundamental para eliminar o 
desperdício. 
 
 
2.5 CAPACITAR A EQUIPE 
 
A execução de primeira linha, consiste em acertar os detalhes de maneira precisa, e 
ninguém entende mais dos detalhes do que as pessoas que realmente fazem o trabalho de 
desenvolvimento. Incluir os desenvolvedores nos detalhes e nas decisões técnicas, é 
fundamental para que seja alcançado a excelência. As pessoas da linha de frente, que 
fazem a parte técnica, são capazes de combinar a importância de detalhes minuciosos, com 
o ponto de vista e percepçãode muitas mentes unidas. Quando estes pontos são 
considerados pelos experts no assunto, e são guiados por um líder igualmente qualificado, 
eles tomarão decisões técnicas e de processos de maneira excepcional, uma vez que 
ninguém poderia tomar estas decisões melhor do que eles. 
Devido às decisões serem feitas de maneira atrasada, e a execução ser realizada de 
maneira rápida, não é possível para nenhum líder, ficar monitorando e orquestrando as 
atividades dos desenvolvedores. Por conta disto, as práticas enxutas usam técnicas de 
“puxar” as instruções para os desenvolvedores, junto com os mecanismos locais utilizados, 
para que assim o desenvolvedor sempre saiba o que precisa ser feito. 
No desenvolvimento de software ​lean​, as práticas de instruções unidas aos 
mecanismos locais para desenvolvimento, é uma determinação que tem como objetivo, 
fornecer versões cada vez mais refinadas de software em intervalos regulares. 
Para que o desenvolvimento não fique obscuro no ambiente de trabalho, as 
sinalizações do andamento ocorrem através de gráficos visíveis diariamente, junto com 
reuniões e integração constante de testes abrangentes. 
 
2.6 CONSTRUIR INTEGRIDADE 
 
Um sistema é considerado íntegro quando um usuário pensa, "Isso é exatamente o 
que eu quero". A estratégia de marketing é uma medida aproximada da integridade 
percebida dos produtos, porque mede a percepção do cliente ao longo do tempo. 
Integridade conceitual significa que o conceitos centrais do sistema funcionam juntos de 
maneira suave e coesa, e é um fator crítico fator na criação de integridade percebida. 
O software precisa de um nível adicional de integridade - ele deve manter sua 
utilidade ao longo do tempo. Geralmente é esperado que um software evolua naturalmente 
à medida que se adapta ao futuro. Software com integridade tem uma arquitetura coerente, 
excelente em usabilidade e adequação ao objetivo e é sustentável, adaptável e extensível. 
A pesquisa mostrou que a integridade vem de uma liderança sábia, experiência relevante, 
comunicação eficaz e disciplina. 
Processos, procedimentos e medições não são substitutos adequados, uma vez que 
não focam exatamente na parte humana do desenvolvimento. 
 
 
2.7 VER O TODO 
 
A integridade em sistemas complexos exige uma profunda experiência em diversas 
áreas. Um dos problemas mais intratáveis do desenvolvimento de produtos é que 
especialistas de determinada área (por exemplo, banco de dados ou GUI) tendem a 
maximizar o desempenho da parte do produto que representa sua própria especialidade e 
não com foco no desempenho geral do sistema. 
Muitas vezes, o bem comum sofre quando as pessoas atendem primeiro a seus 
próprios interesses especializados. Quando indivíduos ou as organizações são avaliadas 
com base na sua contribuição especializada e não no total desempenho, é provável que 
ocorra subotimização. 
Esse problema é ainda mais pronunciado quando duas organizações se contraem, 
porque as pessoas naturalmente querem maximizar o desempenho de sua própria 
empresa. Isto é desafiador para implementar práticas que evitem a subotimização em uma 
grande organização, e é uma ordem de magnitude mais difícil quando os contratos são 
envolvidos. 
 
 
 
 
 
 
REFERÊNCIAS 
 
Wesley, Addison - Lean Software Development: An Agile Toolkit 
<http://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf> 
Acesso em: 4 de Setembro. 
 
Netto, Rafael - 5 princípios do Lean Manufacturing para uma indústria. 
<https://www.nomus.com.br/blog-industrial/principios-do-lean-manufacturing/> Acesso em: 5 
de Setembro.