Como desenvolvedores, nosso trabalho é entregar software que o cliente quer e precisa, com o melhor tempo e custo, mitigando riscos.

Muitos desenvolvedores, adeptos de processos ágeis, ansiosos em dispensar processos desnecessários no desenvolvimento, acreditam que técnicas de arquitetura de software podem ser descartadas. Infelizmente, [tweet]a busca “cega” (quando desprovida de critérios) pela agilidade tem produzido, com muita frequência, software caros para manter e impossíveis de evoluir.[/tweet]

Risk-Driven Architecture ajuda a consciliar práticas de arquitetura, mesmo com abordagens mais agudas de agilidade.

Como indicado no post anterior, Risk-Driven Architecture indica a adoção das práticas indispensáveis para a mitigação dos riscos identificados em cada projeto. Nem mais, nem menos!

Na prática, se todos os riscos previstos para o projeto podem ser contornados no futuro através de refatoração, então fica explícita a recomendação de não investir tempo com design e partir direto para o código. Se, por outro lado, houverem constraints difíceis de atender com refactoring (por exemplo: escalabilidade e segurança), então algum esforço de design se prova necessário.

O código, mesmo bem escrito, não é suficiente para explicitar as motivações para cada decisão. Entretanto, tanto o volume de documentação quanto a frequência para a atualização dessa documentação varia por aspectos geradores de risco como: tamanho do projeto, tamanho do time, especificidade dos requisitos funcionais e não funcionais.

Agilidade não indica desordem!