BT

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

Contribuir

Tópicos

Escolha a região

Início Artigos Arquitetos precisam programar: as distorções no papel de arquiteto

Arquitetos precisam programar: as distorções no papel de arquiteto

Favoritos

Quando entrevisto candidatos à vagas de arquiteto de software, faço perguntas como: "Você acha que um arquiteto deveria programar?" Usualmente recebo uma destas duas respostas:

"Não, busco uma posição na qual eu não precise mais programar."

"Eu adoraria continuar programando pelo menos um pouco mas, provavelmente, não terei tempo"

Na mesma linha, quando pergunto a outros arquitetos de software se eles tem programado, frequenmente escuto:

"Já faz um tempo."

Estas respostas são preocupantes. Desde quando evoluir profissionalmente em uma função da área técnica significa separar definições tecnológicas das atividades de desenvolvimento?

Como alguém espera conseguir acompanhar o vasto cenário de opções em termos de tecnologia e compreender seu papel dentro das organizações, sem estar constantemente em contato com o time responsável pelo desenvolvimento destas tecnologias? Ou, ainda melhor, desenvolvendo ativamente as mesmas?

Como um arquiteto espera conseguir atender mudanças de requisitos frequentes, comuns em projetos, sem conhecer profundamente o que ocorre no desenvolvimento?

Um bom arquiteto deve trabalhar próximo ao time de desenvolvimento. Esse relacionamento é imperativo para uma arquitetura de sucesso que resulte em entregas com qualidade e dentro do prazo.

Receber feedback e oferecer liderança são dois benefícios que derivam dar forma em como o arquiteto se relaciona com as entregas do projeto ou produto.

Feedback

Um arquiteto engajado está sempre presente, recebe feedback em primeira mão e tem disponibilidade para trabalhar com o time de desenvolvimento de forma a corrigir qualquer deficiência. O Feedback pode vir de várias fontes, incluindo mudanças nos padrões utilizados pela organização, mudanças ou evolução de requisitos funcionais/não funcionais e desafios descobertos durante processos de implementação e testes.

Quanto mais cedo os problemas são identificados, mais rápido o arquiteto poderá responder aos desafios evoluindo a arquitetura. Se o arquiteto não está ativamente envolvido com as entregas, os feedbacks podem levar semanas ou meses para chegarem até ele, o que muitas vezes ocorre quando já se está nos estágios finais do ciclo de desenvolvimento.

Decisões arquiteturais envolvem os aspectos mais importantes ou difíceis de mudar de um software. Quanto maior o tempo para que o feedback chegue ao arquiteto, maior a chance de que o tratamento das situações reportadas se acumulem, situação que se agrava caso as mudanças de arquitetura necessárias sejam significativas.

Descobrir deficiências arquiteturais em estágios avançados do ciclo de desenvolvimento resulta no uso de atalhos que geram débito técnico na busca por atingir metas e realizar a entrega no prazo. O quanto antes o feedback é recebido e tem seu impacto arquitetural avaliado, mais ágil é o projeto e menor o risco acumulado.

Liderança

Outra responsabilidade básica de qualquer arquiteto é liderar. A liderança acontece de diferentes maneiras sendo todas importantes para o sucesso de uma implementação e da arquitetura que a suporta.

Liderança arquitetural implica na capacidade do arquiteto de comunicar efetivamente sua "visão" de forma que o time consiga realizá-la com sucesso. A melhor maneira de disseminar essa visão é através da proximidade do arquiteto com o time. Além disso, essa comunicação é quando feita através de discussões contextuais ao invés de através de documentos, reuniões ou "palestras". O direcionamento dado para arquitetura deve ser continuamente reiterado ao longo do tempo. É muito fácil se prender na correria para realização de uma entrega perdendo de vista os objetivos principais de um projeto. Um arquiteto que interage freqüentemente com o time de desenvolvimento ajuda a manter uma visão consistente.

A liderança técnica emerge do fato de que o arquiteto é experiente nas atividades de desenvolvimento e entrega de software. Assim, uma meta do arquiteto deve ser educar e aperfeiçoar o time. Por vezes existem lideranças técnicas específicas para esse papel, mas por que desperdiçar a experiência do arquiteto? A interação entre o arquiteto e o time beneficia não apenas ao time, mas auxilia o arquiteto na compreensão de problemas rotineiros encontrados no desenvolvimento.

A mentoria é uma forma de liderança não técnica que um arquiteto pode exercer em um time. Tópicos como trabalhar com pessoas que não são técnicas, adotar princípios ágeis, definir e modelar uma arquitetura são habilidades importantes para o crescimento de desenvolvedores que no futuro poderão se tornar arquitetos. Uma boa parte do treinamento e conhecimento das funções de um arquiteto é adquirida colocando a "mão na massa" em contraste com oportunidades educacionais formais realizadas no formato "sala de aula". Um arquiteto deve abraçar essa tendência e tornar a aprendizagem de aspectos arquiteturais ativa ao invés de passiva.

Táticas para aumentar o engajamento

Um arquiteto engajado não é, necessariamente, responsável pela escolha das estórias para uma entrega específica. Na verdade, vários fatores como a quantidade de arquitetos em relação a desenvolvedores ou o número de compromissos associados a atividades externas de um projeto, tornam ineficiente a abordagem de deixar a cargo exclusivo do arquiteto a seleção de estórias para uma entrega. Abaixo, seguem algumas táticas para alinhar atividades de arquitetura com entregas e melhorar a interação do arquiteto com o time.

Programação em Pares (Pair Programming)

Martin Fowler mencionou em um Keynote da Conferência em Arquitetura de Software da O'Reilly de 2015 que o uso da programação em pares é uma boa opção para manter o arquiteto engajado. A programação em par é uma técnica de desenvolvimento ágil, popularizada pela metodologia Extreme Programming, na qual dois membros de um time trabalham juntos para alcançar uma meta comum. Neste cenário, o arquiteto nunca é responsável por uma estória, mas faz par com outros membros do time para executar o projeto da estória, desenvolvimento e/ou teste. Essa abordagem tem a vantagem de manter o arquiteto comprometido com a entrega e próximo de qualquer feedback que possa surgir referente a arquitetura ao mesmo tempo em que blinda o time contra a escassez de recursos nos casos de ausência do arquiteto devido a responsabilidades alheias à implementação.

Revisão por pares (peer review)

A revisão por pares é similar a programação em pares, mas mais lenta no que diz respeito a propagação de feedback. Ela ocorre quando um colaborador revisa o trabalho de outro na fase de finalização tendo como foco a qualidade do código produzido. Neste caso, o arquiteto trabalha com o desenvolvedor na revisão de código. Esse trabalho pode ser realizado periodicamente ou apenas quando uma estória está próxima da finalização. Através desta prática, o arquiteto ganha compreensão da aderência da implementação à arquitetura identificando problemas. A revisão também traz a oportunidade de exercício da liderança através de conselhos dados pelo arquiteto ao desenvolvedor.

Spike

O arquiteto pode liderar o desenvolvimento de um spike com foco na exploração de arquiteturas ou no desenvolvimento. Um spike é a implementação de uma prova de conceito funcional de um aspecto específico, utilizada para identificar ou mitigar riscos associados a exploração de uma nova tecnologia. Spikes são uma ótima oportunidade para avaliar a decisões arquiteturais colocadas em prática, contribuindo diretamente para cumprimentos das metas de uma entrega e ajudando a promover maior visibilidade das deficiências e limitações de uma arquitetura. Spikes também encorajam o envolvimento do arquiteto com a implementação, a colaboração com o time, o compartilhamento da visão arquitetural e a aprendizagem através da prática.

Desenvolvimento de estórias

Um arquiteto pode assumir também o papel de um membro do time ao participar na implementação e entrega de estórias. Esta é, provavelmente, a estratégia que resulta em maior velocidade de propagação dos feedbacks. A desvantagem é o risco de o arquiteto limitar seu foco as estórias (passa a enxergar apenas as árvores e não a floresta). Deve haver um equilíbrio entre a visão arquitetural e o que se deseja alcançar ao final do esforço de desenvolvimento e a implementação de fato. Além disso, é importante atenção pois essa abordagem pode causar problemas para um rastreamento consistente da velocidade do time. Por exemplo, se o arquiteto trabalha por três semanas em estórias e, de repente, precisa parar por duas semanas para cuidar de tarefas alheias ao desenvolvimento (alinhamento de road map, por exemplo), pode haver um impacto na velocidade do time. Neste caso, apesar de a velocidade no curto prazo cair, no longo prazo, o impacto é relativizado pelo cálculo da média. Caso o arquiteto esteja trabalhando em tarefas relacionadas ao gerenciamento do projeto, então, essas tarefas deveriam ser estórias juntamente com as estórias diretamente associadas a funcionalidades a serem entregues, facilitando o alternância entre tarefas de desenvolvimento e tarefas associadas ao gerenciamento e condução de um projeto.

Rotação

Nessa tática, o papel de arquiteto é delegado entre os membros do time por períodos definidos de tempo. Enquanto estiver assumindo o papel de arquiteto, é do membro a responsabilidade de tomar decisões relacionadas à arquitetura, manter a coesão da mesma e oferecer orientação sobre aspectos arquiteturais em geral. Rotacionar o papel de arquiteto dentre os membros do time traz o benefício de aumentar o nível de conhecimento a respeito das atividades relacionadas a arquitetura. O membros do time ganham uma compreensão maior a respeito de todos os papéis envolvidos na produção de uma entrega, resultando em empatia entre os papéis, melhoria da interação entre os membros do time e um produto em geral melhor uma vez que para cada papel são aplicados diferentes pontos de vista. É recomendável realizar a rotação com moderação, pois a inconsistência pode trazer mais problemas do que benefícios. Algo alinhado com as publicações de versão (3 - 6 mêses) pode ser apropriado de acordo com a duração dos ciclos de desenvolvimento do time.

Abordagens para aumentar o engajamento a serem evitadas

Assim como existem muitas técnicas para aumentar o engajamento do arquiteto com as entregas, também existem abordagens que aumentam o engajamento mas podem ser prejudiciais para o time e o projeto, devendo ser evitadas.

Apenas as coisas difíceis

Um tendência comum é o arquiteto assumir a parte difícil do trabalho independente da organização destas tarefas em estórias. Isso pode parecer intuitivo dada maior experiência do arquiteto, mas no longo prazo é prejudicial par ao time. Primeiramente, uma vez que o time não está envolvido, não vai compreender ou estar apto a dar suporte ao produto resultante do trabalho do arquiteto. Em segundo lugar, desenvolvedores gostam de desafios. Ao assumir a responsabilidade por todos os problemas complexos, o arquiteto tira a oportunidade de outros membros do time de pesquisar e aprenderem algo novo.

Assumir o controle

Outra abordagem ruim, é assumir o controle de tudo adotando um estilo "eu mando e você obedece". O arquiteto investiu tempo e esfoço na definição da arquitetura. Logo, existem grandes chances de que a entrega tenha sucesso, especialmente se o arquiteto participar ativamente do time responsável pela entrega. Neste cenário, visando este sucesso, o arquiteto passa a controlar todos os aspectos da entrega ao invés de ajudar e se limitar a conduzir a entrega de forma a atingir as metas de arquitetura. Isso pode ter os seguintes efeitos negativos:

  • Criar um time que se ressente de um arquiteto controlador, em contraste com um time auto-organizado, altamente funcional e colaborativo;
  • Limitar o comprometimento e oportunidades de crescimento dentre os membros do time;
  • Não escalar caso o tamanho das entregas cresça.

Foco nos detalhes e não na essência

Ao utilizar programação em pares ou executar revisões de código o arquiteto deve se ater ao essencial e não aos detalhes. Existem diversas formas de se programar um determinado problema, muitas delas perfeitamente funcionais apesar de não refletirem exatamente a forma como o arquiteto executaria a implementação. É papel do arquiteto buscar a implementação da visão arquitetural e reforçar os padrões de código definidos, mas deve permitir a licença poética para time.

Resumo

Par que uma arquitetura tenha sucesso, o arquiteto deve estar engajado com o time durante todo o ciclo de desenvolvimento. Permanecer engajado acelera o recebimento de feedbacks a respeito da arquitetura ao longo do desenvolvimento. Também proporciona ao arquiteto oportunidades de comunicar a visão arquitetural e exercer liderança técnica junto ao time. Conforme o título sugere, o arquiteto pode programar, mas existem outras formas de permanecer engajado com as entregas como a programação em pares e as revisões de código por pares. No entanto, às vezes a forma como ocorre o engajamento pode ser prejudicial ao time quando, por exemplo, o arquiteto assume para si a entrega e não permite que o time se auto-organize e se comprometa coletivamente com a entrega. O arquiteto deve tomar cuidado para não se isolar em uma "torre de marfin" se tornando aquele de decreta uma arquitetura e depois some. É necessário buscar um relacionamento colaborativo com o time responsável pela entrega, trabalhando em conjunto para identificar e solucionar deficiências da arquitetura proposta o quanto antes, de forma a entregar uma arquitetura e um produto final de sucesso.

Sobre o Autor:

http://cdn.infoq.com/statics_s2_20150807-0037u1/resource/articles/architects-should-code-bryson/en/resources/Brandon_headshot.jpgBrandon Bryson é consultor Senior da MasterCard, organização líder da indústria de pagamentos, tendo como foco a arquitetura de aplicações, desenvolvimento e entrega ágeis. Ele tem 15 anos de experiência na indústria de software e é apaixonado pelos temas de liderança técnica, arquitetura e projeto, princípios ágeis, bem como pela interação entre estes três. Já trabalhou tanto para organizações que constam na Fortune 500, como para start-ups em diferentes setores incluíndo: defesa, viagens, cadeia de suprimentos e financeiro. Se formou em Ciências da Computação na Mizzou.

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