Arquitetos de Software na Era da Agilidade

Atualmente tenho trabalhado como arquiteto de software e também como ScrumMaster em um time Scrum. Estamos desenvolvendo um projeto bastante complexo, onde temos na mesma equipe desenvolvedores de software, engenheiros, desenvolvedores de firmware e até mesmo desenvolvedores de hardware. Trata-se de uma única equipe de mais de 10 pessoas, e quem já tem experiência no assunto já pode imaginar que não deve ser nada fácil tocar um projeto como esse, principalmente se acrescentar que esta é a primeira experiência com Scrum para a maioria dos integrantes da equipe, e também meu primeiro projeto como ScrumMaster.

Estou escrevendo isso porque hoje tive contato com um artigo, escrito por Stravos Kontopoulos, que trás não apenas uma excelente definição das responsabilidades de um arquiteto de software como também destaca os principais desafios de um arquiteto de software em um projeto ágil. Achei fascinante, pois a realidade que vivo hoje é muito bem descrita por ele.

Segundo Stravos,

Arquitetos de software, para serem bem sucedidos, devem possuir diferentes habilidades: habilidades técnicas, habilidades gerenciais, habilidades de liderança.
A razão por trás disso é que eles são a interface para muitos grupos dentro da organização: desenvolvedores, interessados do negócio, engenheiros de operação, testadores, marketing, conselhos, etc. 

Habilidades técnicas são uma necessidade para uma arquitetura válida, servindo os propósitos do negócio de acordo com as necessidades atuais e futuras. Além disso, habilidades técnicas destacadas garantem que a tecnologia está sendo aplicada da maneira correta.

Um conjunto de habilidades gerenciais é essencial. Entregar um produto/projeto dentro do tempo/orçamento é de grande importância e um arquiteto de software é normalmente assistido por um gerente de projetos responsável por essa tarefa. O aspecto chave aqui é que o arquiteto de software sabe melhor como priorizar o trabalho, sabe melhor determinar riscos para o cumprimento dos requisitos do projeto/produto de acordo com sua perícia em software. A atual execução do gerenciamento pode ficar por conta do gerente de projetos, que também monitora os recursos/riscos em maior detalhe.

Acima de tudo, todo arquiteto de software deve ser um construtor de equipes. Frequentemente essa não é uma tarefa fácil. Pegar as pessoas certas, que frequentemente não são de sua escolha, manter o equilíbrio dentro do time, gerenciar as expectativas e a produtividade das pessoas, e eventualmente liderar o time é de vital importância. É como conduzir uma orquestra. Se você não fizer isso direito, o resultado será ruim, mesmo que tenha os melhores músicos.

Posso dizer que essa foi a melhor descrição para a função de um arquiteto de software que já encontrei. Reflete exatamente os desafios que encontramos no dia a dia, e as responsabilidades que temos que assumir. Quem pensa que ser um arquiteto de software é sentar a bunda na frente do Enterprise Architect e passar o dia desenhando diagramas (coisa que, como arquiteto ágil, raramente faço), está muito enganado.

Na sequência, Stravos fala sobre o papel do arquiteto de software em uma equipe ágil:

Na era da agilidade, em que não há tal coisa como uma arquitetura estável pré-definida, desenvolvedores devem trabalhar próximos ao arquiteto de software, monitorando a evolução da arquitetura.
Isso quer dizer que desenvolvedores também devem ter alguma habilidade com projeto arquitetural, de modo a fazer parte da evolução da arquitetura, sendo capazes de compreendê-la efetivamente. Um arquiteto de software não é capaz de estar ciente de todos os detalhes de um produto de software, mas deve estar ciente de cada decisão ou restrição que possa fazer a arquitetura se tornar inconsistente ou se desviar de sua tendência inicial.
O arquiteto de software, por sua vez, deve estar próximo de seu time, auxiliando-o durante as iterações de desenvolvimento, e por isso deve estar acostumado à codificação e codificar até um certo nível.

Muito frequentemente, um trabalho negligenciado é a documentação das arquiteturas. Isso pode ser parte de uma tarefa ágil em que a documentação é refatorada a cada iteração que também modifique a arquitetura.
Esta é a única maneira de se saber quais caminhos arquiteturais você está seguindo e ser capaz de apresentar aos interessados que você de fato sabe, e que eles possam ver através de seus olhos, o que você está construindo.

Confira o artigo completo neste link.

Nada substitui o lucro

Se você é um programador apaixonado pelo que faz, já deve ter sofrido bastante ao ver seus chefes, coordenadores, gerentes, ou patrões ignorando questões técnicas de suma importância, para você, como a manutenção de um código fonte de qualidade por exemplo, para viabilizar o cumprimento de um prazo ou algum requisito contratual. Isso é realmente frustrante e deve lhe fazer reclamar bastante pelos corredores e reconsiderar sempre a possibilidade de mudar de emprego, certo?

Não adianta. Onde quer que vamos estamos sempre sujeitos a isso. Você pode até mesmo encontrar uma empresa bacana de se trabalhar, onde os valores técnicos são tão considerados quanto os valores gerenciais, mas se de repente essa empresa entra em crise, rapidamente começaram as demissões, estagiários brotando do chão, agilidade sendo substituída por métodos tradicionais e a qualidade sendo deixada novamente em segundo plano.

Nada substitui o lucro, e isso é algo que você desenvolvedor, por mais bem intencionado que esteja, por mais profissional que seja, e por mais comprometido que se mantenha com a qualidade do código que escreve, não deve deixar de considerar. E não veja isso como algo ruim, ou errado. De fato nada substitui o lucro. Nenhuma empresa é constituída com o objetivo de criar o melhor software se isso não for apenas um meio de levá-la ao lucro. No fim, o que toda empresa busca é o lucro. 

Como então criar software de qualidade se o que interessa à empresa para a qual você trabalha é apenas lucrar? Se um software porcamente feito for mais lucrativo, é isso que a empresa irá lhe demandar, certo? Nem sempre. Cada organização tem seus valores, e muitas já reconhecem que produto de baixa qualidade uma hora ou outra se reverterá em prejuízo. Mas se esse não for o caso da empresa em que você trabalha, não entre numa guerra por interesses que deveriam ser daqueles que lutam contra. Faça sua parte, coloque qualidade no que você faz, na medida em que for possível, e não seja perfeccionista demais, seja mais pragmático. Aprenda também a aceitar que muitas vezes o nível de qualidade necessário será muito inferior ao melhor que você tem capacidade de entregar. Entenda os objetivos do projeto, compartilhe deles, e dentro desse limite, faça o seu melhor.

5 segredos para um propósito compartilhado

Um dos pré-requisitos para um trabalho em equipe saudável e eficiente é sem dúvida ter um propósito compartilhado pela equipe. Abaixo listo 5 segredos elencados por Christopher Avery para facilitar esse objetivo.

1. Estabelecer um entendimento compartilhado:

Discuta cada tópico, a missão, os entregáveis, e o produto do trabalho de sua equipe, até que possam articular juntos uma descrição clara e comum de seu propósito.

2. Selecione sua equipe por sua motivação, não por suas qualificações.

Se trabalho em equipe é importante para você, olhe para as qualificações apenas após considerar diretrizes, energia, interesse, motivação e entusiasmo, por que é um desejo compartilhado, não taleto, que gera trabalho em equipe.

3. Aceite, de uma vez por todas, que colegas de equipe não precisam gostar uns dos outros.

Encorajar afinidade para uma tarefa compartilhada, não para um com o outro, é a maneira mais rápida e certa de criar forte coesão no grupo. Ao invés de usar exercícios e técnicas que promovam a amizade, faça todos adotarem um foco comum de modo que cada membro da equipe veja boas razões para trabalhar um com o outro.

4. Pare de tentar motivar.

Por que tentar motivar outras pessoas quanto isso é quase impossível? Ao invés disso, use a motivação que já existe nos membros da equipe perguntando a eles sobre suas necessidades e desejos.

5. Determine se seu time está "construído".

Um time "construído" compartilha direcionamento e energia. Para atingir esse status para seu time, coloque sua fundação bem cedo perguntando a você mesmo uma variedade de importantes questões. Qual é a tarefa da equipe? Qual o benefício para cada membro da equipe ao se comprometer com esse trabalho? Há acordos que permitam à equipe operar mais rapidamente e eficientemente? Os membros da equipe compartilham um objetivo comum que os inspire? Você sabe o que cada membro da equipe agrega ao time?

Qual é o seu produto de software?

Para muitas empresas, um produto de software é visto como o resultado de um projeto de software, restrito a escopo, prazo e custo predefinidos.

Pensa-se em produto de software como o conjunto de arquivos a serem instalados nos computadores (servidores, desktops, dispositivos, etc) em que o software será utilizado pelo cliente.

Uma vez que tal conjunto de arquivos satisfaça aos requisitos contratados pelo cliente, considera-se que o produto de software apresenta a qualidade esperada.

Okay, mas onde está o problema nisso?

Requisitos de software, e principalmente requisitos informados pelos clientes, nem sempre especificam critérios de qualidade interna, e quando o fazem, fazem de maneira bem superficial, deixando a interpretação a cargo de quem for desenvolver e avaliar o cumprimento de tais requisitos.

À medida que o produto de software vai sendo utilizado, solicitações de mudança começam a surgir, regras são alteradas, novas funcionalidades são incluídas, e uma nova versão do produto de software é distribuída a cada conjunto de alterações negociadas.

Novamente, uma vez que os requisitos apresentados são satisfeitos, a nova versão é aceita e a vida segue.

Eventualmente, algo para de funcionar. "Quem mexeu nisso?", "Isso funcionava na última vez que usei.", "E quando foi isso?", "Não me lembro, mas funcionava."

E ai começa o inferno para o programador. Gerentes cobrando resultados e o desaparecimento dos bugs, prazos apertados ou inexistentes, cliente reclamando, correções feitas sem a devida atenção, novos defeitos sendo introduzidos. Você já deve ter entendido do que estou falando.

Mas o que uma coisa tem a ver com a outra? Atender aos requisitos do cliente e ter o software aprovado com base no cumprimento de tais requisitos é o que causa esse tipo de problema? Não. Mas atender aos requisitos do cliente não deve ser o único objetivo. E ver o produto de software como um conjunto de arquivos executáveis que satisfaça a esses requisitos também não é o mais adequado. Para se evitar esse tipo de "problema inesperado", é necessário investir na qualidade interna do produto, ou seja, naquilo que o cliente não vê, não avalia, não aprova, e que deve ser considerado o verdadeiro produto de software a ser produzido e mantido: o seu código fonte.

A única forma de se evitar que erros sejam introduzidos no software sempre que funcionalidades forem alteradas ou introduzidas é garantir que o código fonte seja mantido em um alto nível de qualidade, seguindo boas práticas de desenvolvimento, utilizando técnicas e disciplinas desenvolvidas especificamente para tal finalidade.

Falta de qualidade interna normalmente não prejudica as primeiras versões do software, não prejudica a sua aprovação, não bloqueia seu pagamento. E com isso investimentos em qualidade interna acabam sendo ignorados, vistos como algo desnecessário, dispensável.

Entregar o software dentro do escopo, prazo e custo é importante, mas manter a saúde do software ao longo de sua vida também é. Lembre-se, o seu verdadeiro produto de software não são os binários entregues, isso se consegue gerar novamente com uma compilação. O seu verdadeiro produto de software são os seus códigos fonte. Invista na qualidade deles, e o resto virá naturalmente.