Nella mia esperienza c'è un equilibrio tra fornire aggiornamenti regolari agli utenti e rendere l'applicazione di alta qualità. Quindi, per prima cosa, guardiamo gli estremi:
Rilascio troppo spesso : quando rilasci troppo spesso, il team addetto al QA è sempre dietro la palla. Anche se possono creare / eseguire script di test automatici, hanno bisogno di tempo per portare a termine il lavoro. Quando una parte abbastanza grande del test deve essere manuale, ci saranno sempre bug che sfuggono. Breve storia: la probabilità che un bug di alto profilo che arriva fino al cliente vada verso l'alto.
Non rilasciare abbastanza spesso : a questo punto si verificano due problemi: i clienti sono stufi dello strumento e tutti diventano pigri. Quando c'è molto tempo tra una release e l'altra, gli sviluppatori vogliono fare di più, i tester diventano meno vigili e aumentano le possibilità di scadenze pianificate. Tutto ciò è dovuto al tempo extra percepito che tutti hanno. I clienti che diventano impazienti iniziano a richiedere una nuova soluzione, una soluzione che risolverà i loro problemi oggi e non tra 6 mesi a partire da ora.
Trovare l'equilibrio : c'è un punto in cui la produttività della tua squadra raggiunge un picco di velocità sostenibile. Dovrai sperimentare per scoprire di cosa si tratta. IMO, 1 mese non è il tempo sufficiente per implementare qualsiasi funzionalità sostanziale e assicurarsi che funzioni correttamente. Il mio team lavora molto bene in intervalli di 2-3 mesi, anche se è al massimo dell'efficienza con 3 mesi. Hai tempo a sufficienza per riprogettare quando necessario e implementare nuove importanti funzionalità. Il team di test non ha la sensazione di avere il lusso del tempo, ma ha abbastanza da tenere il passo e rimanere vigili. I clienti possono anche gestire cicli di rilascio di 3 mesi, in particolare se la qualità della versione è elevata.
Per trovare il picco per il tuo team è necessario misurare la qualità in modo significativo. L'unica metrica significativa che conta davvero è
How many bugs were found by your customers?
Non mi interessa quanti bug sono stati trovati e risolti in casa, questo è solo un segno che tutti stanno facendo il loro lavoro. Più sono e meglio è. Mi interessa di più di quanti bug, e la gravità dei bug che gli utenti scoprono. Questa è la misura diretta più affidabile della qualità di rilascio del software che conosco.
Una metrica correlata che è ugualmente significativa, ma in un modo diverso è:
How many new feature requests from the customers?
Le richieste di informazioni sono un'indicazione che le persone stanno davvero utilizzando il sistema e stanno pensando a come rendere più facile il loro lavoro. Le richieste possono essere semplici come cambiare "felice" in "contento" nei file della guida o complicati come nuovi modi di visualizzare i dati. È importante distinguere una richiesta per una nuova funzione da un'interfaccia utente mal progettata (sarebbe un bug trovato dall'utente). Il numero di richieste di funzionalità non è necessariamente un'indicazione di mancare il marchio, è più un'indicazione dell'interesse dell'utente. Sappi anche che i tuoi clienti stanno imparando come lo strumento migliora il lavoro alla stessa velocità con cui stai imparando a conoscere i tuoi clienti. Il cliente può solo visualizzare e consigliare miglioramenti incrementali. Spetta a te determinare se esiste un tema di base per le richieste e scoprire se esiste un approccio diverso che possa risolvere tutti i problemi.