Depois de 2 anos e meio Ken Schwaber e a Scrum.org lançaram a atualização mais recente do Guia do Nexus, a versão 2018. Mais uma vez tive o prazer e a honra de ser o tradutor oficial do Guia do Nexus para a Scrum.org juntamente com o meu camarada Eduardo Sucena. Para quem não sabe, traduzimos os Guias da Scrum.org oficialmente desde de 2011 do inglês para o português do Brasil.
Para baixar o Guia do Nexus 2018 clique aqui ou acesse https://www.fabiocruz.com.br/guia-do-nexus-2018
Nesta versão do Guia do Nexus 2018 várias mudanças foram realizadas, tanto para melhorar o entendimento de alguns conceitos, quanto para corrigir e /ou adaptar alguns pontos que não estavam tão bons e evoluir para uma versão mais completa e mais consistente, com base no empirismo aplicado nos últimos anos. Os comentários contidos neste post são referentes a minha própria análise das mudanças realizadas entre a versão de 2015 e 2018, podendo ter mais, menos ou diferentes comentários dos que os encontrados oficialmente na Scrum.org, ou no próprio guia.
Em relação as mudanças realizadas nesta versão 2018 do Guia do Nexus resolvi fizer alguns comentários sobre cada uma delas neste post para contribuir com o entendimento do novo guia e de suas atualizações. O texto está longo, mas para comentar todas as alterações que acredito ser relevante não tinha como ficar mais reduzido, espero que o valor seja maior que o tamanho :]
Bom, vamos ver quais foram as atualizações:
1 – Sub título do Guia
Na primeira versão (2015) o Guia do Nexus trouxe a descrição na capa, ou sub título, o texto “O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum em escala”. Já nesta segunda edição (2018) o Guia do Nexus traz como descrição “O Guia definitivo para escalar o Scrum com o Nexus: As Regras do Jogo”. O que podemos perceber é que o primeiro guia trouxe uma descrição mais genérica para o Nexus, orientando que o Nexus seria o Scrum em escala. Porém, nesta mais nova versão ao mudar a descrição os autores nos orientam a entender que o Guia do Nexus traz uma abordagem para escalar o Scrum com o Nexus, e que o conteúdo do guia apresenta as regras do jogo, fazendo inclusive uma referência ao próprio Scrum.
Um ponto interessante ainda nesta alteração e reescrita é o conceito de “escalar o Scrum”, mostrando que o foco é contribuir para o uso do Scrum em múltiplos Times Scrum que necessitam fazer trabalhos dependentes e juntos entregarem incrementos integrados pelo menos ao final de cada Sprint, e “Escalar o Scrum” significa isso.
A descrição do Guia do Nexus, ou para quem preferir, o sub título ficou da seguinte maneira:
O Guia definitivo para escalar o Scrum com o Nexus:
As Regras do Jogo
2 – O propósito do Guia do Nexus
Uma pequena troca de palavras foi realizada na primeira frase no primeiro parágrafo do guia, onde a palavra “desenvolvimento” foi trocada por “entrega”. Algo parecido foi feito no Guia do Scrum 2017 (para saber mais clique aqui), com o mesmo sentido. A troca de palavras aqui expressa que o autor (e autores no caso do Guia do Scrum) deseja reforçar a importância de entregar produto e software e não somente desenvolvê-lo. Sempre foi dito que um dos focos do Scrum, e agora do Nexus, é desenvolver produtos e especialmente entregá-los depois de desenvolvidos ao(s) seu(s) cliente(s), e o que esta troca reforça é que mais fundamental do que desenvolver é entregar. Desta forma o texto ficou da seguinte forma:
Nexus é um framework para desenvolvimento e sustentação de iniciativas de entrega de produtos e de softwares em escala.
3 – Definição do Nexus
Na definição do Nexus uma mudança considerável foi realizada, sendo que agora a definição expressa mais objetivamente o próprio propósito do Nexus que é realizar um trabalho diretamente nas dependências, conexões e relacionamentos entre as pessoas e os produtos que estas pessoas estão desenvolvendo. Então agora a definição do Nexus ficou da seguinte forma:
Nexus (s): um relacionamento ou conexão entre pessoas ou coisas.
Uma outra pequena alteração de palavras foi realizada neste tópico, onde a palavra “técnicas” foi trocada por “regras”, estas regras que assim como no Scrum, tem o objetivo de unir os artefatos, papéis e eventos, e que no Nexus ainda entrelaçam os trabalhos dos times que entregam um mesmo incremento de produto. O trecho alterado ficou assim:
Nexus é um framework constituído de papéis, eventos, artefatos e regras 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.
4 – Pano de fundo do Nexus
A primeira alteração no primeiro parágrafo foi a troca também da palavra “desenvolvimento” por “entrega”. Tendo o mesmo sentido de reforçar o trabalho para entregar produto e não só desenvolvê-lo. Uma frase também foi removida no primeiro parágrafo, deixando-o mais objetivo. Até mesmo porque a frase removida é uma frase meio desconectada e eu mesmo pensei quando a li pela primeira vez: “O que o autor quis dizer com esta frase mesmo?”. 🙂
A frase removida foi a seguinte:
O software demonstra dificuldades adicionais uma vez que ele não está fisicamente presente.
No segundo parágrafo houveram algumas alterações que não causam grande impacto mas ajudam no melhor entendimento dos conceitos abordados, vamos ver todas a seguir:
- Exclusão das palavras “como um time” na parte que diz que os “desenvolveres tem usado o framework Scrum para trabalhar coletivamente
como timepara desenvolver…”, principalmente porque um trabalho coletivo de várias pessoas já representa um time, sem necessidade de repetição. - Inclusão da palavra “entregar”, trazendo junto o conceito é claro, de que o time não só desenvolve mas entrega o que desenvolve. Vejam a importância do entendimento da entrega como trabalho fundamental a ser realizado pelo time.
- Inclusão da palavra “frequentemente” no trecho que diz que “quando mais de um time Scrum trabalham no mesmo produto frequentemente dificuldades emergem”. Esta alteração reforça que nem sempre as dificuldades estarão presentes, mas as chances são grandes de estarem.
- As alterações finais neste parágrafo reforçam que os trabalhos integrados do time ocorrem quando os trabalhos são realizados em um único incremento.
Ainda na parte do pano fundo, mais alterações textuais foram realizadas no trecho que fala das dependências entre os trabalhos de múltiplos times.
- No tópico requerimentos foi trocado o termo “Requerimentos” por “Itens de Backlog do Produto”, deixando um pouco mais genérico a seleção de trabalho, não limitando o entendimento apenas do termo requerimento.
- No tópico domínio de conhecimento o trecho foi reescrito para deixar claro os trabalhos distribuídos entre os múltiplos times, e a importância dos times terem conhecimento dos trabalhos que precisam fazer, e minimizar as interrupções durante a sprint. O novo texto ficou da seguinte forma:
Domínio de Conhecimento: As pessoas nos times têm conhecimento de vários negócios e sistemas de computadores. Este conhecimento pode ser distribuído entre os Times Scrum para garantir que os times tenham o conhecimento que eles precisam para fazer seu trabalho, e minimizar interrupções entre os times durante uma Sprint.
No penúltimo parágrafo do tema pano de fundo houveram mais alterações, uma delas eu considero significativa para mostrar o foco de atuação do Nexus, que vai além de código e testes de código. Justamente a palavra “código/teste” foi substituída por “Software”, reforçando que muitos dos trabalhos realizados com uso do framework Nexus circulam todos os trabalhos que envolvem o desenvolvimento de um software, incluindo dependências de arquitetura, negócio, designer, entre outros. Outra alteração no final deste parágrafo mostra que o responsável pela diminuição das dependências são os Times Scrum, não gerando mais dúvidas em relação a este trabalho com o Time de Integração do Nexus. O texto novo ficou assim:
À medida que os requerimentos, o conhecimento dos membros do time, e os artefatos de software são mapeados para os mesmos Times Scrum, os times podem reduzir o número de dependências entre eles.
Por fim no último parágrafo foi ajustado “time” para “time de desenvolvimento”, deixando claro que os trabalhos nas dependências podem interferir na definição e organização dos Times de Desenvolvimento, justamente para atender, as dependências mapeadas.
5 – Framework Nexus
No tópico que detalha o Framework do Nexus a primeira frase do primeiro parágrafo foi reescrita para deixar claro que o Nexus é um Framework para múltiplos Times Scrum trabalharem juntos na criação de um incremento integrado. O novo texto ficou da seguinte forma:
Nexus é um framework de processo para múltiplos Times Scrum trabalharem juntos para criarem um Incremento Integrado.
Outra alteração importante neste parágrafo, foi no seu final quando o autor substituiu a entrega de “um” incremento pronto, para “pelo menos um” a cada sprint. O texto ficou como segue:
A diferença é que mais atenção é dada para as dependências e interoperação entre os Times Scrum, entregando pelo menos um Incremento Integrado e “Pronto” a cada Sprint.
O título da imagem principal que representa o Framework mudou para: O Framework Nexus™ para escalar o Scrum.
6 – O Fluxo do Processo do Nexus
Alguns textos importantes foram re-escritos no fluxo do processo do Nexus, a começar pelo primeiro parágrafo que descreve o fluxo. O texto foi re-escrito para melhor entendimento do próprio Nexus e do seu fluxo, sendo que o novo texto reforça os trabalhos dos múltiplos times multi-funcionais que trabalham juntos para entregar um incremento integrado e pronto ao final de cada Sprint. Veja como ficou o trecho:
Um Nexus consiste em múltiplos Times Scrum multi-funcionais trabalhando juntos para entregar um potencial incremento integrado e possível de ser entregue pelo menos até o final de cada Sprint.
Na descrição do refinamento do backlog do produto foi removida a parte “o mais cedo possível” ao final da afirmação de que os itens do backlog do produto devem ser refinados e o time que irá fazer os trabalhos precisa ser identificado. Esta alteração nos faz pensar que é preciso realizar estes trabalhos de refinamento mas não o “mais cedo possível”. O conceito aqui é que tanto o refinamento quanto a identificação do time que fará o trabalho deve ser feito no momento mais adequado, que geralmente é próximo dos trabalhos serem realizados, e que na maioria das vezes é o “mais tarde possível”, concorda? 🙂
Outra alteração importante foi na descrição da Revisão da Sprint do Nexus, que também foi re-escrita para deixar claro o momento de realização da Revisão da Sprint do Nexus e seu propósito, além de uma mudança bem significativa ao orientar que os times devem se reunir com as partes interessadas no produto, e não mais somente com o Product Owner como na versão anterior. O texto novo ficou da seguinte forma:
A Revisão de Sprint do Nexus é feita no final da Sprint para promover comentários e opiniões sobre o incremento integrado que um Nexus construiu através da Sprint. Todos os Times Scrum individualmente se encontram com as partes interessadas para revisarem o Incremento Integrado. Ajustes podem ser feitos no Backlog do Produto.
Outro ponto adicionado a Revisão da Sprint do Nexus é que a mesma não é uma apresentação ou explicação, mas sim uma oportunidade para adaptar o Backlog do Produto e o momento de receber retornos e comentários dos Stakeholderss.
7 – Práticas de Software
O parágrafo foi totalmente removido. O autor mencionou que tais práticas são importantes e relevantes, porém é preciso elaborar um texto melhor que agregue mais valor ao conteúdo do Nexus.
8 – Papéis do Nexus
Várias alterações foram realizadas neste tópico, vamos ver as mais importantes delas separadas por papel.
Time de Integração Nexus
Mais uma vez houve a troca de “Desenvolvimento” por “Entrega” como a responsabilidade do time. Lembrando, o Time de Integração Nexus não deve somente desenvolver incrementos, mas entregá-los. Junto a isso, foi adicionado o conceito de “Pronto” a entrega de incrementos, e substituído a entrega de “Software” por entrega de “Produto”. Esta última troca (Produto) reforça que tanto o Scrum quanto o Nexus podem ser aplicados no desenvolvimento e entrega de produtos de várias origens e não somente Software. Então o texto ficou assim:
Os Times Scrum são responsáveis por entregar incrementos “Prontos” de produto potencialmente possíveis de serem entregues, como indicado no Scrum. Todos os papeis para os membros dos Times Scrum são prescritos no Guia do Scrum.
Foi removido a afirmação de que o Time de Integração do Nexus é um Time Scrum. Este era um item que gerava confusão, especialmente porque dava a impressão de que o Time de Integração do Nexus seria um Time Scrum separado do Nexus.
Ainda em relação a esta questão, uma alteração bem relevante foi adicionada. Os membros do Time de Integração do Nexus frequentemente também são membros de Times Scrum, ou seja, reforça que se houver necessidade o Time de Integração do Nexus pode ter em sua formação profissionais que não fazem parte de nenhum Time Scrum, mas podem contribuir com os trabalhos dos Times Scrum no que diz respeito a dependências e trabalhos no incremento integrado por todos os Times Scrum.
Um último trecho foi re-escrito neste parágrafo para reforçar que o foco dos membros do Time de Integração do Nexus deve ser o Nexus e não os trabalhos individuais nos Times Scrum. Isso é muito importante para evitar a confusão, ou entendimento incorreto, de que um membro do Time Scrum deve apenas trabalhar em seu time. Quando há Nexus, ou seja, a necessidade de trabalhar de forma integrada com outros Times Scrum, este trabalho no Nexus passa a ser o dever dos membros do Time Scrum que fazem parte do Time de Integração do Nexus. O trecho novo ficou da seguinte forma:
Membros do Time de Integração Nexus são frequentente membros de um Time Scrum Individual daquele Nexus. Se este for o caso, eles devem dar prioridade para seu trabalho no Time de Integração do Nexus.
Ainda sobre o Time de Integração do Nexus, foi removido o trecho que dizia que este era o Dono e tomava possa de qualquer questão de integração. Esta é uma das mudanças muito importantes, pois agora o Nexus prescreve que o os Times Scrum é que endereçam as questões de integração dentro do Nexus, e o Time de Integração do Nexus é o ponto focal para tratar os pontos endereçados pelos Times Scrum. Veja como ficou o texto reescrito:
O Time Scrum endereça questões de integração dentro do Nexus. O Time de Integração do Nexus provê um ponto focal de integração para o Nexus.
Product Owner
Em relação ao papel do Product Owner uma pequena alteração foi realizada, onde o Product Owner deixou de ser o responsável por apenas ordenar e refinar o backlog do produto dentro do Nexus, para o responsável por gerenciar o backlog do produto. Gerenciar pode envolver mais trabalhos do que ordenar e refinar, de acordo com as necessidades do Time de Integração do Nexus.
Membros do Time de Integração do Nexus
Foi removido o seguinte trecho: “O trabalho de desenvolvimento escalado exige ferramentas e práticas que indivíduos do Time Scrum podem não utilizar frequentemente”.
Foi removida também a palavra “Software” da frase “O Time de Integração do Nexus consiste de profissionais de software…”, ficando apenas “profissionais” e reforçando que o Nexus pode ter pessoas que não são especialistas em Software e que podem realizar outros trabalhos necessários para os trabalhos dos times.
9 – Eventos do Nexus
Na parte dos eventos do Nexus várias alterações foram realizadas, vamos tratar separadamente cada uma delas.
Refinamento
Primeiro que o refinamento saiu do final do tópico para o início, e passou a vir antes mesmo do Planejamento da Sprint do Nexus. Isso se dá pelo fato da sua importância perante os próprios trabalhos do Nexus. Segundo que o tópico foi todo re-escrito e deixou de ser separado em duas partes e focou em transparência do backlog do produto, e não mais somente visualização como na versão anterior. Como o texto que fala de Refinamento no Nexus é muito extenso não vou colocá-lo aqui, mas sugiro que você leia na íntegra diretamente no Guia do Nexus.
Foi removido também o termo “reunião”, deixando apenas a ação de refinamento, que pode ser eventos ou reuniões formais ou informais, acontecendo a qualquer momento e quando necessário. Além, de que o Refinamento deve acontecer durante toda a Sprint quando necessário e não somente em um momento específico.
Planejamento da Sprint do Nexus
No primeiro parágrafo que descreve o Planejamento da Sprint do Nexus, foi adicionado a seguinte frase que reforça a importância do refinamento ser realizado a as dependência do backlog do produto serem identificadas antes do Planejamento da Sprint do Nexus ocorrer para evitar interrupções e para tornar o trabalho mais objetivo e produtivo.
O Backlog do Produto deve ser adequadamente refinado com as dependências identificadas e removidas ou minimizadas antes do Planejamento da Sprint do Nexus.
No segundo parágrafo foi trocada “no início” por “durante”, para expressar que o trabalho de cada Time Scrum são realizados durante toda o Planejamento da Sprint do Nexus, e não somente no início da mesma como afirmado na versão anterior.
O terceiro parágrafo foi re-escrito deixando claro o funcionando de uma parte bem importante do Planejamento da Sprint do Nexus, que dizia respeito ao trabalho dos Times Scrum após o entendimento dos trabalhos do Nexus serem entendidos. Na versão anterior dizia que era para os Times realizarem seus Planejamentos de Sprint separadamente, deixando entender que eles podiam deixar o Planejamento da Sprint do Nexus e dedicar-se apenas ao seu planejamento individual. Porém, nesta última versão o texto prescreve que o Planejamento da Sprint do Nexus continua e os Times Scrum realizam os seus planejamentos separadamente, se mantendo disponíveis para o Planejamento da Sprint do Nexus também. Isso sugere que os Times Scrum, assim como o Time de Integração do Nexus estão todos juntos em um mesmo local, especialmente pela frase que diz que os Times Scrum devem continuar compartilhando as novas dependências encontradas. O parágrafo completo ficou como segue:
O Product Owner discute a Meta da Sprint do Nexus durante o Planejamento da Sprint do Nexus. A Meta da Sprint do Nexus descreve o propósito que será alcançado pelos Times Scrum durante a Sprint. Uma vez que o trabalho geral para o Nexus é entendido, o Planejamento da Sprint do Nexus continua com cada Time Scrum realizando seu próprio Planejamento da Sprint separadamente. Os Times Scrum devem continuar compartilhando novas dependências encontradas com outros Times Scrum no Nexus. O Planejamento da Sprint do Nexus está completa quando cada time tiver terminado seus eventos de Planejamento da Sprint individuais.
Por fim foi alterado o conceito de que o Backlog do Produto devia ser “visualizado” para todos, para o conceito de que o Backlog do Produto deve estar “transparente” para todos. Transparente é mais forte e maior em valor do que Visualizado, pois transparente não é só mostrar, é permitir que se conheça, que se entenda, que se envolva com aquilo que está sendo disponibilizado.
Meta da Sprint do Nexus
Foi removido o conceito e texto que falava da Meta ou Objetivo do Nexus, e incluída a Meta da Sprint do Nexus, que orienta a realização de todos os trabalhos e metas das Sprints dos Times Scrum dentro do Nexus como foco de todos, e por Sprint do Nexus, e não para todo o Nexus como podia ser um dos entendimentos anteriores. Outro ponto que reforça esta alteração é que a Meta do Nexus (anterior) não era considerada como entrada ou saída do Planejamento da Sprint do Nexus, mas sim discutida durante o Planejamento da Sprint do Nexus. O texto ficou muito bom e objetivo como segue:
A Meta da Sprint do Nexus é um objetivo definido para a Sprint. Ela é a soma de todo o trabalho e Metas das Sprints dos Times Scrum do Nexus. O Nexus deve demonstrar a funcionalidade que ele tem desenvolvida “Pronta” para alcançar a Meta da Sprint do Nexus na Revisão da Sprint do Nexus com a finalidade de receber comentários e observações do stakeholder.
Reunião Diária do Nexus
Algumas alterações foram incluídas na Reunião Diária do Nexus para reforçar que este evento não é apenas para um momento de ajustar o Backlog da Sprint do Nexus, mas sim de dar importância a identificação de questões e das descobertas de dependências e impactos entre os Times Scrum dentro do Nexus com o objetivo de inspecionar o progresso em direção a Meta da Sprint do Nexus. A palavra “impactos” foi incluída tanto no primeiro parágrafo quanto na lista de discussões a serem realizadas na Reunião Diária do Nexus junto com as dependências.
O trecho final foi reescrito para deixar claro a realização da Reunião Diária do Nexus, a participação dos Times de Desenvolvimento, tanto dentro da Reunião Diária do Nexus, quanto nas Reuniões Diárias individuais de cada Time Scrum. Vejam como ficaram os trechos novos:
Os Times de Desenvolvimento usam a Reunião Diária do Nexus para inpecionar o progresso em direção à Meta da Sprint do Nexus. Pelo menos a cada Reunião Diária do Nexus, o Backlog da Sprint do Nexus deve ser ajustado para refletir o atual entendimento do trabalho dos Times Scrum dentro do Nexus.
Os times Scrum individuais então pegam de volta as questões e trabalhos identificados durante a Reunião Diária do Nexus para seus Times Scrum individuais planejarem dentro das suas Reuniões Diárias individuais.
Revisão da Sprint do Nexus
Foi incluído na descrição da Revisão da Sprint do Nexus um complemento para reforçar que, além de inspecionar o incremento integrado Pronto do Nexus, este evento também pode gerar uma adaptação ao Backlog do Produto quando necessário. Também foi incluído:
“O resultado da Revisão da Sprint do Nexus é o Backlog do Produto revisado”.
Retrospectiva da Sprint do Nexus
O primeiro parágrafo foi escrito para melhorar o entendimento do propósito da Retrospectiva da Sprint do Nexus, e especialmente para reforçar a importância da Retrospectiva da Sprint do Nexus melhorar o próprio Nexus. Assim como a última versão do Scrum, aqui também a sugestão é de adicionar ao Backlog da próxima Sprint melhorias que garantam que a melhoria contínua está sendo realizada. Vejam como ficou o texto novo:
A Retrospectiva da Sprint do Nexus é uma oportunidade formal para um Nexus inspecionar e adaptar a si mesmo e criar um plano para que melhorias entrem em vigor na próxima Sprint para garantir melhoria continua. A Retrospectiva da Sprint do Nexus ocorre depois da Revisão da Sprint do Nexus e antes do próximo Planejamento da Sprint do Nexus.
Incremento Integrado
Foi alterado a definição do Incremento Integrado que era a soma de todos os trabalhos prontos, para a soma “atual” de todos os trabalhos prontos. Esta pode parecer um detalhe pequeno, mas deixa claro que quando falamos de Incremento Integrado estamos falando da parte atual que foi adicionada ao produto na última entrega, e não dá soma de tudo que já foi realizado.
Transparência do Artefato
Foi removido o seguinte trecho, para que os times possam definir conforme suas necessidades o que é um débito técnico aceitável ou inaceitável, não estabelecendo padrão a partir do Nexus para esta definição.
O teste do débito técnico inaceitável é quando ocorre a integração, e ainda não está claro que todas as dependências estão resolvidas. Nestes casos as dependências não resolvidas permanecem ocultas no código e na base de teste, reduzindo o valor total do software.
Definição de Pronto
Foi incluída a palavra “integrada” na definição de Pronto, complementando que:
“O incremento é “Pronto” somente quando é integrado, utilizável e potencialmente possível de ser entregue pelo Product Owner”.
Foi removido o parágrafo que descrevia como a definição poderia ser considerada realizada. Este item foi removido porque não faz sentido tentar dizer aos times como considerar suas próprias definições de Pronto, cada Time Scrum individual deve ser capaz de definir a sua própria DoD assim como quando estão dentro do Nexus e definem uma DoD para os trabalhos integrados. O parágrafo removido foi o seguinte:
O item do Backlog do Produto pode ser considerado “Pronto” quando a funcionalidade foi adicionada com sucesso no produto e integrada no incremento. Todos os Times Scrum são responsáveis pelo desenvolvimento e integração do próprio trabalho em um incremento que satisfaça estes atributos.
Bom é isso, estas foram todas as alterações do Guia do Nexus 2015 para o 2018, segundo os pontos de vista do autor e os meus.
Para baixar o Guia do Nexus 2018 clique aqui ou acesse https://www.fabiocruz.com.br/guia-do-nexus-2018
#beAgile #reMindset #doScrum #doNexus #scaleScrum
