In quali situazioni la collaborazione da remoto può funzionare? Per quale tipo di progetti?
In Remote versus Co-located Work, Martin Fowler analizza pro e contro del lavoro a distanza, le maggiori difficoltà nel comunicare e, sull’altro piatto della bilancia, la possibilità di coinvolgere esperti non disponibili localmente.
Quali sono le responsabilità di un Product Manager? Cosa lo differenzia da un responsabile di progetto? In quale posizione della gerarchia organizzativa dovrebbe trovarsi?
E soprattutto, quali caratteristiche, quali competenze bisogna possedere per essere un buon responsabile di prodotto? Serve una formazione appropriata, sostiene Ellen Chisa in “Evolution of the Product Manager“, ACM Queue, october 2014.
Il pair programming (programmazione in coppia) è una delle tecniche “classiche” di extreme programming.
Ora il principale esponente di quell’approccio agile, Kent Beck, propone una ipotesi in merito a quando la programmazione in coppia funziona, e quando no: Pairing as Pruning.
In sintesi, lavorare in coppia è utile quando ci sono incertezze in merito alla definizione del problema da risolvere, e al modo in cui può essere risolto. I problemi chiari con soluzioni ben definite non necessitano secondo Beck di collaborazione, ma di automazione.
Nell’era della conoscenza bisogna saper distinguere tra la conoscenza vitale e quella di supporto. Vitale è la conoscenza dei processi operativi specifici e fondamentali dell’organizzazione; di supporto è la conoscenza che riguarda processi comuni a tutti i settori di attività (come ad esempio la gestione amministrativa o la gestione del personale).
Ora, la conoscenza nelle organizzazioni è in gran parte incorporata nel software. Usare pacchetti applicativi standard per gestire i processi operativi comuni, cioè la conoscenza di supporto, comporta vantaggi indubbi sia in termini di costo che di semplificazione. Ma esternalizzare lo sviluppo dei sistemi software che incorporano la conoscenza vitale è rischioso:
“Questa forma di outsourcing significa abdicare al compito di accrescere e rendere operativa la conoscenza vitale del proprio business. Continua la lettura di Quali limiti per l’outsourcing
In alcuni approcci agili allo sviluppo software il ruolo di “analista” è messo in discussione. Nessuno, comunque, dubita che sia necessario fare attività di analisi.
Al contrario, in diverse organizzazioni medio-grandi, il ruolo di analista viene declinato in molti modi, con la creazione di ruoli distinti, ad esempio così:
Come regola, più sono i ruoli che condividono l’etichetta “analista”, più si generano discussioni e documenti sui limiti delle responsabilità di ognuno, sulle competenze distintive che li caratterizzano, su come debbano interagire tra loro.
Un articolo interessante sulla differenza tra ricoprire un ruolo di analista e fare attività di analisi, nell’uscita Winter 2014 di Methods and Tools: “Analysis on Analysts in Agile”, di Leslie J. Morse.
Ready Technology: sono le tecnologie che usiamo tutti i giorni, smartphone, social network, strumenti per condividere documenti in rete, sistemi di videoconferenza.
Per gli individui rappresentano opportunità, non problemi. Sono, però, un fenomeno che sfugge al controllo dei reparti IT delle organizzazioni.
Fino a pochi anni fa, l’acquisizione delle nuove tecnologie informatiche passava per l’IT, o almeno l’IT poteva nutrire l’ambizione di governarlo in modo completo. Il modo di pensare prevalente era che prima di adottare una tecnologia bisognasse analizzare e validare i requisiti di business, e che prima di permetterne la diffusione la tecnologia dovesse venire testata e giustificata dal punto di vista del rapporto costi benefici.
Ora, “è chi lavora nelle business unit a governare l’adozione delle tecnologie e a sfruttarle, senza la ‘guida’ dei responsabili dei sistemi informativi”.
“Ready Technology“, di Stephen J. Andriole, in Communications of the ACM, February 2014.
I progetti hanno bisogno di manager? Sì, ma hanno bisogno soprattutto di buoni capisquadra, capaci di controllare nel merito e di assicurare la qualità di ciò che si produce.
Where is the Foreman? e Oh Foreman, Where art Thou? , di Uncle Bob Martin.
La divisione del lavoro nello sviluppo software, su ZeroUno, Dicembre 2013.
Sul fallimento del sito healthcare.gov, una riflessione di James Bach in merito a “innocenza” dei manager, e colpe dei tecnici.
Per diventare “campioni” in una disciplina servono almeno 10.000 ore di esercizio, ma la pratica da sola non è sufficiente, il talento è decisivo.
In un ambito multidisciplinare come lo sviluppo software, comunque, è essenziale che gli specialisti collaborino tra loro per il successo dei progetti, anche svolgendo attività al di fuori della loro specializzazione, come argomenta Jim Coplien in “Can You Scrum Art?“.