1. Outros assuntos
1.1. Organização de times
1.1.1. Os times deve ser organizados de forma a minimizar as dependências entre times
1.1.2. Uma pessoa que trabalha em múltiplos times perde muita produtividade
1.1.3. Adicionar mais equipes não necessariamente vai garantir aumento da entrega de valor ou de produtividade
1.1.4. Equipes baseadas em features têm menos sobrecarga de comunicação.
1.2. Arquitetura
1.2.1. A equipe de desenvolvimento deve ter um conjunto de princípios de arquitetura que todo integrante da equipe de desenvolvimento entende e segue ao escrever o código.
1.2.2. A arquitetura é uma discussão em andamento na equipe de desenvolvimento, concentrando-se na implementação dos itens atuais do Backlog do Sprint.
1.3. Débito técnico
1.3.1. Isso leva a falsas suposições sobre o estado atual do sistema, especificamente de um Incremento que pode ser liberado no final de um Sprint.
1.3.2. À medida que o desenvolvimento progride e o código é adicionado, o sistema se torna mais difícil de se estabilizar, o que faz com que o trabalho futuro seja desacelerado de maneiras imprevisíveis.
1.4. Sprints
1.4.1. Não é necessário que todos os times comecem na mesma data
1.4.2. A duração das Sprints está relacionada a vários aspectos
2. Definição do Nexus
2.1. Um relacionamento ou conexão entre pessoas ou coisas.
2.2. Um framework constituído de papéis, eventos, artefatos e regras
2.3. 3 a 9 Times Scrum em um único Backlog do Produto
3. O Pano de Fundo do Nexus
3.1. Principais dependências que aparecem com múltiplos times
3.1.1. Requisitos
3.1.2. Domínio de Conhecimento
3.1.3. Software e artefatos de teste
4. Fluxo do Processo do Nexus
4.1. Refinar o Product Backlog
4.2. Planejamento de Sprint do Nexus
4.3. Trabalho de Desenvolvimento
4.4. Reunião Diária do Nexus
4.5. Revisão da Sprint do Nexus
4.6. Restrospectiva da Sprint do Nexus
5. Papéis do Nexus
5.1. Time de Integração do Nexus
5.1.1. Ponto focal de integração para o Nexus.
5.1.2. Composto de
5.1.2.1. O Product Owner
5.1.2.1.1. Só vai existir um, uma vez que só existe um Backlog de Produto
5.1.2.1.2. Maximiza o valor do incremento integrado criado
5.1.2.1.3. Tem a palavra final em relação ao Backlog do Produto
5.1.2.2. Um Scrum Master
5.1.2.2.1. Tem a responsabilidade geral de garantir que o framework Nexus seja entendido e publicado oficialmente
5.1.2.2.2. Também pode ser Scrum Master dos times individuais
5.1.2.2.3. Tem a responsabilidade de garantir que todos os eventos do Nexus são realizados
5.1.2.3. Um ou mais Membros do Time de Integração do Nexus
5.1.2.3.1. Também são membros de um Time Scrum Individual
5.1.2.3.2. Devem dar prioridade para seu trabalho no Time de Integração do Nexus
5.1.2.3.3. A composição pode mudar ao longo do tempo para refletir as necessidades do Nexus.
5.1.2.3.4. São capacitados no uso de ferramentas, várias práticas e nas áreas gerais de engenharia de sistemas.
5.1.2.3.5. Garante que os Times Scrum dentro do Nexus entendam e implementem as práticas e ferramentas necessárias para detectar dependências e frequentemente integrar todos os artefatos à definição de “Pronto”.
5.1.3. Responsabilidades
5.1.3.1. Garante (mas nem sempre vai executar) que um Incremento Integrado (o trabalho combinado e completado pelo Nexus) seja produzido pelo menos a cada Sprint.
5.1.3.1.1. Ele não é responsável por realizar o trabalho de integração, a integração deve ser feita pelos times Scrum
5.1.3.1.2. Só é invocado para realizar o trabalho de integração em último caso, quando os times Scrum estão com muita dificuldade
5.1.3.2. Ajuda a desenvolver utilitários, scripts e outras formas de automação para ajudar as equipes na integração de seu trabalho.
5.1.3.3. Treina equipes em práticas modernas de desenvolvimento e sirva como mentores.
6. Eventos do Nexus
6.1. Características
6.1.1. São anexados, colocados em volta, ou substituem (no caso da Revisão da Sprint) os eventos normais do Scrum para ampliá-los
6.1.2. São timeboxes
6.2. Refinamento
6.2.1. Ajuda os Times Scrum a preverem qual Time irá entregar cada Item do Backlog do Produto,
6.2.2. Serve também para identificar dependências entre esses times.
6.2.3. É feito até que os PBIs possam ser trabalhados por um único Time Scrum
6.2.4. É contínuo ao longo da Sprint quando necessário e apropriado.
6.2.5. Continua dentro de cada Time Scrum a fim de que os Itens do Backlog do Produto estejam preparados para seleção no evento de Planejamento do Nexus
6.3. Planejamento da Sprint do Nexus
6.3.1. Serve para coordenar as atividades de todos os Times Scrum no Nexus para uma única Sprint.
6.3.2. O Backlog do Produto deve estar refinado antes desta reunião
6.3.2.1. Um refinamento adequado do Backlog do Produto minimizará o surgimento de novas dependências durante o Planejamento da Sprint do Nexus.
6.3.3. Todos os membros dos Times Scrum devem participar para minimizar os problemas de comunicação.
6.3.3.1. Inclusive especialistas externos
6.3.4. Os times puxam os itens para trabalhar em acordo com o Product Owner
6.3.5. Meta da Sprint do Nexus é discutida pelo Product Owner
6.3.5.1. Descreve o propósito que será alcançado pelos Times Scrum durante a Sprint.
6.3.5.2. É a soma de todo o trabalho e Metas das Sprints dos Times Scrum do Nexus.
6.3.5.3. É fundamental para que os times Scrum possam avaliar como o seu trabalho está contribuindo para o progresso do produto
6.3.6. Só termina quando todos os times completarem seus eventos de Planejamento da Sprint individuais.
6.3.6.1. Os Times Scrum devem continuar compartilhando novas dependências encontradas com outros Times Scrum no Nexus.
6.3.7. Deve ser assegurado de que todas as equipes estão se comprometendo com o trabalho certo.
6.4. Reunião Diária do Nexus
6.4.1. Acontece antes das reuniões diárias de cada time individual
6.4.1.1. As reuniões diárias dos times individuais continuará existindo
6.4.1.1.1. A reunião Diária do Nexus fornece entrada no Daily Scrums individual de cada equipe, para que cada equipe possa planejar melhor seu trabalho até o próximo Daily Scrum.
6.4.2. Participam representantes dos Times de Desenvolvimento
6.4.3. Serve para inspeção da situação do incremento para identificar questões de integração
6.4.4. O que é discutido?
6.4.4.1. O trabalho do dia anterior foi integrado com sucesso? Se não, por que não?
6.4.4.2. Que novas dependências ou impactos foram identificadas?
6.4.4.3. Que informações precisam ser compartilhadas entre as equipes no Nexus?
6.5. Revisão da Sprint do Nexus
6.5.1. Substitui as Reuniões individuais de Revisão do Scrum
6.5.2. Proporciona retorno do incremento integrado que o Nexus construiu ao longo da Sprint e para adaptar o Backlog do Produto se necessário
6.5.3. Evitar fazer apresentação de trabalho individual, mas sim do incremento integrado
6.5.3.1. Isso facilita o feedback das partes interessadas
6.5.3.2. Apresentação de trabalho individual pode indicar a falta de um Time de Integração do Nexus
6.6. Retrospectiva da Sprint do Nexus
6.6.1. É uma oportunidade formal para um Nexus inspecionar e adaptar a si mesmo
6.6.2. Serve para criar um plano para que melhorias entrem em vigor na próxima Sprint para garantir melhoria continua.
6.6.3. Consiste em três partes:
6.6.3.1. 1 Serve para Identificar questões que afetam várias equipes.
6.6.3.2. 2 Consiste de cada time Scrum manter sua própria Retrospectiva da Sprint como descrito no Framework Scrum.
6.6.3.3. 3 É a oportunidade para os representantes adequados dos Times Scrum se reunirem novamente e chegarem a um acordo sobre como monitorar e controlar as ações identificadas.
7. Artefatos do Nexus
7.1. Backlog do Produto
7.1.1. Há um único Backlog do Produto para todo o Nexus e todos os Times Scrum.
7.1.2. As dependências precisam ser detectadas e minimizadas
7.1.2.1. Fundamental usar alguma técnica para facilitar a visualização de dependências
7.1.3. A ordenação deve considerar as dependências entre os itens
7.1.4. Fundamental "preparar" os PBIs para as reuniões de planejamento de sprint
7.2. Backlog da Sprint do Nexus
7.2.1. Composto pelos itens de Backlog do Produto dos Backlogs das Sprints dos Times Scrum individuais
7.2.2. Usado para destacar as dependências e o fluxo de trabalho durante a Sprint.
7.2.3. Este é atualizado pelo menos uma vez ao dia (pode ser junto com a Reunião Diária)
7.3. Incremento Integrado
7.3.1. Gerado no final de cada Sprint
7.3.2. É a soma atual de todos os trabalhos integrados completados para o Nexus.
7.3.3. Deve ser utilizável e potencialmente possível de ser entregue
8. Definição de “Pronto”
8.1. É de responsabilidade do time de Integração do Nexus
8.2. Todos os times aderem a esta definição
8.3. O incremento é “Pronto” somente quando é integrado, utilizável e potencialmente possível de ser entregue pelo Product Owner.
8.4. Pode ser melhorada ao longo do projeto.
8.4.1. Melhor momento é durante a Retrospectiva de Sprint do Nexus