Azure-Devops - Ideia Original

As Equipes de Desenvolvimento, NÃO acolheram o modelo apresentado em 2014. Cada Equipe desenvolveu o seu próprio processo e a utilizaram de inúmeras ferramentas:

A Equipe do Rio de Janeiro, passou a adotar o Supravizio como ferramenta - ITSM e DEMANDAS, tendo para cada tipo de item, um fluxo diferenciado. Os fluxos na maioria das vezes, estava desassociado do processo de desenvolvimento de software.

Observação: O processo de diferimento de software é uma estratégia frequentemente adotada por equipes de desenvolvimento para adiar ou postergar a implementação de certas funcionalidades ou melhorias em software. Este processo pode ser aplicado tanto em projetos de longo prazo quanto em demandas expressas (geralmente solicitadas por clientes ou usuários internos de forma mais imediata).

Controle de Processo GitHub¶

A estrutura de Organização no GitHub é menos hierárquica, mas permite gerenciar múltiplos repositórios com configurações e permissões centralizadas:

• Organização: É uma conta compartilhada que permite gerenciar repositórios e permissões em um único lugar.
• Repositórios: Representam os projetos de código dentro da organização, podendo ser atribuídos a uma ou mais equipes, cada uma com suas permissões.

Controle de Processo GitLab¶

A estrutura de Grupos e Subgrupos no GitLab é hierárquica e organiza os projetos de forma aninhada:

• Grupo: É o nível mais alto da hierarquia. Agrupa projetos relacionados e permite gerenciar permissões e configurações compartilhadas entre eles.
• Subgrupos: São grupos dentro de um grupo principal. Servem para organizar melhor projetos complexos, dividindo-os por áreas, equipes ou módulos específicos.
• Projetos: Ficam dentro dos grupos ou subgrupos. Representam o repositório de código e incluem todas as ferramentas de desenvolvimento, como issues, merge requests e CI/CD pipelines.

Migração para Azure-Devops¶

A migração do GitLab para o Azure DevOps foi uma decisão estratégica tomada com base em diversos fatores que visam melhorar a eficiência, integração e escalabilidade dos nossos processos de desenvolvimento.

Gerenciamento de Projetos e Work Items¶

O Azure DevOps possui uma abordagem poderosa e intuitiva para o gerenciamento de projetos, com funcionalidades como boards, sprints, e acompanhamento de work items. A integração dos boards com as funcionalidades de controle de versões e pipelines permite que as equipes acompanhem o progresso de forma mais precisa e transparente. Além disso, os work items podem ser facilmente ligados a commits, builds e releases, proporcionando uma visão unificada do ciclo de vida do desenvolvimento.

• O que seriam épicos e features, no conceita da Empresa?
• Temos Product Manager, Owner ou Usuário Chave?
• Tínhamos a cultura, ou seria, melhor começar de PBI, Bug, Task, Spike?
  • Como efetuar uma Hierarquia e tornar um Produto único, documentado e transparente?
  • As Wits poderiam ser EXCLUÍDAS?
  • Quais os campos obrigatórios ou opcionais?
• Trabalhamos bem com o Git, SVN ou só colocamos porque é conveniente?
• Como anda o nosso processo de Documentação onde elas estão? Consigo pegar de forma coorporativa?
• Tínhamos um SQUAD?
• Como incluir as métricas de fluxo (Kanban) e eficiência (DORA Metrics) para uma equipe que mudava constantemente de ferramentas?
  • Métricas de Fluxo (ex: Kanban) medem como as tarefas se movem através de um sistema, com ênfase no tempo de entrega e na capacidade de conclusão.
  • Métricas de Eficiência (ex: DORA Metrics) medem a capacidade de uma equipe de entregar de maneira rápida e confiável, com foco em resultados de produção e manutenção.
• OnBoarding vs OffBoarding:
  • Como garantir que os novos sejam produtivos, engajados e conectados.
  • Como garantir que não perdessemos produtividade com por exemplo, o término de contrato de terceiros? Saída por cessão?

Integração e Ecossistema Microsoft¶

O Azure DevOps oferece uma integração nativa com outras ferramentas do ecossistema Microsoft, como o Teams, Power BI e Office 365.

Segurança e Governança¶

O Azure DevOps possui fortes controles de segurança e governança, incluindo autenticação multifatorial (MFA), integrações com Azure Active Directory (AAD), e opções avançadas de controle de permissões.

Custo¶

Embora o GitLab ofereça uma solução de código aberto com boas funcionalidades, o Azure DevOps se destaca por seu modelo de preços competitivo e escalável, permitindo ajustar os custos conforme o uso.

Problemas vistos¶

• Não tínhamos conhecimento no Azure-Devops;
• Não sabíamos como efetuar alteração e adicionar campos que eram necessários para atender a unificação das Demandas (Projetos, Demanda Expressa e Bugs);
• Havíamos automatizado a criação de Projetos no GitLab e voltávamos para o Manual no Azure-Devops;
• Como poderíamos controlar as horas em um determinado PROJETO, sendo que a maioria dos projetos são de INTEGRAÇÃO.
  • Environment Management (Gestão dos ambientes);
  • Incident Managment (Gestão de Incidentes);
  • Disaster Recovery (Recuperação de desastres);
  • Reliability Driven Development (Desenvolvimento guiado pela confiabilidade);
  • Informative Workspace (Ambiente Informativo): Documentação gerada automaticamente pelo código com um processo de Tech Writer organizado;
  • Isolated Environments (Ambientes isolados): O time de produto dispor de ambientes para validação, desenvolvimento e Sandbox para equipes explorarem os contratos e SLA sobre as APIs;
• Iniciamos com o processo xxxx-lab Scrum e desenvolvemos o xxxxπdev_Scrum;
• Como fazer o processo de Deploy, sendo que a maioria dos desenvolvimentos eram legados e dificilmente entrariam em uma esteira DevSecOps;

Produtividade¶

Refere-se a eficiência e eficácia com que time consegue entregar software de qualidade, atingindo os requisitos e prazos, utilizando de forma eficaz os recursos disponíveis, como tempo, ferramentas, tecnologias e conhecimento, estando relacionada à capacidade de produzir código de alta qualidade e entregar funcionalidades ou produtos de software de forma rápida e eficiente, minimizando desperdícios.

• Onde estão os grandes ladrões de ineficiência?
• Onde o processo parou?
  • Parou em requisitos?
  • Parou em codificação?
  • Parou em Teste de Aceitação?
• Explicite o seu fluxo de trabalho;
• A única maneira de controlar um projeto grande e de agenda apertada é tendo uma agenda.Defina milestones, datas, prioridades.
• Mítico Homem-mês: Ensaios Sobre Engenharia de Software;
  • Conhecer as dificuldades inerentes ao trabalho torna mais fácil suportá-las quando elas surgirem;
  • Projeto de software depende de pessoas;
  • Não se pode dimensionar um software em termos de homem-mês; A adição de mais força de trabalho não implica na redução do tempo de entrega daquela tarefa;
• Melhoria do Product Manager/Owner/Key User
  • Como conseguir engajar a área demandante e a área usuária, para evitar destruição do Time;
  • Integridade Conceitual - Alguém definiu exatamente o que seria cada produto.
  • O PO simplesmente ignora a fase de homologação e esta é uma restrição para a próxima fase;
  • Cada release é uma surpresa, por falta de engajamento do PO;
  • Aumento do Pacote, ou seja, não entrego na Sprint correta e aumento o risco na Sprint seguinte;
• Comunicação
  • Comunicação franca entre equipe de arquitetura e equipe de construção, sem influenciar a clara divisão de tarefas.
• Se esta pronto, porque esperar até o final da SPRINT? Usar Feature Toggle ou Flag.
  • Deploy é o processo técnico de colocar ou instalar uma versão do software em um ambiente específico, como servidores de produção ou de staging, para que ele esteja disponível para execução.
  • Release refere-se ao processo de tornar o software disponível para os usuários.
• Quais as pessoas de gargalo no Time de Desenvolvimento?
  • O que dependente dele.
  • Só ele conhece.
  • A quantidade de trabalho em paralelo.
• Como CONFIRMAR, que o GARGALO é o TIME DE DESENVOLVIMENTO?
  • Como atacar o sintoma e não a causa? O gargalo é móvel?
  • A Teoria das Restrições foi desenvolvida por Eliyahu Goldratt em 1984.
  • O gargalo é um ponto no processo onde a capacidade é menor que a demanda, o que significa que ele limita o desempenho do sistema como um todo.
  • Você resolve Requisitos, para em Código, Code Review e assim vai.
• Contratação de MAIS desenvolvedores resolve o problema?
  • Quem não passou pela experiência de contratar um Developer ficar um tempão pensando cara tem tanto trabalho para fazer?
  • Quem nunca contratou por conhecimento e demitiu por atitude?
  • Começa a colocar item no backlog mas item no backlog que não agrega valor.
  • Features que NÃO entregam valor e colocar para ele fazer.
  • O Time tem a capacidade de PUXAR tarefas?
• Eficiência vs Eficácia
  • Eficiência é fazer certo as coisas;
  • Eficácia é fazer as coisas certas;