Nexus Guide - Amazon Web Services › drupal...3. Artefactos de software e teste: Os requisitos são...

Nexus™ Guide

O guia decisivo de Nexus:

O exoesqueleto de desenvolvimento Scrum em escala

Desenvolvido e mntido por Ken Schwaber e Scrum.org

Agosto 2015

Copyright de Scrum.org, 2015 Todos os direitos reservados Página 1 (Versão 1.1)

Índice

Visão Geral do Nexus ..................................................................................................................... 2

Objetivo do Guia Nexus ..................................................................................................................2

Definição de Nexus.........................................................................................................................2

Antecedentes do Nexus ..................................................................................................................2

A Framework Nexus .......................................................................................................................3

Fluxo do Processo Nexus ................................................................................................................4

Práticas de Software.......................................................................................................................5

Nexus............................................................................................................................................... 5

Papéis Nexus ..................................................................................................................................5

Equipa de Integração Nexus .........................................................................................................5 Eventos Nexus................................................................................................................................6

Sprint Planning do Nexus .............................................................................................................7

Daily Scrum do Nexus ..................................................................................................................7

Sprint Review do Nexus................................................................................................................8

Retrospetiva do Sprint Nexus .......................................................................................................8 Refinamento ...............................................................................................................................9

Artefactos Nexus ............................................................................................................................9 Backlog de Produto .....................................................................................................................9

Objetivo Nexus .......................................................................................................................... 10

Backlog do Sprint Nexus ............................................................................................................ 10

Incremento Integrado................................................................................................................ 10

Transparência dos Artefactos ....................................................................................................... 10 Definição de “Done” .................................................................................................................. 11

Nota Final .................................................................................................................................... 11

Reconhecimento .......................................................................................................................... 11

TRANSLATED BY:

Catia Oliveira & Susana Cabaco

mailto:[email protected]

mailto:[email protected]


Visão Geral do Nexus

Objetivo do Guia Nexus O Nexus é uma estrutura (framework) cujo objetivo é suportar o desenvolvimento em escala de

produtos e software. Utiliza o Scrum como base. Este guia contém a definição de Nexus. Esta

definição consiste em papéis (funções), eventos, artefactos e regras que os unem. Os seus

autores são Ken Schwaber e Scrum.org. O guia Nexus é escrito e fornecido por eles.

Definição de Nexus Nexus (n): Unidade de Desenvolvimento (em Scaled Professional Scrum)

Nexus é uma framework que consiste em papéis (funções), eventos, artefactos e técnicas que

ligam e unem o trabalho de aproximadamente três a nove equipas Scrum que trabalham num

único Backlog de produto para produzir um incremento integrado, que atingirá um objetivo.

Antecedentes do Nexus O desenvolvimento de software é complexo e a integração desse trabalho em algo considerado

final e funcional inclui muitos artefactos e atividades que têm de ser coordenadas para criar um

resultado considerado “Done” (i.e. concluído, completo). O trabalho tem de ser organizado,

ordenado, as dependências resolvidas e os resultados têm de ser faseados. Sendo algo que

não é fisicamente presente, o software apresenta dificuldades adicionais.

Muitos programadores já utilizaram a framework Scrum para trabalhar coletivamente como uma

equipa no sentido de desenvolver incrementos de software funcional. No entanto, se mais do

que uma equipa Scrum está a trabalhar a partir do mesmo Backlog de produto e na mesma

codebase para um produto, as dificuldades começam a surgir. Se os programadores não

estiverem a trabalhar na mesma equipa e fisicamente no mesmo local, como é que comunicam

quando estão a fazer trabalho que os afeta uns aos outros? E se trabalham em equipas

diferentes, como é que integram o seu trabalho e testam o resultado dessa integração? Estes

desafios surgem logo quando apenas duas equipas estão a integrar partes do produto e

tornam-se significativamente mais difíceis com três ou mais equipas.

Há muitas dependências que surgem entre o trabalho de várias equipas que colaboram para

criar um incremento completo (“Done”) em cada Sprint. Tais dependências estão relacionadas

com:

1. Requisitos: O âmbito dos requisitos pode cruzar-se ou sobrepor-se e a forma como eles

são implementados também pode afetá-los mutuamente. Esse conhecimento tem de

ser considerado ao ordenar e ao selecionar requisitos do Backlog de produto.

2. Conhecimento do Domínio: as pessoas nas equipas têm conhecimento de diversas

áreas de negócio e de diversos sistemas de computação. Esse conhecimento deveria

ser mapeado nas equipas Scrum para garantir que está distribuído de forma adequada


e se minimizam interrupções entre equipas durante um Sprint.

3. Artefactos de software e teste: Os requisitos são ou vão ser instanciados em código de

software e test suites.

A dependência entre as equipas pode ser reduzida na medida em que requisitos, o

conhecimento dos membros da equipa e os artefactos de código/teste são mapeados para as

equipas de Scrum.

Quando se escala o desenvolvimento usando Scrum, estas dependências de requisitos,

conhecimento do domínio e artefactos de software/teste deveriam orientar a organização das

equipas. Se assim for, a produtividade será otimizada.

A Framework Nexus Nexus é um exosqueleto que assenta em múltiplas equipas Scrum quando estas são

combinadas para criar um incremento integrado. O Nexus é consistente com o Scrum e as

suas partes serão familiares para aqueles que já trabalharam em projetos Scrum. A diferença

reside em que mais atenção é prestada às dependências e interoperação entre equipas Scrum,

para que um incremento completo (“Done”) seja entregue em cada Sprint.

Como se mostra no gráfico abaixo, o Nexus consiste em:

● Papéis: existe um novo papel, denominado Equipa de Integração Nexus, que serve para

coordenar, orientar e supervisionar a aplicação do Nexus e a operação do Scrum de

forma a que os melhores resultados sejam atingidos. Esta equipa consiste num Product

Owner, um Scrum Master e restantes membros da equipa de Integração Nexus.

● Artefactos: Todas as equipas Scrum utilizam o mesmo e único Backlog de produto. À

medida que os itens desse Backlog ficam prontos e refinados, tornam-se visíveis os

indicadores de qual é a equipa que irá efetuar o trabalho relativo aos mesmos num

Sprint. Surge então um novo artefacto, o Backlog do Sprint Nexus, que existe para

assistir o trabalho do Sprint de forma transparente. Todas as equipas Scrum mantêm o

seu Backlog de Sprint individual.

● Eventos: os eventos são anexados, circundam ou substituem (no caso da Sprint

Review) os eventos Scrum normais para os aumentar. São modificados de forma a

servir tanto o esforço de todas as equipas Scrum no Nexus como cada equipa

individual.


Framework Nexus™, exosqueleto do Scrum em escala

Fluxo do Processo Nexus Todo o trabalho num Nexus pode ser feito por todos os membros das equipas Scrum como

membros multidisciplinares do Nexus. Com base nas dependências as equipas podem

selecionar os membros mais adequados para efetuar trabalho específico.

● Refinar o Backlog de produto: o Backlog de produto precisa de ser decomposto para

que se identifiquem, removam e/ou minimizem dependências. Os itens do Backlog de

produto são refinados em fatias mais pequenas de funcionalidade e a equipa que mais

provavelmente vai realizar o trabalho deverá ser identificada o mais cedo possível.

● Planeamento do Sprint Nexus: os elementos representantes e mais apropriados de

cada equipa Scrum reúnem-se para discutir e rever o Backlog de produto refinado.

Selecionam então itens do Backlog de produto para cada equipa. Cada equipa Scrum

vai então planear o seu Sprint, interagindo com outras equipas da forma mais

adequada. O resultado é um conjunto de objetivos de Sprint que alinham com o objetivo

Nexus, com o Backlog de cada equipa Scrum e com o que se chama o Backlog do

Sprint Nexus. O Backlog do Sprint Nexus torna transparentes as dependências e os

itens do Backlog de produto selecionados por cada equipa.

● Trabalho de desenvolvimento: Todas as equipas desenvolvem software, integrando

frequentemente o seu trabalho para um ambiente comum que pode ser testado para

garantir que a integração é feita.

● Daily Scrum Nexus: os representantes de cada equipa de desenvolvimento Scrum

reúnem-se diariamente para identificar se existem problemas de integração. Se forem

identificados, esta informação é então levada para cada equipa e respetiva Daily Scrum.

As equipas Scrum usam a sua Daily Scrum para criar um plano para o dia, assegurando

que resolvem os problemas de integração levantados durante a Daily Scrum Nexus.


● Sprint Review Nexus: Todas as equipas reúnem com o Product Owner para rever o

incremento integrado. Podem ser feitos ajustes ao Backlog de produto.

● Retrospetiva do Sprint Nexus: os representantes apropriados de cada equipa Scrum

reúnem-se para identificar desafios comuns. Depois disso, cada equipa Scrum conduz a

sua própria retrospetiva do Sprint. Os representantes apropriados de cada equipa

reúnem-se então novamente para discutir quaisquer ações que sejam necessárias

executar com base nos desafios comuns e partilhar informação.

Práticas de Software Muitas práticas de desenvolvimento de software são necessárias para ligar o trabalho das

equipas Scrum que colaboram para criar um incremento integral. Muitas destas práticas

requerem automação. A automação ajuda a manter o volume e complexidade do trabalho e

artefactos, especialmente em ambientes de escala.

Nexus Os papéis, eventos e artefactos Nexus herdam o propósito, atributos e intenções dos

correspondentes papéis, eventos e artefactos Scrum documentados no guia do Scrum.

Papéis Nexus Um Nexus consiste numa equipa de integração Nexus e aproximadamente três a nove equipas

Scrum.

Equipa de Integração Nexus

A equipa de integração Nexus é responsável por assegurar que um incremento integrado (a

combinação do trabalho completado por um Nexus) é produzido em cada Sprint. As equipas

Scrum são responsáveis por desenvolver incrementos de software potencialmente pronto a

entrar em produção, tal como prescrito no Scrum. Todos os papéis para os membros das

equipas Scrum estão descritos no guia do Scrum.

Uma equipa de integração Nexus é uma equipa Scrum que contém:

● Um Product Owner

● Um Scrum Master

● Um ou mais membros de equipa de integração Nexus

Os membros da equipa de integração Nexus também podem trabalhar nas equipas Scrum

desse Nexus da forma considerada apropriada e necessária. Se for esse o caso, a prioridade

tem de ser dada ao trabalho da equipa de integração Nexus. Pertencer a esta equipa toma

precedência sobre pertencer a uma equipa Scrum individual. Esta preferência ajuda a

assegurar que o trabalho de resolver problemas que afetam diversas equipas tem prioridade.

A composição da equipa de integração Nexus pode mudar com o tempo para refletir as

necessidades do Nexus. As atividades mais comuns da equipa de integração Nexus podem


incluir treinos, consultoria e realçar o conhecimento e perceção dos problemas e dependências

entre equipas. Podem também incluir a execução de trabalho contido no Backlog de produto.

O Product Owner na equipa de Integração Nexus

Um Nexus trabalha a partir de um Backlog de produto único e, como descrito na framework

Scrum, um Backlog de produto tem um único dono (Product Owner) que é quem tem a palavra

final acerca do seu conteúdo. O Product Owner é responsável por maximizar o valor do produto

e o trabalho efetuado e integrado pelas equipas Scrum e pertence à equipa de integração

Nexus.

O Product Owner é responsável por ordenar e refinar o Backlog de produto de forma a que se

derive o máximo valor do incremento integrado criado por um Nexus. A forma como isso é feito

pode variar entre organizações, Nexus diferentes, equipas Scrum e indivíduos.

Scrum Master na Equipa de Integração Nexus

O Scrum Master na equipa de integração Nexus tem a responsabilidade geral de assegurar

que a framework Nexus é entendida e concretizada. Este Scrum Master também pode ser

Scrum Master numa ou mais equipas Scrum desse Nexus.

Membros da Equipa de Integração Nexus

O trabalho de desenvolvimento em escala requer ferramentas e práticas que as equipas de

Scrum individuais podem não utilizar com frequência. A equipa de integração Nexus consiste

em profissionais de software que têm competência na utilização destas práticas, ferramentas e

no âmbito geral de engenharia de sistemas. A equipa de integração nexus garante que as

práticas e ferramentas são implementadas, entendidas e utilizadas para detetar dependências

e integrar frequentemente todos os artefactos de acordo com uma definição de completude

(“Done”).

Os membros desta equipa são responsáveis por treinar e guiar as equipas Scrum num Nexus

para que estas adquiram, implementem e aprendam estas práticas e ferramentas.

Adicionalmente, treinam os membros dessas equipas no desenvolvimento, infraestruturas e

standards arquiteturais necessários à organização para assegurar o desenvolvimento de

incrementos integrados com qualidade.

Se a sua responsabilidade primária for satisfeita, os membros da equipa de integração Nexus

também podem trabalhar como membros de equipas de desenvolvimento nas restantes

equipas Scrum.

Eventos Nexus A duração dos eventos Nexus é guiada pela duração dos eventos correspondentes no guia

Scrum. São blocos de tempo (time boxes) adicionais às correspondentes nos eventos Scrum.


Sprint Planning do Nexus

O objetivo do planeamento do Sprint (“Sprint Planning”) do Nexus é coordenar as atividades de

todas as equipas Scrum de um Nexus num Sprint. O Product Owner fornece o conhecimento

do domínio e guia a seleção de itens e prioriza decisões.

Para iniciar o Sprint Planning do Nexus, os representantes apropriados de cada equipa Scrum

validam e fazem ajustes à ordem do trabalho criado durante os eventos de refinamento. Todos

os membros das equipas Scrum devem participar para que se minimizem os problemas de

comunicação.

O objetivo (“Goal”) do Sprint Nexus é formulado durante o planeamento. Descreve o objetivo

que será atingido pelas equipas Scrum durante o Sprint. Quando o trabalho geral para o Nexus

estiver entendido, cada equipa Scrum vai então fazer o seu próprio Sprint Planning. Se a

reunião for feita num espaço comum, as equipas podem continuar a partilhar novas

dependências encontradas. O Sprint Planning do Nexus está completo quando cada equipa

Scrum terminar o seu próprio Sprint Planning.

Durante o planeamento do Sprint do Nexus podem emergir novas dependências. Estas devem

ser visualizadas e minimizadas. A sequência de trabalho entre equipas também pode ser

ajustada. Um Backlog de produto adequadamente refinado irá minimizar o surgimento de novas

dependências durante o planeamento do Sprint do Nexus. Todos os itens de Backlog

selecionados para o Sprint e suas dependências devem estar visíveis no Backlog do Sprint do

Nexus.

O Backlog do produto deve estar adequadamente refinado com dependências identificadas e

removidas ou minimizadas antes do planeamento do Sprint do Nexus.

Daily Scrum do Nexus

A Daily Scrum do Nexus é um evento para os representantes apropriados de cada equipa

individual de desenvolvimento Scrum inspecionar o estado atual do incremento integrado e

identificar problemas de integração ou novas dependências que se tenham descoberto.

Durante a Daily Scrum os participantes devem forcar-se no impacto de cada equipa no

incremento integrado e discutir:

● O dia de trabalho anterior foi integrado com sucesso? Se não, porquê?

● Que novas dependências foram identificadas?

● Que informação precise de ser partilhada entre equipas do Nexus?

Durante a Daily Scrum do Nexus, o Backlog do Sprint deve ser utilizado para visualizar e gerir

as dependências existentes.


O trabalho que é identificado durante a Daily Scrum do Nexus é então levado para as equipas

de Scrum individuais para ser planeado durante os seus próprios eventos Daily Scrum.

Sprint Review do Nexus

A Sprint Review do Nexus é efetuada no final do Sprint para fornecer feedback sobre o

incremento integrado que o Nexus construiu durante esse Sprint.

Uma Sprint Review Nexus substitui as Sprint Reviews individuais porque o foco é todo o

incremento e é aqui que se captura feedback dos diferentes participantes. Pode não ser

possível mostrar todo o trabalho em detalhe e pode ser necessário recorrer a técnicas que

maximizem o feedback dos participantes.

Retrospetiva do Sprint Nexus

A retrospetiva do Sprint Nexus é uma oportunidade formal para um Nexus se poder focar na

inspeção e adaptação.

Consiste em três partes:

1. A primeira parte é uma oportunidade para os representantes apropriados do Nexus se

reunirem e identificarem problemas que tenham tido impacto em mais do que uma

equipa. O objetivo é tornar problemas partilhados transparentes a todas as equipas

Scrum

2. A segunda parte consiste em cada equipa Scrum efetuar a sua própria retrospetiva

como descrita na framework Scrum. Podem pegar em problemas levantados na

primeira parte da retrospetiva Nexus como dados de entrada para as suas discussões

de equipa. As equipas Scrum individuais devem criar ações dirigidas a estes problemas

durante as suas retrospetivas individuais.

3. A terceira (e final) parte é uma oportunidade para os representantes de cada equipa

Scrum se reunirem de novo e acordarem em como visualizar e monitorizar as ações

identificadas. Isto permite ao Nexus como um todo adaptar-se.

Porque são disfunções comuns e em escala, cada retrospetiva deveria tocar nos seguintes

assuntos:

● Houve algum trabalho que não tenha sido iniciado? Será que o Nexus gerou technical

debt?

● Será que todos os artefactos, em particular código, foram integrados com sucesso e

frequentemente (de preferência diariamente)?

● O software foi compilado, testado e instalado com regularidade suficiente para prevenir

a acumulação de dependências por resolver?

Para as questões acima, se necessário, discutir:

● Porque é que isto aconteceu?

● Como se pode remover a technical debt?

● Como se pode prevenir a recorrência do mesmo problema?


Refinamento

À escala do Nexus há muitos níveis de refinamento. Só quando os itens do Backlog de produto

são adequadamente independentes é que podem ser selecionados e trabalhados sem conflito

excessivo entre as equipas Scrum de um Nexus.

O número, frequência, duração e comparecimento em reuniões de refinamento baseiam-se nas

dependências inerentes ao Backlog de produto. Quanto maior for a complexidade e o número

de dependências, mais os itens do Backlog de produto têm que ser refinados para remover

dependências. Os itens do Backlog de produto passam por diferentes níveis de decomposição,

desde conceitos muito vagos e grandes até trabalho que pode ser acionado e que uma equipa

Scrum pode entregar num Sprint.

O refinamento do Backlog de produto em escala serve um propósito duplo. Prevê qual a equipa

que vai entregar um dado grupo de itens do Backlog e identifica dependências entre essas

equipas. A visualização permite às equipas monitorizar e minimizar as dependências.

A primeira parte do refinamento entre-equipas deve ser passada decompondo os itens do

Backlog de produto em detalhe suficiente para se perceber que equipas podem entregá-los e

em que ordem ao longo dos próximos Sprints.

A segunda parte do refinamento deve ser passada focando as dependências. Estas devem ser

identificadas e visualizadas entre equipas e Sprints. As equipas necessitam desta informação

para reordenar e alocar o seu trabalho de forma a minimizar o número de dependências entre-

equipas.

Têm de ser efetuadas reuniões de refinamento suficientes durante um Sprint para que os itens

do Backlog de produto estejam prontos e selecionáveis com o mínimo de dependências

durante uma reunião de planeamento de um Sprint.

Artefactos Nexus Os artefactos representam trabalho ou valor para fornecer transparência e oportunidades para

inspecionar e adaptar como descrito no guia do Scrum.

Backlog de Produto

Só existe um Backlog de produto no Nexus e para todas as suas equipas Scrum. O Product

Owner é responsável pelo Backlog de produto incluindo o seu conteúdo, disponibilidade e

ordenação.

Em escala, o Backlog de produto tem de ser entendido a um nível em que as dependências

possam ser detetadas e minimizadas. Para dar suporte à resolução, os itens do Backlog de

produto são frequentemente resolvidos a uma granularidade funcional dita “fina”. Os itens do

Backlog de produto são dados como prontos (“Ready”) para uma reunião de planeamento de


um Sprint Nexus quando podem ser selecionados para ser feitos pelas equipas Scrum sem

dependências ou com dependências mínimas sobre outras equipas Scrum.

Objetivo Nexus

Durante a reunião de planeamento do Sprint Nexus, deve ser formulado um objetivo para o

Sprint (“Goal”). Este é denominado o objetivo do Nexus e consiste na soma de todo o trabalho

e objetivos dos Sprints de cada equipa Scrum individual pertencente ao Nexus. O Nexus

deverá demonstrar na Sprint Review a funcionalidade que eles desenvolveram para atingir o

objetivo.

Backlog do Sprint Nexus

O Backlog de um Sprint Nexus consiste na composição de todos os itens do Backlog de

produto que foram selecionados para os Backlogs de Sprint das equipas Scrum individuais. É

utilizado para realçar as dependências e o fluxo de trabalho durante o Sprint. É atualizado no

mínimo diariamente, regularmente como parte da Daily Scrum do Nexus.

Incremento Integrado

O incremento integrado representa a soma de todo o trabalho integrado e completo, efetuado

por um Nexus. O incremento integrado tem de ser utilizável e potencialmente capaz de ser

colocado em produção e deve ser fiel e representativo da definição de completo (“Done”). Este

incremento integrado é inspecionado na Sprint Review do Nexus.

Transparência dos Artefactos

Tal como o a sua fundação (Scrum), o Nexus baseia-se em transparência. A equipa de

integração do Nexus trabalha com as equipas Scrum dentro de um Nexus e com a organização

para assegurar que a transparência é real e aplicada em todos os artefactos e que o estado

integrado do incremento é entendido da mesma forma por todos os envolvidos.

As decisões tomadas com base no estado dos artefactos do Nexus são tão eficazes como o

nível de transparência do artefacto. Informação incompleta ou parcial leva a decisões incorretas

ou com falhas, o pode ter impacto em todo o Nexus. A falta de transparência completa faz com

que seja impossível guiar o Nexus de forma eficaz e minimizando o risco ao mesmo tempo que

se maximiza o valor.

O software tem de ser desenvolvido de forma a que as dependências sejam detetadas e

resolvidas antes que se acumule e torne inaceitável o nível de technical debt. O teste à

technical debt inaceitável é feito quando a integração ocorre e continua a não ser claro se todas

as dependências estão resolvidas. Nestes casos, as dependências por resolver ficam

escondidas no código e na base de testes, baixando o valor global do software.


Definição de “Done”

A equipa de integração Nexus é responsável por uma definição de completude (“Done”) que

possa ser aplicada ao incremento integrado desenvolvido em cada Sprint. Todas as equipas

Scrum de um Nexus aderem a esta definição de “Done”. O incremento está “Done” apenas

quando utilizável e passível de ser colocado em produção pelo Product Owner.

Um item do Backlog de produto pode ser considerado completo ou concluído (“Done”) quando

essa funcionalidade tiver sido adicionada ao produto e integrada no incremento com sucesso.

Todas as equipas Scrum são responsáveis por desenvolver e integrar o seu trabalho num

incremento satisfazendo os atributos/propriedades especificados na definição de “Done”.

Equipas Scrum individuais podem escolher aplicar uma definição de “Done” mais rigorosa

dentro das suas próprias equipas, mas não podem aplicar critérios menos rigorosos do que

aqueles acordados para o incremento.

Nota Final

O Nexus é gratuito e oferecido neste guia. Tal como a framework Scrum, os papéis, artefactos,

eventos e regras no Nexus são imutáveis. Embora a implementação parcial do Nexus seja

possível, o seu resultado não poderá ser apelidado de Nexus.

Reconhecimento

Nexus e Scrum Profissional Dimensionado ou em Escala foram desenvolvidos de forma

colaborativa por Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher,

Steve Porter, Christina Schwaber, e Gunther Verheyen.

Nexus Guide - Amazon Web Services › drupal...3. Artefactos de software e teste: Os requisitos são...

Documents

Transcript of Nexus Guide - Amazon Web Services › drupal...3. Artefactos de software e teste: Os requisitos são...