Em janeiro de 2018, o
mundo viu a luz da estrutura Nexus atualizada - uma ferramenta baseada em Scrum projetada para o trabalho em equipe em grandes projetos. Os autores da metodologia corrigiram várias definições de termos e
alteraram o procedimento de licenciamento. Desde o início do ano, o Guia do Nexus está licenciado sob uma licença Creative Commons. E isso significa que qualquer empresa é livre para usar o Nexus (como o Scrum).
Vamos falar sobre os recursos da metodologia e seus principais componentes.
/ foto de Sebastian Sikora CCQuem e por que criou o Nexus
Em 1996, os desenvolvedores Ken Schwaber e Jeffrey Sutherland introduziram a comunidade de desenvolvimento de software ágil
Scrum . É um conjunto de iterações estritamente limitadas no tempo (sprints), para as quais os desenvolvedores devem implementar novas funções para o programa.
Como observa Jeff Sutherland, em seu livro
Scrum. Um método revolucionário de gerenciamento de projetos, o Scrum permite que as equipes de desenvolvimento obtenham “supereficiência” e aumentem a produtividade do trabalho em 300%.
No entanto, o Scrum tem uma desvantagem - é adequado para trabalhar em uma equipe (e o número recomendado de membros é de apenas sete pessoas), mas não ultrapassa suas fronteiras - quando é necessário coordenar o trabalho de um grande número de pessoas.
Para corrigir a situação e ajudar a ampliar a metodologia, Ken Schwaber
introduziu a estrutura Nexus em 2015. O Nexus
ajuda a evitar os problemas frequentes do desenvolvimento conjunto: dificuldades ao usar a mesma base de código e inconsistências ao integrar as conquistas de diferentes equipes.
O Nexus usa abordagens iterativas e incrementais para dimensionar os processos de desenvolvimento de software. Cada equipe trabalha como parte de seu sprint e, em seguida, seus resultados são combinados. Isso facilita a coordenação do desenvolvimento do produto.
Componentes do Nexus
A estrutura consiste em funções, eventos, artefatos, bem como regras, familiares a qualquer adepto do Scrum, que une tudo. No Nexus, esses componentes mudaram um pouco para que a metodologia possa ser aplicada em projetos de grande escala.
Funções Pela metodologia Scrum, todos os participantes do processo de desenvolvimento recebem funções específicas. Eles podem ser divididos em dois grandes grupos - "porcos" e "galinhas". O primeiro inclui todos aqueles que estão diretamente envolvidos na criação do aplicativo: o Scrum Master, que realiza reuniões e monitora a conformidade com os princípios do scrum, o proprietário do produto (Product Owner), representando os interesses dos usuários finais e, de fato, a equipe de desenvolvimento (Equipe de desenvolvimento).
O segundo grupo - "galinhas" - inclui usuários finais, vendedores, consultores etc.
O Nexus apresentou o papel da Equipe de integração do Nexus (NIT) para ajudar a ampliar a metodologia. Esta é uma equipe inteira, que inclui Product Owner, Scrum Master e representantes de equipes de scrum. Sua tarefa é avaliar e prevenir possíveis problemas de desenvolvimento da equipe. É importante
observar que os membros do NIT não estão diretamente envolvidos na programação, mas fornecem recomendações sobre a aplicação dos princípios Scrum e Nexus a todos os outros participantes.
Em geral, a introdução do NIT ajudou a melhorar a coordenação entre as equipes devido à distribuição competente de tarefas. No entanto, membros da comunidade de TI
dizem que a nova função também contribuiu para a criação de um “gargalo” único - quando os membros da NIT resolvem problemas organizacionais, a equipe de desenvolvimento permanece ociosa, esperando instruções.
Artefatos. No Scrum, artefatos são entendidos como um conjunto de requisitos para a funcionalidade do produto que ajudam a organizar as atividades dos desenvolvedores. Esses requisitos são descritos em duas revistas: a lista de pendências do projeto e a lista de pendências do sprint.
O livro de desejos do projeto lista os requisitos gerais de funcionalidade - as chamadas
histórias de usuários , classificadas em ordem decrescente de importância. Eles ajudam a ter uma idéia de como o produto final deve ficar.
Diário de Desejos da Sprint - Uma lista dos recursos de implementação selecionados pelo proprietário do produto. Com base nessa lista, os desenvolvedores rastreiam tarefas que precisam ser concluídas antes do final de um sprint.
No Nexus, as equipes usam o Backlog do produto em vez do livro de desejos do projeto. Para simplificar a interação de um grande número de desenvolvedores, esta revista é dividida em partes. Cada parte é "atribuída" a uma das equipes. Portanto, todos os desenvolvedores entendem em quais tarefas de todo o projeto estão envolvidos. Ao mesmo tempo, cada equipe ainda mantém seu registro de desejo de sprint.
Eventos. Todos os membros da equipe participam de reuniões, às vezes chamadas de termo geral "eventos". Os "porcos" os gastam diariamente e as "galinhas" - no início e no final do projeto ou corrida. São necessárias reuniões para discutir o processo de desenvolvimento, estimar planos, identificar gargalos.
Para melhorar a comunicação entre equipes diferentes, os desenvolvedores do Nexus adicionaram quatro novos tipos de eventos:
- Planejamento do Nexus Sprint - no momento, as equipes decidem quem é o melhor para lidar com um determinado Sprint no Product Backlog. Depois disso, cada equipe planeja seu próprio sprint, comunicando-se com outras equipes de scrum para que suas tarefas não se sobreponham.
- Nexus Daily Scrum - usado para discutir o estado atual das coisas. Permite planejar o dia ou resolver problemas de integração.
- Revisão do Nexus Sprint - aqui as equipes compartilham seus sucessos no final de cada sprint.
- Retrospectiva do Nexus - esse tempo é gasto avaliando a experiência passada e fazendo um plano para melhorar o processo de desenvolvimento no futuro.
Na
página oficial do guia Nexus, você pode encontrar um diagrama da interação e sequência de todos esses eventos.
Quando usar o Nexus
Em projetos de larga escala. A estrutura ajuda a organizar perfeitamente o trabalho de várias equipes de scrum em grandes projetos. Por exemplo, uma empresa indiana que criou software de segurança (os autores do Scrum não divulgaram seu nome) usaram o Scrum por um ano para desenvolver seus produtos. No início, a empresa tinha uma equipe de scrum, mas logo seu número aumentou para três, e os problemas começaram com a
integração de soluções individuais.
Em seguida, a empresa convidou um especialista em Scrum e ele propôs mudar o fluxo de trabalho do Scrum para um nível de várias equipes - implementando o Nexus. Agora, de acordo com a metodologia Nexus, seis equipes já estão trabalhando, que lançam constantemente novos lançamentos de software a cada duas semanas.
Em grandes empresas. Por exemplo, o departamento de TI dos Terminais Portuários Peruanos (TPP), uma empresa envolvida no transporte marítimo em um dos portos da capital do Peru, levou nove meses para lançar o novo software de perfil. Para remediar a situação, a empresa experimentou a metodologia
Waterfall , o
RUP e os princípios do
gerenciamento tradicional de projetos . No entanto, todos eles não deram melhorias significativas e, em alguns casos, pioraram.
Então a empresa decidiu experimentar o Nexus. A técnica permitiu reduzir o tempo de liberação em três vezes e liberar o produto a cada três meses.
O Nexus ajuda a estabelecer a interação entre equipes, "espalhadas" pelo mundo. O Daily Sprints suporta um alto nível de comunicação e envolvimento dos funcionários no projeto.
Observe que, embora o Nexus ajude a coordenar o trabalho de muitas equipes de desenvolvimento ao trabalhar em um grande projeto e a acelerar o lançamento de releases (como é o caso do TPP), ele ainda
não é capaz de resolver problemas associados à estrutura interna da organização. Por exemplo, a estrutura não terá um efeito perceptível se as equipes não tiverem especialistas suficientes para resolver todos os problemas.
Assim, o Nexus é adequado para trabalhar em grandes projetos (de acordo com os criadores da metodologia, permite gerenciar efetivamente nove equipes de scrum) e, com a aplicação adequada, ajuda a acelerar o processo de desenvolvimento de 3 a 4 vezes. No entanto, o foco principal dessa metodologia é resolver problemas de integração, pois não
pode ajudar na solução de outros problemas organizacionais da empresa.
PS Alguns materiais frescos do Primeiro blog corporativo de IaaS:
PS Várias publicações do nosso canal Telegram :