Come adottare una metodologia agile per lo sviluppo di firmware / sistemi embedded-software?

Penso che due tecniche siano fondamentali:

• Sviluppa un simulatore completo o un ambiente di test per l'hardware, in modo che tu possa sviluppare il software come se avessi un vero hardware. Non lesinare o prendere scorciatoie qui: sviluppando un buon simulatore pagherà.

• Scrivi lotti di test unitari contro il simulatore.

Una volta che queste cose stanno andando e le persone sono certe che il simulatore e i test unitari daranno un'idea precisa di come funzioneranno le cose con l'hardware, sarà più facile adottare altre tecniche agili (brevi iterazioni, implacabile refactoring, ecc.).

L'impatto di Agile su un processo di sviluppo che coinvolge più fornitori può essere paragonato a quello che succede quando un'azienda va in JIT.

Per consegnare JIT, ognuno dei fornitori dell'azienda deve consegnare JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

Allo stesso modo, se si desidera sviluppare un prodotto complesso secondo le metodologie Agile, ogni sottogruppo della catena dovrebbe essere in grado di funzionare in questo modo.

In termini di sviluppo "incrementale" (aka Tracer Bullets di 15 anni fa), ciò implicherebbe che il 'core' è stato rilasciato molto presto al pilota, e che il driver di base è disponibile per l'integratore e che la GUI dovrebbe essere sviluppata, beit con un solo pulsante e una casella di modifica, allo stesso tempo.

La parte difficile è convincere i progettisti dell'hardware, provenienti da una solida disciplina ingegneristica all'avanguardia, ad unirsi alla nostra società di riparatori.

La seconda parte più difficile è trovare un modo per consentire lo sviluppo incrementale in un mondo in cui una stampa hardware deve essere ordinata con 3 settimane di anticipo. Sto pensando agli emulatori, qui c'è fpga. Però non sono un ragazzo dell'hardware.

Se si desidera abbandonare lo sviluppo di hardware incrementale, è possibile, proprio come ai bordi di una catena JIT, prevedere un meccanismo di buffer che consenta ai team di Agile di avanzare.

Non essere ciechi: anche Agile deve fare i conti con i processi pesanti! Non chiedere al team Agile di eseguire il "refactoring" del codice Java in Python nel prossimo sprint. È solo perché alcune parti sono davvero molto stabili che possiamo danzare le nostre mosse agili su di esse.

Manifesto agile: link

"Individui e interazioni su processi e strumenti"

• Incontra di più. Spingere la carta di meno.

"Software di lavoro su documentazione completa"

• Prototipo e costruisci picchi di tecnologia precocemente e spesso.

• Risolvi il problema reale dell'utente piuttosto che continuare a costruire un'osservazione pignola su una specifica. Ciò significa soluzioni evolutive . L'idea che dobbiamo costruirla correttamente perché non possiamo mai ricostruirla è sbagliata. Pianifica l'iterazione. Rendila parte della strategia di marketing e di roll-out.

"Collaborazione del cliente per la negoziazione del contratto"

• I processi di controllo delle modifiche iper-complessi sono solo modi per dire "no" al cliente.

• Il blocco dei requisiti tutti in anticipo e l'imposizione del controllo delle modifiche è un altro modo per dire "no".

• Se pianifichi già più di una versione, puoi rinviare più facilmente i requisiti a una versione successiva. Una volta che il cliente ha il dispositivo con il software incorporato, la prossima versione cambierà nelle sue priorità.

"Risposta al passaggio da un piano successivo"

• Mentre l'integrazione complessa richiede un piano complesso, il "programma" (o la sequenza di progetti) nel suo complesso non può essere gettato nel calcestruzzo troppo presto.

Una metodologia totalmente Agile (cioè mischia) potrebbe non avere senso per un sistema integrato.

Il manifesto Agile, tuttavia, fornisce dei modi per consentire il cambiamento possibile senza consentire il semplice caos.

Il mio problema con Scrum nei sistemi embedded è che ci sono molti compiti da fare, specialmente nelle fasi iniziali, che non sono dimostrabili. Abbiamo iniziato con una scheda di sviluppo, nessun sistema operativo, nessun display, nessuna comunicazione seriale, ecc. Non avevamo il nostro display per 6 sprint.

I primi 4 sprint sono stati: Recupero e funzionamento di RTOS Creazione di compiti Scrittura di driver di rete e seriali Scrivere le routine di interrupt per pulsanti, comunicazioni, ecc Scrivere le classi e i metodi del database primario Scrivere un menu di debug seriale

La maggior parte di queste attività non è adatta alle storie degli utenti. In effetti, l'unica interfaccia dell'intero sistema era il menu di debug seriale, realizzato nello sprint 3, quindi non c'era nulla da dimostrare alla fine degli sprint. Anche il menu seriale era pensato per uso interno e non per utente finale.

Naturalmente, ogni classe che scriviamo ha associato i test unitari e usiamo un quadro di test unitario per automatizzare l'esecuzione di tutti i test.

Abbiamo finito per scrivere frasi di "user story" come, "Come sviluppatore ...", di cui non sono soddisfatto ma utilizzando Target Process (www.targetprocess.com), non esiste il concetto di un backlog elemento che è un'attività o lavoretto.

Mi piacerebbe sapere come gli altri hanno gestito queste situazioni.