BT

Kanban - Apenas senso comum?

Postado por Karl Scotland , traduzido por Leonardo Campos em 18 Nov 2013 |

Tenho o privilégio de participar de um grupo de coaches experientes de Agile e Lean que se encontram regularmente para trocar experiências, discutir o que foi aprendido e pensar sobre ideias novas. Em um desses encontros no ano passado, discutíamos a melhor forma de treinar uma equipe acostumada a trabalhar com o método Cascata (Waterfall). Era um bate-papo descontraído durante o almoço e minha sugestão foi bastante simples: se colocar na frente do grupo e falar "Não!" sem parar até que a mensagem fosse recebida e entendida. Essa ideia levou à criação dos slides de treinamento "Introdução ao método cascata".

Pensando de forma mais séria, na verdade não acredito que se trate de uma boa abordagem. No passado já disse "não" a alguns clientes sobre suas abordagens e imediatamente sugeri o que considerava ser a melhor solução, agora procuro entender a situação antes de propor uma série de opções e explicar o impacto potencial de cada uma delas.

O Kanban tem sido a maior influência em meu atual ponto de vista depois de ter ouvido David Anderson falar de sua abordagem em 2007. Anderson documentou o Método Kanban como um conjunto de princípios e práticas em seu livro "Kanban: Mudança evolucionária de sucesso para seu negócio de tecnologia". Nesse meio tempo, desenvolvi um modelo alternativo, chamado "Pensamento Kanban" (fig. 1). O nome representa a forma como penso sobre a resolução de problemas de desenvolvimento utilizando técnicas baseadas no Kanban, em oposição a utilizar soluções específicas. Dessa forma, um dos objetivos é evitar ser prescritivo sem perder a essência do muito que tem sido aprendido nos últimos anos. Os componentes principais que reforçam isso são as ideias de que as heurísticas podem nos guiar ao desenhar sistemas Kanban, bem como julgar a validade das decisões com base no impacto delas.

Figura 1 - O modelo "Pensamento Kanban"

Em relação ao título deste artigo, a resposta para a questão se o Kanban é apenas senso comum é: "não". Apesar da resposta, senso comum é um exemplo de heurística e acredito que o Kanban é uma abordagem heurística para a resolução de muitos desafios do desenvolvimento de produtos. O restante deste artigo explorará mais profundamente o que são heurísticas, as fontes que me levaram a perceber que as heurísticas representam a abordagem correta e como utilizá-las para desenhar sistemas Kanban.

Heurísticas

O dicionário online Merriam Webster oferece a seguinte definição para a palavra "heurística":

Parte ou suporte ao aprendizado, descoberta ou resolução de problemas com a utilização de métodos experimentais e, especialmente, de "tentativa-e-erro"; além disso: de ou relacionado a técnicas exploratórias para resolução de problemas que utilizam técnicas de auto-aprendizado (como avaliação de feedback) para melhorar o desempenho.

Dada essa definição, pode-se ver como as heurísticas são apropriadas para situações em que não exista uma resposta única ou obviamente correta e na qual é preciso descobrir, por conta própria, o que fazer. Assim, pensando no Kanban em termos de um conjunto de heurísticas, pode-se visualizá-lo como um "suporte ao aprendizado" de como "melhorar o desempenho" e assim possibilitar a obtenção de melhores resultados que simplesmente copiam boas ou melhores práticas.

Descobri uma heurística pessoal: quando cruzo três vezes com uma ideia ou conceito de forma independente, eu fico atento a isso. Não estou certo se é por indecisão ou porque três vezes de fato significa que algo deva ser importante, ou ainda se simplesmente são necessárias três instâncias para que perceba uma ideia. Lembro-me que reparei nessa heurística quando descobri o XP. As heurísticas são o último exemplo disso e a seguir estão as três instâncias que me fizeram tomar consciência dela.

Heurísticas substituem regras - Dave Snowden

Dave Snowden comenta a relação das heurísticas em seu modelo Cynefin (fig. 2), assim como em seu artigo "Regras são regras":

Precisamos de uma regra clara para quando (ou quem) pode "quebrar" as regras e as heurísticas que se aplicam além dos limites. Caso seja preciso "quebrar" as regras, tudo bem, desde que as heurísticas sejam seguidas.

Snowden faz uma distinção entre regras, adequadas para os domínios ordenados da direita, e as heurísticas, aplicáveis aos domínios não ordenados da esquerda. Como um exemplo, cita os US Marines, que têm três heurísticas para utilização quando o plano de batalha original falha - capturar o terreno mais alto, manter a comunicação e continuar avançando.

Figura 2 - Cynefin

Nos domínios ordenados do Cynefin (simples e complicado), as causas e efeitos são conhecidas ou, pelo menos, conhecíveis. Para problemas simples utiliza-se uma abordagem Sentir-Categorizar-Responder, aplicando regras com base em melhores práticas mais que evidentes. Para problemas mais complicados, utiliza-se uma abordagem Sentir-Analisar-Responder, aplicando regras com base em boas práticas vindas do conhecimento de especialistas.

No domínio não ordenado da complexidade, contudo, os sistemas não são causais, mas disposicionais. O que se quer dizer é que a relação de causa e consequência só é coerente olhando-se retrospectivamente, e não podem ser repetidas, mas o impacto geral será similar. Para problemas dessa ordem, uma abordagem Sondar-Sentir-Responder é a utilizada, executando-se pequenos experimentos guiados pelas heurísticas para descobrir práticas emergentes. Aliás, para situações caóticas, utiliza-se uma abordagem Agir-Sentir-Responder, na qual tomam-se decisões rápidas e práticas novas são criadas.

Dado que frequentemente (mas nem sempre), desenhamos sistemas Kanban em resposta a problemas complexos, podemos ver que a utilização de heurísticas é uma resposta adequada para determinar quais práticas podem vir a emergir.

Snowden propôs três heurísticas gerais para lidar com problemas complexos, que os tornaria resilientes à quebra e capazes de absorver a complexidade:

  • Cognição distribuída - ter uma rede de partes conectadas, com conhecimento compartilhado pela rede ao invés de centralizado. Auto-organização e equipes multidisciplinares são exemplos de aplicação dessa heurística.
  • Desintermediação - ter acesso direto à fonte da informação, ao invés do acesso por meio de tradução ou interpretação. Os radiadores de informação e os controles visuais são exemplos da aplicação dessa heurística.
  • Objetos de alta granularidade - ter blocos de construção pequenos e em quantidade, que possam ser facilmente reconfigurados ao invés de ter uma única entidade quebradiça. Equipes pequenas e histórias de usuário pequenas são exemplos da aplicação dessa heurística.

As heurísticas ajudam nas substituições - Daniel Kahneman

Em seu recente best-seller "Pensando, rápido e devagar", Daniel Kahneman fala sobre a forma que fazemos julgamentos e tomamos decisões, definindo uma heurística como:

Um procedimento simples que ajuda a encontrar respostas adequadas, mas frequentemente imperfeitas, para questões difíceis. A palavra heurística tem a mesma raiz da palavra "eureka".

Assim, as heurísticas são utilizadas para resolver problemas nunca resolvidos - afinal, não se ouve ninguém tendo um momento "eureka" para algo que todos já conhecem. Nesse ponto, Kahneman argumenta que utilizam-se as heurísticas para substituir questões difíceis por algumas mais fáceis, e sugere um número de instâncias específicas.

Um exemplo é a Heurística da Disponibilidade. Tal heurística é utilizada para substituir uma questão difícil por uma relacionada a exemplos fáceis de lembrar. Kahneman descreve um experimento no qual perguntou-se a um grupo de pessoas: Considere a letra K, é mais provável que seja a primeira ou a terceira letra de uma palavra (em inglês)? Essa é uma questão que a maioria das pessoas não sabe uma resposta estatística, assim, substitue-se a questão por "quantas palavras conheço com a letra K no começo? E com com K como terceira letra?". Isso leva a maioria das pessoas à conclusão de que existem mais palavras começando com a letra K que tendo-a como terceira letra, mas estatisticamente não é o que acontece.

Outro exemplo é a Heurística da Representatividade, em que substituímos a questão difícil com uma que lembre o assunto e estejamos mais familiarizados. Kahneman fez a seguinte questão "um indivíduo foi descrito assim por um vizinho: 'muito tímido e recluso, sempre disposto a ajudar, mas com pouco interesse nas pessoas ou no mundo real. Uma alma certinha e gentil que tem necessidade de ordem e estrutra, assim como uma paixão por detalhes' ". Será mais provável que esse indivíduo trabalhe em uma biblioteca ou seja um fazendeiro? Estatisticamente há muito mais fazendeiros que pessoas trabalhando em bibliotecas, mas as pessoas em geral responderiam à pergunta de outra forma, provavelmente por causa da descrição parecer se encaixar melhor em um bibliotecário.

Os exemplos anteriores ajudam a mostrar como as heurísticas podem levar a inclinações cognitivas, nas quais a substituição pode resultar em uma resposta incorreta. O aspecto da substituição permanece útil, contudo, como vimos com as heurísticas do Marines mencionada antes: capture o terreno mais alto, permaneça em contato e continue avançando. Naturalmente perguntas surgiriam como onde estará o terreno mais alto, como manter o contato, com quem e quando devia ser o próximo movimento. De forma semelhante, podemos pensar nesse aspecto para entender como utilizar as heurísticas como guia para o desenho de sistemas kanban. Quando tiver que responder a perguntas difíceis sobre um cenário complexo, podemos substituir por questões alternativas, mais fáceis, que apesar de não garantirem uma resposta perfeita, podem ajudar a chegar a algo bom o suficiente para melhorar.

Heurísticas guiam para novas possibilidades - Roger Martin

O Design Thinker Roger Martin, em seu livro "The Design of Business" (O desenho do negócio), define heurística como:

regras gerais que nos guiam em direção a soluções por meio da exploração organizada de possibilidades.

Martin descreve o que chama de "funil do conhecimento" (fig. 3) pela qual movemos o conhecimento a partir de mistérios, para heurísticas, para algorítimos. Assim, as heurísticas demarcam a transição entre a exploração de possibilidades e a aproveitamento de uma solução.

Figura 3 - Funil do conhecimento

A transição não deveria obrigatoriamente ser na direção de cima para baixo do funil. Os algorítimos são baseados no passado e o futuro é tanto incerto quanto está em constantes mudanças, por isso, Martin fala sobre a diferença entre a validade e a confiabilidade: um algorítimo que já se mostrou confiável no passado, pode não mais ser válido e portanto falhar no futuro. Conta a história de Bertrand Russel sobre a galinhas que previa que seria alimentada sempre que o fazendeiro chegasse pela manhã. Tal previsão é confiável, mas não válida, como muito bem descobre a galinha quando o fazendeiro chega em uma manhã com outro propósito para ela, a panela. Assim, as heurísticas oferecem um maneira de alcançar um equilíbrio entre a necessidade de validade na exploração de mistérios e a confiabilidade em explorar algorítimos.

A busca por validade e a exploração de novas possibilidades requer a utilização de lógica abdutiva. A lógica abdutiva, distinta da indutiva ou dedutiva, é uma ideia advogada por Charles Sanders Peirce que disse: "Nenhuma ideia nova pode ser provada pela dedução ou indução utilizando informações passada". As diferenças podem ser demonstradas utilizando-se o meme do Cisne Negro desenvolvido por Nassim Taleb e expandido por Jabe Bloom em uma conversa ocorrida no começo do ano. A lógica indutiva é a lógica do "e se". Se não vi nada exceto cisnes brancos, posso dizer indutivamente que todos os cisnes certamente são brancos. A lógica dedutiva, por outro lado, é a lógica do "o que deve ser". Se sei que todos os cisnes são branco, posso dizer dedutivamente que um pássaro negro provavelmente não seja um cisne, já pela lógica abdutiva posso propor ser plausível que os cisnes possam ser negros.

Citando novamente a heurística dos Marines, elas são utilizadas para explorar o mistério de como vencer uma batalha e surgir com um novo algorítimo na forma de um novo plano. De forma similar, ao desenhar um sistema Kanban, utilizamos heurísticas para explorar o mistério de como encontrar uma solução válida para um desafio organizacional, utilizando lógica abdutiva para descobrir e definir as possibilidades, levando à definição de um algorítimo confíavel para o dado contexto. As heurísticas podem levar a resultados surpreendentes com os quais podemos aprender e, conforme o contexto muda, podemos retornar a elas para ajudar-nos a continuamente evoluir o algorítimo mantendo sua validade.

Heurísticas Kanban

Vimos como a noção de heurísticas é poderosa quando pensamos sobre os desafios associados ao desenvolvimento de produtos. Realmente, o Manifesto Ágil pode ser visto como um conjunto de heurísticas, com alguns processos e práticas e como algorítimos específicos. O Kanban também pode ser entendido como uma abordagem heurística e o modelo de Pensamento Kanban citado no início desse artigo inclui cinco heurísticas que encapsulam as áreas chave que considerei importante dar enfoque, assim como três impactos que encapsulam as áreas de melhoria nas quais quero atuar.

As heurísticas são:

  • Estude o contexto;
  • Compartilhe o entendimento;
  • Contenha o trabalho;
  • Sinta a capacidade;
  • Explore o potencial.

Os impactos são:

  • Fluxo;
  • Valor;
  • Potencial.

Ao aplicar essas heurísticas e acompanhando esses impactos espero evitar o dogma das regras. Ao contrário, utilizo as heurísticas para responder a desafios difíceis que enfrentamos tentando responder a questões mais simples à medida que exploro os mistérios do desenvolvimento de produto e levo-os a algorítimos únicos.

Estude o contexto

No livro "The New Economics", W. Edwards Deming lançou uma frase famosa: "não há substituto para o conhecimento". Estudar o contexto é o meio de se adquirir conhecimento sobre a situação atual para melhorá-la. Essa heurística leva à substituição de questões relacionadas ao que pode der aprendido sobre a situação atual. Qual o propósito do cliente? O que podemos fazer para criar empatia com ele? Qual a natureza do trabalho? O que podemos fazer para analisar a demanda? Qual o custo do atraso para demandas diferentes? O que se faz para fluir o trabalho e onde é que o trabalho se atrasa? Quais artefatos e transformações existem à medida que o trabalho flui da ideia original até seu eventual utilização? Essas questões levam a práticas como mapeamento de empatia, análise de demanda ou mapeamento da cadeia de valor.

Compartilhe o entendimento

Compartilhar o entendimento sobre a situação atual, tipicamente na forma de um quadro Kanban, cria um ambiente no qual as pessoas serão mais motivadas intrinsecamente. Em seu livro "Drive", Daniel Pink descreve a motivação intrínseca como sendo criada pela autonomia, maestria, propósito e um entendimento compartilhado torna isso possível ao permitir a auto-organização (autonomia), melhoria (maestria) e entrega (propósito). Essa heurística leva à substituição de questões relacionadas ao que pode ser feito para garantir que todos estejam cientes e tenham o mesmo conhecimento da situação atual. O que é importante que todos entendam? Como isso poderia ser modelado e visualizado, tal que, todos pudessem ver, ler e interagir com? Tenho ainda um conjunto de heurísticas que utilizo para ajudar a criar um entendimento compartilhado que chamo de "TIP" [Dica] de visualização (Token, Inscription, Placement - Símbolos, Inscrição, Localização). Como utilizamos símbolos para transmitir informações? O que registramos nesses símbolos para transmitir informações? Como a localização dos símbolos pode transmitir informações? Essas questões levam a visualizações que são desenhadas e continuamente evoluídas pela equipe que as utiliza.

Contenha o trabalho

Sistemas Kanban podem ser considerados como containers (recipientes), com fronteiras ou restrições pouco rígidas dentro das quais o sistema evolui. Sem tais fronteiras, um sistema recairá no caos. Limitar o trabalho, portanto, é a definição dos limites do trabalho em progresso e outras políticas explícitas que criam fronteiras ou limites. Essa heurística leva à substituição de questões relacionadas às fronteiras que podem ser definidas para conter o trabalho. Quanto trabalho está em andamento? Onde o trabalho em andamento poderia ser limitado? Qual limite de trabalho em progresso poderia ser acordado? Onde o fluxo de trabalho está instável ou imprevisível? Quais políticas explícitas poderiam reduzir atrasos e melhorar o fluxo? Onde a qualidade poderia ser melhorada? Quais políticas explícitas poderiam ajudar a minimizar erros ou retrabalho? Essas questões levam a decisão sobre limitação do trabalho em progresso, assim como políticas como Definition of Ready (Definição de pronto para o desenvolvimento) e "Definição de Pronto" que são critérios de entrada e de saída para diferentes estágios do processo.

Sinta a capacidade

Assim como adquirir conhecimento sobre o que é o trabalho e como é realizado, também é importante saber quão bem é feito. Sentir a capacidade de um sistema Kanban envolve sentir a seu desempenho tanto medindo quanto interagindo com ele. Essa heurística leva à substituição de questões relacionadas a como descobrir quão bem o sistema atual está desempenhando. Quais impactos estamos tendo atualmente no fluxo do trabalho, na entrega de valor, ou na criação de potencial? Como podemos medir produtividade, responsividade, previsibilidade, qualidade, engajamento dos empregados e satisfação do cliente? Quais ideias essas medidas podem nos dar? Quais interações regulares podem ajudar a criar ritmo? Quando priorizar, reabastecer, planejar, revisar e entregar o trabalho? Essas questões levam ao estabelecimento de uma cadência de reuniões e eventos para o progresso do trabalho e captura de métricas como vazão, lead time, desempenho no cumprimento de datas, defeitos em produção, retenção de empregados e Net Promoter Score.

Explore o potencial

Explorar o potencial de um sistema Kanban envolve adotar uma abordagem de aprendizado validado, aplicado à criação de um novo processo no lugar de aplicado a um novo produto ou serviço. Pode, portanto, ser comparado ao "Lean Startup", descrito por Eric Ries, que define uma startup com "uma instituição humana pensada para criar um novo produto ou serviço sob condições de extrema incerteza". Explorar o potencial de um sistema Kanban envolve começar com o conhecimento que se tem do estado atual e experimentar a partir dali. Isso pode ser contrastado com uma abordagem de se desenhar e definir um estado futuro e tentar ir nessa direção. Essa heurística leva a questões novas relacionadas com como mudar e melhorar continuamente um sistema Kanban. Que mudanças poderiam ser feitas para ter um impacto maior no fluxo, no valor ou no potencial? Quais práticas ou políticas poderiam ser ampliadas ou aplicadas mais? O que poderia ser reduzido ou aplicado menos? Quais experimentos poderíamos conduzir para aprender mais? Como poderíamos saber se estamos melhorando? Essas questões levam a utilizar abordagens como Pensamento A3, ou Kata da Toyota, que utilizam o conhecimento adquirido e compartilhado a partir do estudo, para surgir com mudanças de políticas como experimentos cujos resultados podem ser sentidos para saber se tiveram o impacto desejado.

Impactos do kanban

As heurísticas descritas e as questões que elas trazem ajudam-nos a desenhar sistemas Kanban que podem resultar em algorítimos processuais únicos e contextualizados. As equipes se apresentam com diferentes variações para suas situações mais comuns e sempre argumento que estão erradas - pois não há resposta certa e sempre há potencial para melhorias. Ainda estou para trabalhar com uma equipe que tenha chegado a um sistema Kanban perfeito na primeira tentativa. Mais importante que saber se um sistema Kanban é certo é verificar se está trazendo o resultado desejado e se quaisquer mudanças exploratórias estão aumentando ou reduzindo o impacto. Esses são os impactos que procuro no modelo de Pensamento Kanban.

Fluxo

Causar um impacto ao melhorar o fluxo de trabalho é o resultado de "se fazer a coisa certa", ou melhorar a eficiência. Limitar o trabalho em progresso, reduzir o tamanho do lote e eliminar esperas permitem um fluxo através de um progresso de trabalho mais regular da conceituação inicial até o consumo final. É bastante provável a melhora no fluxo seja o efeito da obtenção dos seguintes resultados:

  • Maior previsibilidade, pois evitou-se atrasos e retrabalhos desnecessários;
  • Produtividade melhorada, pois mais trabalho está sendo concluído;
  • Maior responsividade, pois o trabalho está sendo concluído mais cedo.

Fazendo uso da terminologia de Roger Martin, de seu funil do conhecimento descrito anteriormente, um fluxo melhor leva a uma confiabilidade melhor.

Valor

Causar um impacto melhorando o valor do trabalho é o resultado de se "fazer a coisa certa", ou melhorar a eficácia. Lead times melhores criam um ciclo de feedback mais rápido permitindo validação mais rápida. Um portfólio gerenciado de investimento que limita o trabalho através das cadeias de valor e utilizando o custo de atraso como forma de seleção resultará em resultados econômicos melhores. É bastante provável que a melhoria do valor seja o efeito da obtenção dos seguintes resultados:

  • Maior satisfação dos clientes, pois tem suas necessidades atendidas;
  • Produtividade aumentada, pois mais trabalho de valor será entregue;
  • Maior qualidade, pois o trabalho funciona como pretendido e esperado.

Na terminologia do funil do conhecimento do Roger Martin, a melhoria no valor leva a maior validade.

Potencial

Causar um impacto ao se melhorar o potencial das pessoas fazendo o trabalho é o resultado do aprendizado do como "fazer a certo a coisa certa", ou melhorar a euforia. Remover o stress e o sobrecarregamento da vida das pessoas e criar algum tempo livre para construir conhecimento resultará em melhores possibilidades para o futuro. É bastante provável que a melhoria do potencial seja o efeito do atingimento dos seguintes resultados:

  • Melhor engajamento dos empregados, pois estarão motivados e felizes;
  • Mais responsividades, pois o compromisso com o trabalho pode ser feito mais tarde;
  • Maior qualidade, pois produtos e serviços podem se desenvolver mais livremente.

Apesar de Roger Martin não ter um termo equivalente para esse, proponho que uma melhoria no potencial leva a maior humanidade.

Conclusões

Espero que esse artigo tenha demonstrado que o Kanban não é apenas senso comum, mas como ele, uma abordagem heurística que pode ajudar a pensar sobre como tratar os desafios do desenvolvimento de software e de produtos nas organizações. Descrevi o modelo do Pensamento Kanban que encapsula a abordagem com cinco heurísticas - estude, compartilhe, contenha, sinta e explore - junto com três impactos desejados - fluxo, valor e potencial.

Para resumir, existem três recomendações:

  1. Evite o dogma de aderir a regras muito rígidas e a seguir processos - prefira utilizar heurísticas para atacar problemas complexos;
  2. Utilize as cinco heurísticas Kanban para substituir por questões mais simples as questões difíceis que aqueles problemas complexos trazem;
  3. Quando for responder às questões mais simples, adote a lógica abdutiva e pergunte "e se?" - pode ser surpreendente o que se aprende.

Essa abordagem resultará no desenvolvimento da capacidade de resolver problemas no longo prazo, em preferência a apenas uma solução aos problemas no curto prazo. Isso criará uma organização que aprende, sustentável e equipada para continuamente manter o equilíbrio entre validade e confiabilidade, sem abrir mão de enriquecer sua humanidade.

Como uma metáfora de fechamento, confesso que assisto ao programa "dança dos famosos". Acredito que pode-se dizer que os diferentes estilos de dança são definidos por heurísticas. Por exemplo, o Tango tem suas próprias características que o definem, que por sua vez são muito diferentes das do Cha Cha Cha. Cada Tango, contudo, pode ser muito diferente se sua interpretação é definida em um algoritmo. O que significa que o Kanban pode ser visto como um estilo de dança e, assim, é válido se falar em Estilo Kanban.

Sobre o autor

Karl Scotland trabalha com software e possui mais de vinte anos de experiência em desenvolvimento, gerência de projetos, liderança de equipes, coaching e treinamento. Nos últimos dez anos tem aplicado métodos ágeis com sucesso e ainda mais recentemente tem sido um dos pioneiros a defender a utilização de Sistemas Kanban para o desenvolvimento de software. Atualmente, atua como um coach ágil na Rally Software do Reino Unido e é um membro fundador da "Lean Systems Society" e da "Limited WIP Society". Anteriormente, liderou o movimento para o Agile e Pensamento Lean na BBC, Yahoo! e EMC Consulting. Karl escreve suas ideias mais recentes em seu blog.

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 menssagens dessa discussão
Comentários da comunidade

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

Receber menssagens dessa discussão

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

Receber menssagens dessa discussão

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-2013 C4Media Inc.
Política de privacidade
BT