Ho sentito che durante il test delle storie sviluppate nello sprint attuale, non vengono sollevati problemi che non sono stati completati (cioè la definizione di fatto non è stata soddisfatta) e che si dovrebbero sollevare solo problemi quando si trova un altro problema non correlato ecc. ha senso non sollevare problemi su qualcosa su cui gli sviluppatori possono ancora lavorare fino alla fine dello sprint, non riesco a trovare alcune "buone pratiche". È un approccio corretto?
Dipende dal tuo processo. Nel mio mondo, un difetto è qualcosa che sfugge alle tue pratiche di qualità. Ma spetta a te definire esattamente cosa sono quelli.
Alcuni processi hanno una netta separazione tra il team di sviluppo e il team di test / qualità. Questo è il mondo in cui vivo ora. Il team di sviluppo è responsabile dei test di unità e di integrazione e il team di qualità è responsabile della regressione e dei test di accettazione a livello di consegna (a livello di applicazione e di sistema). In questo ambiente, qualsiasi problema non riscontrato dal team di sviluppo durante il test sarebbe stato registrato come difetto in quanto sfuggito alle attività di qualità del team di sviluppo - recensioni e test del codice.
I metodi agili promuovono un team interfunzionale altamente integrato. In questo ambiente, anche le attività di qualità si sono integrate. Persone diverse potrebbero essere alla guida di diverse attività, ma tutti sono coinvolti in ogni fase del processo. Per questo motivo, non sempre un chiaro passaggio da un team di sviluppo a un team di qualità. In quanto tale, considererei un difetto come qualcosa che arriva fino alla fine dell'iterazione e nel rilascio.
Tuttavia, qualcosa da considerare è la comunicazione. Nel mio primo esempio, potrei notare un problema che trovo nei test che è minore, ma non ho il percorso necessario per risolvere il ciclo di sviluppo. Posso registrare un difetto per comunicare che ho trovato un problema e consentire che sia disposto. Il responsabile del progetto o il team di qualità potrebbero dire che in realtà è un grosso problema (per il cliente o dal punto di vista della qualità del prodotto) e richiederlo nel ciclo di sviluppo, o potrebbe essere pianificato per una versione successiva.
Alla fine, devi fare la cosa giusta per permetterti di capire la qualità del tuo prodotto e comunicare lo stato attuale dello sforzo di sviluppo alle parti interessate appropriate.
Uno dei valori chiave dello sviluppo agile è che si desidera fornire software funzionante, il che significa che è stato verificato che le funzionalità fornite sono state verificate per funzionare correttamente (in base alla comprensione della funzionalità da parte del proprio team) .
Se trovi un problema durante il test, ci sono alcune possibilità:
In caso di # 1, dovresti, come squadra, provare a risolvere il problema prima della fine dello sprint. Altrimenti, non sarai in grado di dire che hai finito il lavoro. La necessità o meno di un ticket nel sistema di tracciamento dei bug dipende dalle convenzioni e dai requisiti locali per la tracciabilità.
In caso di # 2 o # 3, il problema deve essere segnalato al proprietario del prodotto, in modo che possa essere inserito nel backlog del prodotto e in base alla priorità. Se un nuovo ticket nel sistema di tracciamento dei bug è necessario o meno dipende dalle convenzioni locali e dal modo in cui viene gestito il backlog del prodotto.
(Preparati che in particolare gli elementi al punto # 2 possano ottenere la priorità "fai quando l'inferno si blocca su "aka never.)
La Guida di Scrum fornisce alcune indicazioni su questo
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”
Pertanto, una squadra che pratica Scrum non dovrebbe consapevolmente consentire al prodotto di subire una regressione inattesa delle funzionalità. Devono anche disabilitare i difetti noti nelle nuove funzionalità a meno che l'incremento non sia in una "condizione utilizzabile e soddisfi la definizione di" Fatto "del team Scrum.
Anche
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.
Scrum consente agli Scrum Teams di creare i propri processi per la gestione dei lavori in corso e bug nel codice di produzione. Questo perché non esiste una "best practice" in un dominio complesso come lo sviluppo di software più . Le pratiche di successo emergono come risultato dell'esecuzione di esperimenti e della scelta di quelli che tendono ad avere successo. Altro sulla complessità qui .
Basta picchiare intorno al cespuglio ... ECCO LA TUA RISPOSTA
Scegli un processo, ad es. registra e corregge tutti i bug, indipendentemente da quando e dove sono stati trovati, e inizia a misurare e a riflettere sugli effetti di quel nuovo processo. Il team vedrà pro e contro e finirà per risolvere un metodo collaudato che funziona per loro all'interno del framework Scrum.
Soprattutto, lo Scrum Team avrà preso la sua decisione empiricamente e in modo auto-organizzativo.