Le epiche sono segnaposto
In quasi tutti i metodi Agile il concetto di Epics sarebbe tanto quanto necessario per una specifica dei requisiti, i segnaposto sono ciò di cui hai bisogno a quel livello. Quelle voci avranno sempre la priorità, più alcun dettaglio è uno sforzo inutile se il requisito diventa a bassa priorità per un lungo periodo, o non viene nemmeno mai implementato. Documentarlo e gestire la documentazione che lo circonda sarebbe una completa perdita di tempo. YAGNI si estende alle attività richieste 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 la Specifica dei requisiti. Una specifica dei requisiti è comunque un documento temporaneo artefatto , non è un documento vivente, è un'istantanea dei requisiti nel tempo. E non è mai in sintonia con la realtà.
Genera automaticamente artefatti
Le storie degli utenti che possono essere esportate da uno strumento appropriato sono molto più preziose di qualsiasi documento di artefatto statico in qualsiasi momento. Personalmente preferisco Pivotal Tracker per tracciare User Stories, 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 di sviluppo dettagliate e simili sulle storie), i dati in tempo reale sono sempre migliori dei dati statici.
Il Wiki è diventato un documento in tempo reale di tutti i negozi / requisiti e il loro stato di completamento e priorità con dettagli e commenti e altri metadati.
Molto meglio di un enorme documento Word in Sharepoint che viene sempre inviato via email costantemente e mai aggiornato, garantendo che tutti abbiano una versione diversa e che non siano sincronizzati con tutti gli altri!
Le User Story sono più ricche dei casi d'uso
L'uso della storia è molto più prezioso di un caso d'uso perché dicono PERCHÉ .
Il formato User Story: As a [ROLE] I [ACTIVITY] so that [WHY] è molto più espressivo di Use Case che sono come 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 CHE COSA vogliono fare (il che può puntare a un diagramma / documento più dettagliato per attività) e tu hai la parte più importante PERCHÉ vogliono svolgere questa attività.
Se hai il primo, il secondo è completamente ridondante e solo il rumore al meglio. Una specifica dei requisiti formali tradizionali di una metodologia Waterfall non ha posto in un ambiente Agile.
Alla fine
Se la tua gestione non si impegna a cambiare, non avrai successo con una nuova metodologia. Ho lavorato per un'azienda da oltre 100 miliardi di dollari l'anno, non hanno preso piccoli passi per passare a Agile / SCRUM, hanno appena detto, l'intera azienda si sta muovendo verso questo, ecco il nuovo modo di fare le cose, ecco quando inizierà la tua formazione sul nuovo modo, ecco i nuovi strumenti che useremo, ecco la data in cui iniziamo a fare le cose in questo modo. Ha funzionato per loro in meno di un anno. Ho lavorato per implementarlo nelle aziende più piccole con lo stesso successo.
Impegno
Le implementazioni
baby steps , indipendentemente da quale sia il cambiamento, sono una ricetta per il fallimento. È una parola in codice per la gestione che tranquillamente non sono d'accordo e passivamente ti stanno preparando aggressivamente per il fallimento. Dicono che non ci credo abbastanza per impegnarmi, quindi ti lascerò fare abbastanza per fallire / non riuscire , in questo modo possono dire che hanno provato e non ha funzionato e il modo in cui gestivano funzionava bene tutto il tempo. L'impegno parziale alla fine porta al fallimento.
Nel tuo caso, probabilmente non credono nelle User Story, e dopo un po 'di tempo inizieranno a sostenere che sono le User Story che sono inutili e non lo SRS e spingono a smettere di scrivere le User Story, che ti porteranno indietro non indietro.