Todo projeto de SW merece um mapa técnico e metodológico

No início da década de 80 eu iniciei meus estudos acadêmicos com FORTRAN, ainda no primeiro semestre de Engenharia Elétrica, troquei para Análise de Sistemas e evolui para Assembler, PL/I e COBOL, sempre perfurando cartões para o antigo IBM 1130. As telas tinham 24 x 80, relatórios 132 ou 80, tudo era previsível. Caracteres especiais era só via tabela EBCDIC ou ASC, base hexa, octal ou decimal.

Trinta anos se passaram e a cada 5 anos tudo mudava, HW e SW, linguagens, bibliotecas, banco, frameworks, camadas, protocolos, automação, ferramentas, plugins, etc. A tela passou a ser um canvas, passamos a usar N camadas, OOP, micro-serviços, SCRUM, Kanban e XP. Sou um aficcionado do uso de Dashboards, Agile Subway Maps e mapas conceituais, afinal: Se não sabemos o caminho e o nosso objetivo a cada passo, qualquer caminho, de qualquer jeito e qualquer resultado estará bom.

Um case dos mais ilustrativos e instigantes, por Matheus Alagia

Arquiteto na TI da Defensoria Pública do Estado do RS, foi responsável por estabelecer uma arquitetura que suporte por muitos anos o novo portal do defensor público, uma solução interna para centralização e organização do trabalho de centenas de defensores públicos RS afora. A imagem abaixo é um exercício acadêmico em uma aula de tópicos especiais em Engenharia de SW, seu potencial vai muito além nas mãos de um PMO ou de uma equipe de métodos, processos ou planejamento estratégico.

Premissas

1. Orientação a serviços;
2. UI leve (JS e CSS);
3. Spring Security;
4. O-Auth (token).

Frontend

1. Angular #1 (mvc simples);
2. Bootstrap (para um sistema web corporativo);
3. Aquisições assíncrona (~ node);
4. JSON.

Backend

1. Inicio JAVA e continuação GROOVY;
2. Spring Boot (micro serviços);
3. JPA / SQL Server;
4. Spring Cloud (descoberta e autenticação de serviços);
5. Eureka – Netflix (open Source sw);
6. FEING (integração REST full serviços);
7. ZOOPROXY – distribuição entre serviços;
8. HYSTRIX – circuit Bresser / tratamento de erros;
9. RX GROOVY -assíncrona de serviços).

Ferramental 

1. GIT (versionamento);
2. GERRIT (peer review);
3. GRADLE (gerencia dependências).

Qualidade

1. Spock – (GROOVE, Spring MVC);
2. JUNIT;
3. Mockito;
4. BDD Mockito;
5. JASMINE.

Deploy

1. JENKINS (integração contínua e garantia de % de cobrtura de testes);
2. PUPPET – provisionamento e configuração de máquinas, escalabilidade;
3. REDIS / ZOOKEEPER – cache distribuida;
4. KUBERNETS – gerência hosts DOCKER, balanceamento.

Outros

1. ALFRESCO (GED);
2. CMIS (protocolo CMS);
3. RABBIT MQ – message queue.

Metodologia

1. SCRUM com sprints de 2 semanas;
2. Quadro Kanban;
3. Estimativas em US Points, TShirt Size e livre;
4. Release Plan – inception com mais de 20 envolvidos;
5. Cotidiano envolvimento dos clientes.

O resultado foi excelente para uma hora de apresentação, a atenção da galera demonstrava que o assunto captou interesse, o Matheus foi perguntando quem já utilizava cada ítem, chamando a atenção de alguns, perguntas surgiam naturalmente, acho que o formato foi 100% validado.

Com certeza faltaram alguns ítens, como IDE e algumas boas práticas, mas ficou excelente, refatoraremos nas próximas. O potencial de um Agile Subway Map, Dashboard ou Mapa conceitual é inimaginável, porque cada empresa e equipe percebe diferentes oportunidades, aproveitadas a sua forma, o que não dá é para abrir mão disso.

A provocação é a falta que faz um mapa completo de arquitetura e tecnologia em qualquer empresa e qualquer projeto. Para materialização e auto-conhecimento, para visibilidade e planejamento, muitas vezes como instrumento comparativo, de forma a perceber qual equipe e projeto usa o que, porque, para quais resultados.