BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Favoritos

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil (veja a primeira), Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para a definição de arquiteturas, além de apresentar mais detalhes sobre a Arquitetura Evolucionária.

[Participaram da edição, revisão e tradução desta parte Thomas Sant'Anna, Rafael Liu e Leonardo Galvão]

Muitas empresas vêm adotando o outsourcing para projetos. Você considera viável implementar ou adaptar as práticas do Agile nesse contexto?

Utilizamos o termo “Agile distribuído” ao aplicar o Agile em um contexto em que diferentes partes das equipes estão separadas geograficamente. Ao analisar os princípios básicos, conseguimos extrair quais são as mudanças que precisam ser feitas nas práticas, de forma que se possa trabalhar com o Agile nesse ambiente.

A base do Agile é o feedback rápido, e o ideal é obter um ciclo de feedback o mais curto possível, de forma que se possa responder rapidamente quando houver problemas. Creio que uma das falhas na maneira inicial de terceirizar o desenvolvimento é gerar toda a especificação no início, jogá-la para o outro lado do muro e esperar que algo de qualidade seja entregue no final. Isto não funciona em um contexto de outsourcing, da mesma forma que a filosofia waterfall não funciona para o desenvolvimento interno. E se analisarmos os ciclos de feedback curtos, ainda haverá a comunicação frequente entre o negócio (“estamos recebendo o que queremos?”) e a equipe de desenvolvimento (“estamos entregando adequadamente?”).

Os princípios ágeis, portanto, continuam sendo aplicáveis para equipes distribuídas, mas é preciso modificar algumas das práticas. Como não há uma interação tão rápida, as coisas precisam ser um pouco mais estruturadas.

Utilizamos várias técnicas para aumentar a interação. Por exemplo, temos máquinas com grandes monitores, com o Skype executando constantemente. Com isso podemos ter reuniões standup virtuais, e há sempre a possibilidade de conversas casuais como, “acabei te ter uma duvida, vamos discutir?”. Assim o fato de a pessoa estar a centenas de quilômetros não importa tanto.

Essas técnicas funcionam bem, desde que os fusos horários sejam razoavelmente próximos. Mas não são tão eficazes se por exemplo houver uma equipe trabalhando na Costa Oeste dos Estados Unidos com um grupo na Índia, uma diferença de mais de onze horas. Mas, se a diferença de fuso não for tão grande, há a impressão de que a equipe está no mesmo local. E é uma solução de baixo custo.

Poderia nos explicar as diferenças entre a Arquitetura Evolucionária e o Design Emergente?

Existem duas diferenças fundamentais. A primeira é relacionada ao tamanho ou escala. No design emergente, trabalhamos geralmente no nível do código. Analisamos trechos de código para deduzir quais partes irão precisar passar por refatoração para a introdução de novas funcionalidades; ou identificamos padrões que se repetem, visando fazer mudanças para apoiar a evolução do código.

Alguns dos mesmos princípios se aplicam à arquitetura evolucionária, mas se opera em um nível diferente. Enquanto que o design emergente se restringe ao nível de componentes, a arquitetura evolucionária trata de como os elementos distintos do sistema trabalham em conjunto; ela cuida de questões relacionadas a infraestrutura, comunicação e integração, além de aspectos como escalabilidade, confiabilidade, características de desempenho e resiliência.

A arquitetura evolucionária extrai conceitos da computação evolucionária, em que é usada uma fitness function [função de adequação]. Dessa forma, há uma ideia do que se gostaria para a arquitetura final, em função dos direcionadores arquiteturais que foram adotados. Temos sempre algo específico em mente, que irá determinar o caminho a ser seguido; uma definição do que constitui uma arquitetura adequada para o problema atual – e que pode mudar entre sistemas diferentes, ou mesmo entre partes de um sistema.

Nem todos os sistemas, é claro, precisam ser tão seguros quanto os que mantêm números de cartões de crédito, ou capazes de lidar com as cargas que a Amazon processa. Na função de adequação para uma arquitetura, características como essas variam de uma aplicação para outra. Direcionamos nosso trabalho para atingir uma arquitetura que satisfaça a função de adequação para um cenário específico.

Em resumo, o design atua num nível mais baixo, em áreas específicas do código; e a arquitetura num nível mais alto, na maneira em que elementos do sistema interagem. A arquitetura determina também a direção a seguir, em vez de responder apenas ao que se vê no código.

Quais métricas de qualidade vocês usam para validar uma boa arquitetura?

Internamente utilizamos métricas de qualidade do lado do servidor, analisando não somente as características do código, mas também características arquiteturais. Por exemplo verificamos como diferentes objetos num sistema interagem, quantas classes estão acessando certa parte do sistema, e até se está sendo usado o número correto de camadas. Portanto, há diferentes métricas arquiteturais que ajudam a entender melhor a qualidade do sistema de modo geral. Também usamos métricas mais comuns, como a Complexidade Ciclomática e outras validações similares.

As métricas de qualidade são muito importantes, principalmente quando procuramos meios de tornar o código mais maleável a mudanças.

Como você vê novas as técnicas para a definição de arquiteturas e o papel atual do SOA?

Um aspecto arquitetural que tenho considerado é a forma de definir cada um dos componentes e como interagem. Existem algumas técnicas, como Hypertext as Engine of Application State (HATEOAS), em que é descentralizado o controle sobre as informações. Assim, se obtém muito mais flexibilidade para efetuar mudanças na maneira como os componentes interagem.

Quanto ao SOA [Arquitetura Orientada a Serviços], estamos bem alinhados com a opinião de Jim Webber; concordamos que a abordagem tradicional do SOA falhou. Muitos dos grandes projetos baseados em SOA simplesmente não forneceram o nível de flexibilidade que as empresas estão procurando.

Se olharmos para as abordagens que Jim tem apresentado em seu livro "REST in Practice", estamos alinhados em relação à maneira como os sistemas devem ser abordados. Da mesma maneira, o trabalho do coautor do livro, Ian Robinson, sobre Consumer-Driven Contracts [Contratos Orientados ao Consumidor] dá uma boa base para decidir quais serviços utilizar. 

Com os Contratos Orientados ao Consumidor, partirmos do ponto de vista do negócio e obtemos sistemas que podem evoluir juntamente com as necessidades da empresa, porque os principais interessados estão participando efetivamente da sua criação. 

--

Sobre o autor

Wagner Roberto dos Santos (@wrsantos) é Agile Coach e Arquiteto de Software pela empresa francesa OCTO Technology.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

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

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

BT