Come gestite il lavoro non funzionale con Scrum negli eystem integrati?

Ho due problemi con Scrum nei sistemi integrati. Innanzitutto, ci sono molti compiti da svolgere, soprattutto 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 display per sei sprint.

I primi quattro sprint sono stati:

• Avvio e funzionamento di RTOS
• Creazione di attività scrivendo driver di rete e seriali
• Scrivere routine di interrupt per pulsanti, comunicazione, ecc.
• Scrittura delle classi e dei metodi del database primario
• Scrivere 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. Tuttavia, voglio ancora tracciare e gestire queste attività di sviluppo tramite Scrum.

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.

In secondo luogo, come gestite le versioni e i test? È una vera seccatura per noi perché i tester non hanno i debugger hardware, quindi dobbiamo creare versioni flash del codice e masterizzarle sulle loro schede di sviluppo per testarle. I tester non sono tecnicamente precisi come gli sviluppatori e spesso richiedono molto supporto per far funzionare le cose nelle fasi iniziali (reimpostare la scheda, collegare la comunicazione seriale, ecc.) O persino per capire l'output.

Infine, per quanto riguarda la definizione di done, uno sprint non può essere completo fino a quando tutte le storie non sono complete. Tutte le storie non sono complete fino a quando non sono state verificate dai tester. Non c'è modo di evitare di "svaligiare" il tempo degli sviluppatori da dare ai tester. In altre parole, se le ultime tre storie utente nello sprint impiegheranno cinque giorni per essere testate, dovranno essere codificate e l'unità testata cinque giorni prima della fine dello sprint. Cosa dovrebbe fare lo sviluppatore? Smetti di lavorare?

Sto facendo il faceto, ma è un vero problema cercare di conformarmi alle regole. Ora sto bene piegando le regole, ma il problema che ho è che rovina tutte le mie metriche di burndown se non riesco a contrassegnare le cose fatte fino a quando non vengono testate.

Mi piacerebbe sapere come gli altri hanno gestito queste situazioni.

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

Nel modo in cui la maggior parte delle persone definisce agile, tutto il lavoro è negoziabile in base al cambiamento delle priorità, riordinabile o sostituibile.

Il modo in cui la maggior parte delle persone definisce cascata è che il lavoro è organizzato in sequenza in anticipo da un significativo sforzo di architettura all'inizio.

I compiti che elenchi sopra mi sembrano molto a cascata. Devono essere in un certo ordine e non sono negoziabili.

Non sto dicendo che devi rispettare la visione di chiunque di qualsiasi processo, ma almeno per questi compiti mi sembra di essere in un progetto non agile per me. Cercare di rovinarlo in un processo agile sarà, nel migliore dei casi, una scelta sciatta.

Se il resto del progetto è adatto all'agile, non mi preoccuperei troppo della configurazione iniziale che non va bene, ma il fatto che tu menzioni RTOS e schede di sviluppo mi fa sospettare che tutto sarebbe meglio in qualcosa di più come cascata (una lunga sequenza di dipendenze immobili).

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 farsi prendere dalla preoccupazione di non avere davvero la funzionalità di fronte agli utenti, quindi è difficile scrivere "user story" con avere utenti. Solo che le storie degli utenti non fanno davvero parte di Scrum - sono spesso utilizzate con Scrum - ma proprio come uno strumento.

Ciò che fa parte di Scrum è l'idea di fornire funzionalità complete che sono completamente testate e potenzialmente implementabili in un ambiente live ogni Sprint. Quando inizi da zero il primo giorno di qualsiasi tipo di progetto, il valore effettivo di qualsiasi tipo di funzionalità che puoi offrire in Sprint 1 è piuttosto piccolo. Questo perché ogni piccola cosa ha bisogno di tonnellate e tonnellate di infrastrutture costruite per farlo funzionare. Ma il punto è che costruisci solo un'infrastruttura sufficiente per far funzionare ogni funzione. E poi lo costruisci quando aggiungi altre funzionalità.

L'idea è che in particolare NON passi mesi e mesi a costruire infrastrutture che non hanno modo di essere rilevate dall'esterno del sistema. Perché? Perché fino a quando non costruisci le cose che effettivamente fanno cose, non sai esattamente cosa deve essere l'infrastruttura. Queste sono cose che impari mentre costruisci le funzionalità effettive del sistema. Se costruisci l'infrastruttura all'inizio, la stai costruendo quando conosci il minimo del sistema.

Se sei pronto a scrivere storie utente, ricorda che gli utenti non devono essere persone. Quindi scrivi cose del tipo: "Come gestore di interrupt CMOS ho bisogno di rilevare lo stato del flag di modulazione dello stack whozzit bingle quando il compressore fluxotronic segnala un sottocarico di bypass passivo". Assolutamente non scrivere storie utente "Come sviluppatore ...".

Si utilizza Scrum in un'area molto specifica e si viola il presunto processo in ogni fase. La tua domanda dovrebbe probabilmente essere: esiste un'altra metodologia agile che si adatterà meglio al mio ambiente? Semplicemente, è molto difficile aiutarti a fare Scrum meglio se il tuo ambiente non lo consente. I problemi che vedo nella tua descrizione:

• Nessun compito dimostrabile che può essere considerato un compito 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 qualcos'altro per essere in grado di fornire valore aziendale, il prodotto può essere suddiviso in due parti / versioni: creazione di uno strumento e creazione di un valore aziendale. In tal caso, le storie utente "Come sviluppatore ..." saranno completamente valide, poiché viene creato uno strumento per gli sviluppatori.

  Il problema qui è come comunicare questo con il cliente, perché il suo coinvolgimento nella prima versione è zero. Se non esiste alcun valore commerciale per i clienti, 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 tenta di fornire prima le funzionalità aziendali più importanti, ma sono necessari due mesi per fornire le prime. Scrum e l'intera agilità abbracciano il cambiamento: cosa succederà se, dopo aver fornito le prime funzionalità, il cliente richiede qualche cambiamento che risale a tutti i tuoi sprint iniziali?

• Testing. Un altro fallimento perché un team di Scrum è considerato come un gruppo di membri interfunzionali. Significa che tutti fanno sviluppo e test e per questo motivo non ci sono situazioni descritte nel tuo punto finale (o almeno non lungo cinque giorni). Ciò non significa che non ci possa essere un QA separato per eseguire test più complessi e sofisticati, ma il team deve fornire una funzionalità già testata / verificata. Nel tuo caso sembra davvero che Scrum non sia ciò di cui hai bisogno. Sono necessari sviluppo e test gestiti separatamente e funzioni di passaggio tra di loro.