O InfoQ Brasil, algumas semanas depois do QCon São Paulo 2011, teve a oportunidade de entrevistar Rebecca Parsons, Diretora de Tecnologia (CTO) da ThoughtWorks. PhD em Ciência da Computação (Rice University, EUA) e com mais de 20 anos de experiência no desenvolvimento e arquitetura de sistemas, Rebecca falou em detalhes sobre mudanças no cenário de TI e práticas importantes em Agile. Falou também em profundidade sobre a Arquitetura Evolucionária (o tema de seu keynote no QCon), que leva conceitos das práticas ágeis para a arquitetura e infraestrutura de sistemas. A entrevista será publicada em duas partes.
[Participaram da edição, revisão e tradução desta entrevista Thomas Sant'Anna, Rafael Liu e Leonardo Galvão]
Quais são, na sua opinião, as dificuldades e desafios que as empresas atualmente estão enfrentando?
Acredito que um dos maiores desafios é saber como reestruturar uma organização de TI para que possa responder rapidamente a oportunidades. Os modelos de negócio estão diminuindo em tamanho e as empresas têm que ter reações muito mais velozes a mudanças. Por anos, os departamentos de TI foram tratados como centros de custo, e o objetivo de um CIO (Diretor de Tecnologia) era diminuir esses custos ao máximo. O caminho escolhido normalmente envolve a padronização de abordagens e o foco na estabilidade dos sistemas, mas isso é exatamente o contrário do que deve ser feito para se ter capacidade de reagir a mudanças.
As organizações estão repensando como potencializar os aspectos que são seus diferenciais em TI, especialmente em formas de entregar rapidamente novas funcionalidades de acordo com o que o mercado espera. Para isso há uma gama de práticas e métodos, incluindo Continuous Delivery (entregas contínuas) e abordagens ágeis, além de conceitos como Arquitetura Evolucionária. Essas práticas permitem entender como os sistemas são construídos e a prepará-los para a mudança.
Vejo a questão da capacidade de resposta como um problema organizacional, de processo e tecnologia. Muitas empresas ainda estão lutando para entender o que significa competir nesse contexto.
Recentemente, celebramos os 10 anos do Manifesto Ágil. Em sua opinião, o que mudou desde então? O "Agile 101" continua sendo suficiente para atender às empresas?
Quando começamos a falar sobre Agile, mesmo antes do Manifesto ser escrito, o foco principal era em novas práticas e novas maneiras de trabalhar. Creio que um dos aspectos mais importantes do Manifesto é ter se distanciado das práticas mais comuns na época, e ter passado a olhar de forma mais abrangente para os princípios e valores envolvidos na construção de software.
Acredito que, conforme amadurecemos como indústria e começamos a entender realmente o significado dos valores do Agile, podemos pensar sobre trabalhar de forma diferente, ao invés de simplesmente restringir-se a usar práticas específicas, como desenvolvimento orientado a testes ou programação em pares. Quando olhamos para as práticas com distanciamento, podemos identificar os princípios ou valores em que elas se baseiam, e passamos a ver como são aplicadas em outros aspectos do desenvolvimento de software, assim como em outras partes da organização. Por exemplo, há departamentos de marketing, jurídicos e grupos financeiros que estão trabalhando de modo diferente, inspirados nos princípios ágeis.
Uma das maiores mudanças é termos visto que nosso trabalho não se restringe ao desenvolvimento de software; trata-se também de como as organizações desempenham suas atividades. Quando observamos os fundamentos do Agile, a mera introdução de algumas práticas pode fazer uma enorme diferença em um time que não está funcionando bem.
E quando passamos deste ponto, há a necessidade de um pensamento mais abrangente. Isto é uma das coisas que eu acho especialmente interessante no Continuous Delivery, em que nada é uma novidade por si só. O Continuous Delivery agrega várias práticas que existem há bastante tempo no mundo do Agile. A diferença está em como as práticas e ferramentas são interligadas para mudar radicalmente a forma como vemos todos o processo de implantação e entrada em produção.
Trata-se tanto de uma de uma mudança de atitude quanto de uma inovação específica. Creio que veremos mais mudanças desse tipo, à medida que entendemos melhor como sistemas de TI funcionam dentro das organizações. Começaremos a ver novas oportunidades e grandes mudanças no que realmente caracteriza o desenvolvimento de software, assim como na relação entre os clientes de negócio e as organizações de desenvolvimento.
Temos visto cada vez mais pessoas falando sobre agilidade aplicada a áreas que não recebiam muita atenção da comunidade ágil, como infraestrutura. O que você pensa sobre isto?
Em um primeiro momento, se você quer que um sistema seja responsivo; se quer ser capaz de mudar radicalmente um sistema, então é necessário projetá-lo e arquitetá-lo para que seja adaptável. Isto vai contra a visão tradicional de arquitetura, em que muitas características são especificadas previamente. É feito muito “desenvolvimento especulativo” na tentativa de construir componentes reutilizáveis, tentando prever as diferentes formas que o negócio pode vir a usar dados, além de imaginar novos processos que precisarão ser suportados.
Mas muitas das funcionalidades criadas dessa maneira jamais serão utilizadas. E isso, claro, gera um grande desperdício, não somente pelo esforço gasto na escrita do código que nunca será usado, mas também porque se chega a sistemas mais complexos e mais difíceis de manter e alterar.
Em vez disso poderíamos ter pensado “não vamos tentar prever todas as mudanças possíveis; vamos projetar o sistema de maneira que seja fácil de mudar”. Isso tem a ver com a forma que trabalhamos com os dados; a maneira que as partes distintas do sistema interagem umas com as outras e o quanto o código é fácil de manter. Métricas básicas de qualidade de código entram em jogo aqui. Todos esses fatores em conjunto constituem o que chamo de Arquitetura Evolucionária.
Um aspecto fundamental é definir inicialmente quais são os requisitos mais críticos, que irão exercer maior influência sobre sua arquitetura. Por exemplo, se precisamos de um sistema altamente confiável, então devemos começar a pensar o mais cedo possível no que vai ser necessário para obter confiabilidade de "cinco 9's". Os requisitos mudam se o foco for a segurança dos dados ou o volume de transações, e assim por diante. Aspectos como esses mudam com menor frequência do que funcionalidades específicas.
Em outras palavras, devemos decidir antecipadamente sobre as diretrizes que irão orientar a arquitetura, e como serão validadas tanto as decisões arquiteturais quanto as de design com relação a essas diretrizes. Isso nos permite focar a atenção nos pontos mais importantes e tomar as decisões no momento certo.
Outro elemento essencial da arquitetura evolucionária é seguir o princípio do Último Momento Possível (Last Responsible Moment). A ideia é adiar ao máximo a tomada de cada decisão, de maneira que seja feita apenas quando seria irresponsável protelar ainda mais.
Um dos fatores mais importantes que nos permitem prorrogar decisões é o modo como arquitetamos os sistemas. Podemos incluir camadas de abstração para nos proteger de mudanças nas decisões. Uma arquitetura adequada com o uso apropriado de camadas permite adiar as decisões. Ao fazer esse adiamento, temos muito mais informações no momento que vamos decidir.
Quando tomamos decisões que afetam a infraestrutura ou a arquitetura muito cedo em um projeto, não sabemos o que realmente será preciso. E ao tomar uma decisão que parece difícil de reverter terminamos, por segurança, introduzindo mais complexidade. Podemos, por exemplo, sugerir a compra de um middleware mais complexo ou criar infraestrutura adicional, no caso de certas funcionalidades virem a ser necessárias. Isso cria peso e atrito no sistema.
Todos esses fatores, nossa habilidade de evoluir o esquema do banco de dados, a forma que definir o contrato de messaging, decisões referentes à infraestrutura e à arquitetura básica – tudo isso deve ser feito levando em conta a diretriz de "Fazer as coisas o mais tarde possível".
É importante criar proteções para quando for necessário fazer mudanças. Um dos princípios básicos do Agile é, ao invés de tentar minimizar mudanças, proteger-se delas. Com a Arquitetura Evolucionária, estamos apenas expandindo este conceito para as decisões fundamentais sobre a arquitetura.
Para concluir esta parte, você poderia nos falar sobre a ThoughtWorks e sua atuação?
A Thoughtworks é uma empresa global, presente atualmente em oito países e mais de 22 cidades. Trabalham conosco hoje cerca de 1.800 pessoas. Um aspecto interessante sobre a empresa é o seu crescimento orgânico. Há vários anos fizemos a aquisição de uma pequena empresa de consultoria com a qual vínhamos trabalhando, e até mesmo nessa escala o processo foi difícil, dada a forte cultura interna da Thoughtworks. Decidimos nos limitar ao crescimento orgânico desde então: de 100 pessoas quando que me juntei à empresa em 1989 para os atuais 1.800, a expansão foi quase que exclusivamente orgânica.
Creio que um dos maiores diferenciais da empresa é ter uma abordagem horizontal, mais focada em tecnologia em vez de verticais de negócio. Baseamos nosso trabalho em três pilares que orientam toda a empresa. Ser um negócio sustentável; ter uma visão revolucionária da indústria de TI e da excelência em software; e defender a justiça econômica e social. Em todos os processos de decisão internos, procuramos levar em consideração esses três pilares. Tentamos, como organização, trabalhar para melhorar as condições socioeconômicas globalmente, com enfoque especial nos países em desenvolvimento.
Veja na próxima parte como a ThoughtWorks usa práticas de várias áreas para implementar o "Agile distribuído" e mais detalhes sobre a Arquitetura Evolucionária.
Sobre o autor
Wagner Roberto dos Santos (@wrsantos) é Agile Coach e Arquiteto de Software pela empresa francesa OCTO Technology.