Scrum - dove fai tutte le cose "altro"?

Question

Con Scrum, c'è il principio delle storie degli utenti e di queste attività di derivazione, ecc., Che scorre intorno a un prodotto finito, il che va bene.

Ma, diciamo che ho 100 funzioni che devono essere implementate, nel mondo reale non posso mettere nessuno sviluppatore su questi fino a quando non sono state fatte molte delle normali cose accessorie - per esempio, facendo un design dell'interfaccia utente (sicuramente hai bisogno di avere un'idea generale di funzionalità per questo?), o di costruire le cose di base che non si manifestano necessariamente come una caratteristica.

Quindi, dove succede?

Answer 1

La mia comprensione è che in mischia si costruisce solo ciò che è necessario per implementare ogni storia utente. Pertanto, si costruiscono le cose sottostanti che non sono funzionalità solo quando è necessario implementare una funzionalità per la storia utente su cui si sta lavorando.

Answer 2

A mio parere, il migliore è quello di includere come "Story" la maggior parte delle cose possibili, in modo che tutti abbiano una buona visibilità di ciò a cui viene applicata l'ora.

Tuttavia, ci saranno sempre attività non pianificate che devono essere eseguite (ad esempio, reinstallare la macchina se è rotta). Per quel compito, un'opzione è di lasciare in ogni iterazione una percentuale del tempo libero, se hai una velocità di 300 punti storia per iterazione, per esempio, solo 250 con storie all'inizio, per lasciare spazio a cose non pianificate, Quindi, nelle seguenti iterazioni è possibile regolare questi valori in base alla cronologia passata.

Answer 3

Fondamentalmente, si verifica all'interno di ciascuna funzione, che è più facile a dirsi che a farsi, ma è forse l'intero punto di sviluppo software agile incrementale.

Ad esempio, invece di creare molte "cose ​​sottostanti che non si manifestano necessariamente come funzionalità", si dovrebbe sospettare che non ne abbia bisogno, e si costruisca solo quanto necessario per la funzionalità in questione.

Answer 4

Le attività non funzionali possono ancora andare sul backlog del prodotto, a mio avviso, mentre stavo usando Scrum lo abbiamo sicuramente fatto. Abbiamo dovuto spiegare al proprietario del prodotto perché dovevano essere considerati importanti, in modo da avere il tempo per farlo. Se il proprietario del prodotto non crede che sia molto importante, non viene eseguito e il proprietario deve convivere con i risultati. Dopo essere stato morso alcune volte respingendo le tue richieste per cose come test di carico e poi cadendo, è probabile che torni :)

D'altra parte, potresti scoprire che ci sono alcuni requisiti non funzionali che inizialmente ritieni importanti, ma può languire senza alcun impatto. A volte, solo a volte, gli istinti degli sviluppatori sono sbagliate :)

Per le attività che sono fattori di gating genuinamente, penso che hai appena avuto modo di essere onesti con il proprietario del prodotto e insistere che si deve fare di loro. Se non riesci ad andare avanti con il proprietario del prodotto nella misura necessaria per continuare con il progetto, ci sono problemi più grandi che non ottenere un design dell'interfaccia utente :)

Answer 5

Vorrei costruire i compiti ausiliari nella prima funzione che lo richiede .

È importante distinguere la differenza tra il backlog del prodotto e il backlog dello sprint. Il backlog del prodotto contiene storie utente che rappresentano "cosa/perché", non "come". Quando una storia viene selezionata per uno sprint, la storia viene quindi suddivisa nelle attività richieste per crearla. Es .: "UI Design" sarebbe un compito per la storia "Seleziona articoli da acquistare".Non c'è nulla di male a livello di pianificazione sprint per le attività di avere dipendenze o; infatti, la maggior parte delle volte ci saranno compiti che rendono la vita più facile per gli altri articoli del backlog di prodotto.

Spero che questo aiuti!