CertiProf – Resumo das certificações Scrum (SFPC) e DevOps (DEPC)

Neste post vou compartilhar algumas dicas para quem deseja realizar os testes de certificação da Certiprof. A empresa liberou por tempo indeterminado o acesso gratuito a estes dois exames online:

1. Scrum Foundation Professional Certificate (SFPC)

O guia de preparação é dividido em 4 partes:

  • Parte 1: introdução dos conceitos de Ágil, Manifesto Ágil, tipos de projeto e Scrum.
  • Parte 2: teoria do Scrum – três pilares (transparência, inspeção e adaptação), valores e essência do Scrum.
  • Parte 3: papéis e responsabilidades dos times.
  • Parte 4: principais conceitos – user story, time-boxing, sprint, eventos e artefatos.

Realize os simulados antes de fazer o teste de certificação. A prova é bem simples para quem já conhece o Scrum Guide e os conceitos de agilidade. Uma revisão no guia de preparação também é recomendado.


2. DevOps Essentials Professional Certificate (DEPC)

O guia de preparação é dividido da seguinte forma:

  • Introdução: conceitos, história, objetivo, benefícios e pilares do DevOps.
  • Conceitos: princípios, papéis e responsabilidades, desafios organizacionais, gerenciamento de configuração, Entrega contínua e Integração contínua.
  • DevOps e outras práticas recomendadas: Agile, Scrum e ITSM (ITIL).
  • Culturas DevOps e Adoção incremental de DevOps
  • Ferramentas DevOps: Eclipse, JIRA, Maven/Ant, Git/GitHub, Chef, Docker, Puppet, Jenkins/Bamboo, Nexus/Artifactory, New Relic, Splunk, Nagios, etc.
  • Modelo Gartner DevOps: pessoas, processos, tecnologia e cultura
  • Modelo de maturidade e autoavaliação

Análise de causa e efeito em projetos ágeis com Fishbone (Ishikawa) e Azure DevOps

Quando executamos projetos ágeis no âmbito de desenvolvimento de sistemas, trabalhamos com algumas técnicas que ajudam a evitar deploys de novas releases com bugs em produção. Algumas práticas de CI/CD nas práticas DevOps, por exemplo, mitigam os riscos por gerenciar todo o ciclo de vida da aplicação – gestão de configuração, integração contínua, estratégia de testes, build e release pipeline, etc.

Mesmo com publicações frequentes e pacotes menores para diminuir os riscos, lidamos com algumas implementações complexas e inúmeras dependências entre os times. Nem sempre temos o “estado da arte” na nossa empresa, contando com os investimentos adequados em ferramentas ou até mesmo a maturidade do time no uso de práticas e processos de desenvolvimento.

E assim, alguns antipatterns podem surgir neste âmbito de implementação:

  • Correções frequentes durante a implementação de releases
  • Confiança em testes manuais para validação das aplicações
  • Resultados imprevisíveis na publicação de novas releases, e ainda muitas vezes apresentam problemas e precisam ser revertidas

Quando isso acontece, uma boa orientação é atuar na causa real dos problemas afim de evitar a recorrência (o mesmo problema apareça novamente) e até mesmo não resolver em definitivo aquele bug. Já falamos anteriormente sobre o uso do 5 Porquês (5-Why). Neste post, vamos abordar o Diagrama de Ishikawa, também conhecido como Espinha de Peixe ou Causa e Efeito, ferramenta de qualidade para identificar a relação de causa e efeito dos problemas. É muito utilizada por gestores na área de TI para descobrir a causa raiz daquele bug apresentado na aplicação em produção.

O uso do diagrama é bem simples. Na “cabeça” do peixe colocamos o problema a ser resolvido. Uma frase como “por que este <problema> aconteceu?” é mais recomendado do que apenas escrever o problema. A “espinha do peixe” serve para descrevermos a causa dos problemas. Por fim, agrupe pelo tipo da causa. Os grupos recomendados no Ishikawa são os 6M: Método, Meio ambiente, Medida, Mão de Obra, Material e Máquina. Em TI trabalhamos com o diagrama adaptado do fishbone. Veja o modelo:

fishbone

Download do template (PPTX): fishbone template

No meu exemplo, estou utilizando o Azure DevOps (da Microsoft) como solução de ALM e assim registrar os erros encontrados nas aplicações. Para relacionar os bugs em aberto, acesse a área Boards > Work Items > faça o filtro do work item tipo “Bug”.

azure-devops-bugs.png

No work item (do tipo Bug) existe o campo de classificação (Classification) que possui uma lista de valores a ser escolhido como a causa do problema. Este pode ser utilizado como o grupo de problemas na construção do Ishikawa. Customize se necessário. Adicionalmente, deve haver o preenchimento da causa do problema no campo  symptom. Oriente seu time para realizar o preenchimento correto dos campos.

azure-devops-bugs-wi.png

Após coletar todos os erros da aplicação, chegou a hora de analisar a causa raiz do problema, agrupando conforme as causas em grupos. Com os principais erros relacionados, podemos atuar na causa e resolver o problema em definitivo. Em processos de melhoria contínua, este aprendizado certamente trará melhorias, sendo o input para implementações futuras.

fishbone-ti

 

Refinamento do product backlog – gestão ágil

Quando trabalhamos com a gestão ágil dos projetos, um dos pontos de partida é estabelecer a cadência e os principais eventos que envolvem o time do projeto – Planning, Daily, Review, Retro e Demo, além da SoS, PO Sync e System Demo para ágil em larga escala.

Mesmo em times com maturidade alta e papéis bem definidos, uma boa reunião de Sprint Planning exige preparação para que o time consiga avaliar corretamente o Backlog da Sprint e obter sucesso na execução do desenvolvimento. O refinamento do Product Backlog é imprescindível para deixar os itens preparados (ready) para Sprints futuras e melhorar a previsibilidade da entrega daquela iteração.

Entre as principais atividades de refinamento estão:

refinamento

O refinamento é contínuo e deve ser realizado pelo time do projeto (não somente pelo PO ou time de desenvolvimento), afim de evitar dispersão das informações. O Scrum Guide recomenda dedicar até 10% da capacidade do time em refinamento.

Para times que trabalham com BDD (Behavior-Driven Development), este tempo pode aumentar em virtude do desenvolvimento de testes de aceitação em prol dos testes automatizados funcionais que validarão a sua solução. Em larga escala, os times refinam o backlog e utilizam as reuniões de sincronização do ART (Agile Release Train) para resolver as dependências, problemas e tarefas que podem aparecer.

Alguns problemas comuns que aparecem durante a Sprint Planning quando não fazemos o refinamento:

  • Planning longa demais ou rasa – com muitas dúvidas das histórias (ou grandes demais), indefinições, critérios de aceitação não especificados, etc.
  • Backlog mal estruturado –  como por exemplo a priorização indevida ou histórias no topo sem o detalhe necessário para desenvolvimento.
  • Spikes – features ou tarefas que precisam ser debatidas e detalhadas para entrar no Product Backlog.
  • Falta de critérios – adote ROI, WSJF (Weighted Shortest Job First) ou qualquer outra matriz de direcionamento entre esforço x valor para o negócio.

Kick-off meeting – iniciando seus projetos ágeis e tradicionais

reunião de Kick-off é importante para determinar o início do projeto, alinhamento dos objetivos, mobilizar os recursos e garantir o entendimento do time de projeto. Em gestão tradicional de projetos, este evento tende a ser mais formal. Já na gestão ágil, focamos em atividades de team building ao invés de detalhes do escopo.

Entre os participantes da reunião, sugiro incluir o patrocinador do projeto, o time chave do projeto, champions, e os usuários finais. O formato e participantes da reunião podem variar de acordo com a cultura da sua empresa. Traga sentido aos envolvidos! Só assim você consegue o engajamento e o senso de importância de todos. Se necessário, faça as adaptações necessárias, por exemplo, trabalhando em um formato híbrido.

A agenda do kick-off pode ter o seguinte formato:

1. Introdução

Apresente os objetivos (goals) e entregáveis (deliverables) do projeto. Aproveite a presença de múltiplos departamentos e empresas na reunião para introduzir as pessoas no projeto. Alinhe o direcionamento do projeto e seus principais benefícios.

2. Time do projeto e responsabilidades

Após a introdução do projeto e apresentação das pessoas, compartilhe quais serão as responsabilidades de cada um no projeto. Neste ponto, é importante um contato preliminar com os gestores de cada departamento, afim de evitar “surpresas” no dia da reunião. Assim, todos os participantes do projeto já terão um alinhamento prévio de suas atividades e poderão contribuir melhor na fase inicial do projeto.

3. Premissas e restrições

As premissas são hipóteses que assumimos verdadeiras (por ainda não termos informações suficientes ou por depender de fatores externos) para fins de planejamento.

  • Liberação dos recursos A, B e C para o projeto
  • Budget disponível para contratação de hosting em Cloud

E as restrições são limitações internas ou externas ao projeto. Por exemplo, requisitos obrigatórios ou até cláusulas contratuais exigidas pelo cliente.

  • O sistema deverá ser publicado até 31/12/2018

4. Plano preliminar do projeto

O plano preliminar do projeto comunica em high level o cronograma, os principais  milestones, o custo (CAPEX e OPEX) do projeto e o modelo de governança (gestão ágil ou tradicional; cadência).

Timeline
Defina um timeline preliminar com as principais entregas do projeto. O time do projeto precisa ter conhecimento para administrar os riscos e tarefas associadas.

timeline

Custos
O custo total do projeto, incluindo o valor dos recursos, infraestrutura, licenças, aquisições de equipamentos, etc.

custos

Governança
Estabeleça a cadência do projeto. Seja em gestão tradicional ou ágil, compartilhe como será o gerenciamento do projeto, as principais reuniões, envolvidos e o time alocado.

cadencia.png

5. Key Success Factors

O que é necessário para o projeto atingir seus objetivos com sucesso? Veja alguns fatores chaves de sucesso nos projetos:

  • Engajamento do time do projeto e áreas relacionadas
  • Governança leve e ambiente agradável
  • Patrocínio onipresente
  • Práticas DevOps e Cloud Solution
  • Outras áreas que podem ser incluídas: planejamento, processos, pessoas, capacidade e estratégia de contingência

Ciclo de vida da aplicação com Azure DevOps – do backlog a homologação

E como está o processo de desenvolvimento e homologação das entregas no seu time? Além da DoD (Definition of Done), recomendo estabelecer um processo que compartilhe as responsabilidades entre as áreas durante o ciclo de vida da aplicação, e assim, garantir a qualidade desde a entrada do backlog até a liberação para homologação.

Veja o diagrama proposto, iniciando a construção do backlog com o PO. O SM facilita o time de desenvolvimento na quebra das histórias em tarefas e estimativas. O time de desenvolvimento utiliza boas práticas (como testes unitários, check-in frequentes, etc.) para liberar a área de QA. Por aqui temos a proposta da execução dos planos de testes e também da automação deles*.

QA-dev-processo
* avalie a maturidade da sua equipe em relação a testes automatizados. Claro, que a automação pode ser incorporada na sua equipe de desenvolvimento.

Azure DevOps possui uma solução completa para te apoiar neste processo. Por exemplo, no Azure Boards podemos criar o backlog da Sprint e gerenciar a capacidade do time. No Azure Pipelines Azure Repos trabalhamos com o desenvolvimento das aplicações, integração contínua e versionamento. E o Azure Test Plans permite criar os planos de testes para estes work items.

azure-devops-01

Azure Boards: além da configuração das Sprints, é imprescindível estruturar o backlog em Epic – Feature – User Story com as tarefas para o time de desenvolvimento executar.

backlog-estrutura.png

Utilize as melhores práticas (INVEST, etc.) para auxiliar o PO a escrever boas estórias com critérios de aceitação claros. As técnicas como planning poker contribuem nas estimativas das histórias.

historias-VSTS

Azure Pipelines e Azure Repos: para mais informações, veja meu post de Pipeline de Build e Release.

azure-devops-pipeline-06.png

Azure Test Plans: o Plano de Testes também pode ser criado no Azure DevOps. Visite este post e veja o passo-a-passo deste processo.

Ágil em larga escala – System Demo meeting

Após a introdução do framework SAFe (Scaled Agile) e de duas importantes reuniões – Scrum of Scrums e PO Sync, chegou a hora de falar sobre a System Demo, outro evento  imprescindível em projetos ágeis de larga escala, que provêm visibilidade das features entregues pelos times no ART (Agile Release Train).

System Demo é uma demonstração do trabalho realizado por todos os times durante a última iteração (Sprint). Um ótimo meio de coletar feedbacks e validar as dependências. Portanto, mantenha ativo o processo de CI (Continuous Integration) no seu time para facilitar as publicações e apresentações do sistema.

continuous-deployment-azure-devops
(exemplo do processo de Continuous Deployment no Azure Devops)

A integração dos sistemas, componentes, etc. no cada final de Sprint pode exigir capacidade e custo de transação inaceitável. Por isso, se você trabalha em estágios iniciais de CI, evolua gradativamente o CI e automação de testes para diminuir o custo de futuras integrações.

Figura: otimização de custo de “curva em U” para os esforços de integração

Algumas características sugeridas para a System Demo:

Frequência: a cada duas semanas, após a conclusão da Sprint.
Duração: o timebox sugerido para este evento é de uma hora. O tempo curto e direto ao ponto mantém o envolvimento de pessoas chaves na reunião.
Participantes: PM (Product Managers) e PO (Product Owners); um ou mais membros do time de sistemas; BO (Business Owners), Arquiteto, Infra e stakeholders necessários
Facilitador da reunião: PM (Product Managers) e PO (Product Owners)

E um roteiro sugerido para a System Demo:

1. Visão de produto: Epic > Feature > User Story. É importante cada time trazer um rápido overview do produto a todos presentes na reunião.

user-story

2. A representação das histórias e a carga realizada na Sprint. Também recomendo demonstrar se o critério de aceitação foi obtido.

sprint-story

3. E por fim, dedicar o maior tempo na demonstração do sistema em funcionamento no ambiente de homologação. Percorrer as featuresuser stories entregues na última Sprint e compartilhar se a DoD (definition of done) foi cumprida.

blog-leonardo.png

A última System Demo de cada PI (Program Increment) exige uma estruturação maior, percorrendo todas as features desenvolvidas naquela PI. Em geral, este evento acontece na I&A (Inspect and Adapt) e orienta o progresso daquela PI. Outras recomendações para uma boa System Demo:

  • Demonstrar somente aplicações testadas (evitar apresentação de slides)
  • Dividir a responsabilidade entre os líderes de desenvolvimento e os POs durante a demonstração.

 

 

 

Ágil em larga escala – Inception e preparação para PI Planning – SAFe

Quando trabalhamos com projetos ágeis em larga escala, utilizando o SAFe como framework, temos a PI Planning como um dos mais importantes eventos. É uma reunião  de planejamento com duração de 2 dias e que acontece a cada 10 semanas. O plano estabelecido e aprovado é o alinhamento entre todos os times do ART (Agile Release Train) para estas próximas 10 semanas (5 Sprints).

E o que devemos considerar na preparação deste evento? By SAFe:

  • Organizational readiness: strategic alignment and teams and trains setup (planning scope and context | business alignment | agile teams)
  • Content readiness: management and development preparednes (executive briefing | product vision briefing(s) | architecture vision briefing)
  • Facility readiness: the actual space and logistics for the event (facility | tech support | communication channels)

Adicionalmente, fiz um resumo que pode ajudar na preparação para a PI Planning:

Premissas de Produto

Lean Inception, por exemplo, é uma ótima oportunidade de cocriar o produto a ser discutido na PI Planning. Desta forma, o escopo do produto ficará muito mais claro para o time durante a reunião de PI Planning, onde será feito o refinamento de atividades e estimativas (planning poker).

lean-inception.png

A organização do backlog do produto é essencial: Epic > Features > User Story > Tasks. Uma boa prática é criar tudo em sua ferramenta de gestão ágil (no meu caso utilizei o Azure DevOps) nesta fase de Inception e refinar o entendimento com as estimativas na PI Planning. A prototipação das telas complementa este trabalho.

historias-vsts

Criar uma WBS (work breakdown structure) para representar as Epics e Features que serão discutidas na PI Planning é outro recurso que pode ser utilizado por PMs e POs na apresentação do produto nesta reunião.

wbs-features

Quando estiver iniciando um novo projeto (1ª PI Planning), vale a pena acompanhar o entendimento de todos os times, principalmente PM, POs e SMs. Recomendo inclusive executar uma mini jornada (2 horas) de PI Planning com os principais participantes.

jornada-PI-Planning

Em estágios mais avançados, vale verificar se os feedbacks coletados no final da última PI foram trabalhados e os pontos que não foram bem, devem estar resolvidos.

feedback

Premissas Técnicas

Alguns dos principais pontos técnicos que devem ser garantidos antes das PI Plannings:

  • Arquitetura: visão da solução e como será a integração entre os sistemas. Também apoia o time na definição de requisitos funcionais, não funcionais e dos enablers. Os enablers apoiam as atividades da Architectural Runway a prover funcionalidades de negócio. Inclui infraestrutura, compliance, exploração e arquitetura de sistemas.
  • Infraestrutura: provisionamento dos ambientes em cloud e estrutura (VPN, rede, acessos, etc.) para suportar o trabalho a ser executado. É esta frente que cuida de banco de dados na sua empresa? Se sim, deve estar envolvido na estruturação das bases, padronização de objetos e otimização das instâncias.
  • ALM: criar os projetos e times de projeto (por exemplo no Azure DevOps), estrutura do código-fonte, estratégia de versionamento (branch, merge e commit) e Continuous Integration (build e release).
  • Outros: segurança da informação e demais áreas que devem ser envolvidas.

* The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Azure-Architecture.png

Facilities

Garantir a reserva das salas com capacidade para todos os participantes. Também confirmar a reserva das salas necessárias para os breakouts – recursos de videoconferência, Datashow, etc.

Viabilizar materiais para PI Planning (flipcharts, post-its, canetas, canetões e folhas de sulfite) e acesso a ferramentas que serão utilizadas no projeto. O coffee é outro ponto a ser considerado no evento.