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?