Propriedade do código com várias equipes Scrum


10

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?

Respostas:


10

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.


"o componente compartilhado pertence ao produto A" ou ...?
Joe Z.

6

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 .


Mas isso não responde diretamente à minha pergunta. O que fazer com os componentes que várias equipes usam? Quem garante que a arquitetura atual seja adequada? Mesmo que a "visão" arquitetônica seja para o próximo Sprint ou dois, ainda tem que haver uma visão. Você não deseja que desenvolvedores de várias equipes do Scrum alterem o componente sem entender o impacto da mudança em todas as equipes e na arquitetura geral.
Eugene

1
Ele responde à sua pergunta ... quando digo "todo mundo", quero dizer "entre equipes". Eu discordo que permitir que todos alterem um componente compartilhado o quebrará - os desenvolvedores devem estar cientes do risco e ser confiáveis ​​para fazê-lo da maneira certa.
21314 Sklivvz

Portanto, suponho que a pessoa que deseja alterar um componente compartilhado irá reunir uma reunião com desenvolvedores mais familiarizados com esse componente e, juntos, eles adaptarão o design do componente aos novos requisitos. É assim que você trabalha na sua organização?
Eugene

@ Eugene não foi o que eu disse: todos podem mudar as coisas sem a permissão de um comitê. Confiamos nas pessoas para pedir ajuda se elas precisarem, e consertar as coisas se elas estragarem tudo.
Sklivvz

Compreendo. Não estou dizendo que este é um processo formal e obrigatório. Eu tenho quase certeza de que, em muitos casos, a pessoa que deseja fazer uma alteração deseja agendar uma reunião para entender o possível impacto de suas alterações.
Eugene

4

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.


Organização muito legal e ideia interessante sobre os proprietários de sistemas #
Eugene

Em vez de colocar em negrito e itálico esse bloco de texto para indicar que é uma citação, o editor fornece um recurso / estilo de "texto entre aspas". Você simplesmente seleciona um bloco de texto e usa o ícone de aspas duplas na parte superior do editor. Usar isso ajuda a manter o texto citado com um estilo reconhecível consistente em todo o site.
Marjan Venema

2

É 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.


1

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ê.


Quando você diz "decidimos", você quer dizer com uma decisão de consenso? Ou a decisão final nesses casos pertence a um arquiteto / líder técnico?
Eugene

Uma decisão de consenso, dirigida um pouco, mas não ditada pelos mestres do scrum.
Karl Bielefeldt

1

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.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.