Nexus – Como Escalonar Multiplos Times Scrum

0
66
gp4us - Nexus Como Escalar o Scrum

Apesar de ser um conceito novo, Nexus vem sendo cada mais difundido e utilizado pelas organizações.  Dotada de papéis, eventos, artefatos e regras, o Scrum é especialmente recomendado para cenários instáveis e ambientes onde mudanças ocorrem com frequência.

A quebra de paradigma do Modelo Tradicional para o Modelo Ágil pode, muitas vezes, causar grande desconforto entre os membros da equipe, uma vez que se torna necessário a mudança de mentalidade das pessoas, forçando-as a deixar sua zona de conforto e fazendo-as aprender novas formas de desempenhar as mesmas tarefas de forma não-trivial.

O Scrum na sua simplicidade não se mostra eficiente quando a projetos que envolvem múltiplos Times de Desenvolvimento, especialmente quando estes ultrapassam a marca de 10 Times.  Neste momento, precisamos escalar o Scrum.

Lançado pela Scrum.org com a finalidade de auxiliar as empresas a conduzir múltiplos Times de desenvolvimento, o Nexus deve ser entendido como um framework cujo objetivo é auxiliar a condução de múltiplos Times Scrum.  Trabalhar com múltiplos Times Scrum pode ser um grande desafio, uma vez que as equipes não necessariamente estarão presentes no mesmo espaço físico onde o projeto é desenvolvido.

Nexus é um framework para desenvolvimento e sustentação de iniciativas de desenvolvimento de produtos e de software em escala.  Utiliza o Scrum como Alicerce para sua construção.  É um framework constituído de papéis, eventos, artefatos e técnicas que os unem e entrelaçam junto o trabalho de aproximadamente três a nove Times Scrum em um único Backlog do Produto para construir um incremento integrado que alcance uma meta. (SCHWABER, 2013, p.2).

Desta forma, algumas dificuldades podem ser relacionadas, como, por exemplo:

  • Como manter a eficiência da comunicação uma vez que os Times não se encontram no mesmo espaço físico?
  • Como garantir a qualidade do incremento através da integração e teste?

Baseado em regras, eventos, artefatos e papéis bem semelhantes aos previstos no framework Scrum.  É uma estrutura criada para suportar de 3 a 9 times trabalhando num único produto.

Porém, a diferença mais significativa é que mais atenção é dada às dependências e ao sincronismo dos Times Scrum envolvidos, para que estes formem uma única e consistente engrenagem, a fim de entregar, com êxito, um incremento pronto e integrado ao final de cada Sprint.

O framework

Mas enfim, o que é o Nexus ?

Nexus é um exoesqueleto que permeia sobre múltiplos Times Scrum quando estes estão organizados para criar um Incremento Integrado.  A diferença é que mais atenção é dada para as dependências de interoperações entre os Times Scrum, entregando um Incremento Integrado e “Pronto” pelo menos a cada Sprint. (SCHWABER, 2013, P.3).

Mais claramente, ele é composto por regras, eventos, artefatos e papéis muito semelhantes aos já existentes no Scrum, diferenciando-se pelo fato da necessidade de se gastar mais tempo e atenção às dependências e sincronismo dos Times Scrum, idealmente de 3 a 9 Times trabalhando em um único produto.

Todo o fluxo do Nexus pode ser observado através da imagem abaixo:

gp4us - Framework Nexus - Escalonar

Podemos observar vários dos elementos presentes no Scrum como Backlog, Planejamento, Sprint e Retrospectiva, entre outros.  A maior diferença, porém, pode ser observada na composição dos Times de Desenvolvimento, onde é apresentado mais de um.

O Time de Integração do Nexus é responsável por garantir que um Incremento Integrado (o trabalho combinado e completado pelo Nexus) seja produzido pelo menos a cada Sprint. (SCHWABER, 2015, p.5)

Ou seja, dentro do Time de Integração Nexus encontramos os mesmos papéis existentes no Scrum, porém com visões e responsabilidades mais amplas.

Suas responsabilidades vão desde resolver problemas que afetem vários times a, como citado por Schwaber, garantir que todos os incrementos produzidos ao término de cada Sprint e de cada time estejam de acordo com as definições de “Pronto”.

Papéis

Um novo papel, o Time de Integração do Nexus, este existe para coordenar, treinar e supervisionar a aplicação do Nexus e a operação do Scrum para que os melhores resultados sejam obtidos. O Time de Integração do Nexus consiste de um Product Owner, um Scrum Master e os Membros do Time de Integração do Nexus.

Artefatos

Correspondem aos mecanismos e ferramentas visuais através do qual oferecemos a transparência do projeto a todas as partes interessadas oferecendo maior facilidade e flexibilidade para inspeções ou mesmo adaptações.

No Nexus, encontramos um único Backlog do Produto para todos os Times Scrum, sendo o Product Owner responsável pelo mesmo. 

Eventos

Eventos são anexados, colocados em volta, ou substituem (no caso da Revisão da Sprint) os eventos normais do Scrum para aumentá-los. Uma vez modificados, eles atendem tanto o esforço geral de todos os Times Scrum no Nexus, quanto de cada time individualizado.

Questionamentos podem então ser levantados quando projetos requerem mais do que 10 Times de Desenvolvimento.  Projetos que requerem mais do que nove ou mais equipes, você possui duas escolhas:

  • Construir estruturas arquitetônicas e de plataforma (IOS, API, etc.) que define como a funcionalidade de cada conjunto de equipes de Scrum devem entregar e interoperar;
  • Demorar mais tempo e só fazer tanto quanto os nove Times de Desenvolvimento podem fazer de uma só vez.  Em seguida, fazer mais.  Em seguida fazer mais.

 

gp4us - Nexus Backlog do Produto - Escalonar

 

Os Processos

Os processos definidos do Nexus são:

Refinar o Product Backlog

O Product Backlog precisa ser decomposto para que as dependências sejam identificadas, removidas ou minimizadas.  Os Itens do Backlog do Produto são refinados em pequenos pedaços de funcionalidades e o provável time para fazer o trabalho deve ser identificado o mais cedo possível.

Planejamento da Sprint

Representantes apropriados de cada Time Scrum se reúnem para revisar e discutir o refinamento do Backlog do Produto.  Eles selecionam os Itens do Backlog do Produto para cada time.

Trabalho de Desenvolvimento

Todos os times desenvolvem software, frequentemente integrando seu trabalho em um ambiente comum que pode ser testado para garantir que a integração está feita.

Reunião Diária

Representantes apropriados de cada Time de Desenvolvimento Scrum se encontram diariamente para identificar se existe alguma questão de integração.  Se identificado, essa informação é transferida de volta para cada reunião diária dos Times Scrum.

Revisão da Sprint

Todos os times se reúnem com o PO para revisar o incremento integrado.  Ajustes podem ser feitos no Backlog do Produto.

Retrospectiva da Sprint

Representantes apropriados de cada Time Scrum se encontram para identificar os desafios compartilhados.  Então, cada Time Scrum realiza sua Reunião de Retrospectiva do Scrum individualmente.

Os Papéis

O Time de Integração do Nexus pode ser simplesmente visto como mais um Time Scrum, porém composto por:

O Dono do Produto

O Dono do Produto é responsável por maximizar o valor do produto e do trabalho desempenhado e integrado pelos Times Scrum.  É responsável por ordenar e refinar o Backlog do Produto para que o máximo de valor seja derivado através do Incremento Integrado criado pelo Nexus.

Como no Scrum existe apenas um Product Owner responsável pelo Product Backlog, no Nexus também encontraremos apenas um Product Owner responsável pelo Product Backlog, independentemente da quantidade de Times Scrum existentes para o projeto. 

O Scrum Master

O Scrum Master no Time e Integração do Nexus possui a responsabilidade geral de garantir que o framework Nexus seja entendido e decretado.  Este Scrum Master pode também ser o Scrum Master de um ou mais times Scrum naquele Nexus.

Além de possuir todas as responsabilidades de um Scrum Master dentro de um Time de Desenvolvimento, ele também possui o desafio de fazer com que todos os princípios do Nexus sejam executados por todos e da forma correta.

Os Membros do Time

O Time de Integração do Nexus consiste de profissionais de software que são capacitados no uso de práticas, ferramentas e nas áreas gerais de engenharia de sistemas.  Garante que as práticas e ferramentas sejam implementadas, entendidas e usadas para detectar dependências e frequentemente integrar todos os artefatos na definição de “Pronto”.

São os responsáveis por difundir todas as práticas e ferramentas do Nexus para que sejam empregadas de forma correta, seja por treinamento, mentoria ou então simples orientações.

gp4us - Scrum de Scrums - Escalonar

Os Eventos

A duração dos eventos é guiada pelos tamanhos dos seus eventos correspondentes no Guia do Scrum.  Além de serem Timeboxes de seus eventos correspondentes no Scrum.

Reunião de Planejamento

O propósito da Reunião de Planejamento Nexus é coordenar as atividades de todos os Times Scrum no Nexus para uma única Sprint.  Representantes apropriados de cada Time Scrum validam e fazem os ajustes na ordenação do trabalho criado durante os eventos de Refinamento.

Reunião Diária

A Reunião Diária do Scrum no Nexus é um evento para os representantes adequados dos times de desenvolvimento Scrum individualmente inspecionarem a atual situação do Incremento Integrado e para identificarem problemas na integração ou recentes descobertas sobre as dependências entre as equipes.  Os participantes devem focar no impacto de cada time no Incremento Integrado e discutir:

  1. O trabalho do dia anterior foi integrado com sucesso? Se não, por que não?
  2. Que novas dependências foram identificadas?
  3. Que informações precisam ser compartilhadas entre as equipes no Nexus?

Revisão da Sprint

A Revisão da Sprint do Nexus é mantida no final da Sprint e proporciona retorno do Incremento Integrado que o Nexus construiu ao longo da Sprint.  A Revisão da Sprint do Nexus substitui as Reuniões individuais de Revisão do Scrum, porque todo o incremento integrado é o foco para capturar o retorno das partes interessadas.

Retrospectiva da Sprint

A Retrospectiva da Sprint do Nexus é uma oportunidade formal para um Nexus focar na inspeção e adaptação, constituindo-se em três partes:

  1. Oportunidade para os representantes adequados de todo o Nexus conhecerem e identificarem problemas que tem impacto além de um time único;
  2. Cada time Scrum mantém sua própria Retrospectiva da Sprint como descrito no Framework Scrum;
  3. Os representantes adequados dos Times Scrum se reunirem novamente e chegarem a um acordo sobre como monitorar e controlar as ações

Refinamentos

Somente quando os itens do Backlog do Produto são adequadamente independentes podem ser selecionados e trabalhos sem excessivos conflitos entre os Times Scrum.  A frequência, a duração e o número de participantes nas Reuniões de Refinamento baseiam-se nas dependências apresentadas no Product Backlog.  Desta forma, entendemos que quanto maior for a dependência e complexidade dos itens do Product Backlog, maior será o tempo gasto neste tipo de reunião na decomposição.

Os Artefatos

Artefatos representam o trabalho ou valor que fornece transparência e oportunidades para inspeção e adaptação, assim como descrito no Guia do Scrum.

Backlog do Produto

Há um único Backlog do Produto para todo o Nexus e todos os times Scrum sendo o Product Owner responsável pelo mesmo, incluindo seu conteúdo, disponibilidade e priorização.

O mesmo deve ser entendido em um nível onde as dependências possam ser detectadas e minimizadas.  Para suportar a resolução, os itens do Backlog do Produto são frequentemente resolvidos em uma granularidade chamada funcionalidades “finamente fatiadas”.

Meta

Durante a Reunião de Planejamento da Sprint do Nexus, a meta para toda a Sprint é formulada.  Esta é chamada de Meta do Nexus.

Esta é a soma de todos os trabalhos e metas das Sprints dos times Scrum individuais dentro do Nexus.  O Nexus deve demonstrar a funcionalidade que eles desenvolveram para alcançar a Meta do Nexus na Revisão da Sprint do Nexus.

Backlog da Sprint

O Backlog da Sprint do Nexus é composto por todos os itens de Backlog do Produto dos Backlogs das Sprints dos times Scrum individuais.  Este é usado para destacar as dependências e o fluxo de trabalho durante a Sprint.

Este é atualizado pelo menos uma vez ao dia, frequentemente como parte da reunião diária do Scrum no Nexus.

Incremento Integrado

Um Incremento Integrado representa a soma de todos os trabalhos integrados completados pelos Times de Desenvolvimento.  Um Incremento Integrado deve ser utilizável e potencialmente possível de ser entregue que significa que este deve atender a definição de “Pronto”.  Um Incremento Integrado é inspecionado na Revisão da Sprint do Nexus.

Transparência do Artefato

Assim como seu elemento de base, Scrum, o Nexus é baseado na transparência.

O Time de Integração do Nexus trabalha com os Times Scrum no Nexus e na organização para garantir que a transparência e aparente em todos os artefatos e que o estado integrado dos incrementos é amplamente compreendido.

Implementação

Muitas dúvidas e questionamentos surgem quando pensamos na melhor forma de se configurar e implementar o framework em organizações.

Algumas dicas práticas são:

  1. Inicie com Scrum;
  2. Implemente o Nexus de forma interativa e incremental;
  3. Conquiste um Incremento Nexus antes de adicionar mais times;
  4. Uma boa Implementação Nexus é aquela que todos seguem;
  5. Promova técnicas que encorajem o compartilhamento de conhecimento;
  6. Deixe a auto-organização surgir dentro do Nexus.

Conclusão

Para todos aqueles que já trabalham com metodologias ágeis e principalmente o Scrum, o conhecimento do Nexus é mais um passo no seu crescimento profissional em busca de novos e grandes desafios.

Não podemos nos limitar ao pensamento de que já sabemos o bastante sobre Scrum e que somos bons nas práticas ágeis.

O universo Scrum é muito amplo e ainda há muito o que ser explorado.

Próximos Passos

Maior informações podem ser obtidas no próprio site da Scrum.org, especialmente na seção blog.

Referências Bibliográficas

Salvar

Salvar

Salvar

Salvar

Salvar

Salvar

DEIXE UMA RESPOSTA

Digite seu comentário
Informe seu nome