Come posso gestire le specifiche in Scrum?

Question

In riferimento a this buddy question, voglio sapere come si possono gestire le specifiche nel processo Scrum? Sto affrontando questo problema mentre assegnavo compiti alla mia squadra per lo sprint. Inutile dire che sono nuovo di Agile/Scrum.

Attualmente, stiamo usando il nostro foglio di specifiche per mappare StoryId in SpecId e viceversa. Sto ottenendo l'abbattimento del fatto che Scrum abbia più a che fare con la gestione dei progetti [fare le cose in tempo] e che sia necessario un processo separato per gestire specifiche e requisiti.

Come gestiamo le specifiche in un processo Scrum?

Answer 1

La risposta breve è, non è così.

L'importante domanda da porsi quando si scrivono queste specifiche è perché li facciamo? Qual è il valore nelle specifiche?

Il valore nelle specifiche di solito arriva comunicando le idee dell'azienda con il team di sviluppo. Scrum è progettato per portare il business (sotto forma di Product Owner) al team di sviluppo. Interagendo frequentemente con il team (ricorda, individui e interazioni su processi e strumenti) e vedendo frequentemente il software di lavoro, l'azienda può lavorare di pari passo con gli sviluppatori per produrre software che risolva problemi aziendali meglio che cercando di specificare l'intero cosa prima di provarlo.

Ecco come i progetti Agile fanno un lavoro migliore per consegnare il prodotto che l'azienda desidera al posto del prodotto richiesto.

Detto questo, ci sono alcuni criteri di base che devono essere soddisfatti. Possiamo testare per questo, e come con qualsiasi buon test, possiamo automatizzarlo.

Dai un'occhiata a BDD e Cucumber. Oltre alla User story, è utile disporre di un set di base di condizioni di soddisfazione, preferibilmente nel formato "Give/When/Then". Queste condizioni sono il minimo insieme di criteri per la storia da accettare come completa.

Ad esempio, "Dato che ho effettuato l'accesso, quando esco, torno alla home page".

Se hai intenzione di avere criteri di accettazione, vorrai automatizzarlo. La parte peggiore della maggior parte delle specifiche è che spesso si esauriscono e raccolgono polvere quando il progetto è completo.

Inoltre, non si dovrebbero assegnare compiti alla squadra. I team Scrum si auto-organizzano e chiunque dovrebbe essere in grado di afferrare qualsiasi compito sentano di poter lavorare rispettando la priorità delle storie. Swarming è una parte importante dei vantaggi prestazionali di Scrum.

Si consiglia di prendere in considerazione l'introduzione di un coach esterno per assistere nella transizione.

Answer 2

Come ho capito SCRUM, non si occupa della gestione delle specifiche. Devi rompere/mappare le tue specifiche o le modifiche delle specifiche a storie e attività separatamente. Ma puoi avere un compito per questo :).

Answer 3

Penso che il modo più semplice sia rendere le specifiche una parte delle storie utente all'interno delle attività stesse. Elenca chiaramente i criteri di accettazione in ognuno di essi (o se il software di monitoraggio dei problemi ti consente, crearli come tipi di elementi di lavoro di prima classe). Lascia che il problema in qualunque cosa tu usi per il tracciamento dell'oggetto di lavoro diventi il ​​documento vivente.

ci sono svantaggi, come trovare le questioni relative specifiche come cambiano nel tempo, ma questo di solito può essere gestito nel tooling elemento di lavoro di monitoraggio, supponendo che i vostri problemi possono riguardare l'un l'altro.

Il modo in cui lo facciamo è che noi (in realtà un BA, non gli sviluppatori) crea un deck di approvazione per il proprietario del prodotto da esaminare e noi creiamo in modo collaborativo le attività al di fuori di esso. Se non siamo in grado di creare un'attività o ci sono domande aperte, torneremo al proprietario del prodotto con tali domande e aggiorneremo il mazzo. Tutti i nostri mazzi sono organizzati (in SharePoint) in modo che possiamo trovarli facilmente in futuro.

Answer 4

C'è una tensione reale tra Scrum e altre metodologie di sviluppo e scrittura spec. Penso che ci siano due grandi punti di tensione:

1. Perché agile dice tutto dovrebbe essere su una scheda, che significa che avere roba pianificato abbastanza per in forma su una scheda. (Per esempio avete bisogno di sapere come è tutto andare a lavorare.)

2. Alcune cose non hanno senso in di isolamento (che cosa è l'uso di una pagina di file di caricati senza una pagina di gestire file caricati, per esempio.)

non è necessario per progettare l'intera applicazione tutto in una volta, ma è necessario avere una visione d'insieme app. Quindi, soprattutto se si dispone di una separazione di progettisti e programmatori, si esegue la progettazione funzionale per un blocco di dimensioni sprint alla volta. Questi progetti devono quindi essere suddivisi in blocchi di dimensioni di una storia.

Questo è un sacco di design funzionale iniziale, e penso che sia trascurato in molti dei discorsi sulle metodologie agili. Forse alcuni negozi hanno gli sviluppatori di fare di più del design. Inoltre, penso che sia molto più facile usare scrum/agile per apportare modifiche/correzioni di bug alle app esistenti piuttosto che crearne di nuove.

La cosa che ho trovato più utile è combattere la dimensione della storia. Molte organizzazioni sono impazzite, dicendo che le storie devono durare solo poche ore.Il libro originale di Scrum dice 16 ore, penso, che è spesso abbastanza grande da contenere un intero schermo di un'app web. Quindi "implementare la gestione del mio account" potrebbe essere una storia (al contrario dell'approccio di centinaia di minuscole storie di "implement username", "implement password" ecc.) Quindi fare riferimento al documento di progettazione per "Gestisci il mio account" e fare sicuro di avere screenshot/prototype/mockup perfetti per le parole in modo che lo sviluppatore possa guardarli e copiare/incollare il testo direttamente nel codice che stanno scrivendo, e sanno con certezza quali campi devono essere presenti (o quali link, o quali immagini, o qualsiasi altra cosa).

Answer 5

Per me le specifiche sono nelle storie degli utenti. Definiamo le specifiche e i compiti durante il primo incontro di mischia insieme al proprietario del prodotto. Le specifiche e i compiti sono solo per il tempo di vita dell'iter di mischia, poiché tutto potrebbe cambiare nella successiva iterazione (nel peggiore dei casi, ma ci saranno cambiamenti in modo definitivo).

Di solito teniamo traccia delle specifiche e del compito su un foglio di calcolo, in modo che tutti sappiano su cosa stanno lavorando. Ho anche provato alcuni software per farlo e uno dei più interessanti che ho incontrato è da [VersionOne] [1] e anche da [Rally] [2].

Ma trovo ancora che l'utilizzo di un semplice foglio di calcolo è la soluzione più rapida e semplice.