Un caso industriale di successo come modello evolutivo dell’XP

E’ proprio vero che sul tema Project Management il mondo software abbia definitivamente preso una strada a sè stante, che ha ormai poco da condividere con altri ambienti di lavoro e sviluppo?

Venendo da più di un decennio di progetti industriali ho dovuto per prima cosa riconoscere ed affrontare le tante diversità rispetto al mondo della programmazione e del web. Penso tuttavia anche che sia stata per me una grande fortuna poter vivere due ambienti tanto diversi, oltretutto sommata a quella di aver conosciuto, nella mia “precedente vita” compagnie appartenenti a Paesi molto eterogenei e con mentalità agli antipodi.

Le fortune vanno valorizzate e mi è quindi venuto naturale cercare di carpire il meglio dalle tante esperienze avute, convinto che nella diversità stia la vera ricchezza e la possibilità – talvolta affatto banale – di integrazione e di continuo miglioramento.

In sostanza, il superamento di modelli classici di project management da sempre legati allo sviluppo industriale di prodotti, a favore di metodi più adatti al mondo della programmazione, sta facendo erroneamente credere che i diversi modelli di gestione di progetto siano destinati a divergere sempre di più. A mio modesto avviso invece c’è spazio per condividere esperienze e avvantaggiarsene nei diversi ambienti.

Assunzioni discutibili

Innanzitutto, non è affatto vero che un progetto industriale sia perfettamente deterministico, con azioni già note e stimabili e di conseguenza pianificabili con un classico Gantt. Questa affermazione può essere considerata veritiera solo di fronte allo sviluppo basato su processi già maturi e consolidati, mentre è clamorosamente falsa durante le fasi di start-up, studio, analisi, definizione e prima prototipazione di nuovi prodotti.

In tale contesto, infatti, niente è predeterminato e l’intero processo e le conseguenti azioni sono tutte da definire, ridiscutere e validare, guidate soprattutto dalla creatività e dalla capacità dei singoli, esattamente come la maggior parte degli sviluppi basati su generazione di codice. D’altra parte, mi è stato detto più volte, “scrivere software è come scrivere un libro”, e quindi per definizione attività poco stimabile in termini di tempo e sforzo. Questa asserzione, pur affascinante, non è ovviamente del tutto conforme alla realtà perchè un libro non deve affatto sottostare ai vincoli ed alle indicazioni di un cliente.

In entrambi i contesti dunque c’è, in primis, un estremo bisogno di una non trascurabile prima fase di definizione della specifica, con l’obiettivo di minimizzare le variabilità dello sviluppo successivo.

Un caso di successo “industriale” potrà aiutare a capire anche altri passi e le relative soluzioni implementate. Una decina di anni fa è stata necessaria una migrazione, in tempi rapidissimi per diverse ragioni, a componenti elettronici che non contenessero alcuna traccia di sostanze ritenute dannose per l’ambiente. Questa migrazione, all’apparenza definibile in modo lineare, portava invece con sé tutta una serie di problematiche del tutto inaspettate, variabili anche quotidianamente:

  • Definizione della specifica finale, ridefinita regolarmente dopo ogni fase di test;
  • Scelta dei prodotti e passi del processo da migrare, e relativa fattibilità;
  • Definizione dei materiali sostitutivi e relative classificazione e qualifica;
  • DOE: prima di pensare al test è necessario pensare a: cosa sperimentare e analizzare? Cosa e come testare?
  • Testabilità: definizione dei test, analisi dei risultati e azioni correttive;
  • Ridefinizione dei parametri di qualità ed affidabilità finale.

E’ utile sottolineare che il fine ultimo di ogni step era arrivare a un prototipo che divenisse prodotto stabile e riproducibile con affidabilità. Ognuno di questi passi era caratterizzato da una non stimabilità a priori intrinsecamente dovuta a due aspetti fondamentali:

  • la maggior parte degli aspetti tecnici non erano prevedibili dai clienti stessi, rappresentando per loro una novità, data la rapidità della richiesta del mercato
  • i risultati di ciascuna prova producevano a loro volta nuove prove data le tante incognite associate ad ogni test.

Come si può facilmente dedurre ci si è trovati di fronte a una variabilità pressochè totale che ha, di fatto, impedito la iniziale stesura di un piano verosimile: tante supposizioni iniziali rimanevano vere solo sulla carta e, su base quotidiana, le azioni da implementare venivano talvolta perfino stravolte.

Appare chiaro a questo punto la analogia con, ad esempio, la proliferazione del backlog in un modello Agile. A cosa è dovuta tante volte, infatti, la tanto temuta proliferazione delle azioni per lo scrum team?

  • Imprecisa definizione della specifica del prodotto;
  • Imprevedibilità di ogni funzionalità desiderata;
  • Opinabilità di valutazioni;
  • Scarsità di comunicazione tra cliente e sviluppatori;
  • Inadeguatezza o persino assenza del product owner.

La soluzione “industriale”

Il caso di successo “industriale è stato gestito grazie alla formazione di un team condiviso tra cliente e fornitore, una sorta di esempio estremo del whole team previsto nel modello di eXtreme Programming, che potesse interagire in modo continuo e regolare, anche su base quotidiana, al fine di definire e ridefinire specifiche, prototipare, e testare congiuntamente.

Deve essere sostanzialmente accettato il presupposto che la definizione di funzionalità numerose e complesse integrate, ad esempio, in una piattaforma web deve essere equiparato allo sviluppo di un prodotto totalmente nuovo che non può prescindere da una strettissima collaborazione con il cliente in tutte le fasi dello sviluppo, in particolare, ma non solo, nelle fasi di:

  • Stesura specifica: la definizione delle funzionalità e conseguente stesura delle user stories dovrebbe essere idealmente frutto di una seria fase di confronto. Tale fase è solo virtualmente tempo perso, perchè maggiore sarà la precisione iniziale più agevole il cammino del progetto stesso.
  • Test: dovrebbe essere svolto non alla fine del processo ma durante lo sviluppo stesso, internamente al team di sviluppo e in continuo confronto con il cliente ed eventuali parti terze. Solo in questo modo sarà possibile intercettare eventuali deficienze nella definizione iniziale e sarà più agevole arrivare ad una scrittura precisa e puntuale della funzionalità finale. I risultati di ogni test devono essere discussi anche quotidianamente.

In sostanza, il confronto con il cliente deve essere necessariamente portato a una dimensione più continua, analitica e strutturata e non delegato a pochi e frettolosi incontri settimanali. Inoltre l’obiettivo fnale non dovrebbe essere quello di gestire solo il progetto in corso ma di poter riprodurre le soluzioni trovate anche nei futuri progetti, come e oltre la tecnica dell’XP impone.

Obiettivo: affidabilità, ripetibililità, riusabilità (pensare oltre al progetto in corso)

Inaspettatamente, quindi, un caso di successo industriale sembra avvicinarsi a un modello finora pensato e nato per il mondo software, pur con alcune accortezze, precisazioni e spunti:extreme2

  • Ridefinizione del team scrum: il product owner da solo non basta, ma deve piuttosto diventare il leader di un team condiviso tra cliente e sviluppatori. Questo “whole team” dovrebbe però includere anche membri dedicati all’affidabilità delle azioni implementate al fine di renderle il più possibili stabili nel tempo, come assolutamente scontato nel caso di un prodotto.
  • Estensione del concetto di demo: una demo settimanale di pochi minuti non è sufficiente ma deve essere sostituita da meeting anche quotidiani con precisi report e azioni da implementare, validate da cliente e sviluppatore. Inoltre ogni “iterazione” dovrebbe a sua volta fare da driver per team members con funzioni trasversali, che implementino azioni volte a stabilizzare e integrare le funzionalità rilasciate in un ambito più globale.
  • Obiettivo dell’intero processo, soprattutto sul fronte developers, dovrebbe essere quello di tendere alla ripetibilità delle soluzioni e funzionalità implementate. Queste a loro volta dovrebbero infatti poter garantire la più veloce scrittura e validazione di altre funzionalità dello stesso progetto e persino essere qualificate e riutilizzate in progetti successivi, in un processo di feedback a ciclo continuo tendente a rendere il codice sempre più simile a un vero e proprio prodotto.

Loading Facebook Comments ...
0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *