Tecnologias de Desenvolvimento de Software: Lean vs Princípios Ágeis

“Lean” e “Agile” são termos que têm sido muito usados recentemente, muitas vezes em referência a metodologias de desenvolvimento de software, gerenciamento de projetos ou estilos organizacionais.

Mas você já se perguntou:

O que é Lean? O que é o Agile? Existe alguma diferença?

Merriam-Webster Dictionary define Agile como “ter um caráter rápido e adaptável, ou marcado pela habilidade de se mover com rápida e fácil graça”

Lean é definido simplesmente como “magro e saudável, ou contendo pouca ou nenhuma gordura”

Baseado nestas definições, podemos assumir que alguém que é lean e alguém que é ágil poderia ter muitas características compartilhadas. O mesmo é verdade no contexto do desenvolvimento de software.

O que é Agile? O que é Lean?

Agile é hoje amplamente conhecido no mundo da tecnologia como um conjunto de valores e princípios para orientar o desenvolvimento de software. “O Manifesto Ágil” estabelece um conjunto de quatro valores e 12 princípios. Destilado até a sua essência, Agile é exatamente o que você pensa que pode ser. É Ágil. A metodologia favorece a flexibilidade, comunicação, colaboração e simplicidade.

Lean é menos entendida e carece de uma definição de corte clara apoiada por um consenso profissional. O termo “Lean” foi originalmente cunhado para descrever um modelo de organização da manufatura baseado no Sistema de Produção Toyota, mas é comumente considerado um sub framework dentro do guarda-chuva Ágil do desenvolvimento de software.Hoje em dia, há muita confusão sobre o que é Lean, o que é Ágil, se eles são um e o mesmo, e que deve ser utilizado.

O Nascimento de Novas Metodologias de Desenvolvimento de Software

Ambos Lean e Ágil foram desenvolvidos em resposta às deficiências dos métodos existentes, como Waterfall. Utilizados desde os anos 70, desenvolvedores e gerentes de engenharia de software começaram a notar as ineficiências de Waterfall nos anos 90. Com mercados mais dinâmicos e consumidores mais experientes em tecnologia, Waterfall foi incapaz de responder com rapidez suficiente às exigências do mercado, mudando a tecnologia, ou entregando software livre de bugs de forma consistente.

Na busca de um modelo melhor, os criadores de Lean e Agile procuraram desenvolver metodologias com uma abordagem mais focada no cliente. As novas metodologias abraçaram a capacidade de adaptação como uma vantagem competitiva, favoreceram os testes iniciais e contínuos, e trouxeram um elemento humano ao gerenciamento e execução de projetos.

Princípios Lean vs. Ágil

Desenvolvimento de Software Lean (LSD) foi proposto pela primeira vez pelo Dr. Robert Charette como uma forma de construir organizações tolerantes à mudança que estavam se tornando cada vez mais dependentes de software.

P>Próximo veio “O Manifesto Ágil” que consagrou os 12 princípios do Desenvolvimento Ágil de Software.

O outro trabalho autoritário sobre metodologias de desenvolvimento de software é creditado a Mary e Tom Poppendieck, que publicaram Lean Software Development: Um Agile Toolkit.

Aqui está uma comparação lado a lado dos valores e princípios de cada um:

Comparando os 12 princípios do LSD do Dr. Charette e os 12 princípios do Agile, você pode ver que eles são surpreendentemente semelhantes. Os sete princípios Lean propostos pelos Poppendiecks são menos direcionados, mas ainda assim se sobrepõem ao “The Agile Manifesto” e ao Desenvolvimento de Software Lean de Charette.

Aqui estão mais elementos que todos eles têm em comum:

• O valor de responder rapidamente às necessidades dos clientes
• Testes preliminares
• Uma abordagem iterativa ao desenvolvimento
• Estilo de desenvolvimento do MVP (Minimum Viable Product) em detrimento de recursos pesados
• Cooperação tanto dentro da empresa como com as partes interessadas externas

Linha do tempo

Nós investigamos os eventos da bacia hidrográfica e publicações que deram origem a essas terminologias para ver como elas se tornaram populares. Confira abaixo a nossa linha do tempo detalhando a progressão, e adicione-a à sua lista de leitura se você estiver tão inclinado!

br>>>/p>

Origens do Lean e do Agile

Como você pode ver na linha do tempo, o termo Lean foi usado pela primeira vez por Womack et. al. em 1990 para descrever o Sistema de Produção Toyota em seu livro, The Machine That Changed The World. Dr. Robert Charette mais tarde adaptou as idéias Lean descritas em publicações anteriores para criar seu “Lean Software Development”.

O termo Agile não foi amplamente adotado até a publicação do “The Agile Manifesto” em 2001. Os termos Ágil e Lean foram ambos cunhados por profissionais da tecnologia ocidental ou acadêmicos que estavam se referindo ao Sistema de Produção Toyota (mais sobre isso mais tarde).

Podemos pegar alguma falha por dizer isso, mas com isso em mente, os termos Lean e Ágil não são realmente tão importantes. Ter dois termos oriundos dos mesmos princípios realmente contribui para a confusão sobre o assunto. Dito isto, esta é a terminologia adotada pela indústria, por isso vamos continuar a usá-los.

A linha do tempo também é outra fonte de confusão. O Dr. Robert Charette apresentou suas idéias sobre o Desenvolvimento Lean de Software no início e meados dos anos 90. O propósito tático e 12 princípios de sua abordagem de Desenvolvimento Lean foram descritos em 1998 em um artigo intitulado “Desenvolvimento Lean”, quase três anos antes do “O Manifesto Ágil”. Em uma prova da sobreposição entre Lean e Agile, este artigo foi escrito por Jim Highsmith, que mais tarde se tornou um dos principais fundadores do movimento Ágil. Entretanto, o artigo de Highsmith não teve grande circulação, e não foi até 2003 que o próprio Charette escreveu uma explicação mais profunda por trás de sua abordagem de desenvolvimento lean no relatório de pesquisa, “Challenging the Fundamental Notions of Software Development”

Em uma troca de e-mail com o Dr. Charette, ele foi rápido em apontar que sua concepção de Desenvolvimento Lean era destinada ao nível organizacional dentro da área de software:

Minha foi resultado de uma necessidade estratégica bem como operacional de melhorar o valor do negócio/missão de TI para a organização, e eu abordei isto a partir de uma perspectiva de gerenciamento de risco.
-Dr. Robert N. Charette

Esta difere ligeiramente do Agile, que foi inicialmente proposto estritamente como uma “melhor maneira de desenvolver software”, mas agora é aplicado a vários projetos e métodos de gestão.

2003 foi também o ano em que a Poppendiecks publicou Lean Software Development: Um conjunto de ferramentas ágeis. Este livro detalhou sete princípios do Desenvolvimento Lean, que se correlaciona diretamente com as sete formas de desperdício no Lean Manufacturing.

O livro Poppendiecks simultaneamente reforçou Lean como metodologia de desenvolvimento de software e esbateu a distinção entre Lean e Agile, propondo Lean como um método complementar dentro do Agile. Na verdade, na época da publicação, o livro foi vendido como a última publicação dentro da The Agile Software Development Series.

Hoje, os múltiplos trabalhos dos Poppendiecks sobre o assunto são considerados leitura essencial para o Lean, e “aspirantes a lean” praticantes de desenvolvimento de software.

Divergence in Application

De acordo com o Dr. Charette, uma das principais diferenças entre Lean e Agile é que Agile é de baixo para cima, enquanto Lean é de cima para baixo. Isto é evidente na estrutura end-to-end (E2E) do Lean e no princípio See the Whole proposto pelos Poppendiecks. Abaixo explicamos estes princípios em ação na prática do mapeamento do fluxo de valor.

Mapeamento do Fluxo de Valor

Para realizar o princípio See the Whole, os Poppendiecks detalham um método de mapeamento do fluxo de valor para revelar as atividades de valor agregado versus as atividades sem valor agregado ao longo do processo de desenvolvimento end-to-end.

O mapeamento do fluxo de valor analisa o ciclo de desenvolvimento desde o momento em que um requerimento é recebido até o momento em que ele é entregue ao cliente. O objetivo é identificar os desperdícios de inventário e espera (atrasos na produção), e explorar novas práticas para reduzir o trabalho em andamento (WIP) e o tempo de execução.

De acordo com o Poppendieck’s, mapear o fluxo de valores é um exercício simples que requer apenas um lápis e um pedaço de papel. O processo é o seguinte:

1. Mapa seu fluxo de valores atuais (começando com um requisito e uma linha de tempo de ações na jornada até a entrega)
2. Analisar a maior causa de desperdício (O que está atrasando o Work-in-Progress?)
3. Desenvolva um plano para cortar esse desperdício pela metade
4. Crie um mapa do fluxo de valor futuro

O paradigma Ágil como exposto no “The Agile Manifesto” favorece ciclos curtos de iteração e entregas freqüentes em vez de uma visão holística de ponta a ponta. O foco do E2E é, portanto, exclusivo do Lean. Na verdade, é por causa da construção do E2E que o Lean (ao invés do Agile) é mais frequentemente aplicado como uma estrutura organizacional e estilo de gestão.

A visão de ponta a ponta requer que toda a organização participe para eliminar desperdícios. Isto ecoa o propósito declarado pelo Dr. Charette para seu conceito original de Desenvolvimento Lean:

Desenvolvimento Lean é uma filosofia, uma maneira de ver e pensar sobre TI e sua relação com uma organização, tanto quanto é uma abordagem de desenvolvimento.

Lean Kanban Vs. Agile Kanban

ambos Lean e Agile adotaram o sistema TPS Kanban com ligeiras variações. O sistema Kanban da Toyota foi projetado para limitar o Work-in-Progress.

Asso que, ao contrário do tradicional “push manufacturing”, que empurra o estoque para a próxima etapa do processo, o Kanban só puxa novo material para a produção depois que a peça atual foi processada e os componentes precisam ser reabastecidos.

Cartões Kanban tornam-se pedidos de reabastecimento e são enviados de volta para a etapa anterior da produção. Como resultado, o trabalho em progresso é minimizado, e o estoque ocioso é reduzido.

Em desenvolvimento de software, ao invés de passar os cartões Kanban de um passo atrás para o anterior, uma placa Kanban é utilizada. Notas adesivas são usadas, na maioria das vezes para representar requisitos em progresso.

De acordo com o capítulo contribuído por Kai Petersen em Conceitos e Práticas Modernas de Engenharia de Software: Abordagens Avançadas, tanto Agile como Lean utilizam uma lista prioritária de requisitos para puxar tarefas de.

Unlike Agile, que utiliza ciclos de iteração de duração fixa para limitar o tempo de desenvolvimento e governar a placa Kanban, Lean limita o número de tarefas permitidas em um dado momento. Isso permite que o Lean cumpra seu objetivo principal de limitar o WIP, enquanto mede com mais precisão o tempo de execução e identifica o desperdício na produção. Uma vez concluída uma tarefa, uma nova tarefa pode ser extraída da lista de prioridades. Enquanto o Lean utiliza o conceito de fluxo contínuo, o Agile começa cada nova iteração com uma nova tábua.

Algumas equipes reconhecem os benefícios de ambas as abordagens, e começam a utilizar um método híbrido conhecido como scrumban.

Estas são apenas duas das diferenças sutis na abordagem Lean e Agile para atingir objetivos comuns. Outro artigo publicado no Codementor explora mais sobre os usos e aplicações do Lean e do Agile.

Na prática, se sua equipe adota a chamada abordagem “Agile” ou uma abordagem “Lean” não é importante. O que é importante é encontrar as práticas certas para otimizar seus fluxos de trabalho e entregar valor consistentemente aos seus clientes, o que ambas as metodologias vêem como o propósito final.

A Conexão TPS

Então o que tudo isso tem a ver com o Sistema de Produção Toyota? Basicamente tudo. Os criadores tanto do Agile como do Lean foram fortemente influenciados pelo TPS, como Womack et. al. descrevem em A Máquina que Mudou o Mundo. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. A empresa não podia esperar seguir um modelo de Detroit de produção em massa e sobreviver.

Até estas condições, Taiichi Ohno e Kiichiro Toyoda se propuseram a permanecer lucrativos eliminando o desperdício na produção, reduzindo o lead time, e produzindo apenas o que os clientes precisavam, também conhecido como fabricação Just-in-Time (JIT).

Para eliminar o desperdício, Ohno resolveu fazer apenas o que era necessário, quando era necessário, e apenas na quantidade que era necessária.

O processo iterativo de Lean e Agile que se concentra em minimizar o desenvolvimento de recursos, e maximizar a entrega de atualizações espelha diretamente a manufatura Just-in-Time da Toyota.

Jidoka

Jidoka (自働化) pode ser traduzido como automação com um toque humano, às vezes referida como “automação inteligente”. Jidoka desempenha um papel importante na eliminação de desperdícios na produção, tornando as máquinas mais independentes que liberta as pessoas para desempenharem um papel mais ativo na produção e desbloqueia a criatividade humana.

Jidoka depende de máquinas inteligentes que param automaticamente quando há uma irregularidade. Os trabalhadores humanos podem então ir e corrigir o problema, impedindo que defeitos sejam passados para baixo no processo de produção.

Jidoka também capacita cada empregado a parar a linha de produção quando um problema é detectado. O princípio inclui um processo de quatro etapas para eliminar o desperdício de produtos defeituosos:

1. Detectar a anormalidade
2. Parar a produção
3. Fixar ou corrigir a condição imediata
4. Investigar a causa raiz e remediar a situação

P>Vemos o conceito Jidoka no foco Lean e Agile nos testes iniciais e frequentes para erradicar bugs, e ênfase na consulta ao cliente para identificar as dores do usuário.

Resíduos de TPS em um contexto de desenvolvimento de software

Para atingir a manufatura JIT, Taiichi Ohno delineou sete formas de resíduos a serem eliminados. O número oito foi adicionado mais tarde. Se você olhar mais de perto os valores, objetivos e princípios do Agile e Lean, você pode ver que eles são projetados para se proteger contra os oito desperdícios do TPS. Em seu livro de 2003 Lean Software Development: Agile Toolkit, os Poppendiecks apresentaram desperdícios de TPS em um contexto de desenvolvimento de software.

1. O desperdício da superprodução. O desperdício de superprodução é uma das maiores razões pelas quais o método Cascata foi abandonado. A superprodução é considerada codificação extra para funcionalidades que não foram solicitadas e que o cliente pode não querer.

p> Isso se reflete nos seguintes princípios:

Agile ⟶ simplicidade
Charette’s Lean⟶ minimalismo
Poppendiecks’ Lean ⟶ eliminar desperdício

2. O desperdício da espera. Na fabricação de JIT, esperar em uma máquina ociosa ou trabalhador é um desperdício. No desenvolvimento de software, o desperdício é esperar em uma equipe com excesso de capacidade. Se há atrasos na produção que fazem com que uma equipe esteja em standby, ou fazem com que o cliente espere pela entrega, há desperdício.

Princípios de correspondência são os seguintes:

Agile ⟶ ciclos frequentes
Charette’s Lean ⟶ do tempo (objetivo do LSD), solução 80% hoje
Poppendieck’s Lean⟶ entregar o mais rápido possível

3. O desperdício do transporte. No desenvolvimento de software, o transporte é traduzido como “mudança de tarefa”. Demasiadas transferências ou funcionários designados a múltiplas equipes com demanda por excesso de multitarefas é ineficiente e um desperdício.

Princípios de correspondência:

Agile ⟶ colaboração de partes interessadas, equipes auto-organizadas, cultura de
confiança, apoio e motivação
Sistema Lean da Carette ⟶ esforço de equipe
Poppendiecks’ Lean ⟶ capacita a equipe

4. O desperdício do superprocessamento. Trata-se simplesmente de processos extras que não são realmente necessários para entregar valor ao cliente. O exemplo principal é a documentação. Documentação excessiva para processos inflexíveis não será valiosa, nem são manuais do usuário excessivamente detalhados que poderiam ser resumidos em uma ou duas páginas. A documentação é demorada, mas oferece um valor limitado ao usuário final.

p>Princípios de correspondência:p>Agile ⟶ simplicidade, software de trabalho como medida
Charette’s Lean ⟶ minimalismo
Poppendiecks’ Lean ⟶ eliminar desperdícios

5. O Desperdício de Inventário. O Desperdício de Inventário é o Trabalho em Progresso para o qual foi feito um investimento, mas não tem valor até a sua conclusão. Em outras palavras, software incompleto não fornece nenhum valor para o usuário. Lean e Agile valorizam as entregas rápidas e frequentes, com ênfase nos ciclos iterativos frequentes e na entrega de software de trabalho.

Princípios de correspondência:

Agile ⟶ satisfação do cliente (através do cliente precoce e frequente
entrega)
Solução Lean da Carette ⟶ 80% hoje
Solução Lean do Poppendieck ⟶ entrega o mais rápido possível

6. O Desperdício de Movimento. O desperdício de movimento é um esforço excessivo necessário para obter informações ou responder a perguntas. Isto é comum quando as equipes não são co-localizadas, se as tarefas são completadas e os resultados não são disponibilizados imediatamente a todas as partes relevantes, ou quando os interessados não estão prontamente disponíveis para consulta.

Princípios de correspondência:

Agile ⟶ colaboração dos interessados, comunicação presencial
Charette’s Lean ⟶ participação dos clientes, esforço de equipe
Poppendiecks’ Lean ⟶ eliminar desperdício

7. O Desperdício de Defeitos. Como na manufatura, produzir software defeituoso ou buggy representa um investimento desperdiçado pela empresa. Quanto mais rápido um defeito é detectado, mais provável é que o desperdício seja mitigado. Muitos princípios Ágeis e Lean procuram deter o desperdício de defeitos. Para reduzir os defeitos, todas as três metodologias colocam um prêmio nos testes iniciais e freqüentes.

Princípios de correspondência:

p>Agile ⟶ excelência técnica, trabalhando o software como medida
Charette’s Lean ⟶ satisfação do cliente
Poppendiecks’ Lean⟶ ampliar o aprendizado

8. O desperdício da criatividade dos funcionários não utilizados. No desenvolvimento de software, a criatividade não utilizada resulta de um roadmap rígido e da falta de colaboração humana. Assim como Jidoka (自働化), Agile e Lean buscam maximizar a cooperação humana e a inovação para obter os melhores resultados com a tecnologia.

Princípios de matching:

Agile ⟶ colaboração de partes interessadas, reflexão em equipe
Lean da Carette ⟶ “não escrito” 13º princípio de satisfação através de
trabalho
Poppendiecks’ Lean ⟶ ampliar aprendizagem

Valores de TPS na Metodologia de Desenvolvimento de Software

Muitos dos valores centrais que compõem o TPS também se refletem nas metodologias de desenvolvimento de software Agile e Lean.

Kaizen (改善) traduzido como melhoria contínua. Com modelos flexíveis, iterativos e focados no cliente, a melhoria contínua é talvez o valor mais importante das metodologias de desenvolvimento de software Agile e Lean.

Hansei (反省) significa auto-reflexão. Como forma de melhorar a eficiência, o Manifesto Ágil adota diretamente a auto-reflexão da equipe como seu 12º princípio. Ao introduzir seu modelo de Desenvolvimento Lean, Dr. Charette desafia os leitores a refletir sobre todos os pressupostos atuais que ditam os processos que eles utilizam como um passo inicial para encontrar melhores processos. O princípio da aprendizagem ampliada dos Poppendiecks também pode ser considerado Hansei.

Respect for People (尊重) é central para os três paradigmas. O primeiro valor do “The Agile Manifesto” é “valorizar indivíduos e interações sobre processos e ferramentas”.

Respect for People também aparece na afirmação da Dra. Charette da importância para que os indivíduos experimentem satisfação através do trabalho, e o princípio Lean dos Poppendiecks de empoderamento das equipes. Este valor reconhece que quando os indivíduos estão envolvidos na tomada de decisões e na melhoria do seu ambiente de trabalho, eles são trabalhadores mais inovadores e eficientes.

Seiri (整理) é o princípio que espelha o desperdício. Seiri dita que o que é desnecessário deve ser removido. Isto engloba todos os sete desperdícios originais do TPS, para os quais já identificamos o desperdício paralelo no ambiente de desenvolvimento de software.

Gengchi Genbutsu (現地現物) traduz literalmente para “lugar, coisa real”. Na prática, isto significa “inspecionar para entender”. Quando há um problema no processo de produção, o gerente deve ir ao código fonte para entender o problema e determinar como resolvê-lo.

No desenvolvimento de software, este valor se manifesta na ênfase em ciclos curtos de iteração, testes iniciais e colaboração do cliente para que os engenheiros de software possam construir software de trabalho que os usuários realmente querem.

Conclusão

Como mencionamos nos parágrafos iniciais deste post, a metodologia Lean é menos bem compreendida e é muitas vezes considerada uma prática Ágil. Lean é talvez menos bem definida simplesmente por causa de suas aplicações mais amplas.

Lean tem uma relação mais direta com o Sistema Toyota de Produção e foi primeiramente proposta como um conjunto organizacional de métodos e práticas de gestão empresarial, e só mais tarde aplicada ao desenvolvimento de software. Agile, por outro lado, foi desenvolvido especificamente para o desenvolvimento de software por profissionais dedicados na área.

Após detalhar o background compartilhado e os princípios gerais dessas duas metodologias, pode-se ver que esses dois paradigmas têm mais em comum do que diferenças.

Um dos principais autores do “The Agile Manifesto”, Martin Fowler, que também trabalhou de perto com os Poppendiecks, apontou que Lean e Agile não são mutuamente exclusivos:

Lean e Agile estão profundamente entrelaçados no mundo do software. Você não pode realmente falar sobre serem alternativas…. você não faz Agile ou Lean, você faz Agile e Lean.

1. Os 12 princípios do Desenvolvimento Lean de Software de Charette foram descritos pela primeira vez no artigo de Jim Highsmith “Desenvolvimento Lean” em 1998. Isto foi posteriormente elaborado no próprio artigo do Dr.Charette “Challenging the Fundamental Notions of Software Development” ︎