Qualcuno nella mia azienda ha recentemente proposto modifiche al nostro prodotto principale che i nostri manager ritengono dovrebbero innescare ciò che immagino che la mia azienda consideri un ciclo completo di QA (ovvero testare l'intera suite di prodotti da zero). Apparentemente il nostro QA richiede 12 settimane per eseguire un ciclo completo di QA per il nostro prodotto. Il mio problema con questo è che stiamo provando a fare lo sviluppo Agile (anche se per lo più semi-valutato secondo me). Faremo un intero set di sprint e poi faremo un rilascio, che il QA impiegherà un'eternità per passare attraverso immagino. La domanda è davvero: se il nostro QA impiegherà 12 settimane per svolgere il proprio lavoro, non dovremmo semplicemente rinunciare a provare a fare Agile? Che diavolo ha senso provare a fare Agile in una situazione come questa?
Dovremmo smettere di provare a fare agili se il QA dura 12 settimane?
Risposte:
Beh, la risposta diretta alla tua domanda sarebbe Mu, temo: non ci sono abbastanza dettagli per indovinare se dovresti o meno smettere di provarci.
L'unica cosa di cui sono abbastanza positivo è che il livello di agilità dovrebbe essere guidato dalle esigenze del cliente / mercato (di cui non hai fornito informazioni).
- Ad esempio, come utente di IDE sono perfettamente felice di aggiornare alla nuova versione una o forse due volte l'anno e non ho mai fretta di farlo. Vale a dire se il loro ciclo di rilascio è di 3 mesi ( 12 settimane ), ne sono perfettamente soddisfatto.
D'altra parte, posso facilmente immaginare, per esempio, che la società di trading finanziaria fallisca se il loro software si adatta a più di un mese per adattarsi ai cambiamenti del mercato - il ciclo di test di 12 settimane in questo caso sarebbe una strada per l'inferno. Ora, quali sono le esigenze del tuo prodotto in questo senso?
Un'altra cosa da considerare è il livello di qualità richiesto per soddisfare le esigenze dei clienti / del mercato?
- Caso in questione: in una società in cui ho lavorato una volta abbiamo scoperto che abbiamo bisogno di alcune nuove funzionalità in un prodotto concesso in licenza da un fornitore di software. Senza questa funzionalità abbiamo sofferto piuttosto fortemente, quindi sì, volevamo davvero che fossero agili e fornissero l'aggiornamento entro un mese.
E sì, sembravano agili e sì hanno rilasciato quell'aggiornamento in un mese (se il loro ciclo di QA è di 12 settimane, probabilmente lo hanno semplicemente ignorato). E la nostra funzione ha funzionato perfettamente - immagino che avremmo dovuto essere perfettamente felici? no! abbiamo scoperto un bug di regressione di showstopper in alcune funzionalità che prima funzionavano bene - quindi abbiamo dovuto attenerci con la versione precedente.
Passò un altro mese: pubblicarono un'altra nuova versione: la nostra funzionec'era ma c'era anche lo stesso bug di regressione: di nuovo, non abbiamo effettuato l'aggiornamento. E un altro mese e un altro.
Alla fine siamo riusciti a eseguire l'aggiornamento solo dopo sei mesi, per la loro agilità.
Ora, guardiamo un po 'più da vicino in queste 12 settimane che menzioni.
Quali opzioni hai preso in considerazione per abbreviare il ciclo del QA? come puoi vedere dall'esempio sopra, semplicemente saltarlo potrebbe non darti quello che ti aspetti, quindi è meglio essere, bene, agili e considerare diversi modi per affrontarlo.
Ad esempio, hai considerato i modi per migliorare la testabilità del tuo prodotto?
Oppure, hai preso in considerazione la soluzione della forza bruta per assumere solo più QA? Per quanto possa sembrare semplice, in alcuni casi questa è davvero la strada da percorrere. Ho visto la gestione inesperta che cercava di risolvere i problemi di qualità del prodotto assumendo ciecamente sempre più sviluppatori senior dove sarebbe bastato solo un paio di tester professionisti medi . Abbastanza patetico.
L'ultimo ma non meno importante: penso che uno dovrebbe essere agile sull'applicazione stessa dei principi agili. Voglio dire, se i requisiti del progetto non sono agili (stabili o cambiano lentamente), allora perché preoccuparsi? Una volta ho osservato il top management forzare Scrum in progetti che stavano andando benissimo senza. Che spreco è stato. Non solo non ci sono stati miglioramenti nella loro consegna, ma peggio ancora, sviluppatori e tester sono diventati infelici.
aggiornamento basato sui chiarimenti forniti nei commenti
Per me, una delle parti più importanti di Agile sta avendo un rilascio spedibile alla fine di ogni sprint. Ciò implica diverse cose. In primo luogo, è necessario eseguire un livello di test per garantire che non si verifichino bug in grado di mostrare se si ritiene di poter rilasciare la build a un cliente ...
Rilascio disponibile . Hm. Hmmm. Considera di aggiungere una o due dosi di Lean al tuo cocktail Agile. Voglio dire, se questo non è un bisogno del cliente / mercato, ciò significherebbe solo uno spreco di risorse (test).
Per quanto mi riguarda, non vedo nulla di criminale nel trattare Sprint-end-release come un semplice checkpoint che soddisfa la squadra.
- dev: sì, uno sembra abbastanza buono da passare ai tester; QA: sì, uno sembra abbastanza buono per il caso se sono necessari ulteriori test shippable - cose del genere. Il team (dev + QA) è soddisfatto, tutto qui.
... Il punto più importante che hai fatto è stato alla fine della tua risposta in termini di non applicazione agile se i requisiti non sono agili. Penso che questo sia perfetto. Quando abbiamo iniziato a fare agili, abbiamo fatto il dial-in e le circostanze avevano un senso. Ma da allora le cose sono cambiate radicalmente e ci stiamo aggrappando al processo in cui potrebbe non avere più senso.
Hai capito esattamente. Anche da quello che descrivi sembra che tu sia arrivato allo stato (maturità team / management e relazione con il cliente) permettendoti di utilizzare lo sviluppo del modello iterativo regolare invece di Scrum. Se è così, allora potresti anche essere interessato a sapere che, per la mia esperienza, in casi come quello iterativo regolare sembrava più produttivo di Scrum. Molto più produttivo - non era semplicemente così tanto meno overhead, era semplicemente molto più facile concentrarsi sullo sviluppo (per QA rispettivamente a concentrarsi sui test).
- Di solito ci penso in termini di Ferrari (come iterativo regolare) vs Landrover (come Scrum).
Quando guidi su un'autostrada (e il tuo progetto sembra averlo raggiunto quell'autostrada ), la Ferrari batte l'inferno di Landrover.
È il fuoristrada in cui uno ha bisogno di una jeep non di un'auto sportiva - intendo se i tuoi requisiti sono irregolari e / o se l'esperienza di lavoro di squadra e di gestione non è così buona, dovrai scegliere Scrum - semplicemente perché provare ad andare regolarmente ti farà bloccato - come se la Ferrari si bloccasse in fuoristrada.
Il nostro prodotto completo è composto da molte parti più piccole che possono essere aggiornate indipendentemente. Penso che i nostri clienti siano molto disponibili ad aggiornare quei componenti più piccoli molto più frequentemente. Mi sembra che dovremmo forse concentrarci sul rilascio e sul QA di quei componenti più piccoli alla fine degli sprint ...
Sopra sembra un buon piano. Ho lavorato in un tale progetto una volta. Abbiamo spedito versioni mensili con aggiornamenti localizzati all'interno di piccoli componenti a basso rischio e l'approvazione del QA per questi è stata semplicissima.
- Una cosa da tenere a mente per questa strategia è quella di avere una verifica verificabile che il cambiamento sia localizzato dove previsto. Anche se questo arriva fino al confronto di file bit per bit per componenti che non sono cambiati, provalo o non lo spedirai. Il fatto è che è responsabile della qualità il rilascio della qualità, non noi sviluppatori.
È mal di testa del collaudatore assicurarsi che non si siano verificati cambiamenti imprevisti, perché francamente come sviluppatore ho abbastanza altre cose di cui preoccuparmi che è più importante per me. E per questo (i tester) hanno davvero bisogno di prove concrete che le cose siano sotto controllo con il rilascio che test-to-ship.
Oh, sento il tuo dolore. Ci sono alcune serie modifiche che devi apportare al team addetto al controllo qualità affinché questo funzioni.
Il mio consiglio è di dividere la squadra in tre squadre:
Test delle funzionalità : inversione rapida dei test sui nuovi sviluppi.
Test di regressione completi del prodotto prima che esca dalla porta. Questo non dovrebbe richiedere 3 mesi, anche dopo aver ridotto le dimensioni della squadra perché la maggior parte dei bug verrà trovata dalla prima squadra.
Test automatizzati : stesura di una suite completa di test di regressione per accelerare il lavoro del team di test di regressione.
La terza squadra è un bonus, ma se non puoi avere le prime due squadre, potresti anche essere a cascata.
A titolo illustrativo:
Nota che il tuo team di QA probabilmente sta lavorando al di fuori del cerchio (ATDD) e stai lavorando all'interno.
Penso che sia OK lavorare in quel modo; se nei test automatici è possibile dimostrare che si stanno soddisfacendo i requisiti del cliente per ogni sprint, è possibile consentire al QA di eseguire i test a proprio piacimento e venire da te con i difetti, che è quindi possibile lavorare allo sprint successivo.
Sembra che tu abbia un problema di "Definizione del fatto".
Dato che il tuo gruppo di controllo qualità è esterno e coinvolto solo nelle versioni dei clienti, non puoi fare affidamento su di esse per un feedback tempestivo sui problemi. Ciò significa che se desideri un feedback rapido, dovrai portare un certo grado di test "in-house" per il team.
Tratta il gruppo QA come se non esistesse. L'atto è se il tuo rilascio alla fine dello sprint verrà distribuito nel tuo ambiente più critico il giorno successivo. Il software non viene eseguito fino a quando non è pronto per andare ai clienti.
Il QA non dovrebbe trovare nulla.
Questo sarà più difficile da raggiungere. Probabilmente avrai alcune cose che si insinuano nelle prime volte. Test di accettazione automatizzati e test di "regressione" sono i tuoi migliori amici qui. TDD ti aiuterà a costruire gran parte di tali suite. Dovresti essere in grado di sapere - rapidamente - se hai rotto qualcosa.
Hai un rappresentante cliente / proprietario del prodotto che può vedere una data versione prima QA venga concluso e darti il feddback autorevole su di esso? In tal caso, puoi fare e beneficiare della maggior parte dei metodi agili trattando il QA come una fonte di feedback secondaria, piuttosto lenta. Un rilascio sarebbe "ufficialmente pronto" solo dopo che il QA sarà finito, ma non dovresti aspettarli prima di iniziare il prossimo.
Ma se le regole della compagnia dicono che il cliente non deve vedere un rilascio prima che il QA lo faccia, allora puoi praticamente dimenticarti di essere agile, finché non riesci a cambiare quelle regole.
Il processo che hai descritto non è un processo agile. Le squadre che hanno un alto grado di agilità sono in grado di fornire build affidabili e potenzialmente rilasciabili ad ogni sprint. Nella maggior parte delle implementazioni agili, la funzione QA è integrata all'interno del team agile che aiuta a raggiungere questo obiettivo.
Se tu, il capo del tuo progetto, il proprietario del prodotto e gli sviluppatori non stai lavorando insieme e non hai un piano di miglioramento (retrospettive), dai un nome al tuo processo e vai avanti. Non sembra che i problemi dei tuoi team siano colpa dei manager o del QA. Sembrano reagire a qualche problema sistemico che emerge dall'organizzazione di sviluppo. Non tutto è perduto se il team è disposto ad assumersi la responsabilità e iniziare a lavorare con le parti interessate.
Potresti provare tre cose. Uno, assicurarsi che ogni stakeholder abbia ruoli definiti in modo conciso e che ogni persona comprenda le proprie responsabilità. Due, stabilizzare la build e quindi ottenere l'approvazione dal QA senza introdurre ulteriori modifiche. Tre, istituto di automazione dei test. Il team QA ti adorerà per questo.
È un peccato che il feedback richieda così tanto tempo ma non credo che valga la pena fermarsi con agilità. Alla fine di uno sprint (o una coppia) rilasci un prodotto, sei sicuro che possa essere immesso sul mercato. Per il tuo team agile offre la possibilità di concentrarsi sul lavoro da svolgere e mantenere il prodotto rilasciabile. Quando il QA rileva problemi, suggerisco di creare segnalazioni di bug per questi problemi e risolverli nel prossimo sprint (se hanno una priorità abbastanza elevata).
I test sul campo dei nostri prodotti durano 8 settimane, in più dipendiamo da coltivatori esterni. Sempre agili, siamo in grado di rimanere concentrati sul lavoro a portata di mano e di produrre una nuova versione molto veloce quando necessario.
Il problema si trova (ai tuoi occhi) con il dipartimento QA il problema può essere risolto lì? Ne hai discusso?
Cosa stanno facendo le persone con QA mentre esegui più sprint? Sembra che sentano il bisogno di testare tutto dopo ogni cambiamento (motivo per cui attendono un sacco di cambiamenti).
Il team di sviluppo è agile, ma il resto dell'azienda non lo è.
Chiunque sia responsabile del QA o non sa cosa sta facendo o ha eseguito un trucco mentale Jedi sull'alta direzione e gli è concesso di prendersi il suo dolce tempo. In che modo il QA può impiegare più tempo dello sviluppo?