Azure Repos Neste post vamos navegar no Azure Repos (do Azure DevOps) e compartilhar a aplicabilidade de Tags no histórico do seu repositório de código-fonte. Existem dois tipos de Tags:
Lightweight Tags: ponteiro para commits específicos.
Annotated Tags: possui informações adicionais como data, mensagem e tagger (marcador).
Entre os principais comandos de uso das Git Tags nas tarefas do Azure DevOps estão: create tag / view tag / delete tag.
Criando Tags Após a realização do commit de seu código, acesse a área Repos > Commits do Azure Devops. Procure o commit que você deseja criar a marcação e escolha Create tag. Defina o nome e descrição para a Tag.
This slideshow requires JavaScript.
* nesta área você pode criar somente annotated tags. Para lightweight tags, você deve enviar via push, utilizando linha de comando para aparecer no Azure DevOps.
Apagando Tags Se você identificou o commit errado, ou por qualquer outro motivo, o recurso Delete Tag permite apagar a Tag do seu repositório. Para isso, você precisa da permissão de Force Push no nível do repositório.
Acesse Repos > Tags no Azure DevOps e escolha a tag que será apagada. Escolha a opção Delete Tag.
Visualizando Tags Em Repos > Tags você pode visualizar todas as Tags criadas. Utilize o filtro de busca para encontrar pelo nome. Em repositórios com um grande número de Tags, este recurso pode ser bem útil.
Criando branch a partir da Tag Outro recurso interessante é a criação de uma nova branch a partir de uma Tag. Para isso, acesse Repos > Tags, clique em + New branch. Especifique o nome e work items a serem vinculados.
Veja que a branch foi criada no seu repositório, conforme as configurações realizadas.
Continuando os posts sobre Ágil em larga escala, vamos falar agora sobre a PO Sync, outra reunião super importante do Program Increment (PI). A Product Owner Sync é uma reunião similar a SoS com o propósito de prover visibilidade do ART (Agile Release Train) em relação aos objetivos do PI.
É uma ótima oportunidade de avaliar ajustes de escopo e elencar problemas no desenvolvimento de features. Também é usada para preparar o conteúdo da próxima PI Planning e priorizar o backlog com WSJF (Weighted Shortest Job First).
Veja algumas boas práticas na execução da PO Sync:
Frequência: semanalmente ou com maior frequência (se necessário). Duração: 30-60 minutos seguida da “meet after” em eventuais resoluções de problemas. Participantes: POs (Product Owners) e PMs (Product Managers). Facilitador da reunião: RTE (Release Train Engineer) ou PM (Product Manager)
Em equipes que estão começando a trabalhar com algum framework de Ágil em larga escala, ainda vale a pena checar com cada PO:
Está claro o papel do PO no projeto?
Os eventos (daily – planning – review – retro) estão acontecendo com o time?
Quais atividades o time está trabalhando nesta Sprint?
Como está a preparação do conteúdo para as próximas iterações?
Existe algum ajuste de escopo?
Algum problema ou oportunidade endereçado pelo time?
Falamos anteriormente sobre tecnologias sociais e como utilizar a Wiki (do próprio Azure DevOps) ou a integração com o Slack para melhorar a comunicação no seu time. O acompanhamento dos projetos exige esta interação imediata entre as equipes, principalmente naquelas distribuídas com fusos e idiomas diferentes.
Além de manter o alinhamento com todos, tais como decisões técnicas e discussões, outra grande virtude é a distribuição rápida das informações e acesso imediato, por exemplo do gestor que precisa demonstrar o Kanban Board do projeto ou do Tester que precisa interagir com o desenvolvedor após a realização do Build.
Neste post vamos demonstrar a integração do Microsoft Teams com o Azure DevOps. Trata-se de um ótimo recurso para acessar os Dashboards ou Kanban Board (dos seus projetos no Azure DevOps) dentro do próprio Teams.
Acesse então o Microsoft Teams e adicione uma nova guia (+) em sua equipe.
Escolha o aplicativo do VSTS e clique no botão Instalar. Faça a autenticação na sua conta do Azure DevOps (antigo VSTS) e conecte nela.
Em seguida, faça a conexão com o Dashboard ou Kanban board do seu projeto e time.
Pronto! O Kanban board * já está disponível dentro do Microsoft Teams. Agora você pode utilizar rapidamente quando precisar de alguma informação do Board do Azure DevOps daquele projeto.
* no meu exemplo escolhi a opção Kanban board, mas há a opção Dashboard também.
Abordamos o Azure DevOps em um dos últimos posts, e os principais recursos Boards (planejamento das atividades), Repos (gestão de fontes), Pipelines (CI/CD), Test Plans (suítes de teste) e Artifacts (artefatos organizados e pacotes protegidos).
E como está a análise dos dados? É possível gerenciar a sua equipe com indicadores? E as métricas de qualidade? Vejo como ponto fundamental coletar as informações de todo o ciclo de vida da aplicação e garantir a gestão dos principais processos – tarefas, sprints, builds/releases, bugs, qualidade do código, cobertura dos testes, etc.
O Analytics é a solução do Azure DevOps para criar dashboards, relatórios, widgets e integração com Power BI para extrações mais detalhadas. Também possui acesso OData para extensibilidade. Há dois conceitos importantes sobre o Analytics:
Analytics Service: serviço que provém o modelo de dados para o Azure DevOps. É otimizado para acesso rápido de leitura e agregações no lado servidor. O Analytics extension é uma extensão utilizada neste contexto.
Analytics View: provém acesso imediato as informações, simplificando o uso de critérios e relatórios no Power BI. Algumas views já são automaticamente criadas após a instalação do Analytics extension.
Veja algumas views disponíveis no Analytics Views para serem utilizadas no Power BI. Você pode utilizar as views padrões ou criar utilizando o Power BI Data Connector ou no próprio Azure DevOps.
A área de Dashboards do Azure DevOps permite visualizar as principais métricas do ALM (Application LifecycleManagement) com o uso dos dados que explicamos anteriormente. Sugiro a leitura de 2 posts – Dashboard de projetos ágeis | Dashboard de projetos ágeis em larga escala para confirmar a aplicabilidade e uso em seu ambiente.
O Power BI é a ferramenta mais completa para análise de informações. Se tiver necessidade de extrações mais avançada, veja como utilizar a conexão entre o Azure DevOps e Power BI:
E assim, criar os indicadores de acompanhamento do seu projeto. O destaque é com as múltiplas visões que podemos construir, por exemplo, a distribuição de tarefas em vários times, ou comparação de Sprints do projeto.
Neste vídeo comento um pouco sobre as expectativas das áreas, principalmente de TI, em relação ao programa de Trainee da Laureate e como preparar os profissionais em desafios e projetos da empresa.
Como já fui Trainee em 2007 (em outra empresa), reconheço o valor do programa e o interesse das empresas em desenvolver e desafiar estes profissionais. Os processos de contratação são extremamente concorridos, etapa por etapa, exigindo habilidades intrapessoal/interpessoal, e também valiosos pelo fit de ótimos profissionais para as posições de liderança da empresa. É um investimento muito relevante.
E o que Trainee espera da empresa? Um bom resumo das expectativas seria em torno do desenvolvimento pessoal e profissional, com a participação em cursos e atividades relevantes na organização. Por exemplo, a participação em projetos internacionais, vivenciando as principais fases de planejamento e execução até o Go-Live do projeto coloca o profissional diante de situações reais de pressão, conflitos, priorização e resiliência.
Outra eventual oportunidade é participar de board meetings, apresentações executivas e do contato mais próximo dos gestores. Acredito que tudo isso colabora com a alavancagem profissional e absorção da experiência de profissionais mais seniores. Como os projetos envolvem diferentes áreas (TI, Finanças, Vendas, etc.), tem se também o conhecimento de processo, negócio e governança obtido com eles.
Gostou do cenário proposto? Veja no vídeo então o que esperamos dos Trainees:
Neste post vamos falar sobre a reunião Scrum of Scrums (SoS), evento que acontece em projetos ágeis em larga escala, e colabora com a comunicação, gestão de dependências entre ARTs (Agile Release Train), visibilidade do progresso em relação aos milestones, objetivos da PI e impedimentos dos times.
Algumas perguntas quanto ao formato? Veja algumas boas práticas:
Frequência: semanalmente ou com maior frequência (se necessário). Duração: 30 minutos seguida da “meet after” em eventuais resoluções de problemas. Participantes: RTE (Release Train Engineer), SMs (Scrum Masters) e outros (quando necessário). Facilitador da reunião: RTE (Release Train Engineer)
Enquanto os eventos do Scrum continuam ocorrendo (planning,daily, review e retro) e os times executando o backlog das Sprints, a SoS reúne o SM (Scrum Master) de cada time com o RTE (Release Train Engineer), famoso líder servo e coach do ART, que facilita este evento e os processos, apoiando os times na entrega de valor.
Agenda recomendada pelo SAFe (Scaled Agile Framework):
Executando a SoS Jeff Sutherland tem a seguinte definição da SoS: “The Scrum of Scrums as I have used it is responsible for delivering the working software of all teams to the Definition of Done at the end of the Sprint, or for releases during the sprint“.
As primeiras recomendações foram mencionadas acima (time box, frequência, agenda, participantes, etc.). A SoS deve ter ênfase nos times (objetivos da sprint) e resolver seus impedimentos. Não deve ser uma reunião de status report (do progresso do time de desenvolvimento aos gestores). Algumas questões que devem ser tratadas na SoS:
Finalizamos aqui! Espero ter contribuído com direcionamentos para a gestão ágil em larga escala na sua empresa. No próximo post vamos falar sobre a PO Sync e como alinhar a expectativa de produto com a execução das atividades.
Aprendemos como criar planos de testes no Azure DevOps e como associar aos work items (do board de desenvolvimento) para garantir a execução dos testes manuais – exploratório e casos de teste – com as atividades do projeto.
E podemos evoluir para a automação dos testes? Sim, para isso você precisa vincular o teste automatizado ao seu plano de teste e executá-los no Azure Test Plans (Azure DevOps) ou no Test Hub do TFS. Por exemplo, no deploy da aplicação, executando os testes sob demanda no fluxo de build e release.
Azure DevOps O primeiro passo é acessar as configurações do plano de teste. No Azure DevOps, clique em Test Plans e selecione Test Plan Settings do plano de teste que irá utilizar.
Em seguida, selecione o Build Pipeline responsável pela geração dos builds que possuem os binários de teste. Escolha o número do Build ou a opção do sistema automaticamente trabalhar com o último Build.
O próximo passo é criar a Release pipeline onde os testes serão executados. Se você já possui, escolha a sua release na lista de valores. Para criar uma nova, clique em new release pipeline contendo single stage com a tarefa Visual Studio Test já adicionada –
As demais opções englobam a versão do Visual Studio Test para uso (Test Platform version), testes UI, input parameters, Settings Files (caminho do arquivo runsettings ou testsettings usado com os testes). Veja mais sobre Visual Studio Test Task.
Suba para o nível do Agente (Run on agent) e verifique se o Agent Job está configurado com as máquinas necessárias para execução dos testes. Adicione em demands quando os testes exigirem máquinas especiais do agent pool. A opção Parallelism permite distribuir os testes entre múltiplos agentes.
Verifique se o Build Pipeline com os binários de teste estão associados com a Release Pipeline.
Por fim, acesse o Test Plans do Azure DevOps e escolha a suite de testes com os testes automatizados. Execute o teste (run test). O sistema checará os testes automatizados, validando configurações (do Visual Studio Test), permissões do usuário para criação da release, executa o teste e dispara a criação da release para o estágio selecionado.
E confira o resultado da execução:
A análise das execuções ficam na área Runs do Test Plans. Veja o gráfico com o resumo da execução e os resultados do teste (em Test results).
A Microsoft divulgou ontem (10/09/2018) o Azure DevOps como nova solução e evolução do VSTS (Visual Studio Team Services) para transformar o ciclo de vida do desenvolvimento, principalmente por trabalhar com projetos open source no processo de CI/CD (nomeados Azure Pipelines) como Jenkins e GitHub.
O Azure Pipelines oferece minutos de CI/CD ilimitados e até 10 jobs (em paralelo) para os projetos open source, utilizando a mesma infraestrutura de projetos pagos com o intuito de prover a mesma performance e qualidade do serviço.
Além da mudança no link de acesso (abc.visualstudio.com -> dev.azure.com/abc) e da experiência do usuário na plataforma (evolução baseada em feedbacks), as atualizações também continuarão para os usuários on-premises com base nos recursos do Azure DevOps.
Os principais serviços da Azure DevOps são:
Azure Pipelines É bom demais trabalhar com CI/CD em qualquer linguagem e plataforma. A automação de build e release em Pipelines e a implementação de Containers são outras facilidades.
Azure Boards A área do Board continua evoluindo os recursos de gestão de times, capacity, backlogs com a organização de Epics, Features, User Stories, Tasks nas Sprints. O bacana é utilizar queries para extrair as atividades e outros itens de análise, além da construção de Dashboards com widgets.
Azure Artifacts Mantém os artefatos organizados e pacotes protegidos. O gerenciamento de pacotes como NuGet, Maven e npm integrados aos pipelines de CI/CD de fontes públicas e privadas são serviços interessantes. Veja mais em Azure Artifacts.
Azure Repos Os repositórios do Git privados e ilimitados (cloud-hosted), integração com webhooks e APIs, suporte para TFVC e os recursos de pull request são destaques por aqui. No GitHub Marketplace você pode habilitar o Azure DevOps na sua conta e a partir dai, comece a executar CI/CD com seus repositórios.
Após conhecer melhor os serviços apresentados pelo Azure DevOps, minha recomendação é considerar a aplicabilidade para o seu negócio. Como a solução independente do framework, plataforma ou linguagem utilizada, sugiro verificar no Azure DevOps pricing o que cada licença oferece como pacote de soluções.
A opção de começar gratuitamente é bem recomendável para provar o conceito da solução e também para equipes que estão iniciando com processos de CI/CD e gestão ágil de projetos. Em equipes maiores, com processo de CI/CD mais maduros, certamente vale avaliar o custo por usuário da solução e papeis existentes na sua equipe.
Capítulo 1 – Nada dura para sempre O tripé do empreendedorismo – flexibilidade, adaptação e resiliência, destacando a adaptação a mudanças como uma das chaves do sucesso, e o atual momento de ciclos mais curtos e velozes de lançamento de produtos.
“Tudo o que você considerava certo e inabalável pode se modificar”.
Capítulo 2 – DNA inovador Gostei da analogia Davi x Golias – pequeno israelita que resolveu enfrentar o gigante filisteu Golias – com o empreendedorismo atual, onde temos acesso mais fácil a informação e um negócio pequeno pode bagunçar o mundo das empresas gigantes.
Os cases de inovação das empresas Skype, Waze, Airbnb, Nubank e Netflix, e como a todo momento, os mercados (e as pessoas) mudam muito depressa e os grandes nem sempre têm agilidade para acompanhar estas transformações.
Encontre um propósito! Inovar não é ficar quebrando a cabeça atrás de algo que não existe, e sim olhar ao redor e descobrir algo que incomoda você e que pode ser melhorado. A inovação é um processo, metodologia, treino. Não tem a ver com a criatividade em si, pois as pessoas mais inovadoras, não são necessariamente as mais criativas.
“As empresas inovadoras são as que criam mercados que não existiam”.
Capítulo 3 – Uai not? Empreender com escala, onde o produto ou serviço pode ser reproduzido com facilidade, sem demandar aumento de custos ou de recursos por causa do aumento da oferta. Por exemplo, uma consultoria não é um negócio escalável, assim como outros que exijam treinamentos complicados.
“Não deixe incômodo adormecido; nele existe uma oportunidade”.
O case da empresa Love Mondays em que os funcionários podem avaliar as empresas gratuita e anonimamente, proposta simples e que surgiu de um problema pessoal. O livro Exponential Organizations numera cinco ponto que definem as características de um negócio exponencial:
Equipe sob demanda
Comunidade e multidão
Algoritmos
Ativos alavancados
Engajamento
E o mindset de ter mais execução e menos planejamento, não se prendendo tanto a teorias e planejamento como business case. Os três motivos planejar menos e executar mais são: o mundo de hoje é veloz; sua ideia não é única; executar é barato.
Capítulo 4 – A lógica da simplicidade O saia do seu lago é uma interessante orientação, pois sardinha só nada sardinha e tubarão só nada com tubarão. Começar a ir atrás dos tubarões, além de acessível, pode oxigenar as ideias e trocar experiências enriquecedoras.
“O que diferencia os empreendedores é esse olhar afiado”. Encontrar problemas reais para você e para os outros podem trazer sucesso no seu empreendimento: Uber (a falta de táxi na rua), GoPro (a dificuldade de fotografar sem borrar as imagens) e 3M (fita adesiva fácil de colar e retirar dos lugares).
Capítulo 5 – Peça ajuda Enxergar seus pontos fracos e pedir ajuda se quiser fazer seu negócio seguir adiante. “Se você não sabe a resposta para alguma questão, alguém sabe e poderá te ajudar”. Neste ponto é narrado a importância com contatos que tenham experiencias distintas e a analogia de nadando com tubarões – quando você é só uma sardinha, mas nadando no meio de manjubinhas, parece o maioral; quando começa a nadar com tubarões, perece que tem muito a aprender para chegar no patamar daquelas pessoas.
Aprenda a criar uma rede de contatos e as chaves para o networking eficiente:
O empreendedor precisa focar vários fatores diferentes que levam ao networking
Faça com que as pessoas falem sobre você
Conheça as pessoas que serão cruciais para você antes de abrir a sua startup
Quanto a sua rede de contatos confia em você como líder da sua empresa influencia o seu sucesso
Aprender com pessoas de fora da sua equipe alavanca a sua rede de contatos, e isso aumenta a reputação da sua startup
Seu conforto ou desconforto com o fato de fazer networking não vai afetar o sucesso da sua empresa
Capítulo 6 – Entre o mapa e o terreno, escolha sempre o terreno As cinco forças de Porter e como não virar commodity em um mundo que gira muito rápido e quem quer inovar precisa entender isso. Os sinais de que é preciso levar o seu negócio para outro caminho:
Quando você começa a ganhar muitos concorrentes que oferecem um serviço com mais eficiência e com preço mais baixo que o seu.
Quando você perde o poder de barganha com seus clientes.
Quando não há mais aquele brilho nos seus olhos – ou nos olhos dos seus colaboradores.
Capítulo 7 – Não perca as pessoas de vista
“Você precisa encontrar algo ao qual você queira dedicar a sua vida”. As descobertas surpreendentes não apareceram por acaso. Tiveram equipes dedicadas e brilhantes enfrentando o problema dia e noite.
Movimentos sociais, organizações em rápido crescimento e descobertas notáveis em ciência e tecnologia têm algo em comum – são muitas vezes subprodutos de um propósito profundamente unificador – MTP (massive transformativepurpose):
Maciço: audaciosamente grande e inspiracional
Transformador: pode causa grandes transformações em uma comunidade ou planeta
Propósito: existe um “porquê” muito claro por trás do trabalho. Algo que une inspirações e ação.
Para encontrar o seu MTP, recomenda-se seguir dois passos:
Identificar o “quem”: descubra quem você quer impactar com seu negócio ou serviço.
Identificar “o quê”: qual problema você quer pegar e resolver?
Capítulo 8 – Seja ágil e leve As startups cresceram no Brasil e provaram que dá sim para começar a empreender com pouco dinheiro. A teoria do faster, better cheaper nasceu com a NASA, experimentando coisas novas e assumindo riscos para ganhar retorno significativo:
Focar missões menores, parar de colocar “todos os ovos em uma cesta só”.
Incorporar tecnologia avançada às missões
Reduzir o headquarter administrativo da NASA, dando mais responsabilidade para os centros.
Criar visões e roteiros emocionantes para novas missões.
Errar é permitido.
“Errando diferente, a gente encontra a inovação e aprende mais rápido”. Experimente (e aprenda) mais. O exemplo da Hack Week na Samba e os projetos gerados a partir de ideias experimentadas. Construir-medir-aprender é o conceito central do livro Lean Startup do Eric Ries, cujo propósito é transformar ideias em produtos.
Capítulo 9 – O sucesso começa pequeno Alguns pontos, considerados por Sangeet Paul Choudary (criador do blog Platform Thinking), como ser disruptivo:
Observe empresas que estão se tornando ineficiente
Observe indústrias que têm acesso a uma demanda específica
Observe indústrias fragmentadas
Capítulo 10 – Não acredite no “sempre foi assim” “Comece agora. A inovação não espera”. Steve Jobs, o criador da Apple, possui uma frase encorajadora: “Todas as coisas que estão ao seu redor e você chamada de vida foram criadas por pessoas que não eram mais espertas que você”.
A revista norte-americana Fast Company listou com base na trajetória dos profissionais que integraram a lista de 100 pessoas mais criativas de 2016, alguns itens importantes para estar atento aos problemas e adotar as lições de criatividade:
Introduzimos a área de Testes no VSTS no último post e como criar os planos de teste, casos de teste e gravar as principais ações durante a execução dos testes exploratórios. Após criar um plano de teste, temos as seguintes opções disponíveis:
Caso de Teste: configura os passos, ações e resultado esperado daquele teste manual.
Suíte de Teste: ajuda a organizar estes casos de teste com três tipos
Static: provém pastas para ajudar a organizar os testes a serem realizados. Funciona bem em testes de regressão, por exemplo, pois há funcionalidades que sempre precisam ser checadas na aplicação, e nem sempre possuem casos de teste relacionados.
Requirement-based: considera a realização de testes manuais em um backlog, podendo ser requirement, user story ou work items. É muito útil, pois numera a quantidade de casos de teste numa user story (por exemplo), evitando o crescimento imprevisto dos casos de teste em seu time.
Query-based: aplica um filtro sobre os work items de seu backlog e de outros Team Projects, permitindo executar testes nas funcionalidades criadas pelo seu time e também nas dependências que podem quebrar o código.
É isso! Espero ter contribuído com a apresentação dos recursos na área de Test do VSTS. Um ponto bem importante desta organização é evitar que a sua aplicação cresça sem uma estruturação adequada de planos de teste. A quantidade de casos de teste geradas para a área de QA e a dependência com outras aplicações são bem controlados com o uso devido destes recursos.
Azure Repos
Fonte: 
Digital Strategy and IT Innovation 