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

Mi sono sempre chiesto come applicare i metodi agili in realtà sono in software di sistema embedded di grandi dimensioni complessi (oltre 100 ingegneri). Lo sviluppo del firmware ha alcune caratteristiche uniche che rendono difficile fare agile (ad es. L'hardware non è disponibile fino a tardi nel ciclo di sviluppo; una volta rilasciato il prodotto, non è possibile aggiornare facilmente il firmware; ecc ...)

La norma in questo tipo di sviluppo è una fitta documentazione e estenuanti revisioni tra pari. Non è possibile ottenere una semplice correzione del codice come rinominare una variabile senza 2-3 firme. (Ho esagerato un po ', ma questo è tipico. Inoltre, molte persone prendono scorciatoie e i Project Manager le approvano persino soprattutto a fronte delle scadenze del mercato.)

Vorrei ricevere consigli o linee guida su come adottare una metodologia agile per i progetti di sviluppo del firmware.

Penso che due tecniche siano fondamentali:

• Sviluppa un simulatore o un ambiente di test completo per l'hardware, in modo da poter sviluppare il software come se avessi un hardware reale. Non lesinare o prendere scorciatoie qui: lo sviluppo di un buon simulatore si pagherà.

• Scrivi molti test unitari contro il simulatore.

Una volta che hai fatto queste cose e le persone sono fiduciose 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, refactoring implacabile, ecc.) .

L'impatto di Agile su un processo di sviluppo che coinvolge più fornitori può essere paragonato a ciò che accade quando un'azienda diventa JIT.

Per consegnare JIT, ciascuno 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" (alias Tracer Bullets di 15 anni fa), ciò implicherebbe che il "core" verrà rilasciato molto presto al pilota e che il driver di base sarà disponibile per l'integratore e che la GUI essere sviluppato, con un solo pulsante e una casella di modifica, allo stesso tempo.

La parte difficile è convincere i progettisti hardware, provenienti da una solida disciplina ingegneristica all'avanguardia, a unirsi alla nostra società più tinker.

La seconda parte più difficile è trovare un modo per consentire lo sviluppo incrementale in un mondo in cui è necessario ordinare una stampa hardware con 3 settimane di anticipo. Sto pensando agli emulatori, l'FPGA è qui. Non sono un ragazzo hardware però.

Se sei disposto a rinunciare allo sviluppo hardware incrementale, puoi, proprio come ai confini di una catena JIT, prevedere un meccanismo di buffering che consenta ai team Agile di avanzare.

Non siamo ciechi: anche Agile deve fare i conti con processi pesanti! Non chiedere al team Agile di "refattare" la base di codice Java su Python nel prossimo sprint. È solo perché alcune parti sono veramente stabili che possiamo ballare le nostre mosse Agile sopra di esse.

Manifesto Agile: http://agilemanifesto.org/

"Individui e interazioni su processi e strumenti"

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

"Software funzionante su documentazione completa"

• Prototipo e costruzione di picchi di tecnologia precoci e spesso.

• Risolvi il vero problema dell'utente invece di continuare a creare una stretta aderenza a una specifica. Questo significa soluzioni evolutive . L'idea che dobbiamo costruirla nel modo giusto perché non riusciamo mai a costruirla di nuovo è sbagliata. Pianifica l'iterazione. Renderlo parte della strategia di marketing e roll-out.

"Collaborazione del cliente sulla negoziazione del contratto"

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

• Bloccare tutti i requisiti e imporre il controllo delle modifiche è un altro modo di dire "no".

• Se hai già in programma più di una versione, puoi più facilmente rinviare 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à.

"Rispondere al cambiamento seguendo un piano"

• Mentre l'integrazione complessa richiede un piano complesso, il "programma" generale (o sequenza di progetti) non può essere concretizzato troppo presto.

Una metodologia totalmente agile (cioè scrum) potrebbe non avere senso per un sistema incorporato.

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

Il mio problema con la mischia nei sistemi embedded è che ci sono molti compiti da svolgere, soprattutto nelle prime fasi, 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: Avvio e funzionamento di RTOS Creazione di attività Scrittura di driver di rete e seriali Scrittura di routine di interrupt per pulsanti, comunicazioni, ecc. Scrittura delle classi e dei metodi del database primario Scrittura di un menu di debug seriale

La maggior parte di questi compiti non è adatta per le storie degli utenti. In effetti, l'unica interfaccia nell'intero sistema era il menu di debug seriale, costruito nello sprint 3, quindi non c'era nulla da dimostrare alla fine degli sprint. Anche il menu seriale era destinato all'uso interno e non all'utente finale.

Naturalmente, ogni classe che scriviamo ha unit test unit e usiamo un framework di unit test per automatizzare l'esecuzione di tutti i test.

Abbiamo finito per scrivere frasi "user story" come "Come sviluppatore ...", di cui non sono contento ma nell'uso di Target Process (www.targetprocess.com), non esiste un concetto di articolo arretrato che è un compito o un lavoretto.

Mi piacerebbe sapere come gli altri hanno gestito queste situazioni.