BT

Podemos acabar com o papel do arquiteto em projetos ágeis?

por Fernando Ultremare em 20 Set 2011 |

A indefinição sobre o real papel do arquiteto de software numa equipe ágil parece estar longe de ser uma questão bem resolvida, como indicam posts recentes de vários líderes e coaches de Agile. A questão ocorre principalmente nas organizações onde o modelo tradicional de desenvolvimento encontrava-se muito enraizado antes da transição. As consequências do impasse podem ser extremamente negativas sobre a capacidade de entrega de valor aos clientes, e sobre a satisfação dos membros da equipe com seu ambiente de trabalho. Qual seria, então, o melhor caminho a ser seguido?

Peter Saddington, em post recente no Agile Scout, traz o tema à tona, comentando uma indagação realizada por Mark J. Balbes:

Afinal, o que faz um arquiteto em um ambiente de trabalho TDD/Agile/XP que seja antagônico à arquitetura?

Para Saddington, o arquiteto ágil é um "faz tudo" no que diz respeito a garantir a integridade arquitetural do produto. Ouvir, orientar e persuadir fazem parte do seu trabalho. A equipe deve ser responsável pela solução do problema, e o trabalho do arquiteto é estabelecer as qualidades que essa solução deve ter.

Balbes também sugere que o arquiteto atue como um mentor ou guia, persuadindo os membros da equipe através de uma visão clara das qualidades técnicas que a solução deve possuir. E afirma:

O arquiteto ágil deve compreender o estado atual do software e saber para onde está indo a solução. Deve passar seu tempo com a equipe e envolver-se em todos os aspectos do projeto. Acabou o tempo em que havia o arquiteto em sua torre de marfim,  sentado à sua mesa produzindo diagramas e documentos.

Em outro post, Chris Chapman concorda com a sugestão de que o arquiteto deva estar mais envolvido com a codificação, mas se mostra relutante sobre a necessidade de “persuasão” da equipe, pois o arquiteto poderá estar equivocado, como qualquer pessoa. Dessa maneira, segundo Chapman, todo o time estará subordinado a uma espécie de “mini-gerente de projetos”.

O risco levantado por Chapman pode ser ampliado, ressalta Martin Wickman, devido ao o título de “arquiteto” permitir muitas interpretações diferentes. Outro fato preocupante é que muitos dos “assim chamados” arquitetos não estão acima da média de habilidades dos desenvolvedores. Wickman concorda com Chapman quando diz:

Colocar um líder com autoridade decisiva sobre a equipe é a maneira mais comum de lidar com problemas, embora seja pouco eficaz. Como resultado, os desenvolvedores se tornam dependentes de uma única pessoa para dar a direção e realizar decisões, fazendo com que nunca realmente aprendam a confiar em suas próprias habilidades. Ao final isso bloqueia a equipe de se desenvolver e aprender a executar o trabalho de maneira eficaz.

Wickman recorre ainda ao Scrum Guide para reforçar sua opinião, através da seguinte referência ao guia:

O Scrum não reconhece outros títulos para os membros da equipe de desenvolvimento que não seja o de desenvolvedor. Não há exceções a essa regra, independentemente do trabalho que está sendo realizado por aquela pessoa.

Para Wickman, uma melhor alternativa é estabelecer um treinador (ou coach) na equipe, que também seria uma espécie de líder, mas sem poder de decisão. Seu principal objetivo não é controlar, mas sim apoiar a equipe, ajudando os membros a desenvolver suas habilidades e orientando-os durante o processo de tomada decisão. O objetivo é torná-los mais capazes de conceber novas ideias e visualizar os problemas por diferentes perspectivas.

Por fim, Wickman sugere que a equipe se prepare para lidar com a necessidade de decisão sobre as definições arquiteturais da solução de maneira autônoma. Isso significa que devem se auto-organizar para criar a sua própria estrutura de tomada de decisão. Assim, os membros da equipe irão confiar mais na área de especialização de cada um dos indivíduos. Em um cenário ideal, a opinião de um profissional mais sênior terá mais peso para os outros membros da equipe. 

O debate sobre o papel do arquiteto em equipes ágeis não é recente, embora os seus desdobramentos ainda possam ser sentidos hoje. Martin Fowler, em 2003, já mostrava preocupações sobre a real necessidade do arquiteto de software (pdf). Fowler parece ter grande influência sobre a visão de Wickman, quando diz:

Promover a melhora da capacidade do time de desenvolvimento como um todo estende a influência do arquiteto para muito além do que seria possível como um centralizador de decisões técnicas da equipe. [...] Isso satisfaz a regra de ouro de que o valor de um arquiteto é inversamente proporcional ao número de decisões que realiza.

As opiniões apresentadas se diferenciam fundamentalmente no que diz respeito à necessidade da existência de um centralizador das decisões técnicas na equipe. Por um lado, através da imposição hierárquica (ou do título), tem-se a garantia de que prevalecerá a visão daquele que é tido como o mais experiente. Por outro, através do incentivo ao desenvolvimento do time, tem-se a expectativa do surgimento de uma liderança espontânea, baseada no respeito e não formalizada.

A figura do arquiteto certamente está entre as principais heranças deixadas pelas metodologias tradicionais de desenvolvimento, fortemente centradas na arquitetura dos projetos. O perfil continua sendo frequentemente referenciado nas descrições de vagas de trabalho, e os próprios desenvolvedores seguem enfrentando longos processos de certificação.

A mudança de paradigma não parece ser fácil, e ainda pode ser encarada como arriscada por muitos. Afinal, até que ponto a auto-organização das equipes é possível? Ou melhor, poderíamos realmente acabar com o papel do arquiteto em projetos ágeis?

Avalie esse artigo

Relevância
Estilo/Redação

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

Acredito que não by George Paoli

Olá,

Primeiro, parabéns pelo post.

Bom, acredito que o papel do arquiteto no desenvolvimento de software é extremamente importante para o sucesso do projeto. Acredito mais ainda que devido as responsabilidades atribuídas a este papel, seja necessário a criação de um time específico de arquitetura, claro, dependendo do tamanho do projeto.

Para projetos pequenos e bem específicos provavelmente este papel não seja tão influente, porém não deixa de ser importante, pode ser compartilhado com a equipe e/ou delegado para o desenvolvedor mais experiênte.
Agora para projetos grandes, com várias equipes envolvidas, várias integrações entre sistemas fica difícil imaginar um ambiente desse sem um responsável pela arquitetura das aplicações/integrações, etc.

Em fim, meu ponto de vista é que este papel é extremamente importante e independente da metodologia deve ser considerado. Se vai existir uma pessoa específica ou um time de arquitetura não importa, o que importa é que de alguma forma este papel exista e seja bem feito no processo de desenvolvimento.

Abs.

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

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.