Cosa la maggior parte dei "guru" dell'Agile sbaglia riguardo allo sviluppo hardware

La metodologia Agile, radicata nel mondo dello sviluppo software, è stata salutata come una forza trasformativa nell'industria tecnologica. Tuttavia, mentre ci avventuriamo nello sviluppo di hardware ed elettronica, l'apparentemente fluida adattabilità dei principi Agile incontra un labirinto di sfide e malintesi. Nella nostra prima puntata di questa esplorazione in tre parti, abbiamo analizzato le sfide Agile derivanti dalle differenze tra lo sviluppo hardware e software. In questo articolo, esaminiamo i miti propagati dai "guru" dell'Agile.

Prima di addentrarci nelle complessità dell'Agile nello sviluppo dell'hardware elettronico, è importante chiarire che il nostro intento non è denigrare i coach e i consulenti Agile. Riconosciamo e apprezziamo le loro buone intenzioni e l'entusiasmo nell'assistere i clienti a cogliere i benefici delle metodologie Agile. Sebbene alcune critiche possano derivare da una comprensione limitata delle sfumature dell'hardware, l'intento non è criticare ma adattare efficacemente i principi Agile per soddisfare le esigenze specifiche dello sviluppo hardware. Il nostro focus è personalizzare le tattiche Agile per sfruttarne i benefici in questo contesto unico, modificando l'approccio ma preservando i principi.

Mito #1: Devi Rimanere Flessibile e Adattarti

Gli esperti di Agile esaltano giustamente le virtù dell'esecuzione iterativa, dei cicli di feedback, e della rapida adattabilità che hanno avuto successo nel regno digitale del software. Tuttavia, la transizione di questi principi al paesaggio tangibile dell'hardware e dell'elettronica introduce un livello di complessità non presente nello spettro puramente digitale. Le soluzioni fisiche, a differenza delle loro controparti software, devono essere "completate" per ordinare parti, fabbricare stampi e soddisfare esigenze di produzione rigorose. L'invito di Agile al cambiamento costante si scontra con la natura implacabile dell'effetto a catena dell'hardware quando sono necessari anche cambiamenti minori in ritardo.

In risposta, modificare Agile per lo sviluppo hardware richiede un cambio di paradigma. Non si tratta di modifiche incessanti, ma di adattamenti informati e strategici e di prototipazione. Questi si basano su cicli rapidi di apprendimento ed esecuzione che mirano a massimizzare il valore entro i vincoli di tempo, budget e risorse. La danza tra l'agilità Agile e le esigenze di finalità del prodotto fisico richiede una pianificazione delle iterazioni più coscienziosa e un profondo impegno nella riduzione dei rischi in tutto il progetto.

Mito #2: Devi Sviluppare un Prototipo Funzionante Ogni Sprint

Mentre lo sviluppo di un prototipo pienamente funzionante ogni due-tre settimane, definito "sprint", è spesso propagato dai puristi dell'Agile come un "must" universale per essere Agile, la fattibilità pratica di questo approccio si sgretola di fronte alla realtà dello sviluppo di hardware ed elettronica (e del budget). L'idea di costruire qualcosa, dimostrare progresso e utilizzare questo risultato per ottenere preziosi feedback tecnici e commerciali per informare la tua prossima iterazione è corretta. Tuttavia, ogni progetto hardware è un'entità distinta con i propri obiettivi, dipendenze, vincoli di tempo, aree di innovazione necessaria e rischio. E ogni progetto merita un approccio unico al prototipaggio e all'apprendimento.

Per abbracciare veramente lo sviluppo di prodotti hardware Agile, i team devono abbandonare la mentalità del "taglia unica". Invece, devono fare un'attenta valutazione delle necessità del progetto e poi collaborare per derivare una strategia creativa, di apprendimento e di prototipazione. È importante riconoscere che un "prototipo" può essere qualsiasi output dimostrabile che va da un opuscolo preliminare a un mockup in schiuma (come il famoso mockup dell'iPod di Steve Jobs che contiene "1000 canzoni in tasca"), e può anche includere prototipi parzialmente o completamente funzionanti.

Mito #3: Aggiungi Storie al Backlog e Inizia Subito

Una forza intrinseca delle metodologie Agile risiede nella loro capacità di avviare un progetto molto più velocemente rispetto agli approcci tradizionali a cascata. Infatti, per i progetti hardware elettronici Agile, abbiamo visto una significativa riduzione del periodo che va dall'identificazione del concetto all'avvio dello sviluppo. Questo periodo, che spesso si estendeva per molti mesi o addirittura anni con un approccio tradizionale per fasi, è stato condensato in una questione di settimane o giorni con i metodi Agile. Naturalmente, parte di questo risultato drammatico è come definiamo "l'avvio dello sviluppo".

Per il software, questo è diretto. Gli esperti di Agile promuovono la scrittura di Storie Utente per definire le funzionalità del software, prioritarizzarle in un backlog e avviare uno Sprint. Tuttavia, nell'hardware, è necessario almeno un minimo di pianificazione preliminare per guidare il progetto nella giusta direzione con una comprensione dell'architettura, degli attributi chiave desiderati, dei vincoli e di altri fattori. Questo sforzo preliminare può sembrare in contrasto con i principi Agile del "software funzionante come principale misura del progresso" e "accogliere i cambiamenti dei requisiti, anche in fase avanzata dello sviluppo".

La riconciliazione sta nel trovare un equilibrio adattando le tattiche comunemente comprese di Agile alla fase iniziale dello sviluppo del prodotto. La gestione di progetti Agile per l'hardware consente un avvio rapido allineandosi all'intento strategico del progetto e accettando molti più incognite rispetto agli approcci tradizionali. I team possono quindi collaborare utilizzando l'apprendimento iterativo di Agile per definire la soluzione ottimale, abbinato a una mentalità aperta ai cambiamenti strategici che migliorano il valore del prodotto pur rimanendo entro i vincoli di programma e di risorse.

Mito #4: Definire Tutti i Tuoi Elementi di Lavoro come Storie Utente

Una direttiva critica che molti guru dell'Agile sostengono è che tutto il lavoro di sviluppo dovrebbe essere definito come Storie Utente. Il consiglio continua dicendo che i componenti del sistema, le interfacce, altri ingegneri, ecc., dovrebbero essere trattati come "Utenti". Questo consiglio lascia molti sviluppatori di elettronica e hardware perplessi e in difficoltà nel conformarsi.

Una delle ragioni principali per cui i team di sviluppo software hanno adottato così facilmente le pratiche Agile è perché documentare le esigenze dei clienti con documenti di requisiti tradizionali e casi d'uso dettagliati era estremamente dispendioso e aggiungeva poco valore al team. Perché non dichiarare semplicemente ciò che l'utente sta cercando di fare, scrivere una Storia Utente per documentare la funzionalità e poi trattare questo come un compito di sviluppo? Non è solo auto-documentante, ma se queste storie sono costantemente prioritarizzate e validate con i clienti, abbiamo il sistema chiuso perfetto per rispondere ai cambiamenti e ottimizzare il valore. Fantastico!

Questo tentativo di scrivere Storie Utente direttamente come elementi di lavoro per lo sviluppo hardware, tracciandoli fino ai risultati preziosi per il cliente, è spesso il punto di rottura dell'Agile per molte squadre hardware. Definire l'hardware è semplicemente diverso dal definire il software. I documenti tradizionali sui Requisiti del Prodotto (PRD) e le specifiche funzionali non solo confortano gli sviluppatori hardware, ma forniscono anche i dettagli necessari per suddividere e consegnare il loro lavoro. Chiedere agli sviluppatori di scrivere una Storia Utente come: "Come unità di elaborazione, ho bisogno della regolazione della tensione per garantire un ingresso pulito..." vanifica lo scopo di catturare il valore per il cliente attraverso le Storie Utente e aggiunge sprechi non di valore che gli sviluppatori di software erano così ansiosi di rimuovere con i principi Agile.

Come Mike Cohn, un leader di pensiero iniziale nell'Agile per il software, lo definisce: "Una Storia Utente è una descrizione breve e semplice di una funzionalità raccontata dalla prospettiva della persona." La parola chiave qui è "persona". L'Agile per le squadre hardware può ottenere un valore significativo dalla scrittura di Storie Utente, ma deve utilizzarle per catturare le esigenze dei clienti da persone, non definire elementi di lavoro. Queste storie devono quindi essere tradotte in attributi del prodotto e elementi di lavoro correlati che soddisfino i risultati desiderati con tecniche che abbiano senso per gli sviluppatori hardware.

MITO #5: Devi Avere Membri del Team Dedicati

Un sondaggio su LinkedIn di Vitality Chicago ha mostrato che il 54% dei praticanti Agile afferma che avere una squadra Scrum o Agile dedicata (implicando membri del team dedicati) è una regola essenziale dell'Agile. Sebbene non ci sia discussione di team dedicati nel Manifesto Agile, gli esperti di Agile spesso trattano questo come una regola, ed è difficile sostenere che non ci sarebbero molti vantaggi nell'avere membri del team concentrati al 100% su un progetto. Ci sarebbero poche scuse per non rispettare gli impegni, nulla a distrarre il successo, e nessuno che dice: "Quest'altro progetto ha la priorità questa settimana!"

Tuttavia, se hai mai lavorato in un ambiente di sviluppo hardware, sai che avere membri del team dedicati sarebbe un lusso che poche organizzazioni possono permettersi. La natura dello sviluppo hardware è tale che architetti, progettisti principali e altri esperti di materia (SME) sono spesso necessari in più progetti. Un'azienda potrebbe avere un esperto di frequenza radio che viene chiamato quando la sua competenza è necessaria, uno specialista di layout che è necessario in momenti chiave, ecc. I team di sviluppo hardware possono comunque abbracciare e sfruttare i metodi Agile, ma avere membri del team dedicati di solito non è un'opzione. Pertanto, avere un approccio alla gestione delle risorse che supporti l'Agile è critico per il successo a lungo termine dell'Agile.

#Mito 6: Agile È la Somma dei Suoi Ruoli Definiti, Riti, Cerimonie e Vocabolario

Due team lavorano fianco a fianco in un'azienda: un team hardware che utilizza un approccio tradizionale a cascata e un team software che usa i metodi Scrum. Un sviluppatore hardware passa accanto alla sala riunioni dove i sviluppatori software sono riuniti in cerchio e sente, "Ok, benvenuti al nostro standup. Durante l'ultimo sprint, abbiamo avuto difficoltà con le stime dei punti delle storie utente e i criteri di accettazione. Il nostro scrum master ha condiviso il nostro ultimo burn-up e ha facilitato una retrospettiva per affrontare i problemi nel nostro grooming del backlog così da poter aumentare la velocità. Facciamo un fist-to-five su come ci sentiamo riguardo ai cambiamenti." Una gamma di pugni e configurazioni di dita si alza rapidamente.

Lo sviluppatore hardware, sebbene intrigato, non può fare a meno di sentirsi un po' perplesso da questo bizzarro rituale e dall'abbondanza di termini non familiari, chiedendosi come queste metodologie Agile potrebbero eventualmente tradursi nel suo mondo di sviluppo hardware tangibile. "Sono finito in un culto?!" si chiede.

Spesso, i guru dell'Agile sono così immersi nel linguaggio e nella cultura dell'Agile per il software che credono che i team hardware debbano adottare le stesse cerimonie, ruoli, strumenti e linguaggio per essere veramente "Agili". Ironia della sorte, il primo principio del Manifesto Agile afferma, "Individui e interazioni più che processi e strumenti." Penso che possiamo costruire su questo e affermare ulteriormente, "Individui e interazioni più che processi, strumenti, rituali e dogmi." Mentre concordare sul linguaggio, sui formati delle riunioni e sulle attività specifiche per costruire una mentalità Agile e un modo di lavorare sistematico sono tutti critici per il successo, adottare i rituali specifici e il vocabolario dello Scrum o dell'Agile per il software non lo è. I team hardware devono esaminare lo scopo e l'intenzione di ogni elemento Agile, cerimonia e ruolo e determinare cosa e come ciascuno possa soddisfare al meglio le loro esigenze.

Colmare il Divario Agile-Hardware

Mentre rifletti se un approccio Agile è adatto ai tuoi sforzi di sviluppo hardware ed elettronico, la "saggezza" convenzionale diffusa da guru Agile benintenzionati spesso non è sufficiente a guidare l'approccio più sfumato e adattivo necessario per lo sviluppo di prodotti fisici. Il percorso verso un'implementazione Agile di successo nell'hardware comporta una miscela riflessiva di flessibilità, preparazione iniziale, pianificazione iterativa e un approccio coscienzioso per convergere sulla soluzione più preziosa possibile nel minor tempo possibile.

Nel segmento conclusivo della nostra serie in tre parti, approfondiremo ulteriormente come sfruttare i vantaggi dell'Agile modificato per lo sviluppo di hardware elettronico, mantenendo al contempo i principi fondamentali della metodologia Agile. Sei interessato ad esplorare l'argomento in modo più dettagliato? Guarda il webinar!