Requisiti agili di raccolta nel progetto incorporato [duplicato]

Scrum non si occupa dei requisiti di congelamento o meno. Scrum funziona ugualmente bene se inizi con 100 storie nel tuo arretrato che non cambiano mai, o 5 storie con più aggiunte / modificate tutto il tempo. Scrum dovrebbe essere un processo iterativo e richiede una mentalità completamente diversa rispetto ai modelli a cascata più tradizionali.

Tecnicamente con Scrum potresti avere diversi sprint in cui tutte le storie degli utenti raccolgono i requisiti di foo, raccolgono i requisiti per la barra, ecc. Consiglio vivamente di non farlo, perché sprecherebbe un sacco di sforzi cercando di raccogliere ogni requisito quando sai il minimo su cosa stai costruendo.

Ciò che raccomando è lavorare per assegnare la priorità a tutte le funzionalità di alto livello di cui hai bisogno, quindi iniziare con la massima priorità e raccogliere i requisiti solo per quella singola funzione e quindi iniziare a implementarli e passare alla funzione successiva quando ritieni di aver completato la funzione corrente. Il motivo per cui questo è un approccio superiore è perché nel peggiore dei casi è lo stesso dell'altro approccio, ma nella maggior parte dei casi risparmierà lo sforzo complessivo. Se alcune ipotesi / requisiti iniziali che hai apportato alla modifica della priorità più alta cambiano durante lo sviluppo utilizzando questo metodo, non vi è alcuna reazione a catena di altri requisiti interessati perché non li hai ancora creati, ma quando arrivi a funzioni correlate hai molte cose che conosci perché parti del sistema esistono già.

Non ho esperienza diretta personale nei sistemi embedded - ma capisco cascata e agilità e le differenze tra i due, come sono sicuro che anche tu lo faccia. Ho anche discusso di questo problema - di applicare Agile in settori come lo sviluppo di software embedded, la progettazione / sviluppo di semiconduttori, ecc. Con amici che lavorano in quei settori - quindi spero di avere una certa comprensione dei problemi che stai affrontando ..

L'obiettivo fondamentale di Agile è quello di garantire che ciò che alla fine fornisci al cliente / utente aziendale sia tempestivo, funzioni secondo i requisiti e, soprattutto, sia fatto in modo che gestisca efficacemente le modifiche ai requisiti lungo la strada. Queste erano le maggiori sfide dei progetti a cascata - e nonostante un'attenta pianificazione e grandi sforzi iniziali per definire i requisiti perfetti - hanno causato la consegna di software che non ha incontrato requisiti aziendali.

Considerato ciò che hai detto sulla necessità di requisiti anticipati e progettazione a causa delle dipendenze hardware, ecc. Direi che per diventare (più) agile, puoi provare a suddividere il tuo ambito di applicazione generale nel modo più "fattibile" moduli (autonomi) (o temi, epopee o MVP, qualunque sia il nome che si sceglie di chiamarli) e definire tutti i requisiti / storie utente in anticipo per ciascun modulo, incluse le dipendenze hardware, ecc.

A seconda della dimensione dei moduli, puoi comunque creare ogni modulo in più sprint, prendendo prima per primo le storie degli utenti con la priorità più alta o seguendo l'ordine delle "dipendenze funzionali" tra le storie degli utenti. In questo modo, ti assicuri che alla fine di ogni sprint, stai distribuendo funzionalità di lavoro su un server / dispositivo di staging che ti consenta di dimostrarlo al proprietario del tuo prodotto / utenti business / clienti - raccogliere feedback, in particolare eventuali modifiche ai requisiti - o nuovi requisiti - e incorporarli in futuri sprint / moduli.

Quindi, invece di considerare questo come un problema di "raccolta agile dei requisiti", forse è sufficiente concentrarsi sullo "sviluppo del prodotto agile" generale che aiuta il / i team / i a erogare anticipatamente, consegnare spesso e infine fornire correttamente?

Solo i miei 2 centesimi. Spero che ti aiuti.

Il team del software ha qualche influenza sulle specifiche hardware? O è puramente il contrario (il team hardware impone un'interfaccia software di basso livello)?

In quest'ultimo caso, una persona HAL (hardware astrazione layer) deve sedere con il team hardware per scrivere l'interfaccia software di basso livello; Il team della GUI può lavorare al proprio ritmo, possibilmente utilizzando Scrum o qualsiasi altra metodologia Agile.

Se l'hardware e il software si evolvono, sarà un progetto di prototipazione rapida. L'attenzione è rivolta a massimizzare i tassi di apprendimento (opere di fortuna e opere vinte), mantenendo i costi sotto controllo (spendendola saggiamente, sapendo molto bene che la prototipazione significa molto lavoro buttar via e sarà accelerata, il che renderà molto più costoso dei progetti tipici).

Ci sono molti Q & A sulla prototipazione rapida, su questo sito e altrove.

Se si tratta di prototipazione rapida, probabilmente non sarà scrum. Potrebbe essere ancora Agile nello spirito, ma potrebbe essere diverso da qualsiasi framework Agile mainstream - perché i framework tradizionali di Agile si rivolgono principalmente allo sviluppo puramente software, orientato al mercato.

Devi certamente "Rispondere al cambiamento dopo aver seguito un piano" ; ti sta costringendo perché l'hardware e il software co-evolvono i progetti sono pieni di "opere vinte".

Scrum ha i cosiddetti "picchi", ma se un progetto è pieno di picchi, in genere non lo chiami mischia. Anziché gli sprint temporali fissi, avrai delle pietre miliari, in cui ogni pietra miliare ha alcuni risultati finali, e il traguardo termina solo se questi elementi vengono consegnati o se in altro modo alcuni degli oggetti vengono annullati amichevolmente dagli stakeholder.

Il software di gestione Scrum potrebbe ancora funzionare, le riunioni stand-up funzioneranno sempre, ecc.

Mentre la domanda, come posta, ha un ampio campo d'azione, i problemi principali sembrano essere:

...Scrum assumes that there is no 'requirements freeze'...

...embedded system due to tight coupling with hardware need upfront specification...

Scrum punta a produrre incrementi di alta qualità di una soluzione consegnabile. Ad esempio, non ha lo scopo di minimizzare la rilavorazione o minimizzare i tempi di produzione di un prodotto finale. È necessario considerare se questa priorità è appropriata per il proprio ambiente.