Il tempo del tester dovrebbe essere incluso nella stima dei biglietti?

17

Quando si creano stime di tempo per i biglietti, il tempo necessario per i tester (QA) deve essere incluso nella stima di un biglietto? In precedenza abbiamo sempre stimato senza il tempo dei tester ma stiamo parlando di includerlo sempre. Ha senso per il nostro sprint attuale, l'ultimo prima di un rilascio, in quanto è necessario conoscere il tempo totale che i biglietti impiegheranno con una settimana.

Ho sempre capito che la stima era solo per il tempo degli sviluppatori in quanto tende a essere la risorsa limitante nei team. Un collega dice che, ovunque abbiano lavorato, è stato incluso anche il tempo del tester.

Per essere chiari, questo è per un processo in cui gli sviluppatori stanno scrivendo unit, integrazioni e test dell'interfaccia utente con una buona copertura.

    
posta TTransmit 10.01.2017 - 16:27
fonte

9 risposte

34

La mia raccomandazione: includi il tempo di test nel ticket o aggiungi un ticket per rappresentare l'attività di test stessa. Qualsiasi altro approccio ti fa sottostimare il vero lavoro necessario.

Mentre il tempo di sviluppo è spesso un collo di bottiglia, nella mia esperienza, ci sono molte squadre vincolate al test. Supponendo che la risorsa limitante sia l'una o l'altra senza prove, può morderti.

Come collega, non ho visto un'organizzazione di successo che non tenga conto del tempo di test.

Addendum per i tuoi chiarimenti: anche se gli sviluppatori scrivono test automatici, in particolare i test di unità (i test di integrazione fanno meglio), non sono sufficienti per testare correttamente.

Se ci sono persone coinvolte nel controllo di qualità, è necessario stimarne il tempo, in un modo o nell'altro. Solo se stai decidendo di rimuovere le persone del QA dal libro paga, il loro tempo di lavoro è effettivamente svanito e puoi rimuoverlo dalla stima. Ma questo avrebbe effetti collaterali facili da ignorare. E potresti ancora perdere prestazioni, stress, sicurezza e test di accettazione.

    
risposta data 10.01.2017 - 16:30
fonte
19

Enfaticamente,

I test fanno parte del processo di sviluppo. Se il tuo team spende effettivamente il tempo per testare il software, il tempo impiegato per i test deve essere parte della stima.

    
risposta data 10.01.2017 - 17:49
fonte
5

Se questo è agile, includerò lo sforzo di test come parte dei punti totali della storia. Ad esempio, lo sforzo di dev può essere di 1 giorno e testare 1 giorno in modo che sia una storia a 2 punti.

Dipende da cosa è la tua definizione di fatto, ma di solito il suo sviluppo è completo, l'accettazione aziendale e il collaudo sono firmati nell'iterazione. Se il DoD è solo accettazione aziendale, non è necessario includere lo sforzo di verifica nei punti della storia, ma deve comunque essere monitorato.

    
risposta data 10.01.2017 - 17:13
fonte
2

La stima dovrebbe tenere conto di tutto il lavoro necessario per completare il ticket. Se il test è una parte richiesta del ticket, allora dovrebbe essere incluso nel preventivo. Se il test è un biglietto separato, allora non dovrebbe.

Ovviamente può diventare tutto sfocato una volta che inizi a utilizzare i punti storia, dal momento che la differenza tra un dev-only 5 e un 8 solo dev sarà piuttosto proporzionale a un dev-and-QA 5 rispetto a un dev-and- QA 8.

Ho visto incluso il lavoro sul tempo del tester. Ho visto storie separate lavorare. Ho visto compiti separati, ciascuno stimato dal gruppo che li fa funzionare. Fai ciò che ha senso per te, dopo tutto il processo è lì per servirti, non viceversa.

    
risposta data 10.01.2017 - 17:30
fonte
2

Il fatto che non si possa rispondere a ciò suggerisce strongmente non si sa perché si stiano scrivendo stime (o almeno che non si è d'accordo con il collega perché si stanno scrivendo stime). Questo è un problema più grande del fatto che le stime dovrebbero o non dovrebbero includere test.

Scopri, o raggiungi un accordo, perché stai scrivendo delle stime. Se si tratta di prevedere cosa realizzerà una determinata squadra in un determinato momento, la risposta dipende semplicemente dal fatto che quella squadra, quella per cui si sta valutando, esegue o meno il test. Se il tuo team di QA è separato e ha una propria programmazione, potrebbe essere interessato a sapere quanto tempo di test tu (gli sviluppatori) ritenga necessario da loro su un dato ticket. Potrebbero ignorare i tuoi numeri e inserirli da soli. In entrambi i casi, possono tenerne traccia separatamente rispetto alle stime del tempo di sviluppo.

D'altra parte, se una squadra sta facendo tutto lo sviluppo, i test e il QA, e lo scopo delle stime temporali è di prevedere e pianificare ciò che sta facendo quella squadra in un determinato periodo di tempo, allora di Ovviamente le stime temporali devono includere il QA, insieme a qualsiasi altro compito che è necessario fare per quella squadra al fine di raggiungere l'obiettivo dichiarato. Se è necessario avere una riunione iniziale per ogni biglietto, o compilare un po 'di documenti al termine, allora il tempo per l'amministratore deve essere lì da qualche parte . Non puoi semplicemente ignorarlo.

Se è tutta una squadra ma con ruoli separati "sviluppatori" e "tester", allora questo potrebbe significare che hai molti ticket su cui solo una parte della divisione è in grado di lavorare, e la tua (forse del tutto ipotetica) Il diagramma di Gantt appare esattamente come il grafico di due team separati. Questo fatto stravolgerà alcune metodologie più di altre, e potrebbe essere meglio suddividere la pianificazione a causa di ciò, ma se non lo dividi devi fare il ticket e stimare tutto ciò che la squadra deve fare o le tue previsioni saranno senza speranza .

Se lo scopo delle stime è qualcosa di diverso dalla previsione e dalla pianificazione, ad esempio "perché seguiamo insensatamente un rituale vuoto che li include", o "perché la gestione li usa come un bastone per batterci per ottenere gli straordinari da noi ", o" perché dobbiamo fare un'offerta a prezzo fisso ei numeri vanno in una formula enorme "(grazie John Wu), allora potrebbe essere più difficile capire cosa dovrebbero includere; -)

    
risposta data 11.01.2017 - 02:50
fonte
1

Stima sempre tutto il lavoro che deve essere fatto per rendere veramente fattibile una storia / caratteristica / biglietto. Chiamiamo questo DoneDone .

We're done when we're production-ready.

Questo include qualsiasi test manuale ed esplorativo, ma anche test di accettazione da parte dell'utente.

Un team Agile dovrebbe essere in grado di rilasciare una nuova parte del lavoro finito in qualsiasi momento. Come:

Working software is the primary measure of progress.

Come fai a sapere se funziona, se non lo hai testato? Ora scrivi che il tempo di sviluppo è il collo di bottiglia del tuo tempo. In qualità di ingegnere della QA, ritengo che la maggior parte delle squadre abbia il collo di bottiglia nella capacità di test o che stiano semplicemente prendendo scorciatoie.

Per farla breve, stimare anche lo sforzo di test. Tieni presente che potrebbe influenzare la velocità . Se hai fatto stime relative in story-points, il test potrebbe già essere incorporato nella tua velocità media.

    
risposta data 10.01.2017 - 20:16
fonte
1

Ecco qualcosa di molto importante: Tutte le stime devono essere accompagnate da ipotesi ed esclusioni .

Questo include specificare cosa è incluso: solo sviluppo, progettazione e sviluppo, test di sviluppo e unità, copertura per test di accettazione, buildout di infrastrutture, ecc.

Se stai fornendo un documento di stima a un project manager, convertiranno quel documento in un ordine di lavoro o una dichiarazione di lavoro per un cliente o (se un progetto interno) per PMO . Loro possono aver impostato le formule per aggiungere un sovraccarico (ad esempio, alcuni progetti possono aggiungere X% per coprire il QA, quindi aggiungere Y% per coprire la governance e la gestione del progetto) stabiliti per contratto o impostati per esperienza. E tu non vuoi il doppio conteggio. D'altra parte, potrebbero non aggiungerli automaticamente.

Le pratiche differiscono. Chiunque stia utilizzando questi numeri dovrà sapere che cosa significano i numeri e dovresti essere esplicito se stai includendo o meno il tempo di test.

    
risposta data 11.01.2017 - 01:14
fonte
1

Il tempo dovrebbe essere incluso nella stima ma tu non dovrebbe stimare il tempo dei tester, invece i tester dovrebbero stimare il loro tempo .

Non includere il tempo di test è una stima errata del tempo totale che ci vorrà, ma il tempo dello sviluppatore e il tempo del tester non sono intercambiabili (anche perché presumibilmente lavorate in parallelo, con i tester un'iterazione dietro) quindi dovreste stimare loro separatamente. Inoltre, non si è in grado di stimare i tester del tempo che dovranno testare eventuali modifiche, solo lo stesso personale di prova dovrebbe farlo.

    
risposta data 11.01.2017 - 10:43
fonte
0

Encapsulation

Tratterò questo approccio da un punto di vista e da un linguaggio di sviluppo del software.

  • Sei un piccolo ingranaggio in una macchina di grandi dimensioni.
  • Dall'esterno del tuo team, il tuo sistema di ticketing funge da interfaccia / API per il tuo team
  • Gli utenti aziendali che utilizzano il sistema di ticketing non sono sviluppatori

Dal buon design del software, dovresti semplificare e incapsulare il più possibile.

Quindi, per vedere il processo dal punto di vista degli utenti aziendali, si preoccupano solo di 2 cose.

  1. Quanto costerà?
  2. Abbiamo finito?

Consentire all'utente aziendale di conoscere il processo interno del proprio team è una cattiva gestione; simile a dare public all'accesso allo stato interno.

La mancata protezione dello stato interno della tua squadra, sta invitando altri team a gestire le tue risorse e ad interferire con il tuo stato interno.

    
risposta data 11.01.2017 - 05:38
fonte

Leggi altre domande sui tag