Pense na definição da profissão “Arquiteto de Software”,
uma das muitas definições existentes segue abaixo:

“A arquitetura de um software é a estrutura ou estruturas do
sistema, o que compreende componentes de software, propriedades
desses componentes que são visíveis externamente e o relacionamento
entre eles”, Paul Clements, SEI.

Muitas vezes os profissionais que trabalham nessa profissão
não realizam exatamente o que devem, mas
a empresa se enaltece por ter um arquiteto de software envolvido em um de seus projeto.

O papel de um arquiteto de software é equiparado ao papel de um gerente de projetos,
onde um gerência a tecnologia aplicada e o outro gerência pessoas. Portanto, temos que o
fracasso de um projeto por causa de uma má gestão pessoal é culpa do gerente de projetos e
o fracasso de um projeto por causa de um problema técnico é culpa do arquiteto de software.

Ao desenvolvermos um software para um cliente temos que seguir uma lista de requisitos
que são eles funcionais e não-funcionais. Os requisitos funcionais estão quase sempre relacionados
ao negócio da empresa, como exemplo “Realizar pedido”. Já os requisitos não-funcionais estão
relacionados com performance, disponibilidade, interroperabilidade, escalabilidade,
segurança, performance, usabilidade, etc. São inúmeros os requisitos não-funcionais e
às vezes são desprezados por muitos, principalmente o gerente de projeto. O gerente de projetos
quer ver o pedido sendo realizado e o dinheiro entrando na conta da empresa e na dele,
mas temos um enorme problema nisso! Ao ignorarmos os requisitos não-funcionais, que nunca são poucos,
estamos escondendo o sol com a peneira e esperando para ficar cegos.

O papel do arquiteto de software deve ser de não permitir que os requisitos não-funcionais
sejam ignorados e nem tão pouco deixados para última hora. Muitos requisitos não-funcionais podem
interferir diretamente em um requisito funcional. O Arquiteto deve entender e compreender os
requisitos não-funcionais e propor soluções para resolvê-los. Mas isso não é o que acontece nas
empresas por ai.

Primeiro, para a maioria das empresas é inaceitável o arquiteto de software ter o mesmo
nível que um gerente de projeto. Segundo, nunca um arquiteto de software tem voz ativa
diante uma equipe de desenvolvedores que estão acostumados a fazer telas em linha de produção.

Por isso um arquiteto de software não é um super brinquedo que somente serve para
se exibir e que com o tempo perde a utilidade. Um arquiteto de software é o ícone muito influente
no ciclo de vida de um projeto e é dever dele garantir que o software funcione desde o
início de sua vida em um ambiente de produção.

O link de referência citado abaixo tem uma ótima descrição do papel de um arquiteto, todas
as empresas deveriam ler e seguir este documento, assim teríamos software funcionando!

http://www.wthreex.com/rup/process/workers/wk_archt.htm

Links relacionados:

http://pt.wikipedia.org/wiki/Arquitetura_de_software

http://www.marcomendes.com/ArquivosBlogIntroducaoArquiteturaSoftware.pdf

Na informática, mais precisamente na área de desenvolvimento, trabalhamos focados em objetivos e entregáveis bem definidos. Claro que sem uma meta bem estabelecida e tarefas bem planejadas não terá trabalho a ser entregue. Para mostrar o que estou tentando dizer vou usar como exemplo em cenário ágil.

Como a maioria deve saber o Product Owner com ajuda do time na metodologia Scrum deve lançar atividades que representam os requisitos de um projeto e priorizar cada um desses requisitos. Após o  Product Backlog ter sido analisado parte-se para os planejamentos das atividades e assim por diante.

Se o Product Backlog não foi bem analisado e bem priorizado o time acaba tendo muita dificuldade em realizar o planejamento das estórias e atividades. Portanto, durante o andamento da Sprint podemos perceber um aumento de atividades que não foram previstas com antecedência gerando uma certa insegurança para o time se realmente aquela estória ou mesmo requisito é necessário ou se deve realmente ser realizada da forma que foi planejado.

Isso faz com que o tempo gasto do time até descobrir que a Sprint deve ser cancelada por ter a meta alterada é uma perda para o andamento do projeto. E até o momento de decidir cancelar a Sprint o time detém seu tempo com várias discusões e elocubrações à respeito do real motivo de tudo estar indo para as cucuias. Isso ao olhar do Product Owner e/ou dos Stackholders aparente puro ócio do time. Como o conceito de <em>pronto</em> não foi bem definido eles não visualizam os entregáveis no tempo em que imaginavam e culpam o time por divagar demais em idéias alheias.

Mas na verdade o time não tem culpa e não está ocioso, o time está correndo atrás para saber se realmente ocorreu um problema durante a Sprint para cancelar e começar novamente de maneira correta. Já que a metodologia ágil prega o princípio de “Quanto antes encontrarmos o problema mais rápido temos que discuti-lo”.

Isso pode ser ocasionado por falta de comunicação e entendimento do Scrum Master, time e Product Owner. Um gráfico que pode ser usado para perceber com rapidez que a sprint esta caminhando em direção a outra meta é o Burn-Up.

Por isso valorizem muito a comunicação e o bom entendimento dos requisitos que serão entregue. Acredite, quem não comunica, se estrumbica.

Referências:

• Tem um artigo bem direto quanto a utilização e alguns benefícios de utilizar o burn-up chart: Burn-up e Burn-Down.