In che modo includi i "requisiti globali"?

7

So che è meglio dividere i tuoi "requisiti globali". Che è qualcosa che faccio quando documento in Confluence.

Tuttavia, quando mi occupo di toelettatura con il team di sviluppo, non so davvero come incorporarli al meglio nelle nostre User Story in Jira. L'approccio ovvio dovrebbe essere quello di aggiungerli come criteri di accettazione per ogni story utente. Ma ciò sconfigge lo scopo di renderli globali in primo luogo.

E.g: per un progetto di checkout

Globale: tutti i markup devono utilizzare gli stili forniti nella guida allo stile

Req: Reimposta password - Come cliente che ha dimenticato la sua password, voglio poter reimpostare la mia password, in modo che possa procedere all'acquisto

Ovviamente, quando si collega la funzionalità al design fornito (html / css), gli sviluppatori devono assicurarsi che rimanga pienamente reattivo (dettagli in html / css). Ma preferirei non scriverlo in ogni storia utente. Come faccio a gestire questo?

    
posta WouterB 29.11.2016 - 23:01
fonte

3 risposte

5

A mio avviso i requisiti globali appartengono alla definizione-di-done perché non vuoi per aggiornare tutti gli utenti corrispondenti quando cambia un requisito globale

    
risposta data 30.11.2016 - 09:03
fonte
3

Bene, non indirizzerai gli standard dell'interfaccia utente nella User Story se l'utente è un'altra macchina.

Dovrai decidere se dividere i "requisiti globali" valga il rischio che non vengano applicati a tutte le storie degli utenti. Se vuoi che i requisiti globali siano implementati in ciascuna storia e desideri test che dimostrino che tali requisiti globali sono soddisfatti, allora penso che tu abbia una delle due possibilità:

  1. Includi i requisiti globali che sono rilevanti per ogni story utente nella storia dell'utente stessa, o

  2. incorporare i requisiti globali per riferimento; vale a dire "Questo User story deve essere conforme allo standard UI 47 e deve superare tutti i test di accettazione specificati in tale standard."

risposta data 30.11.2016 - 00:25
fonte
3

Quando parli di requisiti, hai più tipi di requisiti. Le storie degli utenti spesso catturano una combinazione di requisiti funzionali (input, output, comportamenti) e caratteristiche dell'utente (obiettivi, desideri, obiettivi degli utenti del software). Ma ci sono altre cose che è importante prendere in considerazione quando si acquisiscono i requisiti: i vincoli di progettazione e gli attributi di qualità vengono in mente.

La differenza è che elementi come i vincoli di progettazione e gli attributi di qualità sopravvivono durante la progettazione e la manutenzione di un sistema. Con la funzionalità, si implementa la funzionalità una volta e ce l'hai (salvo una regressione). Tuttavia, è necessario fare attenzione a lavorare sempre all'interno dei vincoli di progettazione e assicurarsi che il sistema abbia gli attributi di qualità.

Nel tuo esempio particolare, prenderei in considerazione l'uso di una guida di stile particolare parte dell'usabilità del sistema software, e l'usabilità è un attributo di qualità. Il tuo requisito di aderire a una guida di stile specifica è un buon requisito - è coeso, completo, probabilmente coerente, atomico, corrente, chiaro e così via.

Non esiste un modo giusto per gestirlo.

La prima cosa che devi fare è catturare e controllare la tua guida. Ad esempio, per una guida di stile, assicurati che sia disponibile per la tua squadra. Per i requisiti di prestazioni, inserire una tabella che mette in relazione le funzioni con i tempi. Per la disponibilità, la tolleranza agli errori e il ripristino di emergenza, disporre di un piano e testare il piano forzando il sistema in modalità di disponibilità bassa o di errore per garantire che gli obiettivi vengano raggiunti. Un wiki con protezione delle modifiche e cronologia delle revisioni può essere sufficiente o potrebbe essere necessario un sistema di gestione della configurazione più rigoroso.

Collegare questi altri requisiti al tuo prodotto può essere semplice come sviluppare piani di test (ci sono plugin per la gestione dei test JIRA - Zephyr , TestFLO ) che vengono eseguiti contro i tuoi standard documentati. Non raccomanderei di inserire i vincoli di progettazione e gli attributi di qualità come biglietti JIRA standard, poiché non seguono il ciclo di vita standard di una storia, bug o attività dell'utente. Devono essere in una forma che sia ricercabile, referenziabile e persistente.

L'ultimo passo è l'istruzione: assicurati che il tuo team di sviluppo sia a conoscenza degli standard o di questi requisiti persistenti e di come progettare e testare gli sviluppatori contro di loro.

    
risposta data 30.11.2016 - 03:04
fonte

Leggi altre domande sui tag