Costruire il frontend del software per l'hardware che non esiste ancora

Non fornisci alcun suggerimento su cosa farà l'hardware, quindi presumo che non si tratti di dispositivi che richiedono la conformità a una specifica (come una scheda di rete).

Nel caso più generale, inizierei con un'API completamente specifica per accedere all'hardware previsto secondo le specifiche funzionali. Una volta approvata la tua API, puoi passare all'implementazione dell'hardware simulato come libreria solo software. Ciò ti darà un grande vantaggio anche dopo che l'hardware è stato eseguito, perché puoi eseguire il debug di un bel po 'dei tuoi client senza mai aver bisogno dell'hardware - molto più semplice che fare casino con un dispositivo hardware. Questo ti darà due prodotti da mantenere: la vera libreria e una libreria di emulazione; ma lo sforzo ne varrà la pena.

Una volta che l'hardware è pronto, puoi iniziare a rimuovere un sacco di codice dalla libreria e scaricare l'elaborazione sul tuo hardware. La libreria verrà quindi trasformata in un livello adattatore: conversione dell'implementazione hardware nell'API implementata nel software. Se la tua API corrisponde perfettamente all'hardware, la libreria sarà uno shim estremamente sottile, forse qualcosa che serializza i parametri, li invia all'hardware e legge i risultati. Oppure può rivelarsi qualcosa di simile all'hardware reale, quindi nella libreria sarà presente un bel po 'di codice, mantenendo lo stato lato client non banale che viene utilizzato per guidare l'hardware.

Questa sembra un'opportunità perfetta per me. Mi piacerebbe un progetto in cui non solo è fattibile ma desiderabile per il cliente passare attraverso molte fasi del prototipo prima di svilupparlo realmente.

Tutti alla riunione di progettazione iniziale avranno una visione leggermente diversa del software. Puoi aiutare ciascuno a visualizzare il prodotto molto facilmente con un prototipo di carta .

Puoi discutere delle differenze, mostrarle ai tuoi capi, ai tuoi clienti, a qualcuno che hai appena trascinato fuori strada e avere una buona idea di cosa funziona e cosa no, finché non arrivi a una singola visione .

Quindi puoi creare un prototipo fisico, in HTML o qualsiasi altro linguaggio di progettazione front-end che stai utilizzando. Non dovrebbe fare nulla. Dovrebbe essere solo un front-end, su cui le persone possono fare clic e digitare e spostarsi tra le loro tre schermate. Qualunque cosa. Lascia che le persone giochino, guardandole e imparino cosa funziona e cosa no, dove sono presenti le incongruenze nella progettazione, in cui le persone sentono la necessità di fare clic, ecc.

Allora e solo allora saprai veramente a cosa dovrebbe assomigliare l'interfaccia più semplice possibile per il tuo hardware. E poi puoi scrivere il tuo adattatore, lasciando solo le complicazioni dell'interfaccia reale, quando arriva, al codice.

Scrum è un'ottima scelta in un progetto con un livello tale di incertezze .

Devi lavorare con attività commerciali e amp; hardware team da vicino e iterate fino a raggiungere l'obiettivo.

Ciò significa che quando arrivano nuove informazioni e precisione, il proprietario del tuo prodotto riordina e inserisce più dettagli nelle sue storie utente.

Supponiamo che tu abbia pianificato la v0.1 ma, mentre il team dell'hardware funziona, vengono definite nuove specifiche. Definisci un nuovo target stimato.

Nuovirequisitieamp;lespecifichearrivanodinuovo.Ilnuovotargetèdefinito.Sigiraversolanuovadirezione,manonènecessarioriscriveretuttocompletamente.

Requisiti e amp; le specifiche possono cambiare molto spesso, ma man mano che avanziamo nel progetto, sia il business che il l'hardware ha una visione più chiara di ciò che devono fare. Anche tu.

Ovviamente,questoprogettocosteràmoltodipiùseavessirequisitipiùchiariall'inizio,matrateeme...èunasituazionepiuttostorara.

Leinformazionidovrebberoproveniredaattivitàcommercialiperchéhannounavisioned'insieme.Leinformazionidelteamhardwaresonofondamentaliperl'implementazionetecnicaeleinterfacce.

Chiaramente,unottimoProductOwnerdiScrumèlachiavediunprogettocosìpocochiaroerischioso.

Leillustrazioniprovengonodaunarticolodavveroeccezionalechiamato Rockets, Cars & Giardini: visualizzazione di waterfall, agile e stage gate .

Sure, you'll probably just say: Write a mock. But this isn't an easy task and a whole mock could turn out to be a whole project by itself.

Dovresti farlo anche tu - sviluppare una sorta di simulatore di software che sostituisce l'hardware reale. Non devi costruirlo in anticipo - in ogni iterazione, sviluppa il tuo simulatore solo nella misura in cui ne hai bisogno per testare le funzioni che hai finora nel tuo frontend. Diamine, non riesco a pensare a un modo efficace di sviluppo iterativo, prototipazione / visualizzazione delle funzioni all'utente se non hai una sorta di "backend" dietro di esso - i tuoi utenti devono vedere / lavorare con il tuo software se vuoi per ottenere un feedback, e se non si dispone anche dell'hardware e del simulatore, come dovrebbero?

Un simulatore sarà anche un utile strumento per testare il frontend anche quando l'hardware è disponibile, perché è possibile fornire funzionalità di test speciali in esso che il proprio hardware reale non fornisce. Non conosco il tuo hardware, ma quando è appena stato costruito ora, ho il sospetto che non sia così economico che ogni membro del tuo team ne ricava un pezzo unico? Quindi un simulatore si ripagherà da solo.

Scrivi prima il software, quindi guida i ragazzi dell'hardware per progettare ciò che hai consegnato. In questo modo Google ha cambiato il mercato degli smartphone di 180 gradi. Consegnarono un sistema operativo e costrinsero i produttori di hardware a progettarlo. Invece del modo in cui lo stavano facendo prima; la creazione di un sacco di hardware che ha causato la scrittura di molti e diversi software incompatibili.

Avrei avviato due diversi progetti: un mockup dell'interfaccia utente e un simulatore hardware.

Le persone orientate all'IU lavoreranno al mockup, lavorando con i clienti per determinare come deve funzionare il prodotto finale (proprio come se stessimo sviluppando per l'hardware già esistente).

Le persone più orientate all'hardware lavoreranno al simulatore. All'inizio sarà relativamente semplice perché apparentemente non si sa molto dell'hardware finale (ancora). Man mano che si impara di più sull'hardware pianificato, è possibile incorporare ciò che si impara. Allo stesso modo, mentre impari di più dalle persone dell'interfaccia utente, puoi incorporare ciò che stanno imparando.

Con il passare del tempo, si "crescono" i due più vicini, vale a dire che i primi prototipi probabilmente non tenteranno nemmeno di adattare l'hardware previsto oltre le idee generali di approssimativamente il fattore di formato previsto, la disposizione prevista per l'input dell'utente, ecc. Man mano che si impara di più sull'hardware reale, si personalizza il mockup per adattarlo a quello che effettivamente fornirà.

Un punto su questo è imparare quanto più è possibile prima viene consegnato il primo prototipo. Un altro è quello di fornire feedback alle persone dell'hardware, quindi se ciò che stanno progettando è completamente incapace di supportare funzionalità cruciali per gli utenti, avranno la possibilità di riprogettare in modo più appropriato. In alcuni casi, la risoluzione di un problema importante può essere piuttosto facile, purché ne siano a conoscenza abbastanza presto. Proprio come con il software, prima sanno di un problema hardware, meno costoso è quello di risolverlo.

Sebbene a nessuno di noi piaccia pensare in quella direzione, significa anche che se l'hardware che si ottiene non è in grado di svolgere il lavoro, potrebbe essere estremamente utile per il tuo futuro avere una traccia cartacea in cui hai detto loro il problema mesi prima del tempo.