Come posso convincere il mio team che una specifica dei requisiti non è necessaria se adottiamo le storie degli utenti?

9

Stiamo pianificando di adottare storie utente per catturare "l'intento" degli stakeholder in modo leggero anziché in un SRS pesante (specifiche dei requisiti software). Tuttavia, sembra che sebbene comprendano il valore delle storie, c'è ancora il desiderio di "convertire" le storie in un linguaggio simile a SRS con tutti gli attributi, le priorità, l'input, gli output, la fonte, la destinazione ecc.

Le storie degli utenti 'eliminano' la necessità di un artefatto SRS formale come iniziare, quindi qual è il punto di avere un SRS? Come dovrei convincere il mio team (che sono tutti persone CS molto qualificate tra l'altro - sia per educazione che per pratica) che l'SRS verrebbe "eliminato" se adottassimo user-story per catturare i requisiti funzionali del sistema? (Anche gli NFR ecc. Possono essere catturati, ma non è questo lo scopo della domanda).

Quindi ecco il mio argomento sul "flusso di lavoro": Cattura i requisiti iniziali come user-story e successivamente li elabora in casi d'uso (che devono essere documentati a basso livello, cioè descrivendo le interazioni con i prototipi / prototipi dell'interfaccia utente e sono un post disponibile) distribuzione). Passando così dalle storie degli utenti ai casi d'uso piuttosto che dalle storie degli utenti a SRS ai casi d'uso.

In che modo state attualmente acquisendo le storie degli utenti sul posto di lavoro (se non del tutto) e come suggerite di "presentare un caso" per assenza di SRS in presenza delle storie degli utenti?

— dottorato di Ricerca
fonte

non accadrà in un giorno, prendi un approccio facile

— Yusubov,

Se lavori per un fornitore di servizi software, l'SRS potrebbe non essere necessario per eseguire l'implementazione, ma per fare il "gioco della colpa" quando il cliente desidera ridurre i costi o gli argomenti del fornitore del servizio secondo cui è necessario più denaro o entrambi stanno andando in tribunale.

— k3b,

14

Piccoli passi. Continua a scrivere l'SRS per un po '. Quindi convoca una riunione e discuti se servono ancora a uno scopo. Qualcuno li legge ancora? Il tempo dedicato a loro è giustificato? C'è un altro passaggio intermedio che sarebbe più leggero?

Non lo sai mai, potresti scoprire che ti sbagli. Ricorda il manifesto Agile, troviamo più valore in "Software funzionante su documentazione completa", ma c'è ancora valore in quest'ultimo.

La mia ipotesi però è che scoprirai rapidamente che il desiderio di continuare a scrivere documenti pesanti svanisce quando vedono quanto i casi d'uso e le storie degli utenti sono strettamente correlati.

— pdr
fonte

2

@PhD: hai ragione. È quasi primordiale. Ed è per questo che non vincerai questa battaglia con qualsiasi tipo di logica, solo con prove. Piccoli passi.

— pdr,

2

Ho lavorato per manager che hanno affrontato il cambiamento con piccoli passi , era la loro parola in codice per "fare solo abbastanza per fallire, quindi posso dire che avevo ragione", questo non è un percorso per il successo perché mostra una fondamentale mancanza di comprensione della nuova metodologia e la mancanza di un acquisto completo da parte della direzione, che è cruciale per un cambiamento di successo. Questo suona bene in teoria, ma in pratica è una scusa per non cambiare e rivendicare la vittoria che il nuovo modo non funziona e il vecchio modo funziona. Così l'SRS è stato rafforzato e le storie saranno etichettate come lavoro extra e tornerai dove eri.

2

La mia esperienza non è singolare, è stata durante i miei oltre 22 anni nel settore, la maggior parte dei quali è stata la consulenza. Quindi ho lavorato con molti più manager e decisori rispetto alla maggior parte delle persone nello stesso lasso di tempo. Il mio punto è che questo approccio a piccoli passi è un approccio fallimentare, solo l'impegno dell'alta direzione nei confronti del cambiamento e la filosofia alla base del cambiamento porteranno a una corretta attuazione. Se i suoi colleghi non sono convinti, lasciare che continuino a fare ciò che vogliono non li convincerà, alimenta solo il fatto che abbiamo ancora bisogno del vecchio modo e il nuovo modo è una discussione sulla perdita di tempo.

1

@JarrodRoberson Voglio solo aggiungere che le mie esperienze riflettono più da vicino le tue. Esistono due tipi di persone, e quindi due tipi di manager, conservatori e risk-taker. I conservatori sono naturalmente contrari al cambiamento e al rischio. Quando trovano un modello che funziona, anche male, si attaccano ad esso. Quando il cambiamento è forzato o premuto su di loro, inconsciamente lo sabotano cercando di fare piccoli passi . Questo è il motivo per cui l'unica volta che ho mai visto un vero lavoro di adozione Agile è quando è guidato da persone che assumono rischi.

— maple_shaft

2

@maple_shaft: il trucco è continuare ad andare avanti. Se una modifica incrementale non funziona, non fare necessariamente di nuovo lo stesso passo indietro, considera perché non ha funzionato ... come forse stai trascorrendo troppo tempo ancora a scrivere un documento ormai inutile. Ora ammetto che ci vuole un buon manager per pensare in quel modo, e che la maggior parte tornerà alla sua zona di comfort. Ma, esattamente con la stessa logica, ciò non significa che l'unica altra opzione sia il cambiamento drastico. Un cattivo manager lo rovinerà.

— pdr

6

Le epiche sono segnaposto

In quasi ogni metodologia Agile il concetto di Epica sarebbe tanto quanto dovresti avere per una Specifica dei Requisiti, i segnaposto sono ciò che ti serve a quel livello. A tali voci verrà assegnata una priorità costante, ulteriori dettagli saranno sprecati se il requisito avrà una bassa priorità per lungo tempo o non verrà mai implementato. Documentarlo e gestirne la documentazione sarebbe una completa perdita di tempo. YAGNI si estende alle attività relative ai requisiti e alle attività di codifica.

Gli strumenti sono tuoi amici!

Se si utilizza uno strumento adeguato per raccogliere e gestire le storie degli utenti, è possibile generare da loro le Specifiche dei requisiti. Una specifica dei requisiti è comunque un documento di artefatto temporale , non è un documento vivente, è un'istantanea dei requisiti nel tempo. E non è mai in sincronia con la realtà.

Genera automaticamente artefatti

Le storie utente che possono essere esportate da uno strumento adeguato sono sempre più preziose di qualsiasi documento di artefatto statico in qualsiasi momento. Personalmente preferisco Pivotal Tracker per tenere traccia delle User Story, ho persino scritto una suite di plugin MoinMoin in Python per pubblicare tutte le varie Storie e i loro stati nel Wiki (che conteneva note dettagliate per gli sviluppatori e simili sulle storie), i dati in diretta sono sempre meglio dei dati statici.

Il Wiki è diventato un documento live di tutti i negozi / requisiti e il loro stato di completamento e priorità con dettagli, commenti e altri metadati.

Molto meglio di un enorme documento Word in Sharepoint che viene sempre inviato via e-mail costantemente e mai aggiornato, garantendo che ognuno abbia una versione diversa e non sia sincronizzato con tutti gli altri!

Le storie degli utenti sono più ricche dei casi d'uso

La Use Story è molto più preziosa di un Use Case perché dice PERCHÉ .

Il formato User Story: As a [ROLE] I [ACTIVITY] so that [WHY]è molto più espressivo di Use Cases simili The System [shall/shall not/may/must] perform [action](dove action è un diagramma di flusso).

Con una User Story, hai CHI vuole fare qualcosa, hai COSA vogliono fare (che può puntare a un diagramma / documento più dettagliato per compiti complessi) e hai la parte più importante PERCHÉ vogliono fare questa attività.

Se hai il primo, il secondo è completamente ridondante e, nella migliore delle ipotesi, solo rumore. Una specifica dei requisiti formali tradizionali da una metodologia Waterfall non ha spazio in un ambiente Agile.

Alla fine

Se la tua direzione non è impegnata a cambiare, non avrai successo con una nuova metodologia. Ho lavorato per un'azienda di oltre 100 miliardi di dollari all'anno, non hanno fatto piccoli passi per trasferirsi in Agile / SCRUM, hanno appena detto, l'intera società si sta muovendo verso questo, ecco il nuovo modo di fare le cose, qui è quando inizierà la tua formazione sul nuovo modo, ecco i nuovi strumenti che useremo, ecco la data in cui inizieremo a fare le cose in questo modo. Ha funzionato per loro in meno di un anno. Ho lavorato per implementarlo in aziende più piccole con lo stesso successo.

Impegno

Le implementazioni di piccoli passi , indipendentemente da quale sia il cambiamento, sono una ricetta per il fallimento. È una parola in codice per il management che non concordano silenziosamente e ti stanno impostando in modo passivo e aggressivo per il fallimento. Stanno dicendo che non ci credo abbastanza per impegnarmi, quindi ti lascerò fare quanto basta per fallire / non riuscire , in questo modo possono dire di aver provato e che non ha funzionato e di come funzionavano va bene tutto il tempo. L'impegno parziale alla fine porta al fallimento.

Nel tuo caso, probabilmente in silenzio non credono nelle User Story, e dopo un po 'di entrambe le cose inizieranno a dichiarare che sono le User Story che sono inutili e non l'SRS, e spingeranno per smettere di scrivere le User Story , che ti condurrà semplicemente indietro, non in avanti.

— kmote
fonte

rimarrai piuttosto sorpreso, le storie degli utenti SONO gestite da uno strumento che può (e lo fa) esportarlo come requisiti. Tuttavia, la preoccupazione sembra essere quella di "tradurre" le storie utente nella lingua SRS di "il sistema deve ..." ecc. E NON lasciarle come storie utente.

— Dottorato di ricerca

1

Bene, se il riaggancio è la termanologia "deve / deve / può" probabilmente stai sputando nel vento con quelle persone. Le storie degli utenti raccontano CHI / COSA e, soprattutto, PERCHÉ qualcosa deve essere fatto, molto più utile di quei casi di utilizzo statico, che sono più sbagliati che corretti nella maggior parte dei casi.

2

-1: Non essere affatto in disaccordo con la maggior parte della risposta, tuttavia affermando che e SRS è "Una specifica dei requisiti è comunque un documento di artefatto temporale, non è un documento vivente", è così sbagliato che mostra una preoccupante mancanza di comprensione di ciò che un SRS è, o come viene usato quando fatto correttamente - di solito solo nelle case di software modello cascata legacy oggi.

— Mattnz,

5

Un SRS è un documento morto non appena viene pubblicato. Li scrivo dal 1990. Sono come un piano di guerra, non sopravvivono mai al primo contatto. E non tengono mai il passo con l'implementazione effettiva, a meno che tu non abbia un team dedicato di scrittori che modifica costantemente la cosa e anche allora è sbagliato a causa della disconnessione dal cambiamento costante e degli sviluppatori che sono sempre in anticipo sul documento e non sempre dire al proprietario del documento cosa sta succedendo. Le aziende trascorrono migliaia di ore a scrivere cose del genere e i documenti vengono messi su uno scaffale e marciscono all'avvio dello sviluppo.

3

@JarrodRoberson +1 per te. In effetti Mattnz ha ragione anche sul fatto che SRS dovrebbe essere un documento vivente, ma poi si prendono un paio di problemi di produzione critici che i clienti richiedono di essere cambiati, mentre si lavora su una o più versioni ramificate della base di codice, interpretando erroneamente i requisiti di gli analisti aziendali, gli sviluppatori e il QA ... ciò che ti rimane è un documento che non è un vero riflesso del sistema in questo momento, ma anche un vero riflesso delle esigenze dell'utente. Le storie degli utenti sono veramente adottate dalle aziende più interessate al cliente che al sistema.

— maple_shaft

0

Vorrei provare ad usare l'umorismo.

Inizia con il http://www.halfarsedagilemanifesto.org/

Parla di questo per un po '( diversione )
e parla di cosa significano veramente i conflitti ( discussione aperta ),
poi dopo un po' rivolgiti alla tua organizzazione ( perno )
ed esamina SRS e se ha senso con il nuovo set-up del progetto .

Quindi vorrei concludere (o forse in un'altra riunione) con una discussione sul cambiamento nell'approccio in relazione a: SRS e vedere se hai più consenso.

Alla fine della giornata sei anche limitato dal budget e dal servizio alla gente di affari, quindi potrebbe esserci un punto in cui sei un po 'più fermo in ciò che viene utilizzato, ma questo dipende davvero dal settore, dalle dimensioni dell'azienda, dai fattori organizzativi e molti altri tali fattori.

— Michael Durrant
fonte

5

Essere molto attenti. Funzionerà solo se i tuoi collaboratori sono molto sicuri e hai un buon rapporto con loro. Molte persone si arrabbiano se usi l'umorismo per dire loro che sono sbagliate e nascoste.

— MarkJ

-1

Convincere mgmt ad allontanarsi dall'SRS e iniziare a usare le storie degli utenti è essenzialmente la stessa cosa di convincere mgmt ad adottare Agile. Esistono statistiche convincenti sui vantaggi della produttività di Agile. Un esempio è la presentazione di VersionOne a una conferenza del 2013. Mostra a questi dati del settore e se sono di tipo in ascolto, hai una possibilità.

— Joe
fonte

1

Spiacente, non è una gran risposta. Dici "mostra statistiche" e non fornisci nemmeno link.

— Jan Doggen,

e scrivi parole e frasi complete ...

— jwenting