agile / scrum e specifiche funzionali

Question

agile / scrum e specifiche funzionali

#1 da (9 voti)
#2 da (5 voti)
#3 da (3 voti)

7

Lavoro in un piccolo team di quattro sviluppatori, un esperto di dominio e un manager. Stiamo cercando di passare all'utilizzo di scrum per provare e formalizzare i nostri processi.

Da quanto ho capito di agile, sembra essere vicino (ish) a quello che stiamo facendo comunque. Abbiamo un breve documento con le caratteristiche generali del nostro prodotto. Quando arriviamo a codificare ogni funzione, ci sediamo e la buttiamo fuori verbalmente, facendo affidamento sul nostro esperto di dominio per ciò che il cliente vorrà. Quindi lo codifichiamo e viene testato in modo vago dagli altri sviluppatori / esperti di dominio. I miglioramenti vengono suggeriti e implementati.

Al nostro ultimo audit ISO 9001 siamo stati (meritatamente) rimproverati per mancanza di tracciabilità. L'auditor voleva un modo per vedere i registri di ciò che il prodotto avrebbe fatto, e poi testare per dimostrare che lo ha fatto.

Stiamo cercando di offrirci un processo per questo, insieme ad altri vantaggi, ma la mia lettura fino ad ora non ha risposto alla mia domanda su dove sono registrati / testati i requisiti funzionali dettagliati? La mia comprensione di agile / scrum è lungi dall'essere completa, quindi per favore correggimi se ho delle incomprensioni.

Ad esempio, supponiamo di avere una User story che dice: "Come cliente, devo essere in grado di selezionare uno stato del sistema di A, B o C". Ha un test di accettazione che dice "Dovrei essere in grado di selezionare lo stato A, B o C, e il sistema cambierà in quello stato"

Vieni allo sprint dove questo viene implementato, ci sediamo e decidiamo che costruiremo un widget con i pulsanti radio A, B e C e un pulsante "Applica". Quindi lo codifichiamo.

Quando questo widget viene testato, vengono trovati i seguenti problemi: 1. La selezione di B a volte non deseleziona il pulsante di opzione precedente. 2. A volte l'opzione C non è disponibile sul sistema e quindi dovrebbe essere disattivata. 3. Alla prima apertura, la selezione iniziale non corrisponde allo stato attuale del sistema.

La mia domanda è come e dove viene registrato? Non ci sono specifiche funzionali dettagliate che dicano "Ci sarà un widget con tre pulsanti radio. Quando viene creato il widget, la selezione radio corrente deve corrispondere allo stato del sistema" blah blah. Data la mancanza di questo documento, come dovremmo dimostrare che il sistema fa o non fa ciò che deve fare un auditor?

testing agile specifications scrum audit

posta GazTheDestroyer 24.01.2013 - 10:13

fonte

3 risposte

Leggi altre domande sui tag testing agile specifications scrum audit

Quanto è pertinente UTF-7 quando si tratta di analizzare le e-mail? Come dovrei implementare la revisione del codice in questa situazione?

score 9 · Answer 1

Given the lack of this document how are we supposed to prove that the system does or does not do what it's supposed to to an auditor?

Perché è un dato? Non esiste una regola di scrum che l'unica cosa creata sia il software. Fai in modo che i tuoi criteri di accettazione includano "fatto quando abbiamo una specifica funzionale conforme allo standard ISO 9001". Oppure, rendi tutto ciò una storia a parte: "come sviluppatore di un team ISO 9001, ho bisogno di una specifica funzionale in modo che il nostro software sia conforme". Crea le specifiche e da lì puoi creare le storie necessarie per implementare questa specifica.

Nei commenti a questa domanda, @Pete ha espresso preoccupazione sul fatto che se le specifiche fossero una storia, in che modo il prodotto può essere "potenzialmente spedibile" se tutto ciò che viene consegnato dopo un'iterazione è una specifica?

Guarda in questo modo: il tuo prodotto finale è composto da molti pezzi: A, B, C, D, ecc. Alla fine di ogni iterazione dovresti avere uno di quei pezzi finito e potenzialmente spedibile, giusto? Quando A è fatto dovrebbe essere potenzialmente spedibile. Quando B è fatto dovrebbe essere potenzialmente spedibile, e così via.

Dove dice che A deve essere un prodotto software? A può essere potenzialmente spedibile anche se si tratta semplicemente di una specifica funzionale, o di un caso di test, o di uno schema DB, ecc.

Non guardare le tue specifiche funzionali come se fosse in qualche modo al di fuori del tuo prodotto. Invece, consideralo come parte integrante del prodotto che stai distribuendo, su un piede di parità con software, schemi DB, casi di test, guide utente, ecc.

score 5 · Answer 2

As an example, let's say we have a user story that says: "As a customer, I need to be able to select a system state of A, B or C". It has an acceptance test that says "I should be able to select state A, B, or C, and the system will change to that state"

C'è il tuo problema, secondo me. E Scrum, una tecnica di gestione del progetto, che rientra nei regni di Agile (non confondere i due termini), non ti aiuterà. Ma ci sono altre tecniche Agili che lo faranno. Per questo scenario, sviluppo basato sul comportamento sarà il posto dove cercare.

Per spiegare perché penso che questo sia il tuo problema: la tua prima affermazione non è realmente un requisito utente (Feature, in BDD) e la seconda non è una definizione di comportamento (Scenario, in BDD).

Feature: State A

As a customer
I need to be able to select system state A
So that the fires of Mordor will burn

Feature: State B

As a customer
I need to be able to select system state B
So that the orcs will be at the gates

(presumo che nessuno dei due richieda l'altro, quindi sono caratteristiche separate.)

Notate le clausole "So that ...". Sono una parte importante di una funzionalità. Se hai problemi a scrivere "So that ..." su ogni funzione, allora non hai bisogno di quella funzione o la portata di essa è troppo grande. Sospetto quest'ultimo in questo caso, quindi l'ho suddiviso nei tre stati.

La tua definizione di test è simile, in realtà non specifica nulla. BDD ha una sintassi Given-When-Then che ci aiuta a concentrarci sullo scenario che stiamo testando:

Given that I am on the state selection screen
When I select state B
Then the horn of Mordor should sound
And the orc-cages should be unlocked

Nota che ogni clausola può avere estensioni And, But or O, se necessario - ma, in generale, quando (l'azione dell'utente) dovrebbe essere una singola azione di definizione.

Tornando ai tre bug che hai elencato:

# Selecting B sometimes doesn't uncheck the previous radio button. 

Given that I am on the state-selection screen
When I select option B
Then options A and C should be deselected

Questo è un test perfettamente valido. Completamente inutile se si utilizzano i pulsanti di opzione della libreria standard, ma se si dispone di questo errore, non è chiaro, quindi è necessario tenerne conto.

# Sometimes option C is unavailable on the system, and so should be greyed out.

Given that state C is unavailable
When I load the state-selection screen
Then option C should be greyed out
And option C should be unusable

Given that I am on the state-selection screen
When state C becomes unavailable
Then option C should be greyed out
And option C should be unusable

Due comportamenti che dovrebbero essere definitivamente testati separatamente, supponendo che siano entrambi richiesti.

# When first opened, the initial selection does not match the current system state.

Given that the current system state is C
When I load the state-selection screen
Then option C should be pre-selected

Iniziare a prendere l'idea? Non fraintendetemi, questo è un LAVORO DURO. Ma essere Agile è molto più disciplinato di quanto la gente pensi che sia. Se hai intenzione di ottenere e mantenere un accreditamento ISO 9001, dovrai decidere quali discipline sono per te e attenersi ad esse. Se è troppo impegnativo, probabilmente devi tornare alle specifiche funzionali.

score 3 · Answer 3

Bene, mi chiedo come Agile / Scrum si riferisca a cose come la ISO 9001. ISO 9001 ha in mente la documentazione e i processi, mentre il Agile Manifesto ha funzionato software in mente. Sebbene valuti la documentazione / i documenti, l'attenzione è di solito sufficiente.

Il ragionamento dietro questo è che puoi scrivere tutto e una settimana dopo averlo implementato, il cliente potrebbe cambiare idea. Certo, puoi mantenere i documenti sincronizzati, ma dopo un po 'noterai che stai impiegando molto tempo e impegno nei tuoi documenti.

Qual è il valore aggiunto di tutta questa documentazione? Se il software non funziona come vuole il cliente, dovrebbe dirtelo. Questo può essere inserito in un sistema come VersionOne, TFS, ecc. Per tornare indietro più tardi, ma vorrei sconsigliare di andare troppo lontano in tutta questa documentazione.

L'applicazione così com'è, è ciò che dovrebbe essere importante. Non è quello che dice un certo documento.

Questo perché Agile abbraccia il cambiamento e riconosce il fatto che il software cambia costantemente e non può essere impostato su pietra.

Consiglio vivamente "Scrum e XP dalle trincee" di Henrik Kniberg. Puoi trovarlo su InfoQ dopo aver effettuato l'accesso, ma è anche disponibile qui .

Nel tuo esempio, penserei di dimostrare il widget al tuo cliente dopo uno sprint. Vedrebbe che non fa ciò che vuole e lo segnala. Questo è il momento in cui il cliente può accettare o non accettare il lavoro che hai svolto. Può anche indicare quali sono le prossime priorità. Forse, ha prima altre priorità. Oppure potrebbe dire che devi aggiustarlo.

Nella prossima demo, potrebbe vedere il widget funzionare come previsto e dirlo.

Forse potresti scrivere queste cose in una sorta di note di riunione. Ma alla fine, sarei ancora critico e chiedo quale sia il valore aggiunto di ISO 9001. Hai costruito un software migliore in un modo più veloce ed efficiente grazie a questo? O hai un grande database di documenti e processi, bloccando la tua capacità di essere agile?

Capisco che vorrà comunque la certificazione ISO 9001, quindi ti consiglio di documentare i tuoi processi il meno possibile, perché nello sviluppo Agile dovresti essere disposto a cambiare costantemente i tuoi processi. Constanzialmente cercando il modo migliore per andare avanti. Essere costantemente critico nei confronti di se stessi (questo è il motivo per cui sono le retrospettive).