Architectural Decision Records - ADR¶

WILLIAM GLASSER - Aplicou sua teoria da escolha para a educação, na qual o professor é um guia para o aluno e não um chefe. Ele, explica que não se deve trabalhar apenas com memorização, porque a maioria dos alunos simplesmente esquecem os conceitos após a aula, em vez disso, nós aprendemos efetivamente fazendo.

Segundo a teoria nós aprendemos:

%%| fig-cap: Mermaid diagram
%%| fig-align: center
flowchart TD
    A(Ideal) --> A00(Propósito) & A01(Direção)
    A00 & A01 --> A02(Como vamos trabalhar</br>Qual a direção</br>Valores, Virtudes</br>Seja um FATOR de SOMA)
    A02 --> A03(Espírito de Missão</br>EU SEI o que quero construir</br>ESCOLHAS ACERTADAS</br>Direcionamento)
    A03 --> A04(Vida Interior</br>O MEU IDEAL</br>QUE FIZ NO DIA DE HOJE)
    A04 --> A05(CULTIVAR A DISCIPLINA</br>A falta do método caos</br>DESORDEM)
    A05 --> A06(Exercitar a CONCENTRAÇÃO</BR>CORPO E MENTE JUNTOS</BR>TREINE A CONCENTRAÇÃO</br>Tecnica TRATAK)

Por fim: Sejamos a pior `EQUIPE DE DESENVOLVIMENTO`¶

Oportunidade única de aprendizado¶

Ainda Sem Solução¶

DONO (PRODUCT OWNER/PRODUCT MANAGER) ou que possa ser engajado e capacitado para gerenciar esse backlog;
Ter um backlog claro e priorizado;
Técnico só ASSUMIR, quando PEGAR (Puxar ao invés de EMPURRAR) e ter o hábito de finalizar ao final do dia.

Livros¶

O livro de Brooks é considerado uma leitura obrigatória para gerentes de projetos de software.

A Lei de Brooks é uma observação sobre o gerenciamento de projetos de software que afirma que adicionar pessoas a um projeto atrasado o torna ainda mais atrasado. A frase foi cunhada por Fred Brooks no seu livro de 1975, The Mythical Man-Month.
Leva tempo para novas pessoas se tornarem produtivas (ramp up).
Gargá-los de comunicação aumenta quando o número de pessoas aumenta.
A divisibilidade de tarefas pode causar mais caos.
Alguns trabalhos à serem feitos não podem ser divisiveis e paralelizados.
Brooks afirma que o número máximo de pessoas em um projeto deve ser determinado de acordo com o número de tarefas que podem ser divididas de forma independente.
Algumas exceções à Lei de Brooks incluem:

Substituir pessoas em vez de adicioná-las;
Delegar trabalho já delimitado para as novas pessoas;

Estrutura do Banco de Dados Oracle¶

Padronizar System Identifier, ServiceName, DBName e DB Unique Name é crucial para garantir consistência, facilidade de gerenciamento e integração entre sistemas em ambientes corporativos. A padronização desses elementos facilita a automação de processos, como backup, recuperação e monitoramento, minimizando erros humanos e garantindo que os serviços de banco de dados sejam acessíveis de maneira uniforme. A uniformidade também contribui para uma gestão mais eficiente, especialmente em ambientes complexos e de grande escala.

Estrutura Diretórios Docker¶

A padronização da estrutura de diretórios no Docker é essencial para garantir a organização e a eficiência no gerenciamento de containers e imagens. Ao seguir convenções consistentes, como separar os arquivos de configuração, volumes e scripts em diretórios específicos, facilita-se a manutenção e a escalabilidade de projetos. A estrutura organizada também melhora a portabilidade e a colaboração entre equipes, tornando o ambiente mais previsível e seguro.

Estrutura do IaM/IdM¶

O Keycloak é uma plataforma de gerenciamento de identidades e acesso (IAM) que oferece autenticação e autorização centralizadas. Com a utilização de três Realms, é possível separar e gerenciar diferentes domínios de usuários de forma isolada. O Realm Administrativo é utilizado para gerenciar a infraestrutura do Keycloak e controlar permissões de admin. O Realm B2B serve para gerenciar acesso de usuários externos, como parceiros e clientes, com diferentes requisitos de segurança. Já o Realm de Aplicações Internas gerencia os acessos dos usuários internos, proporcionando controle sobre sistemas corporativos e garantindo a segurança das interações internas.

Padrão CQRS¶

A estrutura CQRS (Command Query Responsibility Segregation) visa separar claramente as operações de leitura (queries) e escrita (commands) dentro de um sistema, melhorando a escalabilidade e a manutenção. Com essa abordagem, diferentes modelos de dados podem ser usados para otimizar cada tipo de operação, resultando em maior eficiência e desempenho. A padronização facilita o desenvolvimento e a integração, pois define convenções para a organização de handlers, repositórios e eventos. Também promove uma melhor segurança e controle, já que comandos e consultas podem ser isolados e auditados de forma independente. Em sistemas complexos, essa estrutura permite evoluções mais ágeis e maior flexibilidade nas soluções implementadas.

Padrão SAGA¶

É uma abordagem para gerenciar transações distribuídas em arquiteturas de Microserviços, garantindo consistência sem a necessidade de um banco de dados centralizado. Existem duas abordagens principais: Coreografia, onde os microserviços se comunicam diretamente entre si, e Orquestração, onde um serviço central coordena as transações. É essencial para a escalabilidade e a resiliência de sistemas baseados em microserviços, mantendo a consistência eventual sem comprometer o desempenho.

Estruturação das Actions/Pipelines¶

A estruturação adequada das actions e pipelines em repositórios GitHub ou Azure DevOps é essencial para garantir a automação eficiente de testes, builds e deploys, aumentando a qualidade e consistência do código. Além disso, uma boa estrutura facilita a manutenção e escalabilidade dos fluxos de trabalho, garantindo que diferentes ambientes e branches sejam tratados de forma organizada. A padronização também melhora a colaboração entre equipes, permitindo que os desenvolvedores sigam práticas consistentes.

Divisão das Aplicações (OSS, COTS, MOTS, Internas)¶

Padronizar um modelo que leve em consideração aplicações MOTS (Modificable Of The Shelf), COTS (Commercial Off-The-Shelf), OSS (Open Source Software) e Internas é fundamental para garantir uma integração eficaz, reduzir complexidade e aumentar a interoperabilidade entre diferentes soluções tecnológicas.

A padronização assegura que todas essas soluções possam coexistir de forma coesa, sem sobrecarga ou redundância.

Esse modelo também contribui para a escalabilidade, já que um framework padronizado permite a fácil adição de novas soluções conforme a necessidade da empresa, sem comprometer a estabilidade ou a performance do ambiente tecnológico como um todo.

Static Site Generatos - Document as Code vs Wiki¶

Ao utilizar um Static Site Generator (SSG) junto com o conceito de Document as Code traz benefícios significativos para o desenvolvimento de documentação técnica. O SSG permite gerar sites rápidos, leves e facilmente hospedados, onde a documentação é gerada de forma automática a partir de arquivos de texto simples, como Markdown.

O Document as Code trata a documentação como parte do processo de desenvolvimento, permitindo que ela seja versionada, testada e revisada junto ao código-fonte, promovendo maior consistência e colaboração entre equipes. Essa abordagem facilita a automação de atualizações e integrações com o fluxo de CI/CD. Combinando essas práticas, a documentação torna-se mais ágil, acessível e integrada ao ciclo de vida do software.

Com isso, seria uma abordagem que aplica os princípios do desenvolvimento de software e práticas de engenharia de software ao processo de documentação, tratando a documentação como código.

Versionamento e Controle de Mudanças;
Automação de Build e Deploy, juntamente com o ATDD(Acceptance Test-Driven Development + UAT (User Acceptance Testing));
Testes de Documentação;
Colaboração e Controle de Qualidade;
Escalabilidade e Manutenção (Tudo em ÚNICO ponto, mas mantendo a INDEPENDÊNCIA).

Observabilidade com OpenTelemetry¶

OpenTelemetry coleta métricas, logs e traces de aplicações distribuídas, enquanto o SignOz fornece ferramentas avançadas de visualização e análise. Com isso, é possível monitorar o desempenho e identificar problemas rapidamente em sistemas complexos. A integração facilita o rastreamento de requisições, análise de latências e diagnóstico de erros. Juntas, as ferramentas oferecem uma solução poderosa para melhorar a eficiência operacional e a resolução de incidentes.

Arquitetura Unica (MOTS, COTS, INT, OSS, CQRS)¶

Integrar o modelo CQRS (Command Query Responsibility Segregation) com aplicações MOTS (Modificable Of The Shelf), COTS (Commercial Off-The-Shelf), OSS (Open Source Software) e sistemas internos em ambientes operacionais cria uma base sólida para arquiteturas escaláveis e flexíveis. A padronização entre esses sistemas e a definição clara de interfaces e processos operacionais proporcionam maior coesão e governança no ambiente. Isso resulta em um ambiente operacional robusto, onde todos os componentes, internos e externos, colaboram de maneira eficiente, escalável e segura. A abordagem permite que mudanças sejam implementadas de forma ágil, mantendo o controle e a consistência entre sistemas diversos.

Ciclo de Vida de um Produto¶

O Ciclo do software, começa com a ideia, onde identificam-se necessidades ou problemas que o software irá resolver, levando à definição dos requisitos iniciais. Em seguida, entra-se na fase de desenvolvimento, que envolve o design, programação, testes e implementação do software, garantindo que ele atenda aos requisitos definidos. Após a implementação, o software passa pela manutenção, onde são feitas correções, atualizações e melhorias. Com o tempo, o software pode se tornar obsoleto devido a novas tecnologias ou mudanças nas necessidades de mercado, levando à sua descontinuação. Durante todo o ciclo, é importante realizar revisões contínuas para garantir que o software permaneça relevante e eficaz até seu fim.

Tudo começa com ideias,necessidades ou hipóteses. Em um fluxo de valor não há requisitos, apenas ideias,necessidades ou hipóteses e quais serão os resultados.

Estruturação do Azure-Devops¶

Para estruturar ideias em um projeto no Azure DevOps sem uma SQUAD, mas com pessoas alocadas a diversos times de desenvolvimento, é essencial criar um planejamento flexível e organizado. Entendeu-se que a URL base para acessar os recursos de um Azure DevOps Organization e seus projects na plataforma.

https://devops.azure.com/: Esta é a URL base para acessar os serviços de DevOps na nuvem da Microsoft. Todos os recursos relacionados ao Azure DevOps estão acessíveis por meio dessa URL.
{organization}: Representa o nome da organização dentro do Azure DevOps. Uma organização no Azure DevOps é uma coleção de projetos e recursos, geralmente vinculada a uma empresa ou equipe. Exemplo: https://devops.azure.com/mycompany.
{projects}: Refere-se ao nome do projeto específico dentro da organização. Cada organização pode ter múltiplos projetos, que são as unidades de trabalho e colaboração no Azure DevOps, com diferentes repositórios, pipelines, boards e outros recursos. Exemplo: https://devops.azure.com/mycompany/myproject.
Outras informações importantes
Um produto no Azure DevOps representa uma solução contínua que está em desenvolvimento constante, com evolução, melhorias e manutenção regulares. Em vez de ter uma data de término definida como em um projeto, o produto é algo que existe de forma contínua, que precisa ser mantido, evoluído e documentado.

Criação de Projetos¶

Desenvolvido duas scripts para a uniformização dos projetos, que seguem a estrutura:

usage: git-azcesuc -h|help|?
 onde: https://dev.azure.com/{yourorganization}/{project}
      - yourorganization   = {yourorganization}
      - project            = Sistemas MOTS, INTERNOS,  OSS ou DSS.
 OPCOES:
  -p, --produto    Nome do MOTS, INTERNOS, OSS ou DSS            (Exemplo: -p E_BUSINESS_SUITE, GESCON, PEOPLESOFT)
  -t, --projeto    Projeto do PDTIC,DEMANDA                      (Exemplo: -t PROJETO)
  -d, --data       Data Incial da Iteracao dd-mm-yyyy            (Exemplo: -d 01-06-2023)
  -i, --iteracao   Número de Iterações                           (Exemplo: -i 5 (MÁXIMO: 12))
  -q, --query      Share Queries padrões                         (Exemplo: -q)
  -r, --repos      secao1-secao2-secao3                          (Exemplo: -r po,po,po-html,plsql,req-front,back,lib)
  -m, --maven      Estrutura Maven (maven-archetype-quickstart)  (Exemplo: -m)
  -l, --liqui      Estrutura Liquibase                           (Exemplo: -l)
  -u, --subm       Submodule Project                             (Exemplo: -u https://github.com/horaciovasconcellos/Teste.git)
  -y, --codes      Arquivos Padronizados de Estilo               (Exemplo: -y)
  -a, --admin      Adicionar Administradores                     (Exemplo: -a horacio@60pportunities.com.br,carlos@60pportunities.com.br)
  -o, --organ      Organismo/Membro do Projeto                   (Exemplo: -a horacio@60pportunities.com.br,carlos@60pportunities.com.br)
  Exemplo: git-azcesuc -s -p SISGEN -t p23001 -d 01-03-2023 -i 10 -q -l -m -r po,po-req,plsql-docs,sql  OU
           git-azcesuc -p SISGEN -t p23001 -c

Observação:

Para o perfeito funcionamento da estrutura e há a necessidade dos softwares git, mkdocs e Material for MkDocs, estarem instalados.
As data inicial deverá ser sempre segunda-feira e somará de duas(2) semanas.

usage: git-azanual -h|help|?
 onde: https://dev.azure.com/{yourorganization}/{project}
      - yourorganization   = {yourorganization}
      - project            = Sistemas MOTS, INTERNOS,  OSS ou DSS.
  -p, --produto    Nome do MOTS, INTERNOS, OSS ou DSS            (Exemplo: -p E_BUSINESS_SUITE, GESCON, PEOPLESOFT)
  -a, --ano        Ano                                           (Exemplo: 2023, 2024)

usage: git-azestatistica-json -h|help|?
 onde: https://dev.azure.com/{yourorganization}/{project}
      - yourorganization   = {yourorganization}
      - dataSearch         = 'yyyy-mm-dd hh24:mi:ss'

Identifica os commits realizados a partir de uma determinada data e os arquivos alterados.
- Follow de Code.

Uma Lista De Parar De Fazer E Começar A Fazer Para Liderança¶

Fazendo agora/Por favor pare	Não estou fazendo agora/por favor comece
Mudando as prioridades dentro de um sprint	Não mude as prioridades: proteja as equipes para que possam se concentrar. Aprenda e apoie as regras do scrum
Substituindo as prioridades que o proprietário do negócio definiu para a equipe	Colabore com o negócio
Forçar as equipes a cumprir prazos irrealistas e criar dívidas técnicas	Definir data ou escopo, não ambos
Retirar pessoas das equipes para trabalhar em simulações de incêndio ou projetos especiais	Deixe as equipes trabalharem em seu ritmo ideal

Camada de Persistência (PL/SQL)¶

Estratégia CI/CD (Integração Contínua/Entrega Contínua) para a camada de persistência utilizando Liquibase, será da seguinte forma.

ORDS Padronização¶

Modelo Simplificado¶

  flowchart TB 
    subgraph "Fluxo CQRS"
    id1(usuario) --> id3(db-pool-default) & id2(db-pool-cqrs)
    id2 -->|Query</br>Path| id201(Query)
    id201 --> |Obter</br>Dados|id202(DB Read)
    id3 -->|Commando</br>Path| id301(Comando)
    id301 --> |Gravar</br>Dados|id302(DB Normal)    
    end

Final de Pipeline¶

Problemas¶

Cada user story é um cheque - Alguem paga ou o que é pior já está pago;
O time esta entregando pouco, eu preciso acelerar? O que é entregar muito? O que precisa ser entregue? Temos uma lista CLARA, do que precisa ser entregue?
O problema não é trocar prioridade, o problema é deixar explícito o que não vai ser feito;
O time de tecnologia tentando apontar prazo;
inovação acontece quando você tem intolerância a erros. Linus, erro rápido e acerte logo.

Meta vs Métricas¶

Segregar Métricas e Metas;
- Métricas: São medidas quantitativas ou qualitativas utilizadas para avaliar o desempenho de um processo, atividade ou sistema.
- Metas: São objetivos específicos e mensuráveis que uma pessoa ou organização deseja alcançar em um determinado período de tempo.

Métricas de Mercado¶

Dora(DevOps Research and Assessment) matrics¶

Elas são baseadas em um estudo realizado pela Google e ajudam a medir a eficácia das equipes de desenvolvimento e operações em várias áreas críticas, como velocidade de entrega, estabilidade e confiabilidade. As 4 principais métricas DORA são:

Frequência de implantação: com que frequência uma equipe de software envia alterações para a produção;
Tempo de entrega da alteração: o tempo que leva para que o código comprometido seja executado na produção;
Taxa de falha de alteração: a parcela de incidentes, reversões e falhas de todas as implantações;
Tempo para restaurar o serviço: o tempo que leva para restaurar o serviço na produção após um incidente;

Space¶

O SPACE é um modelo de métricas desenvolvido para capturar uma visão holística do desempenho das equipes de engenharia, incluindo tanto a produtividade quanto a experiência e satisfação dos desenvolvedores.

Métricas DevEx (Developer Experience)¶

Developer Experience (DevEx) se refere à experiência geral dos desenvolvedores durante o ciclo de desenvolvimento, desde a codificação até a implantação e a manutenção de sistemas.

O que gostaria¶

Indicador tem que ser evangelizado com o time;
- Se o time não comprar ele na verdade vai trabalhar para melhorar o indicador não o resultado;
- Sempre tem um jeito de colocar o número bom sem necessariamente ficar bom então é importante que o time entenda na verdade;
Quando olhei par ao Azure-Wit, vi valores errados e fiquei triste;
- Início da atividade estava defasada da data de início impostada;
Portal de Colaboração parecido com o InnerSource;

Finalizando¶

Medir a produtividade do desenvolvimento de software é um tópico delicado e, como tal, decisões de cima para baixo podem facilmente causar alguma controvérsia. Por outro lado, sem a direção da liderança de engenharia, é muito fácil desistir. O papel da liderança é construir um ambiente onde equipes e indivíduos possam ter sucesso. Garantir que alguns ciclos de feedback estejam em vigor é um exemplo perfeito disso. Portanto, faz sentido ser proativo nessa discussão.

Os desenvolvedores geralmente têm preocupações sobre rastrear métricas prejudiciais e desempenho individual.