Come gestire i requisiti ridondanti quando si usa Scrum

4

La Changeability è un attributo di qualità dei requisiti enfatizzato in alcune pubblicazioni classiche. Per ottenere la variabilità dei requisiti, non devono essere ridondanti.

Tuttavia, quando si gestiscono i requisiti in Scrum, alcune pratiche porteranno inevitabilmente a storie utente ridondanti. Ad esempio, se un software deve avere caratteristiche numeriche simili dal punto di vista tecnico, ma l'utente ha un percorso diverso nell'interfaccia utente per ciascuna caratteristica: per mantenere le storie piccole (INVEST), vorrei creare storie diverse che sono solo leggermente diversi, o forse addirittura uguali solo con diversi criteri di accettazione. Ora, quando cambiano i requisiti aziendali, devo assicurarmi di aggiornare di conseguenza tutte le storie ridondanti.

Normalmente, questo sarebbe gestibile. Dopotutto, non ci dovrebbe essere un gran numero di storie aperte, ma quanto basta per riempire un piccolo numero di sprint imminenti. In pratica ("Scrum, ma ..."), i clienti possono insistere sulla suddivisione di un gran numero di requisiti per la planabilità. Ma anche Scrum su larga scala può portare a una situazione in cui ci sono molte storie aperte.

È possibile gestire un lungo elenco di storie aperte senza perdere i vantaggi di Scrum?

    
posta Max Hohenegger 31.10.2018 - 10:56
fonte

1 risposta

5

Sembra che questo dovrebbe essere coperto da grooming .

Il cambiamento costante significa che spesso le storie devono essere corrette, ampliate, divise, condensate, unite, ri-valutate ecc.

È una buona idea governare periodicamente tutte le attività. Prima di pianificare è il momento ideale, ma dovrebbe accadere regolarmente o tutte le volte che è necessario.

    
risposta data 31.10.2018 - 12:14
fonte