Menu

Sviluppatori Software: due è meglio di uno. E' vero?

Uno dei principi base dell'eXtreme Programmi e di altre Metodologie Agili è il "pair programminig", ovvero due sviluppatori che lavorano in Team sulla stessa postazione. I risultati in termini di qualità ed efficienza.

Kent BeckRitornando ai principi di base dell'eXtreme Programming (XP), la Medotologia Agile (MA) definita da Kent Beck, che di fatto ha dato il via ad un movimento che ha profondamente modificato i processi di sviluppo software, uno dei punti più controversi è sempre stato il "Paired Programming" in base al quale due programmatori lavorano accoppiati sulle stesse porzioni di software, sviluppandolo e nel contempo testandolo. Apparentemente uno schiaffo alla produttività, visto che al posto di avere un'unica persona, per produrre lo stesso codice se ne impiegano due. In realtà, nell'illustrare le motivazioni che portavano a questa scelta, Kent Becks è sempre stato molto deciso, sebbene non altrettanto convincente.

Nei giorni scorsi, su ZDNet è stato pubblicato un interessante articolo nel quale Justin James presenta le esperienze del proprio Team proprio in relazione al paired programming, maturate partendo da un approccio che lo vedeva profondamente scettico.

Pair Programming: cos'è? La definizione di base

Nel suo libro "Extreme Programming Explained: Embrace Change", pubblicato nel 1999 da Addison-Wesley, oggi disponibile in una seconda edizione rivisitata, Kent Beck illustra i principi dell'XP condensandoli in quattro aree (Feedback a scala fine, Processo continuo, Comprensione condivisa, Benessere dei programmatori) e 12 regole. Tra le regole, dette anche pratiche, della prima area Feedback a scala fine svetta  il Pair Programming, per il quale il codice deve esser sviluppato da due programmatori che lavorano assieme su una stessa Workstation. Fatto piuttosto scomodo, se si considera che sempre più spesso vengono ormai utilizzati Laptop con schermi non proprio grandi, ma certamente efficace sul piano dei risultati.

In pratica, questo vuol dire che due persone sedute fianco a fianco (ognuna su una propria sedia), condividono scrivania e Workstation con uno che "guida", ovvero usa la tastiera, e l'altro fa da co-pilota o da "navigatore" in termini rallystici, con il compito di mantenere la concentrazione sull'insieme di ciò che si sta facendo e di rilevare immediatamente gli eventuali errori commessi in fase di codifica.

Sembra assurdo? Molto meno di quanto si pensi: basti pensare che Facebook ha ormai circa il 15% dei propri sviluppatori che opera in questo modo, mentre EMC la sta adottando per un crescente numero di progetti.

Ovvio che uno dei fattori critici nell'applicazione del pair programming sta nel creare team affiatati di sviluppatori, ma una volta avviato il meccanismo sembra che di altri intoppi non ce ne siano, salvo il dover gestire gli "accoppiamenti" nel tempo, visto che progetti cominciano e finiscono, le persone si muovono e così via. In sostanza, occorre porre attenzione anche alla gestione del "ciclo di vita della coppia"....

Ma torniamo alle esperience di Justin James, project leader di Conigent, società di software e di consulenza specializzata nella revisione e nello sviluppo di processi, applicazioni e servizi Cloud.

Due modi di interpretare il Paired Programming

Lo scetticismo di Justin si manifestava su due considerazioni: la prima è che in ogni caso la competenza e la qualità degli sviluppatori, per Kent Becks costituisce il presupposto fondamentale per il successo di qualsiasi programma. Becks arriva persino a considerare gli sviluppatori degli "artisti" ed il software un'opera dell'ingegno per cui se mancano l'uno e l'altro il fallimento è assicurato. La seconda considerazione era: "ma se uso dei programmatori di prima qualità, che ragione c'è di farli lavorare affiancati? Ciascuno dei due è in grado di svolgere perfettamente il proprio compito, così, dove sta il vantaggio?"

Bene, la conclusione alla quale arriva Justin è che il risultato che si ottiene è molto superiore alla somma di quanto ciascuno dei due potrebbe fare operando in modo individuale. Risultato al quale si arriva in almeno due modi diversi. Applicando la metodologia in modo letterale - ovvero con la condivisione della scrivania, o per lo meno della stanza nella quale i due sviluppatori operano - si stimola un confronto continuo tra le due menti concentrate sullo stesso compito, per cui dalle interazioni nascono sempre modi più intelligenti di arrivare al risultato, con un controllo costante della qualità, per cui anche le successive fasi di test ne traggono benefici evidenti. Il valore nasce dall'interazione e dallo scambio di informazioni che si attiva tra le due persone, che assume ancora maggior valore se queste partono da esperienze o livelli di competenza diversi. Perché questo avvenga è in ogni caso indispensabile che l'ambiente di lavoro risulti confortevole e abbastanza ampio da mettere a proprio agio le persone.

 

Un seconto fattore critico perché il pair programming funzioni è che le persone abbiano buone doti comunicative e predisposte all'interazione, senza che questo comprometta il lavoro di altre persone che non appartengono al loro stesso Team. In paricolare, in Conigent gli sviluppatori possono anche usare cuffie acustiche che permettono loro di eliminare i rumori di fondo e di concentrarsi meglio su quanto stanno facendo. Un altro strumento di uso abituale è GoToMeeting tramite il quale vengono condotte le riunioni e le interazioni, specie quando le persone sono dislocate in sedi diverse.

Il secondo contesto nel quale il pair programming viene regolarmente usato con successo è nelle fasi di revisione del codice. Codice che magari è stato sviluppato da programmatori che hanno lasciato l'azienda, per cui deve esser ripreso e portato avanti da un nuovo Team. I risultati dimostrano che con il pair programming si è molto più produttivi ed efficaci nella ricostruzione degli algoritmi e nell'individuazione degli eventuali errori.

Come già rilevato, Justin sottolinea che "Per usare il pair programming con efficacia, occorre scegliere, accoppiare ed addestrare le persone adatte ad operare in tal modo. Senza il dovuto addestramento, la condivisione degli obiettivi e con una forte discrepanza tra i due sviluppatori non solo sarà impossibile ottenere i risultati attesi, ma con tutta probabilità si avrenno conseguenze controproducenti sul piano della produttività e della qualità. L'ideale è quindi abbinare due persone dello stesso livello, che siano tra loro complementari e con elevata probabilità di affiatamento. Il compito del Projet Leader in tutto questo è molto delicato, ma i ritorni che se ne possono ottenere sono enormemente positivi".

E voi, avete utilizzato il pair programming? Come, in quali contesti e con che risultati?

Ultima modifica ilMercoledì, 10 Aprile 2013 10:50

Aggiungi commento


Codice di sicurezza
Aggiorna

Torna in alto