Resumo P3 - Atlassian & Jira Software PDF

Resumo P3 ATLASSIAN & JIRA SOFTWARE Atlassian: empresa criada por Mike Cannon-Brookes e Scott Farquhar em 2002. Aonde possui produtos focados à gestão de projetos e equipes. Jira: A ferramenta nº 1 das equipes ágeis. Seus objetivos são o planejamento,...

Resumo P3 ATLASSIAN & JIRA SOFTWARE Atlassian: empresa criada por Mike Cannon-Brookes e Scott Farquhar em 2002. Aonde possui produtos focados à gestão de projetos e equipes. Jira: A ferramenta nº 1 das equipes ágeis. Seus objetivos são o planejamento, acompanhamento e análise de entregas de projetos/equipes. Seguindo segmentos do Kanban e Scrum. Quais são as principais ferramentas da Atlassian? Gerenciamento de código Qualidade de código Resumo P3 1  Planeje, acompanhe e trabalhe Jira Software onBoard: Um quadro exibe problemas de um ou mais projetos nas colunas que representam o processo da equipe. Eles fornecem à equipe uma visualização compartilhada de todo o trabalho não iniciado, trabalho em andamento e trabalho concluído. Resumo P3 2  Workflow: caminho que os itens percorrem desde a criação até a conclusão. E possuem 3 elementos: Status: indica onde o item está no fluxo de trabalho. Alguns exemplos podem incluir: Aberto e Em andamento; Transição: representa a ação que está sendo realizada para mover um item de um status para outro; Resolução: quando uma tarefa é concluída e não está mais aberta, ela precisa de um status de resolução. Issues Types: ou tipos de problemas, distinguem diferentes tipos de trabalho de maneiras únicas e ajudam você a identificar, categorizar e relatar o trabalho da sua equipe em todo o seu Jira. Cards: ou cartões, permitem que você trabalhe com itens do Jira diretamente nos boards da Miro. Sprint: é um período fixo no qual as equipes concluem o trabalho da lista de pendências de produto. Epic: representam grandes volumes de trabalho que podem ser divididos em tarefas individuais. Crie se uma grande do trabalho do trabalho precisa ser concluída em vários sprints/longos períodos de tempo e se houverem padrões em várias histórias do usuário. Automação: é um recurso “sem código” que leva apenas alguns cliques. Ao automatizar os processos e fluxos de trabalho, você elimina a necessidade de você e a equipe executarem tarefas manuais e repetitivas, e é possível se concentrar no trabalho que importa. METRIFICAR & MENSURAR & CONTROLAR Para metrificar deve-se pensar o que, como e por quê medir; Não se deve medir pessoas! Stories Points: serve para um planejamento de quantos dias uma atividade leva para ser realizada usando In e Out. Resumo P3 3  CFD (Cumulative Flow Diagram): analisa o fluxo ágil das fases de desenvolvimento(entrega, backlog, e saída, vazão) , possui aumento constante se houver produção. A distância horizontal me mostra o Leadtime(tempo todo, criada até ela ser entregue) do Item; A distância vertical me mostra o WIP (Work In Progress), a quantidade de itens sendo trabalhados no momento. Quanto mais diagonal for os fluxos, mais próxima estará de ser ágil. trata: Scrum Cycle Time Kanban Leadtime e Cycletime Cycletime: É um período de um item sair de uma faixa até a outra faixa, sendo uma forma de identificar gargalos dentro do fluxo de desenvolvimento. Control Chart: É um gráfico de dispersão, mistura de leadtime com roadmap dos processos. Quanto mais a linha vermelha estiver no centro demonstra que, quanto mais próximo as tarefas (bolinhas) dessa linha, com maior constância, maior será a chance de previsibilidade e controle do tempo de entrega. Service Level Expectation Agreement - SLA: acordo de quanto tempo será realizada a tarefa. Service Level Expectation - SLE: expectativa de quanto tempo uma tarefa será realizada. Resumo P3 4  UP STREAM: Tarefas antes de serem produzidas, como tarefas em espera para entrarem no board por exemplo; DOWN STREAM: Tarefas que já entraram no board e estão sendo produzidas; EXTRA TEAM: Tarefas que estão em espera ou em processo de entrega. Lei de Little & Teoria das Filas: É um princípio matemático que relaciona o tempo médio de espera em uma fila de espera com a taxa de chegada de clientes e o número médio de clientes em serviço. Customer Demand: Quanto que nosso cliente é capaz de gerar de demanda para a empresa; Product Rate: quanto é capaz de produzir, mas não em quantidade. “Sou capaz de produzir uma tarefa por minuto, por dia, por semana, a cada um mês?”; TAKT Time: permite analisar se é possível atender a demanda dentro de uma faixa de tempo; Throughput Time: É o mesmo que o leadtime, porém no scrum é comum ser chamado de Throughput Time; WIP e Cycle time entram nessa lei/teoria. Throughput Histogram: gráfico no qual é possível analisar o número médio de unidades processadas por unidade de tempo. Importâncias: Compreender qual tem sido o montante de trabalho entregue; Identificar se o time está criando uma tendência de aumento no número de entregas; Identificar existência de algum tipo de fator que está afetando a cadência de entrega do time. Cycle Time Histogram: pode ser caracterizado por cada iteração de coluna, ou como um todo, realizando a somatória de todas as colunas de efetivo trabalho da equipe. Resumo P3 5  Cycle Time = Tempo Líquido de Produção / Nº de Unidades Produzidas Lead Time vs Cycle Time: Pluggin no jira que usa métricas de fluxo = Actionable Plugin. ESCALANDO O SCRUM Nexus Framework: tem objetivo de ajudar a escalar o Scrum com mais times, no qual possui regras, papéis, artefatos, muitos semelhantes ao aplicado pelo Scrum. Tendo o foco na integração e dependência dos times. Papéis no Nexus NIT - Nexus Integration Team: responsável por garantir que um incremento, não são desenvolvedores do produto, pronto seja entregue ao final de cada sprint e tratar problemas técnicos e não técnicos que impeçam que os times scrum de atingirem seus objetivos. Promovendo SUPORTE - TREINAMENTO - AUXÍLIO para os times Scrums Resumo P3 6  Um Dono do produto: é responsável por maximizar o valor de negócio do produto, alinhando as necessidades dos clientes e priorizando o backlog com base no retorno sobre o investimento. Ele coordena o time Scrum, define critérios de aceitação, controla o progresso e o orçamento do projeto, e garante a entrega conforme as expectativas dos stakeholders. Um Scrum Master: Tem como objetivo dentro do NIT assegurar que as regras do Nexus sejam atendidas. Pode fazer parte de um ou mais times scrum. Um ou mais membros do time de integração nexus: responsáveis por treinar e orientar os times scrum a implementar e aprender sobre práticas de ferramentas contínuas, padrões de desenvolvimentos pretendidos, integração contínua entre outros. Eventos do Nexus Cross-Team Refinement: é o refinamento do backlog; Nexus Sprint Planning: nesse evento a meta da sprint do nexus que se alinha com a meta do produto; Nexus Daily Scrum: visa identificar problemas de integração e acompanhar o progresso da sprint no Nexus, com representantes dos times Scrum compartilhando status, interdependências e propondo soluções para desafios comuns; Nexus Sprint Review: é realizada ao final da sprint para oferecer um feedback do incremento integrado e determinar adaptações futuras. Essa revisão substitui as revisões de sprint dos times individuais; Nexus Sprint Retrospective: como objetivo planejar maneiras de melhorar a qualidade e eficácia em todo o Nexus, inspecionando a última sprint em relação a indivíduos, processos, interações, ferramentas e a definição de pronto. Quando usar? Quando não usar? Resumo P3 7  Quando o projeto precisa de Quando os times não depende vários times para desenvolver. um do outro; Quando o produto é construído com pequenos componentes; Artefatos Backlog do produto: Quando implementamos o backlog do produto, devemos definir o Product Goal (Meta do Produto). Backlog da Sprint Nexus: define o Nexus Sprint Goal (Meta da Sprint Nexus), sendo a única que deve ser atingida conjuntamente por todos os times. A diferença é que o backlog da sprint nexus é realizada para compor todos os backlogs das sprints dos scrums individuais. Incremento Integrado: a definição de pronto é de responsabilidade do time de integração nexus. Deve garantir o incremento do produto integrado ao final de cada sprint. Pré-requisitos Para adotar o Nexus, é necessário que os times tenham experiência com Scrum, um único backlog de produto, um time de integração definido, uma definição de pronto estabelecida antes da primeira sprint, sprints com time- boxe sincronizadas entre os times e equipes compostas por Scrum Masters e desenvolvedores. Por que entre 3 e 9 times? 9 = Por causa do número de Dunbar, no qual é uma métrica que determina que nosso cognitivo é limitado a um número de pessoas no qual podemos nos relacionar, sabendo o que cada um faz; 3 = Não há necessidade de implementação do Nexus entre dois times! Podemos apenas ter dois times bem organizados. Resumo P3 8  Requisitos mínimos Único backlog de produto; Time de Integração Nexus (NIT) com papéis definidos; Definição de pronto antes da primeira sprint; Time-box estabelecido; Sincronia entre os times; Times compostos por Scrum Master e desenvolvedores; Apenas um dono do produto no Nexus. GERENCIAMENTO DE DEPENDÊNCIA Inferno das dependências: quando há um grande volume de dependências de código interno e externo; Arquitetura Monolítica Normalmente aplicado a sistemas com menor escala; Todo o código implementado de forma única e acoplado, onde todos os módulos utilizados estão em um único local e compartilham recursos variados. Arquitetura de Microserviços Normalmente aplicado a sistema que tem a ter maior escala; Coloca cada funcionalidade em um serviço separado no qual cada um funciona em seu próprio processo. Quanto mais complexo o sistema menor será o custo de manutenção; Quebra barreiras do monolítico: Maior estabilidade na manutenção e evolução dos serviços. Resumo P3 9  Serviços com baixo acoplamento e interdependências, facilitando a manutenção. Escalabilidade independente de servidores e máquinas virtuais. Redução de custos com serviços otimizados para funcionalidades e carga. Flexibilidade tecnológica, sem amarração a uma única linguagem ou tecnologia. Facilidade de deploy, sem necessidade de reinicializar todo o sistema. Riscos Promove Complexidade na coordenação Escalabilidade Controle na comunicação de Variedades tecnológicas microserviços Controle da governança de processos Resiliência Facilidade de implantação Capacidade de composição Substituição de código Manutenção mais eficiente Código Proprietário e Colaborativo Propriedade Estrita de Código: módulo de código exclusivamente de uma pessoa. Caso necessite alterar algo no código precisa de permissão do “dono”; Propriedade Restrita de Código: módulos são atribuídos aos mantenedores, mas desenvolvedores podem modificar os códigos de outras pessoas - pedindo a permissão para isso - e eles devem estar de olho nessas modificações; Propriedade Coletiva de Código: código é compartilhada pelo time todo, e todos estão livres para modificar o código (refatoração ou reescrita); Resumo P3 10  Problemas com propriedade Problemas com propriedade estrita de código coletiva de código A propriedade estrita de código pode A propriedade coletiva de código isolar desenvolvedores, gerar pode causar inconsistências, bugs, dependências e gambiarras, além de falta de responsabilidade e levar a um investimento excessivo de desenvolvimento mais lento, pois os tempo em melhorias desnecessárias, desenvolvedores precisam entender prejudicando a colaboração e a o código dos outros. produtividade da equipe. Código Interativo/compartilhado/colaborativo: funciona melhor quando todos têm conhecimento semelhante, confiam uns nos outros, mantêm a base de código em bom estado e utilizam testes unitários para detectar problemas nas mudanças. Modelos de código compartilhado funcionam quando todos entendem a arquitetura, praticam disciplina técnica e Pair Programming, mas algumas partes do sistema não podem ser compartilhadas devido a limitações de conhecimento. Rodando o Nexus Mapeamento de dependências - User Story Mapping Ferramenta que cria uma lista de itens do backlog do produto e um mapa das histórias de usuários. Aplicação deve ser feita em grupo com contribuidores de várias áreas além do desenvolvedor, como um designer e até mesmo os clientes; Para desenvolver essa técnica, é possível utilizar flipchart, mesa, caneta, post-its e um time multidisciplinar de 4 a 8 participantes. As fases do método O método, aplicado na fase inicial do projeto, envolve listar as funcionalidades do produto (Passo 1), organizar em fluxo lógico (Passo 2), priorizar as tarefas pela criticidade (Passo 3) e agrupá-las em temas (Passo 4). Por fim, no Passo 5, é selecionado o MVP. Resumo P3 11  Mapeamento de dependências - Impact Mapping A técnica ajuda a identificar incertezas, conexões e tomar decisões alinhadas ao objetivo do negócio, permitindo entregar um MVP. Ela é simples, baseando-se em fazer as perguntas certas para determinar o que é necessário para alcançar o objetivo do projeto. Resumo P3 12  Mapeamento de dependências - Cross Team Dependency Board No Nexus devido a complexidade do processo de gerenciamento, o refinamento do backlog do produto se torna obrigatório e é um evento oficial. Isso é feito pelos times e eles podem se concentrar em remover dependência entre eles. O quadro ajuda a visualizar dependências entre equipes, com cada linha representando um time e cada coluna uma sprint. O dono do produto explica os itens a serem refinados e os participantes discutem as habilidades necessárias para cada tarefa; Resumo P3 13  As dependências são divididas em: 1) Sequência de construção, onde um item depende da conclusão de outro; 2) Pessoas ou habilidades, onde apenas equipes específicas podem concluir o item; 3) Externa, quando a conclusão depende de fornecedores fora do Nexus. Refinamento de Backlog Product Owner é responsável por analisar e refinar o backlog; O Refinamento é contínuo ao longo da Sprint quando necessário e apropriado, até que os Itens do Backlog do Produto estejam suficientemente independentes para serem trabalhados por um único Time Scrum sem conflitos excessivos. Haverá muita conversa entre Product Owner e parte interessada antes que o produto possa entrar no backlog do produto; Desse modo, é de responsabilidade do PO definir um status de “Preparado” - Ready para item do backlog; Cross Team Refinement: participam representantes selecionados de cada equipe e deve do workshop com base no trabalho que está sendo aprimorado e não no papel que desempenham dentro de sua equipe. Pode ser comum que diferentes pessoas participem desses workshops com base nas habilidades exigidas; Durante o Planejamento da Sprint do Nexus, representantes apropriados de cada Time Scrum validam e fazem os ajustes na ordenação do trabalho criado durante os eventos de Refinamento. Todos os membros dos Times Scrum devem participar para minimizar os problemas de comunicação. Resumo P3 14