ITERAZIONE DEL DESIGN

Una delle domande più frequenti nell’ambito di prodotti tangibili o embedded quando si considera Scrum è “come possiamo completare le attività in un solo Sprint? Ci vuole più tempo a sviluppare un pezzo fisico delle due settimane previste per lo Sprint!”. Lo sviluppo di prodotti fisici ha bisogno di un punto di vista diverso sulle iterazioni rispetto al software.

Quando il team Wikispeed iniziò a lavorare sugli interni, realizzarono subito il fatto che la mancanza del freno a mano stava rallentando i lavori. Il freno a mano doveva essere posizionato in mezzo ai due sedili, accanto al cambio ed ai binari dei sedili e gli attacchi delle cinture di sicurezza. Siccome non si sapeva come costruirlo nessuno si sentiva confidente nel decidere il design di un pezzo così importante e così vicino agli altri componenti.

La soluzione “versione 0.01” del freno a mano consisteva in una scatola di cartone con su scritto: “il freno a mano occuperà lo spazio di questa scatola”. Quella funzionalità permetteva al team di lavorare sui componenti adiacenti anche se tutti erano consapevoli che quella scatola non era in grado di frenare la macchina, era una funzionalità finta!

Lavorando con l’hardware, per iterare il design occorre:

1. Creare un test che il componente da disegnare deve superare.
2. Disegnare il componente nella maniera più semplice in modo da superare il test.
3. Migliorare il design del componente in modo da risultare più semplice e più elegante.
4. Ripetete il processo (Iterazione del design) finché migliorare il componente non aggiunge ancora valore al prodotto.

Iterare il design nell’Hardware. Il corrispettivo degli oggetti mock e stub, fake e dummy nel software.

Nel caso della versione v0.01 del freno a mano, il test di accettazione consisteva in “può il team disegnare i componenti adiacenti con confidenza?”. In pratica assomiglia a quello che nel software si ottiene con i mock object e con gli stub.

La scatola di cartone che definiva l’ingombro del freno a mano soddisfaceva il test. Progettare il resto era giudicato più importante in quel momento. La scatola di cartone servì finché gli altri componenti non erano buoni abbastanza.

Nel software, sviluppare Agile significa avere un incremento di prodotto potenzialmente consegnabile ogni iterazione. Questo potrebbe non essere sempre possibile con l’Hardware, per cui occorrerà iterare diverse volte finché il design sia soddisfacente. Nel caso di Wikispeed le iterazioni inclusero user stories come “esiste un freno a mano che permette di bloccare l’auto” e “il freno a mano non produrrà resistenza quando la macchina è in movimento”.

Occorrerà un “iterazione del design” anche per i test di accettazione, specialmente se si intende renderli automatici. Prima che Wikispeed facesse il primo crash test reale erano stati svolti diversi test al simulatore. Questi erano economici e ripetibili in quanto tutto quello di cui avevano bisogno era un computer. Dopo che eseguirono il crash test reale usarono i dati prodotti per arricchire il crash test simulato. Alla fine i test simulati erano così realistici che non necessitarono più di test fisici.