Scrum per dispositivi di sistema integrati

Dove lavoro, creiamo sistemi embedded e stiamo anche utilizzando scrum per il nostro sviluppo. Stai osservando le cose da una prospettiva tecnica , non da una prospettiva delle caratteristiche .

La prima cosa che dovresti chiedere è "Perché dobbiamo implementarlo?" Ad esempio: Perché hai bisogno di SPI? Sarà utilizzato per EEPROM in modo da poter memorizzare i numeri di serie? O magari collegarsi a un controller del display in modo che gli utenti possano vedere gli oggetti su un display? Ci sono molti buoni motivi per creare un driver SPI, ma crearlo solo per averlo non è uno di questi motivi.

Con Scrum dovresti adottare un "Non ne abbiamo bisogno finché non abbiamo bisogno " di politica, il che significa che non devi perdere tempo con SPI o wifi o qualsiasi cosa altro finché non c'è un bisogno di business che richiede tali tecnologie per essere realizzato. Quindi quella necessità di business diventa la storia.

Prova "Aggiungi su EEPROM per l'archiviazione di configurazione" invece di "Crea codice SPI"

e "Crea connessione al server per la gestione remota" invece di "Trova documentazione per WIFI e implementa"

Non restare impigliato nei dogmi di scrum. Scrum esiste per renderti più agile. Tutto ciò che si frappone può essere ignorato.

È vero che non si dovrebbe fare un lavoro che non dia valore al business, ma il valore si presenta in molte forme. Trai valore dall'avere un driver ethernet? Sospetto che tu lo faccia, perché senza di esso non puoi fornire certe funzionalità. "Come sviluppatore, ho bisogno di un driver ethernet per poter implementare le funzionalità che richiedono la connettività Internet".

Quindi, non considerare il valore solo come funzioni visibili all'utente. Il valore è tutto ciò che rende il tuo prodotto migliore, anche se è invisibile all'utente finale.

Alcuni diranno che non è una storia valida, e le storie dovrebbero solo avere caratteristiche visibili all'utente. Penso che sia ok, fino al punto in cui ti causano problemi come questo. Ancora una volta, l'obiettivo di scrum è quello di aiutarti e migliorare l'attenzione e la comunicazione. Non lasciare che ciò che pensi che tu debba fare impedisca il tuo svolgimento. Sii pragmatico e sii onesto. Se pensi di aver bisogno di sviluppare una certa cosa, rispondi alla domanda "perché" e "per chi è questo?". La risposta non deve sempre essere la stessa persona.

Una delle principali sfide che utilizzano Scrum con lo sviluppo integrato, secondo la mia esperienza, è che i migliori team di Scrum offrono fette di funzionalità a pieno stack. Dalle viscere più profonde all'esposizione dell'utente. Ciò mantiene i problemi di integrazione all'interno di una squadra e all'interno di uno sprint. E dimostra il valore aziendale perché l'utente finale può vedere e provare il risultato.

Anche per i software puri può essere difficile rendere la storia abbastanza sottile ad ogni livello in modo che l'intera storia possa essere costruita in uno sprint o due. Ma per l'embedded, questo potrebbe essere impossibile perché l'intestino più profondo coinvolge l'hardware che non si adatta rapidamente come il software perché è radicato nel mondo fisico.

La soluzione ideale è potenziare le tue capacità hardware in modo che possano pedalare più velocemente ... con simulatori, tiri veloci di breve periodo, modelli e così via. Ma può essere costoso. Quindi, un compromesso spesso utilizzato, che penso si applichi alla tua situazione, è quello di rilassare il concetto di valore aziendale e lasciare che includa funzionalità più generali richieste dagli utenti finali e dall'applicazione.

Quindi, per esempio, se hai bisogno di costruire il WiFi, è meglio che ci sia una ragione per l'utente finale o perché lo stai facendo. Trovalo e inseriscilo nella definizione della user story, come questa per il settore automobilistico: "Fornisci funzioni di controllo degli occupanti in modalità wireless, per soddisfare le esigenze dei passeggeri, riducendo al tempo stesso i costi e aumentando l'affidabilità e la manutenibilità."