Um pouco mais sobre arquitetura

Vamos discutir um pouco mais sobre arquitetura?
Bem, logo depois de ter entendido o problema e traduzido as necessidades do cliente em requisitos (vide posts anteriores sobre esses assuntos), é hora de definir a solução técnica.

Importante: pode existir solução técnica preliminar, normalmente feita antes de vender o projeto, ainda em fase de negociação com o cliente, com o objetivo de fazer estimativas de prazo e custo. Para o escopo deste post, focaremos na solução técnica da fase de projeto mesmo, quando o negócio já foi fechado. 

Primeiro ponto importante: normalmente há mais de uma solução técnica candidata. Por isso, é preciso decidir qual dessas opções será a implementada. Para isso recomendo montar uma tabela de decisão, em que são colocados critérios objetivos, com uma escala numérica e pesos para os critérios. A solução que obtiver mais pontos, segundo esses critérios ponderados será a escolhida. Não há uma receita para os critérios, mas posso dar exemplos: conhecimento do time na plataforma tecnológica, tempo previsto para implementação segundo base histórica, dependência de terceiros / vendor lock-in, posição no hype-cycle ou nos quadrantes mágicos do Gartner, custo, entre outras.

Uma vez tomada a decisão, sugiro fortemente que você guarde a tabela de decisão para relembrar no futuro todo o racional desenvolvido. Isso mostra profissionalismo e evidencia que houve planejamento no processo.

Chegou a hora de montar um roadmap arquitetural, em que são colocados os grandes marcos da arquitetura numa linha do tempo. Recomendo separar por mês. Aqui teremos um horizonte do que será desenvolvido. Depois, é criado/detalhado o backlog, com ênfase nas atividades mais técnicas. O ideal é estar um ciclo de desenvolvimento (sprint) a frente do time que fará o código. É uma forma de antever problemas e evitar bloqueios que atrasariam o time. É interessante também mapear os riscos técnicos, indicando chance de ocorrer e impacto. Sempre que possível, já indicar quais ações serão feitas para atacar/mitigar os riscos. Um risco comum é justamente o time disponível para executar o projeto não estar pronto para a atividade, porque ainda falta alguma capacitação. Isso também deve estar no plano de ação que surgiu do levantamento dos riscos.

Uma vez levantado o que tem que ser feito, é importante formalizar os donos. Todos devem saber o que vão fazer e quais os prazos. Se houver uma gestão visual (quadro / kanban / monitor são opções), melhor. Os marcos do projeto devem ser de conhecimento de todos e visíveis o tempo todo.

Cada elemento arquitetural deve estar associado a um requisito, seja funcional ou não funcional. Documente de forma a conseguir manter a rastreabilidade entre esses elementos. Se o requisito que motivou algum ponto na arquitetura mudar, será fácil identificar o impacto. Recomendo usar algum tipo de matrizes de rastreabilidade e de dependências. Já usei a ferramenta Sparx Enterprise Architect para isso e gostei bastante, mas há outras opções e vai do gosto/bolso de cada um.

Depois disso, é interessante formalizar tudo em um documento de arquitetura. Mas isso vai ficar para o próximo post.

Provocações finais

Seu processo é rastreável? Se um requisito muda, é fácil saber qual item arquitetural será afetado?
Arquitetura tem relação apenas com requisitos não funcionais? Quanto da funcionalidade do sistema pode ser afetada por uma decisão arquitetural mal feita?
Você se lembra por que decidiu usar a abordagem A e não a B no seu projeto? Quais foram os critérios para decidir?
Você tem um roadmap arquitetural? Nele foram previstas as validações arquiteturais?
Como você lida com riscos?

Comentários

Postagens mais visitadas deste blog

Arquitetura em projetos de aplicações em nuvem - noções iniciais

Requisitos conflitantes e dilemas no projeto de software

Levantamento de requisitos