Come gestisci il lavoro non funzionale con Scrum nei sistemi integrati?

Stai utilizzando una metodologia su un prodotto che non è compatibile con IMHO.

Nel modo in cui la maggior parte delle persone definisce agile, tutto il lavoro è negoziabile in base alle mutevoli priorità, ri-ordinabile o sostituibile.

Nel modo in cui la maggior parte delle persone definisce cascata è che il lavoro è presentato in sequenza in anticipo rispetto a uno sforzo significativo di architettura all'inizio.

L'attività che elencherai qui sopra mi sembra molto interessante, devono essere in un certo ordine e non sono negoziabili.

Non sto dicendo che devi rispettare la visione di qualcuno di qualsiasi processo, ma almeno per questi compiti ti sembra di essere in un progetto non agile per me. Cercare di infilarlo in un processo agile sarà al meglio un aspetto sciatto.

Se il resto del progetto si adatta bene ad agile non mi preoccuperei troppo del fatto che l'installazione iniziale fosse un brutto adattamento, ma il fatto che tu menzioni le schede RTOS e dev mi fanno sospettare che tutto sarebbe meglio in qualcosa di più simile a cascata (una lunga sequenza di dipendenze inamovibili).

OK, quindi non so nulla sulla costruzione di sistemi embedded, ma da quello che posso vedere non c'è nulla che possa rendere Scrum inappropriato per tale sviluppo. È facile lasciarsi prendere dalla preoccupazione di non avere realmente le funzionalità di fronte all'utente, quindi è difficile scrivere "storie degli utenti" con gli utenti. Tranne che le User story non fanno veramente parte di Scrum - sono spesso usate con Scrum - ma in realtà solo come uno strumento.

Ciò che fa parte di Scrum è l'idea di fornire funzionalità complete completamente testate e potenzialmente implementabili in un ambiente live ogni Sprint. Quando si inizia da zero il primo giorno di qualsiasi tipo di progetto, il valore effettivo di qualsiasi tipo di funzionalità che è possibile fornire in Sprint 1 è piuttosto ridotto. Questo perché ogni piccola cosa ha bisogno di tonnellate e tonnellate di infrastrutture per farla funzionare. Ma il punto è che si costruisce solo un'infrastruttura sufficiente per far funzionare ciascuna funzionalità. E poi lo costruisci mentre aggiungi altre funzionalità.

L'idea è che in particolare NON passi mesi e mesi a costruire un'infrastruttura che non ha modo di essere rilevata al di fuori del sistema. Perché? Perché fino a quando non costruisci le cose che effettivamente fanno roba, non sai esattamente quale deve essere l'infrastruttura. È roba che impari mentre costruisci le effettive funzionalità del sistema. Se si crea l'infrastruttura all'inizio, la si costruisce quando si conosce il minimo del sistema.

Se sei morto per scrivere storie di utenti, ricorda che gli utenti non devono essere persone. Quindi scrivete cose del tipo "Come gestore di interrupt CMOS ho bisogno di rilevare lo stato del flag di modulazione whozzit stack bingle quando il compressore fluxotronic segnala una sottocarica passiva di bypass". Assolutamente non scrivere storie di utenti "Come sviluppatore ...".

Usi Scrum in un'area molto specifica e violerai il presunto processo ad ogni passaggio. La tua domanda dovrebbe probabilmente essere: esiste un'altra metodologia agile che si adatta meglio al mio ambiente? Semplicemente è molto difficile aiutarti a fare meglio Scrum se il tuo ambiente non lo consente. I problemi che vedo nella tua descrizione:

• Nessuna attività dimostrabile che può essere considerata come attività di infrastruttura. Se hai bisogno di più sprint per fare qualcosa che non è considerato come valore aziendale, le tue storie utente sono probabilmente mal definite. Se è necessario creare uno strumento o qualsiasi altra cosa per essere in grado di fornire valore di business, il prodotto può essere diviso in due parti / versioni: la costruzione di uno strumento e la creazione di un valore aziendale. In tal caso, le tue storie utente "Come sviluppatore ..." saranno completamente valide perché lo strumento è stato creato per gli sviluppatori. Il problema qui è come comunicare questo con il cliente perché il suo coinvolgimento nella prima versione è zero. Se i clienti non hanno alcun valore commerciale come possono partecipare? In che modo il proprietario del prodotto può definire la priorità aziendale? Penso che il problema principale qui sia che questo non è qualcosa che si adatta a Scrum. Scrum cerca di fornire le funzionalità di business più importanti, ma per la prima occorrono due mesi. Scrum e tutta l'agilità abbracciano il cambiamento: cosa accadrà se dopo aver consegnato le prime funzionalità il cliente richiede qualche cambiamento che risale a tutti gli sprint iniziali?
• Testing. Un altro errore perché il team di Scrum è considerato come un gruppo di membri interfunzionali. Significa che tutti fanno sviluppo e test e per questo non ci sono situazioni descritte nel tuo punto finale (o almeno non lungo 5 giorni). Ciò non significa che non ci possa essere un QA separato per fare alcuni test più complessi e sofisticati, ma il team deve fornire funzionalità già testate / verificate. Nel tuo caso sembra davvero che Scrum non sia ciò di cui hai bisogno. È necessario gestire separatamente lo sviluppo, testare e passare le funzionalità tra di loro.