• No mundo acelerado de hoje, a busca pela excelência é uma jornada implacável.
• Ao receber uma demanda necessitamos estabelecer, um critérios objetivos como devemos atende-la, para tal cito alguns questionamentos básicos.
• Entrego Tempo + Conhecimento - Pacote de Reccmpensa. NÃO é uma família, é pedir para todos aguanterem em nome do sangue.
• A demanda tem um objetivo claro e definido que busca entregar uma funcionalidade nova ou uma mudança significativa?
• A demanda possui um escopo bem delimitado, com entregas e prazos específicos?
• A demanda impacta o produto existente de forma que altera sua funcionalidade ou seu valor percebido pelos usuários?
• A implementação da demanda requer recursos e esforços significativos (equipe, tempo, orçamento)?
• A demanda é única e não deve se repetir no futuro, ou faz parte de uma série de melhorias planejadas?
• O produto já existente, porem novas funcionalidades deverão ser abarcadas e/ou modificadas em função de pequenas alterações.

Com os critérios acima respondidos, então podemos classificar esta demanda como Melhoria Contínua/Bug ou um Novo Produto.

Em ambos os casos seguimos o conceito do PMBOK, que define um projeto como um esforço temporário empreendido para criar um produto, serviço ou resultado único, enfatizando sua natureza temporária e sua unicidade.

Então, sendo o foco de entregar um resultado específico, que pode ou não se tornar um produto e tendo seus objetivos alcançados ou quando cancelado, designaremos como: Bug ou Melhoria Contínua.

Logo, um produto é uma solução que é desenvolvida para atender às necessidades dos usuários de forma contínua, geralmente tem um roadmap e uma visão de longo prazo.

Gestão e Liderança¶

Liderança é sobre construir equipes de alto desempenho, uma habilidade que entrelaça entender pessoas, inspirar ações e tomar decisões difíceis. Como qualquer ofício, dominar a liderança exige persistência e aprendizado.

A liderança, como a arte, mistura teoria fornecendo uma base, a verdadeira expertise vem por meio da aplicação no mundo real, aprendendo com cada interação, sucesso e fracasso.

• Pontos interessantes a serem discutidos no "PROJETO".
• A felicidade não é a ausência de conflito, e sim a habilidade de lidar com ele. Uma pessoa feliz não tem o melhor de tudo, mas ela torna tudo melhor.
• Começar → Manter → Terminar (Contexto → Ritmo → Direção (Se vc não estiver no meu ritmo, eu não consigo esperar o seu).
• Pare de Focar em Resultados. Resultados são consequencias de Processos + Pessoas, sendo o que otimiza Processos e Pessoas de fato é a Gestão e Liderança.
• Não se foca na consequencia, se foca na CAUSA da consequencia, que é a otimização de processos e otimização de pessoas.
• Confiança se constroi com Diálogo e Atitude.
• Gestores NÃO são acostumados a lidar com pessoas:
  • 100% dos clientes são pessoas..
  • 100% dos funcionários são pessoas.
  • Logo, entender de pessoas é entender de negócio..
  • Promovemos gestores por: Comportamento e conhecimento específicos, Inteligencia Exata, Extroversão, Não ter vergonha ir a público, Raciocínio Dinamico, ou seja, performance não atrelado ao cuidado.
• Transformando pessoas, em uma máquina de lucros:
  • Pessoas NÃO são despesas e sim o maior ativo de uma empresa, desde que bem GESTIONADA;
  • Não procure: Convencer, Concordancia e Consenso. Não sendo falta de ética, não sendo CRIME, vamos abandonar as três coisas e estabelecer uma quarta: COMPROMISSO.
  • “Você é livre para fazer suas escolhas, mas é prisioneiro das consequências”. (Pablo Neruda)
  • Se você decidiu ficar, apesar de tudo o que você não gosta, é uma decisão sua de ficar, então faça o negócio acontecer. Empenhe-se. Pare de resmungar, reclamar, não jogue contra...
  • Ou seja, Entrar, jogar e sair, sem problema algum. Mas se esta JOGUE.
  • Como é que fazemos o PROJETO ser FUNCIONAL? Se é aqui que queremos estar, se é aqui que EU, quero estar, se a gente faz AQUI, ACONTECER, temos que deixar de pedir ao TRABALHO, o que não NÃO dará e focar no RESULTADO e COMPROMISSO.
  • Somos literais: A importancia da comunicação clara e objetiva. - [x] Minha mãe, disse: "Compra 10 pães, se tiver ovo traga 6". Então, fui a padaria e vi que tinha ovo, logo trouxe 6 pães. Quando chegei em casa, bronca de mamis.
  • Os engramas são marcas deixadas na mente por experiências intensas, principalmente emocionais ou traumáticas, e ficam armazenados no subconsciente, influenciando nosso comportamento de forma automática.
    • O tempo todo: ema, ema ...como chama a clara do ovo..: Alguns irão dizer GEMA, e não clara.
    • Branco, branco, branco, o que a vaca bebe? Alguns irão dizer leite, mas a vaca, bebe Água.
  • Quando uma porta se fecha, você tem duas opções: entregar sua carreira nas mãos da empresa ou tomar as rédeas e seguir em frente. Não deixe que um feedback negativo, uma puxada de tapete ou uma promoção que não veio definam o seu futuro. Lembre-se sempre: a sua carreira É SUA.
  • Ética é a obediencia ao que não é obrigatório. Mas é bom, é justo, coloca o coletivo sobre o individua.Bom/Mau - Ética.
  • Moral algo que é certo ou errado, dependendo de sua cultura.Quanto maior o numero de leis, menor a ética.
• Crie histórias de seus produtos - Storytelling:
  • Lego não vende brinquedos, ela vende criatividade;
  • Halley Davidson - não vende moto, vende liberdade;
  • Nike não vende tenis, vende motivação;
  • Red Bull Não vende energético, vende adrenalina.
  • Ferrari não vende carro, vende status.
• O sucesso profissional está surpreendentemente 85% ligado ao networking.
• O que preciso fazer para melhorar a liderança?
  • Quanto tempo você irá esperar para algo melhorar?
  • Qual o prazo?
  • O que precisa acontecer, para você sentir que mudou?
  • O que te leva a crer, por histórico, que isso irá mudar?
  • Lista de Comportamento Concreto e observável.
  • Quando vc não sabe reconhecer quando chega ou quando falta.
  • Não temos como localizar um CULPADO, nós inventamos uma estrutura, que é difícil mudar a direção de forma SIMPLES.
  • Novos anseios, mentalidade, novas visões que talvez faça sentido para a gente, pode NÃO fazer sentido para outros.
  • Infelizmente não temos respostas prontas..mas cabe a gente tomar uma decisão.
  • Hoje, seguro mais os meus anseios, mentalidade e novas visões, que talvez faça sentido para mim, mas pode NÃO fazer sentido para outros.

Criamos o conceito: Ilusão da Previsibilidade¶

• AVT (Análise de Viabilidade Técnica);
• AVE (Análise de Viabilidade Econômica);
• AVF (Análise de Viabilidade Financeira);
• NÃO sabemos, mas temos que ESTIMAR, ou melhor, dar o PRAZO ou META e depois a cobrança você se COMPROMETEU a este PRAZO.

Quando faz uma estimativa esta trabalhando com certo nível de incerteza, como:

• Experiência do time,
• Diversidade de níveis dos envolvidos na execução da atividade,
• Baixo nível de detalhamento do que será feito entre outros fatores provenientes da atividade.

Quais os fatores¶

• O fator principal de uma estimativa é ajudar a tomar uma decisão.
• O melhor jeito de fazer estimativas é pensar em intervalos e não cravar.
• É muito difícil acertar se os valores e respostas forem precisos.
• Um outro componente da estimativa é o nível de confiança, ele diz sobre a certeza de acerto da estimativa.
• Quanto maior o intervalo, maior a confiança que a estimativa tem, pela sua margem de confiança.
• A estimativa (é um cálculo que é feito a partir da avaliação estatística, geralmente realizado em uma amostra e não em todo o conjunto) de tamanho é composta por 3 componentes:

• Medida é um item de dado bruto que é medido diretamente, e que será utilizado para calcular uma métrica;
• Métrica é uma interpretação de uma medida que você utiliza para orientar o seu projeto.

Estimativas¶

Então se tem uma discrepância ali, uma diferença muito grande de opinião, as pessoas param e discutem: "espera lá, então é provável que o seu entendimento sobre essa funcionalidade tenha sido diferente do meu, vamos conversar".

No meu caso para: MELHORAR, ESTIMAR e PARA ENGENHEIRAR.

Estimativas (Esforço)¶

PRODUTOS NÃO SE ATRASAM. Eles levam o tempo que for necessário para serem concluídos. Nosso trabalho é definir o que está “feito” e revisar as estimativas com frequência.

• A estimativa é uma suposição com conhecimento parcial, mas somos tendenciosos a ver o que está lá e não o que está faltando.
• Fazemos estimativas com base nas informações que nos são disponibilizadas e ainda querem que acertemos.
• O fator principal de uma estimativa é ajudar a tomar uma decisão.
• O melhor jeito de fazer estimativas é pensar em intervalos.
• Baseia-se nas melhores informações disponíveis no momento.
• É um intervalo (ou distribuição de probabilidade), não um número. Se sua estimativa for um número, é uma meta.
• É muito difícil acertar se os valores e respostas forem precisos. Um outro componente da estimativa é o nível de confiança, ele diz sobre a certeza de acerto da estimativa.

Então, usaremos o ESFORÇO, contrariando o FRAMEWORK SCRUM (não são convertidas em horas, servindo somente para medir o esforço de cada história do usuário, já estimando suas tarefas técnicas), nossas estimativas serão realizadas em HORAS.

Estimativa em função do T-Shirt Sizing (Unidade Horas)¶

• No início do projeto, quando começamos a usar story points, a subjetividade é muito alta.
• Com a inclusão de mais critérios de pontuação,tais como:
  • Complexidade do Teste;
  • Dependência de pessoas que não fazem parte da equipe (internas ou externas);
  • Riscos relacionados aos PBIs;
• Diminuímos a variabilidade do lead time e aumentamos a taxa de entrega dos cartões dividindo o cartão em outros menores.
• Fazer o time pensar não só no desenvolvimento, mas também na duração do processo como um todo (considerando as etapas de revisão de código, testes, deploy, etc) e convidar mais pessoas para compartilhar suas preocupações sobre as ESTIMATIVAS, ajuda a melhorar a previsibilidade do time.
• Métodos de ESTIMATIVAS consideram apenas o momento em que uma demanda está sendo trabalhada, e não consideram/não podem prever o tempo que uma demanda ficará esperando para ser trabalhada.
• Pensando o quanto é difíficil estimar em PRODUTOS NOVOS, onde o grau da INCERTEZA é muito alto e o medo á GRANDE, elaboramos um QUADRO, para que possamos "ESTIMAR" em um primeiro momento com a EXPERIÊNCIA em PRODUTOS ANTERIORES nos MOTS.

Metodologia de Sprint de Design¶

A metodologia Design Sprint é um processo de cinco dias para testar ideias e resolver problemas complexos. O princípio por trás disso é simples: começar é mais importante do que estar certo.

Design Sprint Kit é um recurso de código aberto para líderes de design, proprietários de produtos, desenvolvedores ou qualquer pessoa que esteja aprendendo ou executando Design Sprints.

Planejar um Design Sprint¶

• Compreender: Crie uma base de conhecimento compartilhada em todos os participantes. Peça para cada especialistas em conhecimento realizar uma palestra CURTA, para articular o espaço do problema dos ângulos de negócios, usuários, concorrentes e tecnológicos.
• Defina:A equipe avalia tudo o que aprendeu na fase Compreender para estabelecer o foco.
• Esboço: Compartilhamento das ideias como indivíduos. Cada participante do Design Sprint gerará individualmente ideias para consideração. A partir daí, a equipe reduzirá as ideias como grupo a um único e bem articulado Solution Sketch por pessoa.
• Decidir: Cada participante compartilhará seu Esquete da Solução e a equipe encontrará consenso sobre uma única ideia por meio de exercícios de tomada de decisão.
• Protótipo: Você terá como objetivo criar um protótipo que seja real o suficiente para validar, e você vai fazê-lo muito rápido. como um experimento para testar uma hipótese. Não há necessidade de construir um back-end funcional completo ou resolver cada fluxo em seu produto.
• Validar: colocará seu conceito na frente dos usuários - este é o seu momento de verdade! Você coletará feedback de usuários que interagem com seu protótipo e, se for relevante, você realizará revisões de viabilidade técnica e de stakeholders.

Cronograma do Design Sprint¶

Nada é tão simples...¶

• Foi bem difícil fazer com que as pessoas estivessem online no tempo exato que precisávamos delas, a Internet falha.
• Convencer as pessoas a congelarem cinco dias da sua agenda para a dinâmica é um desafio à parte no processo de planejamento do seu sprint, principalmente se for a primeiro.
• Pense no espaço, reveja checklist para não faltar nada (post its, canetas, flipcharts, lanches), preparando câmera para filmar e tirar fotos.

SCRUM MASTER¶

O Scrum Master é o responsável por ajudar todos os envolvidos na equipe de projeto, ele facilita as interações e ensina os stakeholders a utilizar o Scrum. Ele utiliza os seus conhecimentos e técnicas para lidar com as pessoas e ajudar o Product Owner e a equipe de desenvolvimento a se tornarem mais eficientes no seu trabalho. Relacione o time de Scrum Masters, que você pode trabalhar.

Observação: Ao selecionar o Scrum Master troque o emoji de não selecionado (☑️) para o selecionado (✅).

Diferimento¶

Tipo de Projeto¶

DEVELOPER/FUNCIONAL¶

ERelacione os papéis de um Analista Funcional, que atua como intermediário entre as partes interessadas (stakeholders) e a equipe técnica, assegurando que os requisitos do negócio sejam bem compreendidos e implementados e um Developer, que é responsável por escrever, testar e manter o código de software. Eles transformam requisitos técnicos e funcionais em soluções programáticas.

ENTENDA O PROJETO¶

Além de entender o negócio, você precisa olhar para os Requisitos de Arquiteturais (RA) e os Variáveis Arquiteturais(VA).

Requisitos de Arquiteturais¶

O time deverá discutir o projeto, cada um seguindo a sua especialidade, arquitetura, riscos de segurança e automatização de teste.

Relacione os Product Owner/Manager e Stakeholders¶

Tipo de Servidores¶

Provedor Serviço em nuvem¶

Tipos de Serviços de Computação em nuvem¶

Tipo de Serviço¶

Ambientes Operativos¶

Controle de Atividades¶

Source Control Management¶

• Monolito

• Monorepo

Estratégias de Branch¶

Tecnologia Oracle¶

Generate REST APIs¶

Servidor de Aplicação¶

Front/Back¶

Low-Code Platform¶

Trace/Logs¶

Container¶

Gerenciadores de Banco de Dados¶

Documentação Produto¶

Documentação Técnica¶

Emulador¶

Framework¶

BPMS¶

Content Management System(CMS)¶

Containers¶

Framework de Teste Unitário¶

Code Coverage Tool¶

Framework de Teste¶

Framework de API/Contrato/Stress¶

Gerenciadores de Dependências¶

Maven Archtype¶

RPA¶

ETL/ELT/ELTT (Extract, Load, Transform, Transfer) Ferramentas¶

Exposição de Dados¶

Azure-Devops¶

Repository Management¶

Estratégia de Desenvolvimento¶

Escrita de Código¶

Convenções de Desenvolvimento¶

Preenchimento do Board/Timesheet¶

O lançamento de horas em um determinado projeto ou atividade, tem como finalidade melhorar a gestão de tempo ao registrar o tempo gasto para realizar determinada atividade. Utilizar o lançamento de horas traz mais transparência e precisão para a gestão de tempo, o que permite um melhor controle e monitoramento das atividades realizadas.

• Compreensão da rotina dos profissionais;
• Alocação eficiente da Equipe;
• Estimativa de Tempo médio para a realização de uma tarefa ou atividade;
• Maior assertividade nos prazos acordados;
• Melhorar a organização da equipe
• Ter suporte para o planejamento
• Tomar decisões baseadas em dados

Sugere-se que o lançamento de horas seja realizada de forma diária e com 10 minutos antes de suspender e/ou finalizar as atividades diárias.

Code Review¶

• Pratique revisões pequenas de código;
• Cultura de qualidade;
• Boa documentação na base de código para manutenção(PLDoc,JavaDoc,PHPDoc)
• Discutão soluções alternativas;
• Guia de forma colaborativa;
• Mantenha um cronograma de Code Review

Cultura,Automação,Lean,Medição e Sharing¶

Segurança¶

Autenticação¶

• Não use Basic Auth. Use padrões de autenticação (exemplo: JWT, OAuth).
• Implemente funcionalidades de limite (Max Retry) e bloqueio de tentativas de autenticação.
• Limite as tentativas de , e Login APIs Verify One Time Password(OTP) para um usuário específico. Tenha um conjunto de espera exponencial ou/ou algo como um desafio baseado em captcha.
• Use criptografia em todos os dados confidenciais.

JWT (JSON Web Token)¶

• Use uma chave JWT Secret para tornar ataques de força bruta menos eficientes.
• Não utilize o algoritmo de criptografia informado no cabeçalho do payload. Force o uso de um algoritmo específico no back-end (HS256 ou RS256).
• Defina o tempo de vida do token (TTL, RTTL) o menor possível.
• Não armazene informações confidenciais no JWT, pois elas podem ser facilmente decodificadas.
• Evite armazenar muitos dados.

Acesso¶

• Limite a quantidade de requisições (Throttling) para evitar ataques DDoS e de força bruta.
• Use HTTPS no seu servidor para evitar ataques MITM (Man In The Middle Attack).
• Use cabeçalho HTTP Strict Transport Security (HSTS) com SSL para evitar ataques SSL Strip.
• Para APIs privadas, permita o acesso apenas de IPs/hosts da whitelist.

Requisição¶

• Utilize o método HTTP apropriado para cada operação, GET (obter), POST (criar), PUT(atualizar) e DELETE (apagar). Não esqueça as operações no e-BS.
• Valide o tipo de conteúdo informado no cabeçalho Accept da requisição (Content Negotiation) para permitir apenas os formatos suportados pela sua API (ex. application/xml, application/json ... etc), respondendo com o status 406 Not Acceptable se ele não for suportado.
• Valide o tipo de conteúdo do conteúdo da requisição informado no cabeçalho Content-Type da requisição para permitir apenas os formatos suportados pela sua API (ex. application/x-www-form-urlencoded, multipart/form-data, application/json e etc).
• Valide o conteúdo da requisição para evitar as vulnerabilidades mais comuns (ex. XSS, SQL-Injection, Remote Code Execution ... etc).
• Não utilize nenhuma informação sensível (credenciais, senhas, tokens de autenticação) na URL. Use o cabeçalho Authorization da requisição.
• Use apenas criptografia do lado do servidor.
• Use um serviço gateway para a sua API para habilitar cache, limitar acessos sucessivos (ex. por quantidade máxima permitida (Quota), por limitar tráfego em situações de estresse (spike arrest) ou por limitar o número de conexões simultâneas na sua API (Concurrent Rate Limit)), e facilitar o deploy de novas funcionalidades.

Processamento¶

• Verifique continuamente os endpoints protegidos por autenticação para evitar falhas na proteção de acesso aos dados.
• Não utilize ID's incrementais. Use UUID.
• Se você estiver processando arquivos XML, verifique que entity parsing não está ativada para evitar ataques de XML externo (XXE - XML external entity attack).
• Se você estiver processando arquivos XML, verifique que entity expansion não está ativada para evitar Billion Laughs/XML bomb através de ataques exponenciais de expansão de XML.
• Use Content Delivery Network(CDN) para uploads de arquivos, arquivos estáticos como fotos e vídeos para aplicações de modo mais rápido e eficiente.
• Se você estiver trabalhando com uma grande quantidade de dados, use workers e queues (fila de processos) para retornar uma resposta rapidamente e evitar o bloqueio de requisições HTTP.
• Não se esqueça de desativar o modo de depuração (DEBUG mode OFF).
• Use stacks não executáveis quando disponíveis.

Resposta¶

• Envie o cabeçalho X-Content-Type-Options: nosniff, onde o navegador é instruído a não tentar adivinhar o tipo de conteúdo do arquivo e deve seguir estritamente o tipo de conteúdo fornecido pelo servidor.
• Envie o cabeçalho X-Frame-Options: deny, impossibilitando que outros sites renderizem em um iframe.
• Envie o cabeçalho Content-Security-Policy: default-src 'none'.

  <meta>http-equiv="Content-Security-Policy"content="default-src 'self'; img-src https://*; child-src 'none';" />
  

• Remova os cabeçalhos de identificação dos softwares do servidor - X-Powered-By, Server, X-AspNet-Version.
• Envie um cabeçalho Content-Type na sua resposta com o valor apropriado (ex. se você retorna um JSON, então envie um Content-Type: application/json).
• Não retorne dados sensíveis como senhas, credenciais e tokens de autenticação.
• Utilize o código de resposta apropriado para cada operação. Ex. 200 OK (respondido com sucesso), 201 Created (novo recurso criado), 400 Bad Request (requisição inválida), 401 Unauthorized (não autenticado), 405 Method Not Allowed (método HTTP não permitido) ... etc.

CI & CD¶

• Monitore a especificação e implementação do escopo da sua API através de testes unitários e de integração.
• Use um processo de revisão de código, escolha o mais experiente para code review;
• Execute continuamente testes de segurança (análise estática/dinâmica) em seu código.
• Verifique suas dependências (software e sistema operacional) para vulnerabilidades conhecidas.
• Implemente funcionalidade de reversão de deploy (rollback).

Criação do Projeto¶

Esta rotina deverá ser executada em ambiente Linux/MacOS e deverá possuir os seguintes softwares instalados:

Ajustes no Azure-Devops¶

• Após a criação do PROJETO e/ou TIMES, há a necessidade em se IGUALAR os BOARDS.
• Acesse o Board do Time e efetue as seguintes alterações, em Boards → Columns:

• Limitar a WIP ao número de desenvovedores do PRODUTO;
• Ajuste Swimlanes
• Bug -

  Vermelho

• Demanda Expressa -

  Verde

• Projeto

• Boards → Configuração → Fields → Product Backlog → Additional Fields → Add Field → iSBlocked

Dashboard Team¶

Ajustes no Github¶

Pipeline - DevSecops¶

Teams (WebHook)¶

Registrar Produto¶

Gerenciamento da Identidade e Acesso¶

Provedor de Identidade (IdP)¶

Desevolvimento¶

Validação de Campos Utilizando Expressões Regulares¶

RegEx ou RegExp são usadas para englobar um padrão de caracteres usando alguns caracteres especiais.

Associe a validação do RegEx a um código de erro e grave o erro na tabela de mensagens, na lingua desejada.

Mensagens Padronizadas¶

• Mensagens serão divididas em n grupos:
  • Códigos de Status HTTP
  • Mensagens da Aplicação

Apresentação dos Membros do Projeto Autodescrição¶

Pré-Produção¶

Métricas¶

Definição das Métricas¶

Front-End: Core Web Vitals (Google)¶

Métricas de Dados¶

Métricas para Desempenho do Banco de Dados¶

A observabilidade do banco de dados também se estende ao desempenho do próprio banco de dados incluir:

Métricas para segurança de Banco de Dados¶

As medições de observabilidade do banco de dados podem colocar em foco a segurança e a conformidade do banco de dados, elevando o nível de segurança dos dados.

Documentação¶

Catálogo de Serviços¶

• Registrar a Aplicação no Catálogo de Sistemas Internos;
• Associar demanda do Catálogo de Sistemas Internos ao Projeto;
• Elaborado plano junto a area de segurança para realização/revogação de acesso;
• Elaborado documentação para Equipe de N1.

Segurança¶

Lei Geral de Proteção de Dados Pessoais (LGPD) e Acesso¶

Realização de OPT-In e OPT-Out para a Segurança?

API Security¶

• Testes de segurança - API(csaf report);

Application Performance Management/Monitoramento¶

Periodicidade de Clonagem¶

Complemente a Leitura¶

Modelo Base¶

A metodologia doze-fatores pode ser aplicada a aplicações escritas em qualquer linguagem de programação, e que utilizem qualquer combinação de serviços de suportes (banco de dados, filas, cache de memória, etc). Os contribuidores deste documento, possuem experiencia em desenvolvimento, operação através do seu trabalho na plataforma Heroku.

The Twelve Factors ou Fourteen Factors(*)¶

• Obviamente o 14 fatores NÃO existem no mercado, mas estava trabalhando para tal.
• Podíamos ter utilizado a suite SharePoint, OneDrive,Power Apps e Microsoft Forms, mas optei em utilizar um Static Site Generatir - MkDocs e fazer tudo como se fosse código.

Arquitetura Proposta¶

Já se foi o tempo em que todos os serviços eram gerenciados a partir de um único servidor ou local. Estamos vivendo a era de poder criar software em uma ampla rede de máquinas e software gerenciado por sua própria equipe ou por serviços externos. Este blueprint de serviços tecnológicos, permite a visualização, das relações entre diferentes componentes de software/hardware, estabelecendo caminhos a serem seguidos para a melhoria do atendimento e garantia da segurança.

Centralização de Logs¶

Configuração de Logs

Arquitetura Proposta Nomenclaturas¶

Projetos¶

Um projeto é um “esforço temporário empreendido para criar um produto, serviço ou resultado único” em uma organização. No entanto, para ser verdadeiramente competitiva, uma organização precisa ser capaz de fornecer um fluxo contínuo de mudanças. A estrutura define explicitamente um fim: um ponto em que o projeto será concluído.

Em vez disso, deve ser entendido que cada PRODUTO se destina a alcançar um ou mais resultados de negócios e, para isso, deve mudar e melhorar continuamente.

Padronize-se no Estilo hipster:

• Contribuição e Estilos
• Código de Conduta

Command Query Responsibility Segregation¶

É um padrão de arquitetura de software que propõe separar as operações de leitura (queries) das operações de escrita (commands).

• Responsibility Segregation (Segregação de Responsabilidades): Refere-se à ideia de que diferentes partes do sistema têm responsabilidades diferentes.
• Command (Comando): Representa uma ação que causa uma mudança de estado no sistema.Os comandos são usados para operações de escrita, como criar, atualizar ou excluir recursos.
• Query (Consulta): Representa uma solicitação de informações do sistema. As consultas são usadas para operações de leitura, como recuperar dados ou realizar operações de busca.

Oracle REST Data Services¶

É um serviço de dados baseado em Java Enterprise Edition (Java EE) que fornece segurança aprimorada, recursos de cache de arquivos e serviços Web RESTful, no caso da 60pportunities, optou-se na implantação com o uso de servidores Apache Tomcat.

Volumes Docker¶

Volumes persistentes no Docker são uma maneira de manter os dados dos containers mesmo após o container ser desligado ou excluído. Isso é especialmente útil para aplicações que precisam armazenar dados ou configurações que devem persistir entre diferentes execuções do container.

Estratégias de Branch¶

Consulte Material - Registro de Arquitetura Estratégia de Branch.

NÃO deixe de ler o material de Vincent Driessen sobre o modelo de ramificação git-flow, apresentada em sua publicação em 2010 e released em 2020.

Os aplicativos da Web normalmente são entregues continuamente, não são revertidos e você não precisa oferecer suporte a várias versões do software em execução.
Esta não é a classe de software que eu tinha em mente quando escrevi a postagem no blog há 10 anos. Se sua equipe estiver fazendo entrega contínua de software, sugiro adotar um fluxo de trabalho muito mais simples (como GitHub flow ) em vez de tentar encaixar o git-flow em sua equipe.

Diretório Pipeline¶

Quando se trata de organizar a estrutura de pipelines em um projeto, é importante manter uma organização clara e coerente que facilite a compreensão, manutenção e execução dos pipelines. Dentro de cada diretório de pipeline, há um arquivo pipeline.yml que descreve os passos e etapas a serem executados no pipeline correspondente. Além disso, pode haver outros arquivos ou diretórios conforme necessário para armazenar recursos ou configurações relacionadas a cada tipo específico de pipeline.

Documentos as Code¶

É uma abordagem na qual a documentação do projeto é tratada e gerenciada como código-fonte. Estruture o documento seguindo o modelo PORTIFÓLIO.

• Versionamento: A documentação é versionada e mantida EM um sistema de controle de versão, permitindo rastrear alterações, revisar históricos e identificar facilmente quem fez cada alteração.
• Colaboração: As mesmas práticas de colaboração e revisão de código podem ser aplicadas à documentação.
• Automatização: Ferramentas de automação podem ser usadas para gerar documentação a partir do código-fonte ou para atualizar automaticamente a documentação conforme o código é alterado.
• Testabilidade: A documentação DEVE SER parte do processo de integração contínua (CI).
• Implantação Contínua: A documentação DEVE SER implantada automaticamente em um ambiente de produção ou em um sistema de publicação sempre que houver alterações.

• Garante com isso Maior Consistência, Transparência, Facilidade de Manutenção, Melhor Colaboração, Agilidade e Redução de Erros.
• O projeto 60OPT_ADMISTRAÇÃO, possui um monorepo POROTIFÓLIO, e um diretório para cada documentação de PRODUTO, tornando o gerenciamento muito mais fácil.
• No repositório PORTIFOLIO, use o diretório documentacao e crie uma entrada utilizando o submodule, para cada produto a ser documentado.
• Caso o produto seja novo, ajuste o arquivo de DOCUMENTAÇÃO - mkdocs.yml, para incluir o seu submodule.

• Adicionando um repositório a Documentação, ao repositório 60OPT ADMINISTRAÇÃO no repositório PORTIFOLIO.

  • git submodule deinit --force backstage (excluir um submódulo Git)
  • git rm --force backstage (Remove the submodule directory from Git)
  • rm -rf .git/modules/backstage (Remove the submodule directory from .git/modules/)
  • git submodule add --name backstage https://github.com/P0010/mkdocs.yml.git backstage (Adiciono o submodulo)
  • Alterando o mkdocs.yml, para inclusão da Documentação
  • Vá até a entrada nav e procure o seu sistema.
  • '!include ./documentacao/APLICACAO/mkdocs.yml' 60opt-documento-produto

Estrutura padrão¶

Seguir o nodelo Nomenclatura de Repositórios de documentação - PRODUTO - FINALIDADE - ESTRUTURA. Verifique e ajuste o modelo de PORTIFÓLIO para a sua necessidade EXEMPLO.

 mkdocs-project/        Local do projeto onde estão todos os arquivos MkDocs.
      mkdocs.yml           Arquivo de configuração do Mkdocs.
      docs/                Pasta onde existem Markdown e outros arquivos de conteúdo.
        *.md               Arquivos em Markdown
        img/               Pasta contendo arquivos de imagens
          *.regex          Arquivos `^[^\s]+\.(jpg|jpeg|png|gif|bmp)$`
        objetos/           Pasta contendo o javadoc, godoc, plsqldoc ou phpdoc
          *.html           Arquivos gerados normalmente em html
        unitest            Pasta contendo informações sobre o resultado dos Testes Unitários  
        moldb              Modelo de Dados
          *.html           Arquivos gerados normalmente em html
        allure             Arquivos de Testes
          *.html           Arquivos gerados normalmente em html    
        swagger            Pasta contendo os arquivos json Openapi
          *.json           Arquivos extraídos do ORDS ou gerados pelo editor swagger
          index.md         Arquivo contendo uma página com as entradas dos JSON.  
      site/                Pasta criada automaticamente pelo software MkDocs, quando build.
        index.html         Página de destino padrão para site estático.
        muitos outros arquivos Cada markdown virará uma pasta

• Exemplo de criação:

  .
  ├── README.md
  ├── docs
  │   ├── allure
  │   │   └── .gitkeep
  │   ├── img
  │   │   ├── .gitkeep
  │   │   ├── favicon.ico
  │   │   ├── how-it-works.png
  │   │   └── logo.jpg
  │   ├── index.md
  │   ├── moldb
  │   │   └── .gitkeep
  │   ├── objetos
  │   │   └── .gitkeep
  │   ├── swagger
  │   │   └── .gitkeep
  │   ├── unitest
  │   │   └── .gitkeep
  │   └── versions.json
  └── mkdocs.yml
  

• git remote remove origin

• git remote add origin <remote-repo-url>
• git pull <remote-repo-url> main
• git commit --amend
• git push -u origin main

Projetos MOTS¶

É um repositório de controle de versão que contém vários projetos, aplicativos ou componentes relacionados em um único repositório. Para aplicativos MOTS (Many Off-The-Shelf), que são aplicativos prontos para uso, há vários exemplos de produtos que adotam essa abordagem.

Temos tido muitas integrações de produtos internos ou outros ERPs, o que nos leva a pensar ONDE deixar o objeto, logo, podemos sempre deixar no PROJETO do MOTS, para tal há a necessidade em se trabalhar com submodules do git.

A utilização de submódulos, no git, faz-se necessária quando está delegando uma parte do projeto/produto a outro produto e deseja integrar o trabalho deles em um momento ou lançamento específico.

• Publique a alteração do submódulo antes de publicar a alteração no superprojeto que faz referência.
• Lembre-se de confirmar todas as suas alterações antes de executar,git submodule update.

Projetos Internos¶

Para sistemas internos, desenvolvidos internamente são cruciais ter um processo bem definido para garantir a eficiência, qualidade e segurança do desenvolvimento e implantação de software.

Keycloack¶

Uma solução de Identity and Access Management (IAM) de código aberto que oferece uma série de benefícios e justificações para sua utilização em projetos de software.

• IAM (Identity and Access Management):
  • Refere a um conjunto de políticas, processos e tecnologias utilizadas para gerenciar e controlar identidades de usuários, bem como suas permissões de acesso a sistemas, aplicativos e recursos.
• IDM (Identity Management):
  • Subcategoria do IAM e se concentra especificamente na gestão de identidades de usuários em sistemas de TI. Envolve o gerenciamento de informações sobre usuários, incluindo seus atributos, credenciais de autenticação, permissões e outros dados relacionados.

Arquétipos Maven¶

São templates de projetos que possibilitam iniciar o desenvolvimento de novos projetos de forma padronizada. É uma poderosa ferramenta de gerenciamento de construção para projetos para ajudar a executar uma estrutura de ciclo de vida de construção. A base do Maven é o conceito de POM (Project Object Model) em que todas as configurações podem ser feitas com a ajuda de um arquivo `pom.xml`.

Efetue a instalação do maven, você NÃO precisa abrir chamado para efetuar a instalação do maven. A instalação do Apache Maven é um processo simples de extrair o arquivo e adicionar o bin diretório com o mvn comando ao arquivo PATH.

Maven Wrapper¶

O Maven Wrapper garante que nosso projeto tenha tudo o que é necessário para executar a construção do Maven, instalando e gerenciando automaticamente uma versão específica do Maven. Por exemplo, se enviarmos um projeto Maven para o GitHub que desenvolvemos usando o Maven versão 3.9.6 e outra pessoa tentar construí-lo localmente usando uma versão mais antiga como 3.7, a compilação poderá falhar. O Maven Wrapper baixa e instala automaticamente a versão correta do Maven, se necessário, garantindo que o projeto use a versão correta do Maven, independentemente da instalação local do Maven.

Gerar arquivos Maven Wrapper¶

• Certifique-se de que nosso sistema instalou o Maven. Podemos verificar isso executando: mvn --version
• Navegue até o diretório raiz do projeto Maven: cd repositorio\PRODUTO
• Execute o seguinte comando para gerar arquivos Maven Wrapper. mvn wrapper:wrapper
• Agora, em vez de usar mvn para construir o projeto, podemos usar ./mvnw (no Linux ou macOS) ou mvnw.cmd(no Windows) para construir o projeto.
• O comando gerará os arquivos mvnw, mvnw.cmd e .mvn/wrapper/maven-wrapper.jar e .mvn/wrapper/maven-wrapper.properties no diretório do projeto.

Repositório local Maven¶

É o local onde o Maven armazena todos os arquivos jars do projeto, bibliotecas ou dependências. Por padrão, o nome da pasta é '.m2'

Repositório Central Maven¶

O repositório central do Maven é o local padrão 'http://artifacty.com/' para o Maven baixar todas as bibliotecas de dependência do projeto. Para qualquer biblioteca necessária no projeto, o Maven primeiro procura na pasta .m2 do Repositório Local; se não encontrar a biblioteca necessária, procura no Repositório Central e baixa a biblioteca no repositório local.

As etapas detalhadas são: Tenha uma instalação do JDK em seu sistema. Defina a JAVA_HOME variável de ambiente apontando para a instalação do JDK ou tenha o java executável no seu arquivo PATH.

• Extraia o arquivo de distribuição em qualquer diretório.
• Instale o arquétipo: 60opt-archtype-plsql, através do comando mvn clean install.

$ mvn -B archetype:generate -DarchetypeGroupId=br.com.60pportunities.archetypes -DarchetypeArtifactId=60opt-archetype-plsql -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=br.com.60pportunities -DartifactId=exemploplsql
$ mvn wrapper:wrapper

Ciclo de Vida¶

O ciclo de vida é uma sequência predefinida de fases que guiam o build de um projeto por meio da execução de objetivos.

Instalação do Liquibase¶

Liquibase pode ser usado como uma ferramenta de linha de comando executada em macOS, Windows, Unix e Linux. Use a CLI do Liquibase para migrar seu banco de dados da linha de comando sem precisar integrar o Liquibase ao seu aplicativo ou instalar uma ferramenta de construção.

• Baixe e execute o instalador apropriado.
• Certifique-se de adicionar Liquibase ao seu PATH.

Camada de Persistência¶

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

Vertical Slice Architecture¶

A Vertical Slice Architecture nasceu da dor de trabalhar com Arquiteturas em Camadas. A Vertical Slice Architecture, por outro lado, organiza o código em torno de recursos ou casos de uso. Cada fatia representa uma funcionalidade especifica do projeto. E dentro de cada fatia cabe ao desenvolvedor definir qual caminho seguir para efetuar o comportamento dessa funcionalidade, ou seja, não é necessário encaixar cada pedaço do sistema dentro de uma estrutura rígida de camadas na hora de desenvolver. Portanto cada pedaço é desenvolvido de forma isolada seguindo seu próprio estilo de implementação.

Um recurso é um caso de uso de um problema que você está tentando resolver. Com a Vertical Slice Architecture,você organiza seu código em um recurso em vez de camadas. Isso significa que você pegará todas as questões técnicas relacionadas a um recurso e organizará esse código em conjunto. Concentre-se na organização pelos recursos e capacidades do seu sistema.

Ao fazer isso, você está lidando com o acoplamento de uma maneira diferente, porque as fatias são, em sua maior parte, independentes.

Em fatias verticais, cada fatia pode ter seu próprio método de acesso a dados em um armazenamento de dados. Uma fatia poderia usar micro-ORMs, enquanto outra poderia usar um ORM completo e outra poderia usar uma API externa. Você pode acabar com a duplicação de código e está tudo bem. Este é o preço a pagar pela autocontenção e pelo acoplamento frouxo com fatias verticais.

Monitoramento de Aplicação/Experiência do Usuário¶

É fundamental para monitorar e otimizar o desempenho de aplicações em produção. Monitoramento de contêineres, orquestradores, bancos de dados, cache e sistemas de armazenamento para garantir que estejam funcionando corretamente para garantir que os aplicativos estejam sendo executados corretamente e escalados conforme necessário.

Pipeline 60OPT¶

Build Artifacts x Pipeline Artifacts x Azure Artifacts¶

Os artefatos são criados para quase todos os processos de desenvolvimento de software , incluindo codificação, configuração, compilação, testes automatizados, arquivamento, empacotamento, documentação, requisitos mínimos viáveis de produto e etc.

Também posso restringir o artefato, como sendo qualquer tipo de arquivo que sua construção produz, ou que você pode querer reutilizar em outra construção, outro trabalho de sua construção ou um pipeline de implantação ou lançamento.

No Azure DevOps, os artefatos podem ser subdivididos em três categorias principais: Build Artifacts x Pipeline Artifacts x Azure Artifacts.

Build Artifacts¶

Os artefatos de construção são publicados por meio da tarefa Publish Build Artifacts e podem ser baixados com a tarefa Download Build Artifact. Os artefatos de construção podem ser consumidos de outros trabalhos no mesmo pipeline e de outros pipelines. Build Pipelines pode ser usado se você quiser consumir seu artefato de um Release Pipeline acionado pela conclusão da construção. Isso pode incluir arquivos executáveis, arquivos .dll, modelos de dados, bibliotecas ou arquivos de banco de dados. aqui estão alguns exemplos:

• Casos de teste, suítes de teste, relatórios de teste, Microsserviços, Código compilado.

Pipeline Artifacts¶

Estas são a versão mais recente , por assim dizer, do Build Artifacts e, como tal, podem ser usadas apenas nos pipelines YAML. Um dos principais benefícios dos artefatos de pipeline é que eles podem reduzir drasticamente o tempo necessário para fazer upload e download dos artefatos devido à forma como os arquivos são carregados e armazenados.

Para publicar os artefatos de pipelines, você pode usar a tarefa Publish Pipeline Artifact baixá-los usando a tarefa Download Pipeline Artifact.

Build vs Pipeline Artifacts¶

Os artefatos Build e Pipeline são muito genéricos, você pode salvar o que quiser neles, e o que o Azure DevOps faz é apenas empacotar os arquivos em um arquivo zip e salvá-lo em algum lugar.

Azure Artifacts¶

É mais um serviço de software específico do que uma categoria de artefato, mas vale a pena mencioná-lo aqui devido ao seu lugar no cenário do Azure DevOps. Azure Artifacts é um serviço pago para repositórios de artefatos superiores a 2 GB.

É um repositório onde ele suporta vários tipos de pacotes, como NuGet, npm, Python, Maven e etc. você pode basicamente vê-lo como uma alternativa ao Artifactory, Nexus e pacotes GitHub.

• Preço

Outra grande diferença é quanto ao preço. Quer você use Build Artifacts ou Pipeline Artifacts, você não terá que pagar um único centavo por eles, não importa quantos arquivos você armazene ou quão grandes eles sejam. Os Artefatos do Azure, por outro lado, são cobrados por tamanho.

• Build Artifacts somente se estiver usando Build Pipelines Clássicos.
• Pipelines Artifacts se você estiver em YAML Pipelines e não precisar compartilhar o resultado do seu CI com outras equipes.
• Artefatos do Azure se precisar compartilhar pacotes dentro da mesma equipe, entre organizações ou até mesmo publicamente.

Repositório de Artefatos¶

Mantém todos os artefatos seguros e com controle de versão. As ferramentas de construção ajudam a gerenciar dependências e outros artefatos compilados. Essas ferramentas fornecem uma fonte única de pacotes, gráficos Helm, imagens de contêiner e outros artefatos para integração perfeita com ferramentas de CI/CD e avanço no ciclo de vida de desenvolvimento de software.

Observabilidade¶

Refere-se a ferramentas de software e práticas para agregar, correlacionar e analisar um fluxo contínuo de dados de desempenho de uma aplicação distribuída, juntamente com o hardware e a rede em que ela opera permitindo monitorar, depurar e solucionar problemas na aplicação ou comportamento do mesmo.

• Monitoramento

Capacitando a melhor Análise de Negócios com Inteligencia Artificial¶

Imagine que quase tudo o que você faz é auxiliado por um agente/assistente de IA? Uma ferramenta de IA treinada para ser um Business Analysis ou treinada especificamente para ser um Business Analysis da sua organização?

Estamos vendo inúmeros prompts que escrevem histórias de usuários e critérios de aceitação, tomarem e analisarem notas de reuniões e muito mais!

Agora, e se tudo isso estivesse em um "agente" e você não precisasse "solicitar" isso.

Isso já está acontecendo e evoluirá rapidamente nas próximas semanas/meses. Algumas maneiras pelas quais isso está acontecendo:

• GPTs personalizados (públicos ou privados);
• Ferramentas do fornecedor (requisitos, modelos, análises e muito mais baseados em IA);
• Ferramentas de automação SDLC;
• E, mais por vir, tenho certeza.x`

E, BAs que são bem treinados nas habilidades, técnicas e habilidades de pensamento crítico corretas de BA usarão essas ferramentas e terão um desempenho dramaticamente melhor do que aqueles sem habilidades de BA em técnicas de BA, mentalidade e outras habilidades críticas de BA.

✅ Define o problema a ser resolvido e para quem estamos resolvendo antes de qualquer trabalho técnico ser definido. BAs ocupados definem os detalhes técnicos das soluções solicitadas, muitas vezes causando retrabalho.

✅ Obtém 100x o trabalho feito no valor entregue sobre o trabalho real que está sendo feito. Eles se concentram no valor em vez de fazer o trabalho de "requisitos", documentos concluídos e detalhes definidos. Dica... a maioria dos documentos e detalhes na verdade não precisa ser feita e não agrega valor. Nosso trabalho como BA é descobrir isso. BAs ocupados fazem tudo o que todos pedem deles, e é muito, mas agrega pouco valor.

✅ Use o tempo dos stakeholders de forma tão eficiente que eles estejam implorando por mais tempo dos BAs! Eles demonstram seu valor com a forma como criam conversas com os stakeholders, mostrando que há muito mais para falar, sem contar isso aos stakeholders. Um BA ocupado sempre sente que precisa de mais tempo dos stakeholders e normalmente não está realmente usando seu tempo de forma eficaz, na maioria das vezes está duplicando conversas que os stakeholders já tiveram com outros.

✅ Cria e reutiliza modelos visuais e outros artefatos para inspirar análises em si mesmos e nos outros. Essa análise é onde as lacunas nos requisitos são realmente encontradas. Um BA ocupado cria novos para cada projeto e os trata como entregas versus ativos usados ​​continuamente.

Gamificação¶

O objetivo é aumentar o engajamento, a motivação, bem como, a participação dos usuários. Este conceito envolve a utilização de pontuações, níveis, recompensas e desafios, para transformar atividades comuns em experiências mais interativas e divertidas.

• Kahoot!: Plataforma permite criar quizzes gamificados que engajam pessoas em tempo real. Util para perguntas e respostas, tornando o aprendizado mais atraente, pois incentiva a participação ativa. Ajuda no desenvolvimento de habilidades, como trabalho em equipe e resolução de problemas, e com isso melhorando o engajamento dos funcionários, aumentando a produtividade e promovendo uma cultura organizacional positiva.
• KARMA: É uma ferramenta que gamifica o gerenciamento de tarefas, recompensando os usuários com pontos à medida que completam tarefas.

Sugestão de Calendário¶

Calendários dos Projetos(Sugestão)¶