Il nostro sapore di Scrum [chiuso]

Question

Il nostro sapore di Scrum [chiuso]

#1 da (5 voti)
#2 da (4 voti)

0

Nella mia organizzazione non finiamo quasi mai tutte le storie nello Sprint e la maggior parte delle storie è finita all'80%.

Una ragione è che molte volte i tester non hanno abbastanza tempo per testare tutte le storie e gli sviluppatori non vogliono testare. Un altro motivo è che i team di solito sono troppo ottimisti, quindi si impegnano a fare più di quello che possono completare, e a nessuno importa davvero, quindi continuano a farlo ogni Sprint. Solitamente i test, le correzioni dei bug e gli ultimi lucidi rimangono sulla bacheca degli eventi dopo lo Sprint.

Il manager di R & D ritiene che non sia così male lasciare alcuni bug non risolti o saltare alcune implementazioni non critiche, perché in questo modo può avere un test di usabilità per le nuove funzionalità più velocemente. Tuttavia penso che sarebbe felice se la squadra potesse finire tutti i test e le correzioni dei bug, ma se non è tutto ok anche per lui, perché ci sono sempre degli sprint di stabilizzazione (hardening) alla fine in cui le cose più piccole saranno curato.

Vorrei chiederti, cosa ne pensi di questo metodo di sviluppo (che non è puro Scrum, ma una versione più flessibile / debole di esso).

Grazie.

scrum

posta Eugene 17.02.2014 - 21:31

fonte

2 risposte

Leggi altre domande sui tag scrum

Dove inserire l'interfaccia INotifyPropertyChanged in Model o ViewModel [closed] Come evitare errori e non perdere nulla [duplicato]

score 5 · Answer 1

È inaccettabile rilasciare il lavoro non testato. C'è bisogno di comunicazione su cosa deve essere testato, quanto tempo ci vorrà e come sapere quando tutto funziona.

Dici che la tua squadra sta usando una variante Scrum. Stimi le tue storie? Siete testers coinvolti in questa stima? Tieni traccia di quanti punti hai effettivamente completato oltre a quanti ti sei impegnato a?

La ragione per usare i punti storia è tracciare la velocità. Questa metrica dovrebbe essere inserita nei prossimi sprint, regolando la quantità di lavoro a cui ci si impegna di conseguenza. Se non segui i punti completati o non aggiusti gli sprint futuri usando quell'evidenza, perderai costantemente tempo o rimarrai costantemente indietro (come suona come sei).

I miei suggerimenti basati sulle informazioni fornite sono:

Assicurati che i tuoi tester siano coinvolti nella pianificazione e siano d'accordo con le stime della storia
Definisci "fatto". Il punto di uno sprint è consegnare un artefatto funzionante e testato. Se non è possibile nel tempo assegnato, tagliare l'ambito in modo che ciò che viene consegnato sia di buona qualità.
Tieni traccia dei tuoi precedenti sprint. Non hai bisogno di molti, solo tre o quattro iterazioni. Se scopri di esserti comportato troppo in precedenza, esegui il commit per ridurre questo sprint.

score 4 · Answer 2

Le cose sono finite su X% (le cronologie degli utenti sono terminate o non completate)
Gli sviluppatori che non vogliono testare
Le persone a cui non interessa il miglioramento continuo (rendendo le stime migliori il suo continuo miglioramento)
Sprint di stabilizzazione

Per me ci sono GRANDI difetti nel tuo processo attuale. Vedo gli stessi problemi o molto simili un sacco di volte. Uno dei principali vantaggi di Scrum è scoprire questi difetti, quando la mischia rende visibili questi problemi ci sono due possibili reazioni:

Cerca di trovare le cause alla radice di questi problemi e migliora il tuo processo, le retrospettive e uno spirito critico (ma costruttivo) la sua chiave qui.
"Il nostro mondo è diverso, la mischia è una cosa ideale che non può essere fatta, abbiamo bisogno di più flessibilità." ... e nulla cambia ...