Gestão de Risco na Arquitetura de Software

É sabido que as decisões tomadas em arquitetura de software, de alguma forma, envolvem aceitar alguns riscos. É uma falácia afirmar que existe um modelo de decisão perfeita, onde todos os problemas sejam resolvidos e prontos para que a evolução do software aconteça de forma ideal.

Na arquitetura de software, para encontrarmos boas soluções, as etapas como discussão, planejamento e, principalmente, execução são estabelecidas para que o software possa efetivamente resolver problemas e inovar. Entretanto, aceitar riscos não quer dizer que devemos deixar de lado esse assunto, mas sim ter a consciência que existem riscos para serem mapeados e com planejamento conseguir mitigar ao longo dos ciclos de desenvolvimento.

Leis de Lehman

Já na década de 70, Meir Lehman estabelecia algumas diretrizes em relação a tomada de decisão na construção e manutenção de um software. Diretamente não falava sobre riscos mas em 2 de suas “Leis”, indiretamente, pode ser observado esse ponto.

• Mudança Contínua: Todo software deverá ser continuamente adaptado para ser compatível com os recursos utilizados (e.g. banco de dados), bibliotecas e linguagem. Essas mudanças e atualizações deverão acontecer sempre, pois quando não acontecem há um risco progressivo em problemas e compatibilidade;
• Complexidade Crescente: Conforme o desenvolvimento de novas funcionalidades de um software há possibilidade de aumentar a sua complexidade. Softwares complexos são mais difíceis de dar manutenção e desenvolver novas features. Por isso, estabelecer padrões de design (design patterns) adequados é fundamental para que isso não aconteça. E, sempre que possível, deve haver um esforço para reduzir a complexidade enquanto recebe alterações. O nome mais conhecido disso é refatoração. Deixarei este artigo para aprofundar mais sobre este tema.

Quem nunca se deparou em um software legado, incompatível com recursos utilizados e bem complexo pra manutenção a ponto de precisar criar um novo software para novas funcionalidades?

Porém, o que é legado? Talvez podemos fazer um exercício que a cada versão implementada, o software se torna um legado.

Normalmente, quando se fala em decisões arquiteturais soa como pedir permissão a alguém muito técnico ou esperar uma decisão de um time específico que irá resolver o problema. Hoje com equipes descentralizadas as tomadas de decisões são e devem ser compartilhadas.

Porém, mesmo assim, é difícil quantificar e priorizar riscos ou até mesmo levantar isso em alguma parte do planejamento. Para isso sempre é importante trabalhar baseado em metodologias e abaixo apresentarei uma que ajuda na gestão de riscos.

Agile Architecure Risk Managment (AARM)

Esta metodologia leva em consideração a descentralização de tomada de decisão, levantamento e gerenciamento de risco. Tendo como princípio a evangelização de boas práticas de arquitetura, promovendo a troca de experiências.

Nela os times trabalham em conjunto com suas lideranças técnicas e arquiteturais afim de tomar as melhores decisões. Para isso existem 4 fases. São elas:

Estratégia de Produtos

Esta fase consiste em coletar o máximo de informações da estratégia de negócio referente ao planejamento do produto. Muitas vezes são realizadas reuniões de brainstorming, kick-off, refinamentos ou qualquer outra cerimônia que consiga identificar o máximo de informações sobre o produto.

Priorizar Características de Arquitetura

Esta fase é muito importante para levantar as características de arquitetura baseadas nos requisitos não-funcionais levantados na estratégia do produto. Neste levantamento começarão a surgir trade-offs que deverão ser mapeados para permitir sua priorização. Nesta fase começamos a mapear e validar características arquiteturais para habilitar o produto. A priorização deverá ser realizada em conjunto com as decisões de estratégias do produto, afim de conseguir planejar as suas execuções.

Risk Storming

Esta fase é caracterizada como mapeamento dos riscos. Isso dever ser feito em conjuntos com todos as pessoa técnicas que estão envolvidas na solução (desenvolvedores, líderes técnicos, arquitetos, engenheiros, etc). As cerimônias de risk storming são feitas com todos e os riscos são discutidos, identificados e até chegar ao ponto de definir como mitigá-los. Caso seja interessante, podem ser convidados para essa discussão áreas, times ou pessoas especialistas no tema. Por exemplo, se em uma cerimônia estiver sendo discutido os riscos de segurança da solução proposta pode-se convidar a área, time ou pessoas da empresa que são especialistas neste assunto. Não quis colocar a palavra responsável pois segurança, ou qualquer outro conceito, não é responsabilidade de um único time, área ou pessoas, mas sim de toda a organização.

Para ajudar nessa discussão é muito importante que a linguagem seja ubíqua, ou seja, que os conceitos e linguagens sejam padronizadas por todos. Para isso, a discussão pode ser realizada em cima de diagramas, como por exemplo o diagrama C4. Esses diagramas podem ser construídos e discutidos em conjunto, para que possam ser identificados os riscos individualmente. E, por final, seja apresentado em uma matriz de prioridades. Esta é uma técnica de identificação de risco visual e colaborativa.

Histórias de Arquitetura

Esta fase é a criação de épicos e histórias referentes aos riscos de arquitetura. Ou seja, depois dos riscos serem apresentados e discutidos na matriz, histórias deverão ser criadas no backlog do produto para que o time possa desenvolver nos ciclos.

Além de trabalhar com o planejamento de forma antecipada, não podemos esquecer que problemas acontecerão quando o software estiver em produção e para que problemas e riscos não sejam repetidos futuramente, pois sabemos que times mudam e pessoas entram e saem do ciclo de desenvolvimento, vale adotar uma prática que é conhecida como postmortem. Crie e compartilhe documentações com intuito de apresentar o problema acontecido e a solução adotada para evitar que o problema ocorra novamente.

Mesmo utilizando uma metodologia de gerenciamento de riscos não podemos esquecer das métricas. Elas são importantes para mensurar o desempenho do que está sendo avaliado. Este artigo aborda a importância delas e sua relação com a cultura. Porém, o que vamos falar aqui são as métricas que mensuramos para os riscos, sendo chamadas de 8 métricas de débito técnico.

Sabemos que débitos técnicos tem relação direta com os riscos de um software, podendo levar em casos extremos (mas infelizmente comuns!) a impossibilidade de novas implementações, melhorias e/ou descontinuar o projeto.

As métricas abaixo serão importantes para identificar as deficiências técnicas do software.

Novos Bugs x Bugs Fechados

Esta métrica é a relação entre novos bugs que surgem em um determinado ciclo com bugs abertos. Se, por acaso, o número de novos bugs estiver superando os bugs que estão sendo resolvidos é preciso, urgentemente, discutir sobre a arquitetura e o desenvolvimento do software.

Índice de dívida

Esta métrica está relacionado com a anterior e também com a matriz de priorização de riscos apresentada anteriormente. Não basta resolver os bugs, eles deverão ter pesos ou nível de prioridade. Podemos pegar como exemplo onde se o risco de segurança é considerado alto (nota 9) seus bugs tem mais peso e prioridade. Não basta resolver bugs, tem que saber quais bugs resolver.

Qualidade do código

Vamos partir do princípio que código complexo é difícil de dar manutenção e evoluir. Esta métrica está relacionada a qualidade e complexidade do código. Alguns pontos deverão ser levados em consideração como: complexidade ciclomática, acoplamento de classe, linhas de código e profundidade de herança. Atualmente existem ferramentas que quantificam a complexidade e apresentam pontuações.

Tempo do ciclo de correção (Cycle Time)

Talvez essa seja a métrica mais comum, calculando o tempo do ciclo da correção a nível de código. Onde verifica o intervalo entre a primeira alteração e commit de código até a sua implantação. Porém, neste caso, há uma especificidade quando falamos de débito técnico. Essas correções são associadas a algum bug ou correção e mesmo com um cycle time baixo é importante levar em consideração quais são essas correções.

Retrabalho (Code Churn)

Esta métrica está relacionada a quantidade de vezes que o código sofre alterações — podendo ser uma linha, um método ou uma classe. Vale lembrar que correções são feitas no seu código, porém, a princípio não seria mais necessário rever alguma parte do código após a correção ou com o surgimento de um novo bug. Caso perceba-se aumento de rotatividade no código implementado é importante descobrir o que está acontecendo, pois isso é um sinal de dívida técnica.

Cobertura de Código (Code Coverage)

Neste caso será medida a cobertura de testes unitários para as implementações. Quanto maior for a cobertura, mais o seu código está testado. Uma boa prática de desenvolvimento guiada por testes é o Test-Driven Development (TDD).

Propriedade de Código (Code Ownership)

Este é um valor absoluto de quantas pessoas colaboram com o projeto. Não é aconselhável que um projeto ou código tenha apenas 1 ou poucas pessoas colaborando ou trabalhando, caso elas deixem de contribuir a distribuição de tarefas e melhorias ficarão difíceis. Um projeto colaborativo, onde muitas pessoas tenham acessos ou até mesmo onde uma equipe por completa colabore caracteriza um sistema eficiente em delegação de tarefas e um sistema livre. Não que seu projeto deverá ser OpenSource, porém a ideia colaborativa com aberturas de issues e pull requests acaba sendo uma prática interessante.

Índice de Dívida Técnica (TDR)

Esta métrica é relacionada diretamente ao custo da dívida técnica. É a relação do custo para corrigir um problema com o custo total de construir o projeto. Seu resultado pode implicar em recursos financeiros ou tempo gasto.

Esta métrica é obtida a partir do cálculo abaixo:

(Custo de Correção ÷ Custo de Desenvolvimento Total) × 100 = TDR

O custo de correção pode ser extraído de métricas apresentadas anteriormente como o tempo do ciclo de correção, caso queira calcular o tempo. Porém pode ser calculado qualquer outro valor de recurso que deseja obter, como por exemplo recurso financeiro.

O custo de desenvolvimento leva em consideração o total de recurso a ser calculado necessário para a construção do projeto.

Resultados aceitáveis são no valor de até 5%, acima disso pode representar um problema sério para o negócio. Este cálculo pode ser feito levando com base um determinado período ou até mesmo desde a concepção do projeto.

“Arquitetura é sobre as coisas importantes — o que quer que isso seja.” (Martin Fowler)

Podemos concluir que gestão de risco é algo muito importante para o ciclo de desenvolvimento do produto, principalmente quando levamos em consideração as análises das métricas obtidas referentes a esse tipo de gestão. Atualmente existem algumas ferramentas que realizam o trabalho de extração de uma ou mais métricas.

Por final, adotar uma metodologia para nos guiar pode ser efetivo no planejamento e evolução do produto.