Propriedade do código com várias equipes Scrum

Se duas equipes Scrum usam o mesmo componente de software, quem é responsável por fornecer uma visão arquitetônica clara desse componente e manter / desenvolver essa visão à medida que a base de código evolui? No Scrum, você deve possuir uma propriedade coletiva do código; então, como garantir que o desenvolvimento feito pelo Time A não interfira no desenvolvimento feito pelo Time B?

Não sou especialista em Scrum, mas o AFAIK "propriedade de código coletivo" deve ser por equipe e por produto (e acho que sua pergunta não é específica para o Scrum, pode ser aplicada a qualquer processo de desenvolvimento de "código compartilhado").

Se você possui duas equipes A, B, dois produtos A, B e um componente compartilhado C, existem diferentes cenários possíveis. Talvez o componente compartilhado pertença principalmente ao produto A (e é apenas reutilizado, mas não evoluído, pela equipe do produto B). Nesta situação, a equipe A é claramente responsável pela visão arquitetônica. Ou vice-versa: ele pertence claramente ao produto B - então a responsabilidade está aí. Se a equipe A for responsável, a equipe B poderá usar uma bifurcação do componente para permitir correções de bugs urgentes (também deve haver uma maneira de reintegrá-las na linha principal de C), mas B deve evitar uma evolução maior do componente.

No entanto, se os produtos A e B tiverem muitos "requisitos de direção" para C, você deverá gerenciar C como um produto completamente separado, com versões próprias, gerenciamento de versões, gerenciamento de alterações, testes de unidade, etc., e uma equipe separada responsabilidade por esse componente. Essa equipe pode ser apenas uma "equipe virtual", consistindo em desenvolvedores separados da equipe A, B ou de ambos. Essa equipe tem a "propriedade de código compartilhado" para C e a responsabilidade pela "visão arquitetônica". Pense em C sendo um componente entregue por um fornecedor terceirizado.

Não há conceito de "clara visão arquitetônica" no Scrum ou no ágil!

Sou arquiteto há muito tempo e está claro para mim que, para ter uma visão arquitetônica, é necessário ter uma visão clara dos requisitos futuros. Como na maioria dos casos, os requisitos não são claros, não faz sentido ter uma visão fixa.

O que é necessário é ter uma arquitetura que seja adaptável o suficiente às mudanças nos requisitos. Em outras palavras, as coisas mudam e a arquitetura muda - não estou defendendo uma arquitetura "flexível" que possa ser reconfigurada. Estou falando de aceitar que a arquitetura que temos hoje será obsoleta em breve e precisará ser alterada, para que ninguém "se case" com ela.

A propriedade do código coletivo significa que todos deveriam - em teoria - ser capazes de mudar qualquer coisa. Isso deve ser entendido como o "oposto de silos". Em outras palavras, pode haver uma barreira de habilidades, o que é normal e esperado - nem todo mundo é um DBA experiente que pode ajustar as consultas SQL, para dar um exemplo - mas a partir disso, não se segue que apenas um DBA pode mão otimizar consultas. Haverá um "especialista em domínio de recursos" que pode ajudar outras pessoas a se tornarem proficientes, mas as tarefas ainda devem recair sobre todos.

Por exemplo: se eu sou especialista em domínio no recurso "A", ainda espero que alguém trabalhe no recurso "A", mas provavelmente será consultado quando houver grandes alterações ou quando as pessoas precisarem de ajuda. O recurso "A" certamente não seria o meu recurso. Será um recurso que eu conheço bem. Será do meu interesse conhecer muitos outros recursos e o interesse de outras pessoas conhecer esse recurso.

Em síntese: a arquitetura é projetada e redesenhada várias vezes pelos desenvolvedores conforme os requisitos surgem e mudam. Todos devem fazer as alterações necessárias de acordo com suas habilidades e saber quando pedir ajuda. Não há visão de longo prazo sobre a arquitetura, porque confiamos nas pessoas e não confiamos nos requisitos .

Por exemplo, o spotify usa uma função chamada "Proprietário do sistema" para resolver o problema diretamente do documento:

Tecnicamente, qualquer pessoa pode editar qualquer sistema. Como os esquadrões são efetivamente equipes de recursos, eles normalmente precisam atualizar vários sistemas para colocar um novo recurso em produção. O risco desse modelo é que a arquitetura de um sistema fique confusa se ninguém se concentrar na integridade do sistema como um todo.

Para mitigar esse risco, temos uma função chamada "Proprietário do sistema". Todos os sistemas têm um proprietário do sistema ou um par de proprietários do sistema (recomendamos o emparelhamento). Para sistemas operacionalmente críticos, o Proprietário do Sistema é um par Dev-Ops - ou seja, uma pessoa com uma perspectiva de desenvolvedor e uma pessoa com uma perspectiva de operações.

O proprietário do sistema é a pessoa que acessa quaisquer problemas técnicos ou de arquitetura relacionados a esse sistema. Ele é um coordenador e orienta as pessoas que codificam nesse sistema para garantir que não tropeçam umas nas outras. Ele se concentra em questões como qualidade, documentação, dívida técnica, estabilidade, escalabilidade e processo de liberação.

O proprietário do sistema não é um arquiteto de gargalo ou torre de marfim. Ele não precisa tomar todas as decisões pessoalmente, nem escrever todo o código, nem todas as versões. Ele normalmente é um membro do esquadrão ou líder de capítulo que tem outras responsabilidades diárias, além da propriedade do sistema. No entanto, de tempos em tempos, ele tira um "dia do proprietário do sistema" e faz o trabalho de limpeza nesse sistema. Normalmente, tentamos manter a propriedade desse sistema em menos de um décimo do tempo de uma pessoa, mas isso varia muito entre os sistemas, é claro.

Eu realmente gosto dessa ideia, tendo os benefícios ou a propriedade coletiva do código no nível da empresa (não apenas no nível da equipe), mas com os proprietários deste sistema tentando garantir alguma integridade arquitetural.

Um link para o documento completo: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , é um documento curto, mas muito, muito interessante, com base na experiência real sobre o dimensionamento ágil.

É um problema difícil de resolver, e certamente não foi resolvido pelo Scrum, que é uma metodologia de gerenciamento de projetos, não uma metodologia de desenvolvimento.

A solução mais eficaz que encontrei é um bom gerenciamento de pacotes (nuget / gem / etc) e controle de versão. Nunca imponha uma alteração em outra equipe até que ela esteja pronta para consumi-la. Deixe-os continuar usando a versão antiga, enquanto você passa para a nova.

Certifique-se de ter uma estratégia de versão que deixe claro quais alterações estão sendo quebradas e quais são extensões.

Além disso, quando você faz uma alteração, envie uma revisão de código para alguém EM CADA EQUIPE. Deixe-os ver como é provável que os afete, muito antes de serem obrigados a consumi-lo, para que possam implementar suas próprias alterações no topo.

E, quando as coisas ficam realmente confusas; quando uma equipe precisa fazer uma alteração e não pode consumir outra alteração facilmente (esse deve ser um caso muito raro), ramifique o código, faça um pacote totalmente diferente, mas faça com que seja uma prioridade voltar ao código comum assim que o tempo permite.

A resposta que nem sempre é tão óbvia quanto poderia ser é deixar as equipes decidirem como compartilharão qualquer componente.

Por exemplo, minha equipe começou recentemente a desenvolver uma nova linha de produtos que compartilha muito código em comum com outras duas equipes que desenvolvem produtos similares há muito tempo. Nosso produto é diferente em alguns aspectos; portanto, ocasionalmente, precisamos descobrir maneiras de adicionar pontos de personalização ao código comum.

Tivemos alguns conflitos sobre esse código e tentamos algumas maneiras diferentes de lidar com a propriedade comum. Então, com um novo recurso grande, decidimos que precisávamos reunir todas as equipes para entrar na mesma página, o que resultou em um grupo menor composto por dois membros de cada equipe que estão trabalhando nos detalhes.

A solução que nossas equipes criaram pode não funcionar em outra situação. Você pode precisar de algo mais simples ou algo muito mais formal. O ponto é que você assume a propriedade coletiva e descobre o que funciona para você.

Terei liberdade para assumir:

• testes de aceitação são automatizados ..
• O componente emprega bons princípios de POO: baixo acoplamento e alta coesão.

Se as premissas acima estiverem corretas, ocasionalmente deve haver momentos em que duas equipes interfiram entre si. Eles podem resolvê-lo usando as seguintes maneiras:

• Assim que o teste de aceitação da outra equipe falhar, converse com eles para entender se o uso do componente compartilhado está correto ou o seu. Se os dois usos forem bons, verifique se parte comum desse uso é transferida (refatorada) para um componente base comum e a variação no uso é gerenciada usando classes filho ou pode ser via composição.
• Responsabilize uma pessoa pelo componente enquanto ele estiver em desenvolvimento ativo. Ele deve atuar como um recurso compartilhado entre as equipes.