A propriedade de recursos é uma boa prática?

Recentemente, na minha empresa, foi sugerido que um desenvolvedor deveria se concentrar (e apenas um) em um recurso. Isso significaria algo como deixar o desenvolvedor de lado da rotina normal da equipe, liberando-o de outras responsabilidades (reuniões e outras) e essa pessoa seria o "único" responsável pelo recurso, em termos de tecnologia.

Para constar, usamos o SCRUM no SAFe e temos para desenvolvedores em tempo integral por equipe, compartilhando o controle de qualidade e os proprietários do produto entre nossas duas equipes (Android e iOS).

Embora eu concorde que isso aumentaria a produtividade em curto prazo, tenho a sensação (e acho que aprendi na universidade) de que essa é uma prática ruim por vários motivos:

A revisão de código perde valor.
Compartilhamento mínimo de conhecimento.
Incremento de risco.
Perda de flexibilidade da equipe.

Estou certo ou não é uma prática ruim?

agile team code-ownership

— mdelolmo
fonte

Minha reação imediata é que isso pode funcionar se for feito com moderação, mas você está certo sobre os problemas se for levado longe demais. Por outro lado, minha experiência é que todo recurso já possui um proprietário de fato: a última pessoa que passou muito tempo trabalhando nele.

— Ixrec 11/07/2015

" um desenvolvedor deve se concentrar (e apenas um) " - Se você deseja um SPOF, é uma boa ideia fazê-lo dessa maneira. Recentemente, formulei uma teoria empírica segundo a qual a pessoa de que você mais precisa em uma determinada situação (" wtf?!? Por que ele escreveu dessa maneira? ") É tipicamente exatamente aquela que é realmente absolutamente inacessível.

— JensG

@JensG: meh, tenho uma teoria empírica de que a pessoa que mais frequentemente preciso ("wtf? Por que ele escreveu dessa maneira?") Sou eu e, como tal, o fator de ônibus para "lembrar as coisas que deveriam ter sido escritas" no momento" é 0. é apenas mais notável quando estou bloqueado por outra pessoa, porque eu preocupar com isso em vez de re-examinar o código existente a partir do zero em seus próprios méritos ;-)

— Steve Jessop

@SteveJessop: Claro, tentar reorganizar a maneira de pensar de outras pessoas examinando um monte de KLOC de seu código, enquanto o cliente grita que ele precisa de uma solução agora ( ou então! ) Pode ser uma boa idéia para algumas pessoas, mas eu não sou nerd o suficiente para ver algo engraçado em desperdiçar meu tempo e poder gastar mais produtivamente.

— JensG

@ JensG: felizmente, meus clientes são mais socializados que os seus. Portanto, não estou sob tanta pressão a ponto de me engajar no tipo de pensamento mágico que resulta em uma conclusão que é importante para mim genuinamente faz com que as pessoas sejam menos alcançáveis por mim. Como tal, pensei que houvesse um elemento de piada no que você disse, então sim, sou nerd o suficiente para achar engraçado uma situação em que você compensa um código incompreensível tentando manter várias pessoas por perto que se lembram de como ele funciona. Especialmente porque esses wtfs costumam ser minha culpa estúpida e não dos meus colegas.

— 21715 Steve Steveop

Respostas:

Nos meus 20 anos de experiência, é melhor ter a propriedade do código alternar responsabilidades entre os designers ou pelo menos ter um par de proprietários. A propriedade de recurso único tem os seguintes problemas, vários dos quais você mencionou:

tende a projetar pombos e limitar suas oportunidades de crescimento
coloca todos os ovos em uma cesta; se alguém for atropelado por um ônibus ou sair, poderá haver um buraco no conhecimento
uma única pessoa pode não encontrar um problema no código e sem as revisões do código do proprietário é muito menos eficaz
é difícil manter a consistência e a legibilidade do código se todos estiverem trabalhando no código usando seu próprio estilo - embora isso possa ser contornado com diretrizes de estilo, as sutilezas podem surgir especialmente ao usar a convenção sobre a configuração em que as pessoas confiam no comportamento padrão
os desenvolvedores podem tender a se tornar protetor e defensivo de seu código se o possuir, o que pode inibir a evolução do código - se várias pessoas o possuirem, essa tendência será reduzida

— Jason K.
fonte

Absolutamente. É importante mencionar o fator de barramento como o problema mais evidente com a propriedade de apenas uma pessoa.

— JensG

No entanto, o fator de barramento precisa ser negociado com o custo e o YAGNI, e se o barramento realmente prejudicaria sua organização ou causaria muito aborrecimento. Se fosse uma escolha entre perder, digamos, 3 horas por semana para sempre, garantindo que duas pessoas fossem instruídas sobre um determinado código em vez de apenas um, ou perder, digamos, 60 horas como uma oportunidade única para alguém se apresentar para acelerar no caso de um de seus desenvolvedores ser atingido e, em muitos casos, você escolheria o custo único. Mas, pelas razões expostas, os silos de conhecimento têm outras desvantagens mais importantes (embora menos evidentes).

— 21715 Steve Steveop

A propriedade dos recursos é inevitável, e o bom desempenho pode ser uma coisa boa. Ele ajuda a criar domínio e permite autonomia - dois dos pilares de engajamento geralmente reconhecidos . Ele deixa claro quem é responsável por esse código e ajuda na delegação, comunicação e outras tarefas.

Mas você não está falando sobre isso. Você está falando sobre formar uma nova equipe - isolar essa pessoa do resto do código. Isso não é ótimo. Limita a carreira deles. Acrescenta risco ao projeto / empresa. Isso prejudica a comunicação.

Portanto, pode haver alguma moderação para afastar isso de uma má idéia.

— Telastyn
fonte

Eu discordo que a propriedade do código por uma única pessoa é inevitável, mas será de propriedade de um pequeno número de pessoas. Vi organizações que fizeram um trabalho ruim de compartilhar código, mas fizeram o mesmo. As configurações mais eficazes que vi foram quando 2 a 3 pessoas conheceram partes do código e colaboraram. Isso reduziu o estresse e o isolamento entre os codificadores, porque eles não estavam sozinhos quando as coisas falhavam e os recursos atrasados podiam receber mais atenção para cumprir os prazos sem rampas de treinamento rápido de outras pessoas na organização.

— 18715 Jason

@jason - claro, deve haver algumas pessoas na equipe confortáveis e capazes de trabalhar em um pedaço de código. Mas uma pessoa acabará o especialista no assunto simplesmente trabalhando mais nele.

— Telastyn

Concordo que isso geralmente acontece, é o cenário mais provável e que a experiência no assunto é uma coisa boa - o único desacordo é inevitável, simplesmente porque eu tive um melhor sucesso com várias pessoas sendo as PME de uma área, com uma considerável sobreposição

— Jason K .