È un must assoluto quando si segue la Scrum metodologia per praticare proprietà del codice collettivo , anziché per esempio proprietà del codice debole ?
È un must assoluto quando si segue la Scrum metodologia per praticare proprietà del codice collettivo , anziché per esempio proprietà del codice debole ?
La proprietà del codice collettivo non è parte integrante di Scrum .
È, tuttavia, una parte della Programmazione estrema . Extreme programming & Scrum funziona molto bene insieme.
L'elemento centrale in Scrum è la squadra. Pertanto, è strongmente incoraggiato a esercitare la proprietà collettiva del codice in opposizione a qualsiasi tipo di individualismo .
Scrum funziona meglio nei grandi progetti (> $ 1M) con molte incertezze e con grandi team (> = 5 sviluppatori sulla stessa base di codice). La proprietà del codice debole può essere molto efficace in team più piccoli e in progetti più piccoli come Paul Graham lo descrive .
Sull'argomento della proprietà del codice, penso questo post qui lo mette meglio di quanto potrei mai scrivere:
I don’t want to depend on anything without an owner. I see how this reasoning can be infuriating. Shifting the focus from software to wetware is a dirty trick loved by technically impotent pseudo-business-oriented middle-management loser types. Here’s my attempt at distinguishing myself from their ilk: not only do I want to depend on stuff with an owner, but I require a happy owner at that. Contrary to a common managerial assumption (one of those which rarely hold but do keep managers sane), I don’t believe in forcibly assigning ownership. If the owner doesn’t like the module, expect some pretty lousy gardening job.
/ credente fanatico del codice debole.
Non penso che la proprietà collettiva del codice sia assolutamente necessaria per scrum, tuttavia, minore è la proprietà del codice, maggiore è la flessibilità nelle assegnazioni delle attività. Questo è particolarmente vero quando ci sono più gruppi di mischia. La minore proprietà del codice rimuove anche i colli di bottiglia che possono svilupparsi quando un proprietario del codice è sovraccarico di lavoro.
La proprietà del codice dà continuità allo sviluppo e, a seconda delle competenze dei membri del team, potrebbe essere impossibile rimuoverla completamente.
Leggi altre domande sui tag scrum code-ownership