La proprietà delle funzionalità è una buona pratica?

Recentemente nella mia azienda è stato suggerito che uno sviluppatore dovrebbe concentrarsi (e solo uno) in una funzione. Ciò significherebbe qualcosa come mettere lo sviluppatore da parte della normale routine del team, liberandolo da alcune altre responsabilità (riunioni e simili) e questa persona sarebbe il "solo" responsabile della funzionalità, per quanto riguarda la tecnologia.

Per la cronaca, utilizziamo SCRUM all'interno di SAFe e abbiamo per sviluppatori a tempo pieno per team, condividendo il controllo qualità e i proprietari dei prodotti tra i nostri due team (Android e iOS).

Mentre sono d'accordo sul fatto che ciò aumenterebbe la produttività a breve termine, ho la sensazione (e penso di averlo imparato all'università) che questa è una cattiva pratica per molte ragioni:

La revisione del codice perde valore.
Condivisione minima delle conoscenze.
Incremento del rischio.
Perdita di flessibilità della squadra.

Ho ragione o non è affatto una cattiva pratica?

agile team code-ownership

— mdelolmo
fonte

La mia reazione immediata è che questo potrebbe funzionare se fatto con moderazione, ma hai ragione sui problemi se è portato troppo lontano. D'altra parte, la mia esperienza è che ogni funzione ha già un proprietario di fatto: l'ultima persona che ha trascorso molto tempo a lavorarci.

— Ixrec,

" uno sviluppatore dovrebbe focalizzare (e solo uno) " - Se vuoi uno SPOF è una buona idea farlo in quel modo. Di recente ho formulato una teoria empirica secondo cui la persona di cui hai più bisogno in una determinata situazione (" wtf?!? Perché l'ha scritta in quel modo? ") È in genere esattamente quella che è assolutamente assolutamente irraggiungibile.

— JensG,

@JensG: meh, ho una teoria empirica secondo cui la persona di cui ho più bisogno ("wtf? Perché l'ha scritto in quel modo?") Sono io, e come tale il fattore bus per "ricordare cose che avrebbero dovuto essere scritte al momento "è 0. È solo più notevole quando sono bloccato da qualcun altro, perché mi preoccupo invece di riesaminare il codice esistente da zero per i suoi meriti ;-)

— Steve Jessop

@SteveJessop: Certo, cercare di riprogettare il modo di pensare di altre persone esaminando un mucchio di KLOC del loro codice mentre il cliente ti urla che ha bisogno di una soluzione ora ( o altrimenti! ) Potrebbe essere una buona idea per alcune persone, ma io Non sono abbastanza nerd da vedere qualcosa di divertente nello sprecare il mio tempo che potrei invece spendere in modo più produttivo.

— JensG,

@JensG: fortunatamente, i miei clienti sono socializzati meglio dei tuoi. Quindi non sono così sotto pressione da impegnarmi in quel tipo di pensiero magico che porta alla conclusione che essere importanti per me fa sì che le persone siano meno raggiungibili da me. In quanto tale, ho pensato che ci fosse un elemento di scherzo in quello che hai detto, quindi sì, sono abbastanza nerd da trovare una situazione divertente in cui compensi il codice incomprensibile cercando di tenere in giro più persone che ricordano come funziona. Soprattutto perché tali wtfs sono spesso la mia stupida colpa e non quella dei miei colleghi.

— Steve Jessop,

Risposte:

Nei miei 20 anni di esperienza, è meglio che la proprietà del codice ruoti le responsabilità tra i progettisti o almeno abbia una coppia di proprietari. La proprietà di una singola funzione presenta i seguenti problemi, molti dei quali hai menzionato:

tende a progettare buchi di piccioni e limitare le loro opportunità di crescita
mette tutte le uova nello stesso paniere, quindi se qualcuno viene colpito da un autobus o esce, può esserci un buco nella conoscenza
una sola persona potrebbe non vedere un problema nel codice e senza un peer le recensioni del codice proprietario sono molto meno efficaci
è difficile mantenere la coerenza e la leggibilità del codice se tutti stanno lavorando al codice usando il proprio stile - mentre questo può essere risolto con le linee guida di stile, le sottigliezze possono insinuarsi soprattutto quando si usa la convenzione sulla configurazione in cui le persone si affidano al comportamento predefinito
gli sviluppatori possono tendere a diventare protettivi e difensivi del proprio codice se lo possiedono, il che può inibire l'evoluzione del codice - se diverse persone lo possiedono, questa tendenza è ridotta

— Jason K.
fonte

Assolutamente. È importante menzionare il fattore bus come il problema più evidente con una proprietà di una sola persona.

— JensG,

Il fattore bus deve essere scambiato a fronte di costi e YAGNI, tuttavia, e se l'autobus paralizzerebbe davvero la tua organizzazione o causerebbe solo molta seccatura. Se fosse una scelta tra perdere, diciamo, 3 ore a settimana per sempre assicurando che due persone siano istruite su un particolare bit di codice anziché solo uno, o perdendo, diciamo, 60 ore come una tantum per qualcuno da sollevare per accelerare nel caso in cui uno dei tuoi sviluppatori fosse colpito, in molti casi avresti scelto il costo una tantum. Ma per i motivi indicati, i silos della conoscenza presentano altri svantaggi più importanti (sebbene meno evidenti).

— Steve Jessop,

La proprietà delle funzionalità è inevitabile e una buona esecuzione può essere una buona cosa. Aiuta a costruire la padronanza e consente l'autonomia - due dei pilastri dell'impegno generalmente riconosciuti . Illustra chi ha la responsabilità di quel codice e aiuta a delegare, comunicare e altrimenti fare merda.

Ma non stai parlando di questo. Stai parlando di creare una nuova squadra di uno - tagliare questa persona fuori dal resto del codice. Questo non è grande. Essa limita la loro carriera. Si aggiunge rischio per il progetto / società. Si danneggia comradarie.

Quindi un po 'di moderazione potrebbe essere al fine di allontanare questo da una cattiva idea.

— Telastyn
fonte

Non sono d'accordo sul fatto che la proprietà del codice da parte di una sola persona sia inevitabile, ma sarà di proprietà di un piccolo numero di persone. Ho visto organizzazioni che hanno fatto un brutto lavoro con il codice condiviso ma lo stesso. Le configurazioni più efficaci che ho visto sono state quando 2-3 persone conoscevano pezzi di codice e hanno collaborato. Ciò ha ridotto lo stress e l'isolamento tra i programmatori perché non erano da soli quando le cose si sono guastate e le caratteristiche in ritardo potevano essere prestate più attenzione a rispettare le scadenze senza rampe di addestramento rapido di altre persone nell'organizzazione.

— Jason K.,

@jason - certo, ci dovrebbero essere alcune persone nel team comode e capaci di lavorare su un pezzo di codice. Ma una persona finirà con l'esperto in materia semplicemente lavorando di più su di esso.

— Telastyn,

concordo sul fatto che ciò accade spesso, è lo scenario più probabile e che la competenza in materia è una buona cosa - solo il disaccordo è inevitabile semplicemente perché ho visto un migliore successo con diverse persone che sono le PMI in un'area avendo una considerevole sovrapposizione

— Jason K .