Quale modello di sviluppo software ha funzionato meglio per i team di software con una strong dipendenza dai team hardware?

Dipende davvero da come il tuo team hardware fornirà utili artefatti che il tuo team di software può utilizzare per sviluppare, e come i team sono impostati per comunicare tra loro.

In genere, troverete che il team dell'hardware realizzerà un prodotto, lo porterà a una fase di prototipo per il test e solo allora il team del software otterrà qualsiasi tipo di documentazione sui requisiti dal team dell'hardware. Inutile dire che questo non è sempre il modo migliore per andare, in quanto il software di solito si sviluppa molto tardi nel processo e generalmente non ci si può fare altro che lavorare con una metodologia basata su cascata. Sul lato positivo dal punto di vista del team hardware, se improvvisamente hanno bisogno di cambiare qualcosa, il team del software non avrà bisogno di modificare il loro software. Il problema qui, naturalmente, è che il tuo tipo di hardware medio ha bisogno di sviluppare prodotti in questo modo e si aspetta che tutto ciò che gli darà un beneficio aiutino il team del software.

In alternativa, se il tuo team hardware sta costruendo un prodotto e aggiornando i requisiti del software mentre vanno, e ancora meglio, se coinvolgono presto il team del software mentre ogni caratteristica hardware viene pianificata e simulata, allora hai il opportunità per il team del software di lavorare in modo molto più agile. Naturalmente con questo intendo che il team hardware è il cliente e fornisce al team del software un elenco di problemi che devono essere risolti nel software. Il team del software può discutere con i propri clienti le priorità relative di ciascun requisito e, non appena il prototipo hardware è pronto, il software sarà probabilmente disponibile in un modulo di rilascio anticipato e può essere utilizzato per aiutare a testare l'hardware. Se i requisiti cambiano, il team del software si spera che abbia l'agilità di cambiare il software mentre va, e può fornire un feedback tempestivo al team dell'hardware prima che la progettazione dell'hardware si impegni a prototipare. Il team del software ha anche accesso diretto al cliente molto presto nel progetto, il che significa che possono avere un'idea migliore di ciò di cui hanno bisogno per prendere in giro - e come farlo - mentre aspettano che l'hardware venga testato.

Realisticamente, non troverai una metodologia ideale che vada bene sullo scaffale, e posso garantire che avrai un sacco di ritocchi da fare indipendentemente dalla metodologia che sceglierai di adottare o sviluppare. Il vero problema è che vuoi provare a rendere la sincronizzazione tra i team facile da gestire, e significa che devi trovare un modo per aumentare la quantità di contatti e input tra le due squadre il prima possibile nel processo, anche se sembra "dispendioso" o "contro-intuitivo" farlo. Questo è un grosso problema nella società con cui sto attualmente lavorando. Il nostro "genitore" europeo sta lottando con questo problema esatto, mentre il team qui a Oz sembra essere in grado di far funzionare le cose in modo un po 'più fluido, ed è davvero tutto dovuto dare il coinvolgimento del team di software all'inizio delle fasi di progettazione e simulazione dello sviluppo hardware.

Probabilmente sono prevenuto, avendo lavorato più sul lato hardware di grandi team di sviluppo di prodotti hardware-software. L'hardware può essere molto costoso da revisionare se è progettato o progettato in modo errato. Spesso un errore nella progettazione dell'hardware è così costoso che significa annullare l'intero progetto. Riparare un errore nella maschera del chip può costare più dello stipendio annuale di dozzine di ingegneri. Quindi vedo che lo scopo principale del team del software per il primo 50% + del ciclo di sviluppo è assicurarsi che il team dell'hardware non abbia esito negativo. Ciò può significare dimenticare il codice dell'applicazione finale e il suo design in un primo momento, e solo lavorare su architetture hardware e simulazioni delle prestazioni, strumenti per aiutare il team hardware a completare e verificare il loro design e codice per testare ed esercitare tutti i vari componenti necessari del primi prototipi hardware parzialmente funzionanti.

Aspettatevi di essere agili, non solo sulle specifiche del cliente, ma anche su vari strani bug / bug nella piattaforma hardware, in cui una soluzione software potrebbe avere un impatto molto meno sulla pianificazione rispetto a una rotazione hardware.

Uno degli inquilini principali di Agile è "fallire presto". Con l'hardware, questo non potrebbe essere più vero. L'hardware di produzione di massa è estremamente costoso. Inoltre, l'hardware fisico non può semplicemente essere "patchato" come un software. Esacerbando questi problemi, i team hardware tendono ad essere meno orientati ai clienti, quindi i team del software in pratica, e tendono ad essere utilizzati per il modello di sviluppo "big bang".

Per questi motivi, non prendere i problemi hardware il più presto possibile è in genere un ordine di grandezza più costoso, quindi non riuscire a individuare i problemi del software in anticipo. I clienti si aspettano di richiedere aggiornamenti software, potrebbero smettere di lavorare con te interamente se devono gestire un richiamo hardware.

In breve, non si aspetta e si prepara per i problemi hardware in anticipo è la sfida più grande di un modello di sviluppo quando si sviluppano software e hardware in parallelo.

Devi assolutamente prevenire il fallimento. Prendi un prototipo presto. Utilizzare il prototipo per sviluppare contro. Aspettarsi che sia un fallimento. Impara dall'errore. Risciacquare. Ripetere. Assicurati che sia previsto da tutti che i prototipi dell'hardware debbano essere rivisti / criticati / riprogettati sulla base del feedback delle parti interessate.