Scrum: rilassante "fatto" o usando le punte?

Prima di tutto, proverei a spostare alcuni degli elementi dalla tua "definizione di fatto" alla "definizione di pronto". La definizione di ready determina quando una storia è in uno stato sufficiente per essere implementata dagli sviluppatori.

Gli elementi che vorrei provare a passare alla "definizione di pronto" sono:

• I requisiti sono stati scritti e approvati da PO
• Le specifiche dell'interfaccia utente sono state scritte e approvate da PO

questi articoli in genere implicano una sequenza di discussioni avanti e indietro tra l'OP, le parti interessate e il team e danno forma alla trama. Per questo motivo, dovrebbero essere fatti prima che il team possa raccogliere la storia per l'implementazione.

Dopo, l'opzione 2 mi sembra la migliore. Una delle idee di base dietro agile (e scrum) è che si dovrebbe essere in stretta collaborazione con (rappresentanti del) cliente e utenti, in modo da poter facilmente allineare l'idea del team di cosa hanno bisogno di fare con le reali esigenze / desideri del cliente. La dimostrazione alla fine di uno sprint in mischia è una pietra miliare regolarmente ricorrente in cui la squadra può mostrare al mondo ciò che ha realizzato, ma non c'è motivo per cui non si possa chiedere un feedback durante uno sprint.

Se ci sono discussioni regolari su quale forma dovrebbero assumere le nuove funzionalità, potresti prendere in considerazione l'introduzione di un tipo speciale di "prova del concetto" che ha una definizione rilassata del fatto e che può essere utilizzata dall'OP per avere un'idea per come funzionerebbe una funzionalità. Tali storie dovrebbero essere implementate su un ramo separato per assicurare che non vengano incluse in un'eventuale release. Per sottolineare, è una decisione del Proprietario del prodotto se una determinata storia è una storia normale o una storia di "prova del concetto".

Non posso giudicare, ma mi sembra che la tua definizione di fatto sia abbastanza irrealistica. Naturalmente, spetta alla tua organizzazione, ma in primo luogo dovrei considerare se hai bisogno, ad esempio, della localizzazione, prima della consegna, dopotutto, viene utilizzata solo una lingua alla volta. Forse è davvero necessario però!

Quindi, dopo essermi assicurato che non ci sia alcun valore senza tutte queste condizioni e assumendo che l'elenco sia ancora valido, prenderei una di queste due idee:

1. Riduci l'ambito di ciascuna storia in modo che si adatti a una iterazione e faccia in modo che il team faccia più storie parallelizzando. In altre parole, il tempo massimo trascorso deve essere di una iterazione, tuttavia è possibile riprodurre contemporaneamente più di una storia.

2. Rimuovere una serie di vincoli che si applicano solo alla distribuzione effettiva (ad esempio manuali utente?) in modo che il team possa essere più veloce, quindi aggiungere uno "scatto" di sprint ogni tanto, quando si rilascia effettivamente. Non molto agile, ma probabilmente qualcosa che devi fare.

Più in generale: l'adozione di un processo agile sta evidenziando un fattore di rischio nel modo in cui funziona la tua organizzazione. Questo è piuttosto un evento comune e, a mio parere, è un tratto desiderabile di metodologie agili. In particolare, sembra che ci sia una grande quantità di cerimonie. Vorrei iniziare esaminando il motivo per cui non può essere ridotto in modo massiccio prima, più che cercare di adattare la metodologia alla tua situazione. Hai pensato di chiedere al team di aiutarti (ad esempio in una retrospettiva?)

Ho notato che la tua domanda usa il tag "Scrum" e tuttavia, il tuo elenco di compiti per completare una storia mi porta a credere che non puoi fare Scrum. Ecco perché:

1. Scrum non richiede demo. La cosa più vicina che otteniamo è Sprint Review, che è ancora molto diversa da una demo
2. Scrum non richiede requisiti o specifiche. Il più vicino che otteniamo sono gli articoli del Product Backlog e il sovraccarico nella loro creazione è considerevolmente più piccolo rispetto alla creazione di requisiti e specifiche
3. Scrum non ha un ruolo di 'test manager'. Se stai utilizzando uno esterno, potresti aver infranto un elemento fondamentale di Scrum (che il team sia pienamente funzionale)
4. Idem per il ruolo di "gestore software"
5. Ditto "software architect"

Mi sembra che tu abbia una variante che può essere basata su Scrum ma non è Scrum. Suggerisco che il flusso di lavoro abbia alcuni elementi di processo pesante applicati che ti trascinano verso il basso e quindi il tuo disagio molto comprensibile.

Il mio consiglio è di tornare alle origini di Scrum, identificare le disfunzioni e poi lavorare sodo per risolverle.