{"id":32176,"date":"2025-03-04T11:00:00","date_gmt":"2025-03-04T10:00:00","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=32176"},"modified":"2025-03-03T16:13:47","modified_gmt":"2025-03-03T15:13:47","slug":"lo-sviluppo-del-software-e-una-attivita-collaborativa","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/soft-skill\/lo-sviluppo-del-software-e-una-attivita-collaborativa\/","title":{"rendered":"Lo sviluppo del software \u00e8 una attivit\u00e0 collaborativa"},"content":{"rendered":"\n

Lo sviluppo del software \u00e8 una attivit\u00e0 collaborativa, non ricordo pi\u00f9 dove ho letto questa frase, quindi mi dispiace di non saper citare la fonte, e, purtroppo non e mia.<\/p>\n\n\n\n

L\u2019ho letta molti anni fa, quando ancora sviluppavo software e forse perch\u00e9 ero una autodidatta e quindi mi approcciavo a mio modo alla programmazione, mi rimase impressa, tanto da ricordarla ancora adesso.<\/p>\n\n\n\n

L\u2019idea, forse un po\u2019 romantica, che mi ero fatta entrando nel modo della programmazione era quella di poter risolvere problemi, io, la mia competenza, una tastiera ed una IDE.<\/p>\n\n\n\n

Quello che poi ho imparato \u00e8 che non si \u00e8 mai da soli. E per fortuna, dal mio punto di vista!<\/p>\n\n\n\n

\n

Lo sviluppo del software \u00e8 una attivit\u00e0 collaborativa.<\/p>\n<\/blockquote>\n\n\n\n

Perch\u00e9 molto spesso si lavora in un team, perch\u00e9 il team ha degli stakeholders che lavorano allo stesso prodotto\/progetto\/programma, perch\u00e9, per i pi\u00f9 fortunati, c\u2019\u00e8 anche la possibilit\u00e0 di parlare con il cliente finale!<\/p>\n\n\n\n

Non si \u00e8 mai da soli. <\/p>\n\n\n\n

E per alcune persone questo \u00e8 un bene, per altre \u00e8 un qualcosa con la quale fare pace.
Questo articolo \u00e8 per quelle persone che vorrebbero farci pace.<\/p>\n\n\n\n

Collaborare \u00e8 comunicare<\/h2>\n\n\n\n

Capire i requisiti<\/h3>\n\n\n\n

Collaborare pu\u00f2 avere pi\u00f9 accezioni ma presuppone comunque una forma di comunicazione, scritta o orale: non importa se ricevi il documento dei requisiti o se fai un workshop con tutti gli stakeholder in una stanza per una settimana fino a tirare fuori un prototipo. <\/p>\n\n\n\n

In tutti e due i casi stai comunicando.<\/p>\n\n\n\n

Nel primo, tramite un documento che, nella mia esperienza \u00e8 il metodo meno efficace, nel secondo lavorando a stretto giro e scambiando feedback nel modo pi\u00f9 ravvicinato e veloce possibile.<\/p>\n\n\n\n

Quando sar\u00e0 finito?<\/h3>\n\n\n\n

Qui tocco un tema tanto caro quanto spinoso: le stime.<\/p>\n\n\n\n

Ed anche per questo tema si possono fare in diversi modi, potreste saltarle a pi\u00e8 pari, perch\u00e9 qualcuno le ha gi\u00e0 fatte per te e allora forse la comunicazione che dovrete mettere in campo sar\u00e0 di un altro tipo… oppure potresti doverle comunicare.<\/p>\n\n\n\n

E magari anche attivare una sana forma di contrattazione, che secondo me altro non \u00e8 che una forma pi\u00f9 sofisticata di comunicazione, con tecniche specifiche.<\/p>\n\n\n\n

Bug in produzione!<\/h3>\n\n\n\n

Moriremo tutti?
No, ma forse qualcuno salter\u00e0 la cena.<\/p>\n\n\n\n

Anche qui dipende dai processi implementati, se lavori in una startup o in una corporate, se c’\u00e8 uno o pi\u00f9 team dedicati, se c’\u00e8 una policy per dare priorit\u00e0 ai bug, se c’\u00e8 un presidio h24…<\/p>\n\n\n\n

In tutti i casi, sapere come e a chi comunicare lo stato del problema, risulta utile.<\/p>\n\n\n\n

Se hai riconosciuto qualcuno di questi scenari, potresti essere interessato a qualche esperimento da provare.<\/p>\n\n\n\n

Per ogni scenario, condivido quello che per me ha funzionato, sia nella mia esperienza di dev sia come facilitatrice.<\/p>\n\n\n\n

Capire i requisiti – Non dare per scontato nulla, controlla il contesto<\/h2>\n\n\n\n

Verifica se esiste il vocabolario comune<\/h3>\n\n\n\n

Quando scegli di condividere delle informazioni tecniche a chi tecnico non \u00e8, potresti cadere nell’errore di dare per scontato un vocabolario comune.<\/p>\n\n\n\n

Framework, protocollo, pattern, microservizi… potrebbero essere parole che tu usi abitualmente ma che non fanno parte del vocabolario del tuo interlocutore.<\/p>\n\n\n\n

\n

Per avere pi\u00f9 possibilit\u00e0 che la comunicazione avvenga, potresti verificare quali parole fanno parte del loro vocabolario e che il significato sia lo stesso o per lo meno molto simile.<\/p>\n<\/blockquote>\n\n\n\n

Definisci il livello di dettaglio<\/h3>\n\n\n\n

Se sei una persona attenta al dettaglio, potresti aver bisogno di capire fino all’ultimo bit prima di essere pronta a spiegare qualcosa. Magari ti piace andare in fondo ai problemi, studiare soluzioni diverse ed essere preparato a rispondere anche alle domande pi\u00f9 complesse.<\/p>\n\n\n\n

Mi ricorda un po’ il famoso schema di Alastair Cockburn<\/a> sui livelli degli Use Case.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Se nella tua comunicazione riesci a stare a livello del “mare”, potrebbe andare bene, con qualche capatina sopra (kite) e sotto (fish).<\/p>\n\n\n\n

Potrebbe essere utile capire il livello di dettaglio di cui hai bisogno, e se ti serve per sentirti bene andare in profondit\u00e0 e poi tornare su e capire quali informazioni sono state utili per te e quali sono quelle essenziali da comunicare.<\/p>\n\n\n\n

In questo modo, se ti chiedono pi\u00f9 dettagli, li hai, magari messi in appendice.<\/p>\n\n\n\n

Il livello di dettaglio di cui hai bisogno potrebbe non servire per\u00f2 alle persone con cui stai comunicando per capire il problema. <\/p>\n\n\n\n

Anzi potrebbe creare confusione.<\/p>\n\n\n\n

Una volta che hai il livello di dettaglio utile per te, cerca di capire quale potrebbe essere quello utile a Prodotto o a Marketing o al tuo manager.<\/p>\n\n\n\n

Lo sviluppo del software \u00e8 una attivit\u00e0 collaborativa, lo avevo detto no?<\/p>\n\n\n\n

Schemi, diagrammi ed altri animali fantastici<\/h3>\n\n\n\n

Se schemi e diagrammi sono il tuo pane quotidiano, ti fanno capire le cose, e sono anche il modo di comunicare con gli altri colleghi del team di sviluppano, perch\u00e9 non funzionano con chi non \u00e8 tech?<\/p>\n\n\n\n

Anche qui, dipende, ci sono diagrammi che potrebbero essere pi\u00f9 utili di un documento di 200 pagine!<\/p>\n\n\n\n

Ma usare un diagramma presuppone che l’altra persona capisca la notazione, il significato di un quadrato, un cerchio, una freccia. <\/p>\n\n\n\n

Sempre di un vocabolario comune si tratta. Quindi usali controllando che siano chiari ed utili per ragionare insieme.<\/p>\n\n\n\n

Quando sar\u00e0 finito? – Numeri pi\u00f9 che parole<\/h2>\n\n\n\n

Ho assistito a lunghe discussioni anche solo per decidere se una storia valeva 2 o 3 punti.<\/a><\/p>\n\n\n\n

Ho anche partecipato a lunghe discussioni su stime da rivedere, perch\u00e9 non coincidevano con le aspettative che in un altro dipartimento si erano create sulla base di… ecco, non so esattamente sulla base di cosa.<\/p>\n\n\n\n

Ed \u00e8 qui il punto: dati storici!<\/p>\n\n\n\n

I dati storici alleggeriscono di molto il problema della comunicazione delle stime, perch\u00e9 si passa dalle stime al forecasting su dati storici.<\/p>\n\n\n\n

Sia chiaro, lo sviluppo del software \u00e8 una attivit\u00e0 collaborativa, quindi la comunicazione non diventa meno importante se si utilizza il forecasting invece degli story point.<\/p>\n\n\n\n

Dal mio punto di vista per\u00f2, diventa pi\u00f9 interessante perch\u00e9 si sposta sulla affidabilit\u00e0 dei dati che si basa su stabilit\u00e0 del team, conoscenza di dominio, capacit\u00e0 di innovazione, pratiche di programmazione…<\/p>\n\n\n\n

Quindi la comunicazione che deve avvenire non \u00e8 pi\u00f9 se una User Story \u00e8 3 o 5 o se ce la facciamo a rilasciare 10 funzionalit\u00e0 in 3 mesi, ma come possiamo incrementare l’affidabilit\u00e0 dei team e quindi dei dati.<\/p>\n\n\n\n

Bug in produzione! – Manteniamo la calma<\/h2>\n\n\n\n

Quando ci si rende conto di un problema in produzione la capacit\u00e0 di comunicare in maniera chiara cosa sta succedendo risulta ancora pi\u00f9 importante.<\/p>\n\n\n\n

Probabilmente, appena scoperto il problema, non si ha una idea chiara di quello che sta succedendo e tutti vogliono saperlo!
Quello che si deve comunicare \u00e8 proprio questo insieme all’esigenza di avere lo spazio mentale ed il tempo di capire cosa sta succedendo.<\/p>\n\n\n\n

Se non esiste un processo collaudato, quello che si pu\u00f2 fare \u00e8 di accordarsi sulla frequenza di update brevi. Anche qui, meno di parla “tecnichese” meglio \u00e8.
Di solito quello che si vuole sapere \u00e8 se il problema \u00e8 stato individuaro, se la soluzione \u00e8 stata trovata ed in quanto tempo si potr\u00e0 risolvere.<\/p>\n\n\n\n

Risolto il problema bloccante, si dovr\u00e0 avere una conversazione pi\u00f9 lunga sulle possibili cause per esempio utilizzando la tecnica dei Five Whys<\/a> per fare una root cause analisys.<\/p>\n\n\n\n

Conclusioni<\/h2>\n\n\n\n

Per fare un buon prodotto servono diverse competenze e comunicare per andare verso un obiettivo comune diventa essenziale.<\/p>\n\n\n\n

In ogni fase dello sviluppo del software avere la capacit\u00e0 di comunicare e capire cosa l’interlocutore ha bisogno di sapere sono due elementi essenziali per la collaborazione.<\/p>\n\n\n\n