Ao participar da Primeira Conferência Latino Americana sobre Métodos Ágeis, o Agiles 2008 realizado em Buenos Aires, na Argentina tivemos a oportunidade de realizar uma entrevista exclusiva com o simpático e bem humorado casal de gurus, criadores do Lean Software Development, Mary e Tom Poppendieck que foram Keynotes no evento.
A entrevista será publicada em vários capítulos, em uma espécie de degustação ágil, criando um ritmo, uma cadência como diria Tobias Mayer, também palestrante do Agiles 2008 em entrevista exclusiva para InfoQ na discussão sobre Time Box.
Primeiro capítulo destinado aos que nunca ouviram falar do casal Poppendieck (http://www.poppendieck.com/) ou mesmo Lean Software Development (http://www.infoq.com/br/lean), ou aqueles que já os conhecem e admiram, e tem interesse em conhecer um pouco sobre a sua trajetória.
Em breve serão publicadas as muitas outras perguntas e respostas realizadas em mais de uma hora de entrevista. Lembrando sempre que graças a participação e networking brasileiro e a sinergia com a comissão organizadora a segunda edição do Conferência Latino Americana será realizada em Florianópolis dias 6 a 9 de outubro. (http://www.agiles2009.org/), e nós três, autores desta entevista, fazemos parte da comissão organizadora.
InfoQ Brasil: Poderia nos contar um pouco sobre a sua trajetória até chegar ao Lean Software Development?
Mary Poppendieck: Ok. Comecei minha carreira como matemática. Fiz mestrado em matemática e fui trabalhar na Bell Telephone Laboratories fazendo uma coisa, que na época era nova : programação! Eu não tinha a mínima idéia do que fosse, mas era divertido.
Foi então que a Bell Labs começou a mandar funcionários para cursos de especialização em matemática, pois naquela época ainda não havia diploma de ciência da computação.
Isso foi em 67, 68, e assim resolvi voltar a estudar e fazer um mestrado em matemática.
Quando terminei, Tom havia ido para Universidade de Wincosin para fazer seu PhD, estava ocupado com isso.
Eu fui então ao departamento de física onde ele estudava e perguntei: “Que tal se eu fizer programação para vocês?” e eles me contrataram para fazer programas para experimentos físicos.
Aprendi a ser programadora e, depois de 4 ou 5 anos Tom conseguiu seu PhD; Foi então que fomos para Detroit e eu fui até a General Motors, bati na porta deles e disse: “Oi, eu posso programar qualquer computador, com certeza vocês querem me contratar...”, e eles disseram: “ ah, claro, alguém experiente que saiba programar !” – porque naquela época haviam poucas pessoas com experiência nisso... Então trabalhei na automação de veículos e o computador que eles tinham, mesmo naquela época, era bem primitivo e só fazia linguagem Assembly, mas eu trabalhava bem daquela forma.
Assim programei um sistema de controle de veículos automatizados, para isto tive que comprar um livro sobre sistemas de controles porque mesmo os engenheiros que me diziam o que fazer também cometiam erros e eu tinha que corrigi-los.
Depois de um ano em Detroit, Tom conseguiu um emprego em Minnesota, como professor em uma universidade. E eu fiz a mesma coisa que já havia feito antes. Fui bater na porta da 3M e disse: “com certeza vocês gostariam de me contratar, eu posso fazer software, eu posso fazer muitos programas de computador” – então eles me contrataram para seu sistema de controle de processo experimental, onde eles estavam justamente tentando usar o computador para controlar processos.
Trabalhei na 3M por 20 anos. Comecei como engenheira de controle de processos e então me envolvi com processamento de informação e controle de sistemas e depois fui para a fábrica. Na fábrica fui gerente de TI e fazia tanto processamento de dados, análise estatística e clássica, quanto software de controle de material e, compilava dados em cluster, coisas assim e, de lá fui para a matriz corporativa e trabalhei com softwares em várias áreas.
Consegui um trabalho fazendo desenvolvimento de produto, eu havia conseguido trabalhar com desenvolvimento de produtos de software e me apaixonei por isto. Mas a 3M não estava realmente preparada para produzir softwares como produto, mas eu gostava muito de trabalhar na 3M, deixei a divisão de desenvolvimento de produto e fui trabalhar com sistemas de iluminação e, de verdade, fiz o produto campeão para sistemas de fibra ótica.
Nós desenvolvemos todo um novo processo, foi muito divertido e, no final dos anos 90, a 3M fez uma proposta: eles ofereceram um plano de apostendoria maravilhoso para alguns de nós que estávamos com seus 50 e poucos anos. Irrecusável, então eu disse: “claro, por que não?”.
E eu saí da 3M e busquei outro emprego, trabalhei numa empresa da Califórnia por um ano e, naquele momento, decidi que ainda precisava trabalhar por mais alguns anos e me envolvi como gerente em um projeto do governo da Minnesota.
Naquela época eu já não fazia software há 8 anos. Primeiramente eu estava só fazendo algumas análises, análises comerciais e, o projeto se tornou um desastre. No momento em que eles já haviam passado por dois gerentes de projetos que falharam eu fui chamada para tentar resgatar o projeto, o que eu fiz mais ou menos, mas aprendi muito sobre Waterfall.
Essa foi na verdade a primeira vez que eu ouvi falar sobre Waterfall na vida...
InfoQ Brasil: Em que ano foi isso?
Mary Poppendieck: Isto foi em 98.
Na realidade nós não fazíamos Waterfall na 3M em controle de processos, não entendíamos o conceito, ok?
Eu não entendia como aquilo podia funcionar e, não funcionava.
Então o que eu fiz foi mais ou menos... Conseguimos que o sistema funcionasse, mas aí eles ficaram sem dinheiro e não me contrataram mais como gerente de projeto e eu pensei: eu tenho que escrever um livro porque esse Waterfall é absurdo, não faz nenhum sentido. Tenho que descobrir um modo de ensinar a essas pessoas a tornarem as coisas lean, como fizemos na nossa planta de fabricação e que poderia funcionar em desenvolvimento de software, pois quando trabalhava na fábrica tivemos que passar por uma conversão massiva para o “just in time”, que depois foi chamado de lean, para que ela sobrevivesse a enorme concorrência do Japão.
Então resolvi escrever um livro sobre como essas idéias lean poderiam ser aplicadas no desenvolvimento de software, e escrevi. Eu queria escrever um livro e achei que seria um bom tópico e, depois disso, Tom e eu começamos a viajar dando aulas sobre o tema e é o que temos feito desde então.
InfoQ Brasil: Tom, poderia nos contar um pouco sobre a sua trajetória até chegar ao Lean Software Development?
Tom Poppendieck: Mary falou sobre nós até a época em que eu era um professor universitário. Fiz isso durante oito anos e gradualmente, fui passando de professor de física para professor de computação. Na época a linguagem vigente era o Pascal, então ensinei linguagem Assembly, estrutura de linguagem Assembly e estrutura de programação Pascal. Depois de um tempo decidi que seria melhor voltar para empresas e fui para Honeywell onde estive na divisão que fazia sistemas de navegação para aviões comerciais, como laser gyro, eu estava profundamente envolvido com o sistema de navegação do 777 (esse avião Boeing). Vendo como eles são construídos, testados e programados, posso garantir que são seguros... Mas não era um processo muito eficiente.
Na época em que eu estive na Honeywell fizemos muitas melhorias nos processos. Uma delas foi introduzir o “just in time” na área de fabricação, mas, além disso, o principal projeto pelo qual eu era responsável era de uma melhoria que transferia o design de engenharia para áreas de consumo; área de produção, área de documentação, área de suporte; e a parte importante daquele projeto era conseguir que todos entrassem em acordo: mudança no processo, mudanças nos padrões.
Parte do processo era um programa de software que era basicamente um banco de dados, funcionando numa pequena L-11, se você ainda se lembra daquelas maquininhas: eram milhões de linhas de códigos em milhões de registros de banco de dados. Aprendi muito com isso.
A indústria aérea tem altos e baixos, obviamente, e durante um desses períodos em baixa me foi oferecida a oportunidade de um outro emprego e, fui para uma empresa que havia sido comprada pela General Electric, que fornece computadores, servidores e equipamentos de rede para empresas de todo o mundo.
O grande projeto deles era instalar SAP. Nós inicialmente começamos com outro produto, mas não funcionou muito bem e, a empresa se tornou global então fomos para o SAP e eu fui o arquiteto disso e, foi a maior implementação de SAP que já havia sido tentada até aquela época e na verdade acabou funcionando.
Fui convidado a ir para Atlanta para completá-la, mas como não estava interessado em me mudar, segui adiante e me uni a uma empresa de consultoria, onde atendíamos uma ampla variedade de empresas diferentes. Era uma empresa cujo modelo de negócios era assessorar clientes a utilizar os últimos modelos de tecnologia.
Originalmente era linguagem de quarta geração, depois SmallTalk, depois Java e no final as coisas baseadas em componentes. Lá, como em qualquer outra empresa, havia altos e baixos, e – quando foi isso, 2002? – eu me uni a Mary em nossa empresa atual e nós temos seguido esse maravilhoso hobby de aposentadoria desde então.
Nós viajamos ao redor do mundo, interagimos com as pessoas mais brilhantes, em qualquer lugar do mundo e, tem sido uma alegria imensa para nós podermos aprender com pessoas e dividir o que aprendemos com outras.
Depois do primeiro livro, depois de alguns anos, nosso curso evoluiu para o ponto em que o conteúdo de nossas aulas já não se relacionava mais com o que estava escrito no livro, então escrevemos um segundo livro que foi lançado há três anos, e agora isso está acontecendo de novo.
Temos aprendido bastante e trabalhado com empresas de todos os tamanhos, com as pessoas que estão na linha de frente, profissionais, desde os times de gestão até os níveis executivos e é hora de sair em sabático e escrever um terceiro livro, um guia lean para desenvolvimento de software.
InfoQ Brasil: Você pode falar um pouco sobre lean para aqueles que não sabem o que é?
Mary Poppendieck: Imagine que você está no Japão, em 1947 e, está tentando produzir carros. Você quer abrir uma indústria local, mas tem medo dos carros importados dos Estados Unidos. Está bem consciente disso, pois tem participado da indústria global nas últimas décadas, sabe que tem que ser tão produtivo como os EU para competir na produção de carros. Essa era a posição que a Toyota estava e, eles perceberam isso constatando que eram nove vezes menos produtivos que os EU. E assim o desafio foi lançado para todos na Toyota: temos que nos tornar dez vezes mais produtivos se quisermos competir. Foi assim que toda idéia do lean começou: um aumento drástico em produtividade. Bem, é um conceito bastante simples. Quando você esta tentando construir alguma coisa, está tentando entregar valor a um cliente. Se você tiver que ser muito, muito produtivo, terá que eliminar qualquer coisa que não adicione valor, porque não há nenhuma maneira de ser dez vezes mais produtivo a não ser que se pare de fazer qualquer coisa que não esteja diretamente relacionada com o que o cliente irá pagar. Este é o conceito fundamental de lean: parar de fazer coisas que não adicionem valor.
Há uma quantidade enorme de coisas que as pessoas fazem que não deveriam estar fazendo; que são desperdício. Coisas que não acrescentam valor são chamadas desperdício, e em desenvolvimento de software nós fazemos uma incrível quantidade de coisas que na verdade desperdiçam tempo e energia das pessoas. Vou dar um exemplo: temos essa idéia que devemos testar no fim do ciclo de desenvolvimento. Sabe, se nós escrevêssemos os testes e testássemos e, nunca deixássemos que os defeitos entrassem nos códigos em primeiro lugar, as pessoas descobririam que são duas, três, quatro vezes mais produtivas, pois elas não teriam que buscar os erros já no final e a qualidade do produto acaba sendo significantemente mais alta. Temos que tirar isso da cabeça, que é uma boa idéia construir todos os códigos e só testar no final.
Quando você tenta fazer quatro coisas ao mesmo tempo, não consegue fazer nenhuma delas bem. Você tem que descobrir uma técnica de planejamento que pare essa bobagem e permita que as pessoas façam realmente bem uma coisa de cada vez. Lean é um modo de pensar sobre o fluxo durante um processo, que seja uniforme, rápido e de qualidade excepcionalmente alta. Não importa se for trazer pacientes para um hospital e trata-los o mais rápido possível, ou fazer o estoque em uma grande loja e fazer com que sejam comprados o mais rápido possível, ou que a fabricação de algo desde a matéria prima até o produto final seja a mais rápida possível. Lean se refere a um fluxo rápido sem tempo extra perdido, sem defeitos acrescentados, nenhum trabalho extra que não necessite ser feito, é de muito alto impacto. Quando você começa a pensar sobre desperdícios, é impressionante o que começa a ver até dizer: “oh, acho que isso é um desperdício”. Mas testar não é desperdício.
Então você tem que pensar muito para saber o que é necessário para ir de “eu tenho um cliente com um problema” até “o problema foi resolvido” de maneira muito rápida. Lean diz respeito a isso tudo. E é usado na fabricação, é usado no gerenciamento de redes de fornecimento, é usado em operações hospitalares, em todos os tipos de lugares.
Tom Poppendieck: Mary descreveu o primeiro dos dois pilares do lean. O segundo é o respeito pelas pessoas e esse pilar é baseado no maior, no mais sério desperdício: o desperdício de talento, desperdício de esforço, desperdício intelectual de pessoas e seus aprendizados. Respeitar pessoas é uma coisa muito profunda. O principal trabalho de um líder numa empresa lean não é conseguir que o trabalho seja feito; seu principal trabalho é treinar seu pessoal, ajuda-los a melhorar, ajuda-los a tornarem o processo melhor.
A percepção chave é a de que um excelente resultado vem de pessoas excelentes utilizando um processo excelente. Se o foco for somente um aumento de ganho, há muitas maneiras tolas de se conseguir isso em curto prazo, mas se seu foco for o aumento da habilidade de seu pessoal e o aumento da habilidade do processo que é usado para trabalharem juntos para produzirem esses resultados, você terá um resultado financeiro excelente. Assim, o respeito pelas pessoas é a chave da coisa e, o mecanismo chave para isso é kaizen – aperfeiçoamento contínuo para se tornar melhor. O enfoque principal de kaizen é o aperfeiçoamento do produto e do processo. Todos envolvidos no trabalho dão suas idéias e percepções; “se fizermos isso um pouquinho diferente irá funcionar melhor..”. Mas não há mecanismo, não há prazo, esqueça isso, é um desrespeito.
O mecanismo do kaizen é de separar um tempo para agir assim, se eu tiver uma idéia, vou até o líder do meu time e digo: “eu tenho idéia para fazer isso melhor” e, o líder me ajuda a formular uma forma muito clara para descrever o que é o problema. Eu trabalho junto aos meus colegas formando uma imagem clara da situação atual para ter certeza de que eu realmente estou entendendo o que está acontecendo e, quando tiver uma compreensão clara da situação atual, de como as coisas estão funcionando, então eu faço uma análise, um diagrama de bolhas tentando entender o que não está funcionando direito e o que precisa ser mudado para tornar a situação melhor.
O enfoque principal de kaizen é o aperfeiçoamento do produto e do processo.
Agora, uma vez que isso é feito, que seu líder e seus colegas (pessoas afetadas pelo problema), concordarem onde ele está, aí é hora de descobrir – como deveria ser, o que é preciso mudar para melhorar a situação? – e você propõe uma situação futura e aí diz: “tudo bem, o que vamos fazer? como vamos realmente agir? que experiências vamos fazer?” E para definir um experimento você não tem só que dizer: “vamos fazer isso”, mas tem que dizer – “se eu entendi isso corretamente, se eu fiz uma análise correta, espero que as medidas críticas que importam, tempo de ciclo, talvez o número de defeitos que passam, qualquer que seja o problema que você estiver tentando chegar, irão melhorar em no mínimo 50%” ou qualquer que seja o impacto do experimento proposto. E quando seu líder e colegas concordarem, todos terão ajudado a articular a experiência, todos os que são afetados pela mudança que você está propondo se envolveram na discussão e ai você tenta, você mede, e se sua previsão estiver certa, então esta nova maneira em que seu grupo, as pessoas que são afetadas pelo problema, fazem seu trabalho.
E todo mundo faz dessa maneira não para ficar aderente a um processo padronizado, mas para ter um baseline para melhorias progressivas. Agora, esta técnica é utilizada na Toyota em todos os níveis: o pessoal da limpeza o usam para melhorar os processos de manutenção da planta, os trabalhadores do chão de fábrica o usam para melhorar a eficiência da linha de produção, os gestores o usam para melhorar seus processos, os executivos o usam e é o principal mecanismo que é usado na Toyota e outras empresas Lean para que as pessoas cresçam, para utilizá-las no seu máximo potencial, para dar a elas um profundo e íntimo orgulho do que fazem e para eliminar desperdício, de forma tal que todos tenham mais valor para ser compartilhado para a prosperidade da companhia, para a prosperidade de todos os acionistas, e para o país.
Sobre os autores
Yara Senger é Diretora Educacional e Instrutora da Globalcode, formada pela USP em São Carlos, diversos artigos publicados na Java™ Magazine e palestras ministradas nos maiores eventos de Java do Brasil, e também no JavaOne/EUA e Javapolis/Bélgica. Suas áreas de interesse estão realacionadas principalmente a desenvolvimento web com JavaServer Faces e tecnologias relacionadas, bem como metodologias ágeis de desenvolvimento e gestão.
Jorge Alberto Diz é Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP. Com 25 anos de estrada na área de tecnologia da informação, boa parte deles em grandes empresas, ensina há 7 anos, 2 deles na Globalcode. Interessado atualmente em metodologias, testes e linguagens específicas de domínio. Foi fisgado pelo Java em 1999.
Manoel Pimentel É Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach em Agile, Lean e TOC para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e Editor Chefe da InfoQ Brasil, Já escreveu sobre agile para importantes portais e revistas do Brasil e exterior e Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Tradutoras:
Ana Claudia R. Silva, Canadense, ministra aulas, faz transcrições e traduções e é responsável pelo programa de Imersão em Ubatuba (http://immerseyourselfubatuba.blogspot.com/) e Olivia Borges, tradutora, trabalha na área de assessoria em idiomas a mais de vinte anos prestando serviços para diversas empresas.