A propriedade do código coletivo é obrigatória no Scrum?

9

É uma necessidade absoluta, ao seguir a metodologia Scrum, praticar a propriedade coletiva do código , em vez de, por exemplo, a propriedade fraca do código ?

scrum code-ownership Dimitri C.
fonte
Devo dizer que isso me deixa louco porque outras pessoas na minha equipe de pseudo-scrum alteram meu código por uma necessidade que não exigiu nenhuma alteração, apenas um entendimento adequado da arquitetura ou API que eu coloquei em prática.
Ando
3
Se não houver propriedade coletiva, como é possível ter compromisso por equipe ? Dentro de um conjunto de habilidades (digamos, programação Java), qualquer pessoa deve estar disposta a executar qualquer tarefa.
merryprankster

Respostas:

13

A propriedade do código coletivo não é parte integrante do Scrum .

É, no entanto, parte da programação extrema . Programação extrema e Scrum funcionam muito bem juntos.

O elemento central do Scrum é a equipe. Portanto, é altamente recomendável praticar a propriedade coletiva do código em oposição a qualquer tipo de individualismo .

O Scrum funciona melhor em grandes projetos (> US $ 1 milhão) com muitas incertezas e com grandes equipes (> = 5 desenvolvedores na mesma base de código). A propriedade fraca do código pode ser muito eficaz em equipes menores e em projetos menores, como Paul Graham descreve .

Christopher
fonte
"> 1 milhão" o que? Funcionários? Recursos? Linhas de código no produto geral? Linhas de código pertencentes a uma equipe de scrum? Por que não funciona melhor com tamanhos de código mais modestos (supondo que você quis dizer tamanho do código)?
Bryan Oakley
1
1 milhão de dólares. Como a equipe ideal de scrum é composta por 7 pessoas, o uso do scrum em menos de vários meses não é realmente um projeto que deve usar o scrum. 7 desenvolvedores * 6 meses é um projeto típico de 1 milhão de dólares.
1
US $ 1 milhão parece terrivelmente arbitrário (e datado - daqui a dois anos, US $ 1 milhão não comprará tanto quanto hoje, e certamente não tanto quanto comprado há dois anos). No entanto, acho que é um número tão bom quanto qualquer outro. Um orçamento de um milhão de dólares não pagará muito mais do que uma única equipe de scrum, então acho que você está dizendo que o SCRUM não funciona se você não puder pagar pelo menos uma equipe de scrum. Isso faz sentido. No entanto, isso não se aplica a uma verdadeira startup, onde todos estão trabalhando com um orçamento pequeno. Eu acho que sua resposta seria melhor se você aceitasse o limite artificial.
Bryan Oakley
@BryanOakley: não exatamente, escrevi scrum funciona melhor quando você tem os números ideais . O Scrum pode trabalhar em equipe menor e com menos iterações, mas se torna menos útil nesses casos. Prefiro não usar nenhuma estrutura nesse caso, ou um scrum "leve", que é o que faço em uma de minhas empresas, onde há apenas três desenvolvedores. Sobre o que você pode comprar com US $ 1 milhão, não vi isso flutuar muito desde os últimos 10 anos.
10

No tópico propriedade do código, acho que este post aqui o coloca melhor do que eu jamais poderia escrever:

Não quero depender de nada sem dono. Vejo como esse raciocínio pode ser irritante. Mudar o foco do software para o wetware é um truque sujo, amado pelos tipos de perdedores de gerenciamento médio orientados por pseudo-negócios tecnicamente impotentes. Aqui está minha tentativa de me diferenciar da classe deles: não só quero depender de coisas com um proprietário, como também preciso de um proprietário feliz. Ao contrário de uma suposição gerencial comum (uma daquelas que raramente mantêm, mas mantêm os gerentes sãos), não acredito em atribuir à força a propriedade. Se o proprietário não gostar do módulo, espere um trabalho de jardinagem bastante ruim.

/ crente fanático em propriedade de código fraco.

Denis de Bernardy
fonte
4

Não acho que a propriedade coletiva do código seja absolutamente necessária para o scrum; no entanto, quanto menos propriedade do código, maior flexibilidade há nas atribuições de tarefas. Isso é especialmente verdade quando existem várias equipes de scrum. Menos propriedade do código também remove os gargalos que podem surgir quando um proprietário do código está sobrecarregado.

A propriedade do código dá continuidade ao desenvolvimento e, dependendo dos conjuntos de habilidades dos membros da equipe, pode ser impossível removê-lo completamente.

Blake
fonte