Dimensione: 4528
Commento:
|
Dimensione: 4531
Commento:
|
Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
Linea 7: | Linea 7: |
Questo documento è stato scritto da PaoloSammicheli nel periodo di passaggio di consegne al nuovo amministratore del Gruppo Test. Se trovate degli errori e typo sentitevi liberi di correggerlo. Non cambiate però il senso di quanto scritto... si tratta di miei punti vista personalissimi ;) | Questo documento è stato scritto da PaoloSammicheli nel periodo di passaggio di consegne al nuovo amministratore del Gruppo Test. Se trovate degli errori e typo sentitevi liberi di correggerlo. Non cambiate però il senso di quanto scritto... si tratta di miei punti di vista personalissimi ;) |
Introduzione
Questo documento è stato scritto da PaoloSammicheli nel periodo di passaggio di consegne al nuovo amministratore del Gruppo Test. Se trovate degli errori e typo sentitevi liberi di correggerlo. Non cambiate però il senso di quanto scritto... si tratta di miei punti di vista personalissimi
Principi fondativi
L'idea del gruppo test è nata durante l'UDS Lucid a Dallas. Marjo Mercado mi parlò di una sua idea di far partecipare i LoCo Team ai test per avere una sorta di competizioni, "le olimpiadi dei test". Ai tempi mi occupavo di Marketing con il GruppoPromozione e di Traduzioni ma l'idea mi piacque molto per cui proposi agli altri di realizzarla. In un certo qual modo vedevo il GruppoTest come un valido supporto al GruppoPromozione. Il GruppoPromozione, infatti, era percepito come il gruppo di accoglienza, dove chi voleva iniziare a collaborare con Ubuntu potesse farlo facilmente. Questo però era una percezione errata perché i progetti del gruppo, fatta esclusione di pochissimi già sovrabbondanti di volontari, erano in realtà complessi e richiedevano parecchie conoscenze che difficilmente un giovane ha. Il Gruppo Test nascque quindi con i seguenti principi:
- Attività semplici
- cercammo di abbassare la soglia minima di partecipazione. Per questo motivo scegliemmo il caso di test Live
- Attività ripetibili
- basandosi su azioni routinarie si semplificava l'apprendimento e si dava la sensazione anche a chi fosse completamente digiuno d'informatica di "potercela fare"
- Impegno minimo
- per far parte del gruppo è sufficiente mantenere un impegno minimo, corrispondente all'adozione. Una immagine da testare ogni Milestone, in pratica mediamente un test al mese. In modo da invogliare anche chi avesse poco tempo libero.
- Spirito di squadra
- dividere l'effort di testing sulle adozioni permetteva di introdurre lo spirito di squadra. È stato introdotto il principio che chi non poteva fare i test era chiamato almeno ad avvertire prima. Questo ha fatto sì che altri si impegnassero a fare il test dichiarato scoperto favorendo lo spirito di squadra.
Il buon amministratore
dare l'esempio
Il buon amministratore del gruppo test deve dare l'esempio. Occorre che segua le liste internazionali e, quando può, stazioni nei canali internazionali di QA e Testing. È anche opportuno che stabilisca rapporti di conoscenza con chi si occupa di QA a livello internazionale, volontari e dipendenti canonical. Deve anche bloggare ogni tanto, per cercare di attirare nuovi contributori e, se possibile, parlare a qualche conferenza/incontro di sofware libero di quanto sia bello e semplice partecipare alla comunità di Ubuntu.
mentoring
L'amministratore verrà rapidamente individuato come la persona a cui domandare. Questo comporta dover trovare le risposte, e non è sempre semplice. È consigliato essere assolutamente sinceri, dire tranquillamente che una cosa non la sappiamo e che chiediamo informazioni. Inutile dare l'idea di sapere tutto, nessuno sa tutto ed in Ubuntu tutto cambia ogni sei mesi
È anche importante dire senza problemi "ho sbagliato", "mi dispiace" oppure "questa cosa non la sapevo". Sdrammatizza il ruolo e semplifica il rapporto con i volontari.
motivazione
Tenere alta la motivazione è uno dei compiti dell'amministratore. Occorre ringraziare chi si impegna, mandare qualche mail che ricorda quanto importante è cio' che facciamo, ma anche occorre riprendere chi sbaglia. Trovare il giusto equilibrio è difficilissimo, sono certo di non riuscirci sempre per cui non mi avvento in consigli, sappiate che occorre trovarlo.
lavori manuali
Ci sono dei lavoretti manuali da fare, ogni tanto:
- Aggiornare l'header delle pagine wiki mettendo la prossima scadenza.
- Manutenere la tabella dei casi svolti spostando i casi delle milestone via via che si completano
- Rivedere i test degli altri e i bug segnalati dai nuovi; spesso sono pieni di errori e imprecisioni.
Riunioni su IRC
È provato che le riunioni su IRC aiutano lo spirito di gruppo. È importante mantenere questa pratica dopo ogni rilascio Milestone. In esse viene di solito valutato il lavoro svolto, ad esempio con tabelle come questa. Al nuovo amministratore consiglio di leggersi i verbali delle vecchie riunioni, almeno si fa un'idea