Skip to content

Arquiteto de Software não é brinquedo!

É incrível como algumas empresas tratam o arquiteto de software
como se fosse o brinquedo da vez. Lembra quando éramos pequenos e
existia aquele brinquedo especial que todos queríamos ter e quem o tinha
era visto como um ídolo diante a criançada. Pois bem, as empresas fazem
o mesmo com o arquiteto de software!

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/ArquivosBlog/IntroducaoArquiteturaSoftware.pdf

Anúncios

Quando o ócio não é culpa do time!

Esta é uma das muitas situações que acontece dentro de um ambiente de trabalho, quando o ócio do time não é pura preguiça e sim ocasionado por outro problema. Um dos problemas que podem ocasionar eu vou explicar abaixo já que vivi uma situação destas.

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 pronto 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.

Bem-vindo!

Bem-vindo ao meu Blog!

A proposta deste Blog é discutir sobre tecnologia e ciência!

Abraços,

Paulo R. A. Sales