BT

Lean e Agile: Casamento dos céus ou contradição?

Postado por Dave West , traduzido por Felipe Rodrigues em 19 Fev 2009 |

Sim, eu estou deliberadamente tentando lhe provocar. E sim, de uma forma muito específica, eu acredito que a última metade da questão é a verdade.

Isso pode ser supreendente já que LeanAgile parece ter se tornado uma palavra no mundo de desenvolvimento de software. Então, talvez alguns avisos foram dados.

Eu conheço Mary e Tom Poppendieck por mais de uma década. Nós éramos amigos e colegas no maior grupo de usuários do mundo - em Minneapolis. Tom foi meu aluno na University of St. Thomas (também em Minnesota, não - muito infortuna no inverno - nas Ilhas Virgens). Tom era um dos revisores técnicos do meu livro sobre objetos.

Exceto pelo fato de que o livro deles vendeu mais que o meu uns 100 pra 1 (e por isso nunca irei perdoá-los), eu só tenho respeito e admiração pelo seu conteúdo e idéias. O Livro deles é um discurso de mestres e deveria ser aprendido e aplicado pelos desenvolvedores de software do mundo todo. Incluindo, talvez, desenvolvedores ágeis.

Então qual é o problema?

ResumidamenteL Lean e Agile são baseados em visões fundamentalmente diferentes e portanto se encontrarão inevitavelmente em oposição nos pontos críticos.

Nos próximos parágrafos eu tentarei mostrar a visões opostas, ilustrar um ponto de conflito e então sugerir como os dois pontos podem ser reconciliados.

Visão do mundo Lean = Produção

Algumas citações do livro Lean oftware Developmente, An Agile Toolkit para introduzir minha declaração que a visão do Lean é uma visão de produção.

O prefácio de Jim Highsmith "... Mary e Tom Poppendieck levaram as práticas do lean industrial a um novo nível - eles nos ensinam como aplicá-las ao desenvolvimento de software." e "... fornece informação saudável sobre aplicação de técnicas lean da perspectiva industrial ao desenvolvimento de software."

Da página xxii da introdução, "Enquanto reconhecendo o perigo de aplica incorretamente metáforas, nós acreditamos que a indústria de desenvolvimento de software pode aprender muito examinando como as mudanças nas abordagens de desenvolvimento de produtos trouxeram melhoras ao processo de desenvolvimento de produtos."

Produção, vocabulário de processo e metáforas são presentes ao longo de todo o livro. Embora haja uma clara rejeição das idéias sobre produção do século 19 (ex: Tailorismo) há uma adoção igualmente clara dos modelos de produção destacados (ex: o modelo de produção Toyota)

Práticas ágeis especificas são avaliadas da perspectiva da contribuição para a produção. Se uma prática ágil específica é vista como estando em conflito com o modelo de processo de produção lean, esta prática deve ser modificada ou eliminada.

Lean não é apenas sobre processo. Por exemplo, dos sete princípios de Lean,

  • Eliminar Desperdício
  • Amplificar o aprendizado
  • Decidir tão tarde quanto possível
  • Entregar tão rápido quanto possível
  • Fortalecer o time
  • Construir integridade
  • Ver o todo,

somente a primeira é inequivocadamente conectada ao processo de produção.

Estes princípios sugerem uma forma de transcender a visão de produção evidente em cada um do outros aspectos do Lean. Nós iremos retornar a esta possibilidade na última parte deste artigo.

Visão do Agile = Construção de Teoria

Eu tive o grande privilégio de ser associado com, e conto a mim mesmo como um do amigos da, maioria dos criadores e defensores da agilidade. Eu discuti a seguinte idéia sobre os fundamentos filosóficos do Agile e descobri que eles concordam. Somente um, Alistair Cockburn, colocou a idéia em papel.

Apândice B, páginas 227 a 239, do Agile Software Development de Cockburn contém um reprint de um artigo escrito por Peter Naur em 1985, entitulado "Programando como Construção de Teoria".

Naur argumenta que o ato de desenvolver software tem sido incorretamente tomado por um ato de produção - produção de "um programa e certos outros textos". Ele cita vários exemplos de inconsistência de dados empíricos com o modelo de produção de desenvolvimento; incluindo, o fato que documentação arbitrária e exatidão tem pouco, talvez nada, a ver com um entendimento de um programa para aqueles que não estão envolvidos em sua criação original.

Construir teoria, a la Naur, é o esforço individual e coletivo para:

  • Entender o Mundo
  • Entender como o software é formado pelo Mundo e como ele se integrará com este Mundo
  • Entender a essência do software e como melhor articular (codificar) esta essência
  • Entender se você alcançou os tres primeiros entendimentos corretamente.

As atividades observáveis assiciadas com a construção de teoria incluem contar muitas histórias, explorar idéias, tentar coisas para ver se elas funcionam, testar seu entendimento, popular seu espaço físico com lembretes evocativos de seu entendimento e fazer estas coisas interativamente em incrementos compreensivos e cada vez crescentes.

Parece muito com um ambiente ágil, mas lembra um pouco um ambiente de produção.

Esceto para citar as idéias de Ryle sobre posse de uma teoria, Naur não apresenta explicitamente um conjunto de princípios para construção da teorias. Se ele tivesse feito isso, esses princípios seriam consistentes com os valores do XP para Simplicidade, Comunicação, Coragem e Feedback.

Visões em conflito

Lean vê o desenvolvimento de software como um processo para sair de uma concepção para um produto. Ele quer otimizar o processo, mesmo que de uma forma radicalmente diferente e com valores radicalmente diferentes do tradicional (ex. Tailorismo) tentar uma otimização.

O Agile vê o desenvolvimento de software como um processo para construir uma teoria consensual do mundo: com um artefato sendo um produto - uma expressão - desta teoria.

Porque as visões fundamentais dos dois lados são dramaticamente diferentes, é inevitável que existam conflitos. Estes conflitos irão manifestar-se normalmente a nível de ferramentas e práticas.

Por exemplo: o product backlog.

Agile embasado na idéia de modularizar o trabalho em uma base de user stories. Uma user story é "algo que o cliente que que o sistema faça." (Kent Beck)

Estórias de usuaŕios (User stories) são originadas a partir do usuário, também chamado de, clientes ou negócio. Estórias podem ser produzidas muito mais rápido que implementadas, especialmente no começo de um grande projeto, ou quando o objetivo é "agilizar" uma corporação inteira.

Quase todos os projetos ágeis estabelecem um product backlog, um conjunto de estórias a serem implementadas. Este conjunto pode ser bem grande. Eu tenho visto projetos com um backlog de centenas de estórias.

Lean olha para o product backlog e vê 'inventário' e 'desperdício'. Mary Poppendieck sugere que o product backlog deveria ser eliminado ou, no mínimo limitado a um tamanho mais condizente com a velocidade dos times.

O Agile vê o product backlog como uma previsão de uma teoria emergente. Mesmo se esta previsão seja fisicamente manifestada como uma parede cheia de cartões de estórias, isso nào é um inventário! A cartas na parede servem como uma forma de memória externa, com cada cartão evocando (reavivando na mente) conversas detalhadas e entendimentos de como as coisas funcionam.

Agile funciona melhor quando há um grande product backlog e quando há uma grande quantidade de gordura na composição do backlog. Gordura resultante de conversas sobre a essência da estória; prioridade da estória; feedback dos desenvolvedores sobre estórias não compreendidas'estórias que acabaram sendo bem mai fácil ou difícil de desenvolver do que o esperado; estórias que tiveram de ser refatoradas para torná-las mais compreensíveis e mais rastreáveis para o desenvolvimento; e feedback da aceitação do usuário em relação às estórias completas.

Eventualmente, a gordura diminui e o product backlog se torna estável. A quantidade de novas estórias adicionadas é reduzida a poucas e a priorização de estórias muda somente nominalmente. Neste ponto se torna ainda mais tentador considerar o product backlog como um inventário.

Reista a tentação. O backlog ainda é uma manifestação física da teoria. Ele fornece o contexto absolutamente essencial para todo o trabalho de desenvolvimento sendo feito.

O backlog fornece o mesmo tipo de suporte crítico para o desenvolvimento de software que os editores de continuidade e conselheiros técnicos fornecem à produção de filmes. Quando a atenção está focada em uma única cena, é fácil esquecer que o herói estava vestindo uma camisa azul, não uma vermelha, no último frame da cena anterior. É fácil esquecer que você não pode ouvir uma explosão no espaço. Erros semelhantes ocorrem quando trabalhando na implementação de estórias e este é o contexto - o prodcut backlog - que fornece a continuidade e correção dos malentendidos da essência.

Em todos os projetos ágeis em que eu fui o coach, eu insisti em manter o product backlog na parede na forma de cartões de estórias adjacentes à informação de monitoração do sprint. As reuniões diárias (stand-up meetings) eram conduzidas com uma visão facilitada tanto das estórias de foco imediato quanto das estórias do product backlog. O product backlog era revisado e discutido em detalhes durante cada jogo de planejamento e cada retrospectiva - simplesmente para refrescar a memória de todos envolvidos com o estado de nossa teoria atual.

O ponto deste exemplo: sua visão necessáriamente colore sua interpretação das "coisas". Um simples artefato, como um product backlog, tem muitas realidades, propósitos,valores e funcionalidades diferentes, baseado na sua perspectiva do mundo. Neste caso a 'visão da produção' resulta em um ainterpretação que é atualmente prejudicial ao desenvolvimento ágil de software.

Eu sei que estou argumentando de forma geral e oferecendo apenas um único exemplo para suportar este argumento. Esta é uma questao de limitação de espaço, não falta de exemplos.

Reconciliação

Um casamento é pura felicidade - exceto pelos desentendimos, argumentos e objetivos conflitantes. Lean e Agile forma um belo casal. Tem certeza que este casamento pode ser salvo?

Claro que pode, mas há 3 pré-requisitos, uma para o Lean, uma para o Agile e um para ambos.

O Lean precisa tirar os "óculos de produção" e olhar para o Agile e elementos do processo de desenvolvimento ágil a partir de uma perspectiva holística que inclui todo os sete princípios do Lean. Se o product backlog for avaliado como mais do que o princípio de 'eliminar desperdício', suas contribuições para "amplificar o aprendizado, decidir tão tarde quanto possível, fortalecer o time, construir integridade e ver o todo" seriam óbvias.

Os praticantes de Agile devem, ironicamente, fazer a mesma coisa. Quando você ouvir praticantes de agile falarem sobre o que eles fazem - seu vocabulário, metáforas e implementação de práticas refletem a perspectiva do agile como um modo de produção alternativa. Pergunte para a maioria dos agilistas sobre Naur e construção de teoria e você receberá um olhar vazio.

Tanto o Lean quanto o Agile devem parar de aplicar, de forma literal, as ferramentas e práticas. Ferramentas e práticas não são nada mais que expressões de valores, princípios e filosofia. Eles não as únicas expressões possíveis e podem nem ser as melhores expressões. Nenhum lado será capaz de perceber o aviso de seus fundadores para "usar, adaptar e transcender" até e a não ser que eles venham a entender porque as práticas e ferramentas são o que são.

AgiLean foi um caso de amor a primeira vista. A lua de mel foi um excitante intervalo para encontrar novas idéias e mesclar idéias. Mas este tempo já é passado. Se este casamento vai sobreviver, ambas as partes precisam deixar para trás suas atrações superficiais - porque este tipo de conflito irá inevitavelmente surgir.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Péssima tradução. by Ian Gallina

Gente, este artigo é interessantíssimo, mas está mal traduzido e mal revisado (até ortografia, que o Editor de Texto faz sozinho).
Vamos caprichar mais né ?

Grato

Re: Péssima tradução. by Leonardo Campos

Minha visão sobre o assunto:
Uma implementação com base nos princípios Lean não é necessariamente ágil, mas tende a se tornar caso exista uma cultura kaizen (melhoria contínua) em ação.

Um exemplo disto seria a aplicação do método Kanban sobre um processo RUP padrão. Ela seria uma abordagem Lean, pois a partir deste ponto haveria uma busca contínua pela eliminação dos desperdícios e os demais princípios do Lean.

Imagine o processo, neste momento de implatação do Kanban, como sendo totalmente faseado - waterfall, passando-se 100% do output de uma fase anterior (upstream) como input para a próxima (downstream).

Invariavelmente isso gerará retrabalho e esperas, idas e voltas de artefatos etc (desperdícios de movimento, de espera etc).
Ainda há o problema, neste caso, do Loop de Feedback ser longo. Aos poucos, o Kanban vai fazer estes problemas se tornarem evidentes (não vai resolvê-los magicamente), vai tornar clara a necessidade de ampliar o aprendizado (mais loop de feedback, mais conversa direta etc) entre muitas outras coisas.

Veja onde quero chegar, ao aplicar os princípios do Lean (só citei dois, mas vale para os demais), é bastante provável que se chegue a um estado ágil.

Resumindo, acredito que o Agile é um processo já mais "consolidado" em termos Lean, com bastante redução de desperdício, com ampliação do aprendizado por meio do uso de iterações (ou fluxo contínuo) e com práticas como reviews, dailies, retrospectivas etc. Ele fortalece o time sustentando a auto-organização. A parte de construir integridade está lá no manifesto ágil quando fala da excelência técnica em seus 12 princípios.

Também é possível perceber algum grau de postergar decisões até o último momento responsável no Agile, como decisões tomadas só no momento de planning por exemplo, e de entregar quase que Just In Time quando o Manifesto fala em entregar software funcionando com frequência.

Em relação ao "Ver o todo", há pouco foco em systems thinking a meu ver.

----------
O argumento do autor sobre o backlog:
Acredito que exista um mal entendido neste quesito. Existe o que eu chamo de "LembreteLog", no qual os clientes/POs colocam tudo o que quiserem, e o Backlog, no qual os itens já foram trabalhados para serem user stories, já passaram por algum tipo de estimativa e já estão priorizados, ou seja, todos os itens passaram por uma fase de análise.

Backlog não é LembreteLog. Assim, é realmente um desperdício analisar/estimar/priorizar/escrever como user stories, centenas ou até milhares de itens em um Backlog. Imagine o trabalho para achar os itens, mantê-los priorizados e por aí vai. Um backlog (não lembretelog) deveria conter, dependendo da volatilidade do mercado que você está trabalhando, algo equivalente ao trabalho de três meses (volátil) a um ano (estável) de sua equipe com base em sua velocidade histórica.

Ufa

Re: Péssima tradução. by Leonardo Campos

Faltou deixar claro que o LembreteLog pode (e normalmente irá) coexistir com o Backlog, sendo o primeiro uma fonte para o segundo.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT