Come convincere il management che il QA è importante? [chiuso]

Question

Lavoro per una piccola società di software con meno di 10 programmatori. Il nostro software è installato in dozzine di luoghi in tutto il mondo. La nostra base di codice è enorme, principalmente a causa del design scadente e di enormi quantità di duplicazione del codice (IMO). Abbiamo circa 30 progetti diversi, ciascuno con un totale di circa 600 KLOC, di cui circa 200 KLOC sono il nostro codice nazionale. Quando ci sono arrivato nel 2006, questo codice non era nemmeno sotto controllo di revisione. Sono riuscito a convincere i poteri che è importante, e ora usiamo un sistema di controllo del codice (cs-rcs, non la mia scelta ma è meglio di niente) e un sistema di tracciamento dei bug. L'enorme pezzo mancante è la totale e completa mancanza di QA nel processo. Il nostro processo di rilascio è inesistente su supporto cartaceo e, in pratica, consiste nel "premere ctrl-F9, copiare il binario sul client, dichiarare risolto il problema."

Qualcuno può indicarmi alcuni documenti ufficiali o documenti o articoli in linguaggio PHB che possono spiegare la palese follia in questo processo? Sono sicuro che il capo potrebbe assumere un consulente per dirglielo, e poi potrebbe crederci. Ma sono solo un modesto manutentore con una laurea in Ingegneria del Software. E neanche la mia etnia mi aiuta. Qual è la migliore munizione da utilizzare in questo caso?

Answer 1

Tautologicamente, l'unico modo per convincerli è metterli di fronte a qualcosa di convincente. Quella cosa potrebbe essere disegnata da un elenco come:

• Il disastro predetto costoso che richiede l'adozione della soluzione presentata in precedenza
• Il disastro imprevisto con a soluzione pronta per l'uso
• A predicazione brillantemente persuasiva di un disastro
• A brillantemente appello persuasivo all'avidità (risparmio il costo opportunità di un predetto disastro)

O qualcos'altro. In tutti questi casi, qualcuno dovrà presentare il caso ad un certo punto per la soluzione di QA che proponi e che qualcuno, dal suo aspetto, dovrà essere tu. Quindi inizierei a imparare a essere persuasivo.

Come conquistare amici e influenzare le persone dovrebbe costare qualche soldo al massimo. Arrivare a Sì è anche economico.

Come hai ottenuto il consenso al controllo del codice sorgente? Riesci a continuare a scheggiare, migliorando il processo con un piccolo incremento alla volta?

Prova a cercare su Google "

Answer 2

La tua migliore munizione in questo caso è aspettare l'inevitabile disastro. Una volta che succede, fai in modo che tutte le tue anatre siano in fila con un piano che non si ripeta più questo disastro, sottolineando che i costi di implementazione sono molto più bassi di quelli del disastro stesso.

Nessun discorso farà sì che i PHB " ottengano " se non vogliono " esso " innanzitutto. Solo un grande schiaffo in faccia da quel duro padrone - la realtà - alla fine li convincerà.

Oh, e mentre ci sei, aggiorna il tuo curriculum e guarda. Le catastrofi che tendono a convincere le persone che hanno bisogno del QA sono molto simili ai tipi di catastrofi che uccidono le aziende.

Il denaro è la tua scommessa migliore - fa male peggio quando si tratta di pagare.
Penso che la seguente immagine dica tutto:
(L'immagine è tratta da www.developertesting.com )

La direzione non capirà altro che due cose: (1) Vantaggi e amp; (2) Soddisfazione del cliente. Il secondo è difficile da quantificare, ma il primo è facile. Puoi spendere da $ 40k a $ 60k su un decente ingegnere QA che può entrare e iniziare a dare un senso al disordine e iniziare a sviluppare un piano intorno ad esso. Il vantaggio in termini di costi deriva dall'assicurarsi che un ingegnere più esperto non debba passare 2 mesi a rintracciare un bug nascosto in 100k righe di codice.

C'è un altro modo di fare questo ... Puoi fare quello che stiamo facendo dove lavoro. Inizia a scrivere i test per il codice all'inizio e poi quando hai finito con il codice se il test ha esito positivo sei d'oro. Dopo aver superato il test, avrai un test in atto che ti assicurerà se rompi quel codice che lo saprai quasi all'istante. E se fai in modo che i tuoi colleghi programmatori entrino in quell'azione, almeno tutto il nuovo codice verrà sviluppato in un framework di test. Sviluppo guidato dai test non solo rende il processo più veloce (sai già cosa vuoi risultato prima di iniziare a scrivere codice), ma aiuta anche a perfezionare le tue esigenze in fretta. Soprattutto, con un po 'di ingegneria sociale (lavorando con i tuoi colleghi) puoi cambiare la cultura dello sviluppo un po' alla volta fino al completamento del processo.

Posso consigliare The Toyota Way. La versione breve è spesso possibile ordinare gratuitamente dai siti Web di Toyota. La direzione avrebbe dovuto leggerlo già, ma a quanto pare non lo hanno fatto. Leggilo, digeriscilo, fai leggere al management. Per ispirazione, posso davvero consigliare di leggere Lezioni da Toyota Long Drive (vale la pena spendere qualche soldo per ottenere il PDF).

Forse se fai in modo che alcuni dei tuoi colleghi programmatori ti sostengano, la gestione sarà un po 'più disposta ad ascoltare. Non è necessario essere un genio per rendersi conto che una base di codice enorme e ingombrante è indicativa di un ampio margine di miglioramento.

Consulta il libro di Joel

Se il tuo management non ritiene che il QA sia importante, qualcosa di così ovvio e "buon senso" al punto che qualsiasi profano sarebbe d'accordo, quindi non penso che mettere un mucchio di documenti accademici, o qualsiasi altra cosa, facciano la differenza.

La tua unica speranza è probabilmente quella di provare a mettere insieme un documento che mostri i risparmi sui costi, ma dubito che sarebbe di aiuto in questo caso.

Ho lavorato in un dipartimento in cui un pool comune ruotava tra attività di sviluppo e test. Ciò ha compiuto due cose:

• tester altamente qualificati ed efficienti, che nella peggiore delle ipotesi sapevano cosa stava cercando di fare il codice e come
• sviluppatori che sapevano che il loro turno stava per fare test o che erano appena tornati dai test. Quindi era noto il dolore del test del codice errato, così come il piacere del test del buon codice.

Il ragazzo più rispettato di tutto il gruppo era uno spietato tester e, durante lo sviluppo, avrebbe prodotto software a zero difetti.

Answer 3

La tua migliore munizione in questo caso è aspettare l'inevitabile disastro. Una volta che succede, fai in modo che tutte le tue anatre siano in fila con un piano che non si ripeta più questo disastro, sottolineando che i costi di implementazione sono molto più bassi di quelli del disastro stesso.

Nessun discorso farà sì che i PHB " ottengano " se non vogliono " esso " innanzitutto. Solo un grande schiaffo in faccia da quel duro padrone - la realtà - alla fine li convincerà.

Oh, e mentre ci sei, aggiorna il tuo curriculum e guarda. Le catastrofi che tendono a convincere le persone che hanno bisogno del QA sono molto simili ai tipi di catastrofi che uccidono le aziende.

Answer 4

Il denaro è la tua scommessa migliore - fa male peggio quando si tratta di pagare.
Penso che la seguente immagine dica tutto:
(L'immagine è tratta da www.developertesting.com )

Answer 5

La direzione non capirà altro che due cose: (1) Vantaggi e amp; (2) Soddisfazione del cliente. Il secondo è difficile da quantificare, ma il primo è facile. Puoi spendere da $ 40k a $ 60k su un decente ingegnere QA che può entrare e iniziare a dare un senso al disordine e iniziare a sviluppare un piano intorno ad esso. Il vantaggio in termini di costi deriva dall'assicurarsi che un ingegnere più esperto non debba passare 2 mesi a rintracciare un bug nascosto in 100k righe di codice.

C'è un altro modo di fare questo ... Puoi fare quello che stiamo facendo dove lavoro. Inizia a scrivere i test per il codice all'inizio e poi quando hai finito con il codice se il test ha esito positivo sei d'oro. Dopo aver superato il test, avrai un test in atto che ti assicurerà se rompi quel codice che lo saprai quasi all'istante. E se fai in modo che i tuoi colleghi programmatori entrino in quell'azione, almeno tutto il nuovo codice verrà sviluppato in un framework di test. Sviluppo guidato dai test non solo rende il processo più veloce (sai già cosa vuoi risultato prima di iniziare a scrivere codice), ma aiuta anche a perfezionare le tue esigenze in fretta. Soprattutto, con un po 'di ingegneria sociale (lavorando con i tuoi colleghi) puoi cambiare la cultura dello sviluppo un po' alla volta fino al completamento del processo.

Answer 6

Posso consigliare The Toyota Way. La versione breve è spesso possibile ordinare gratuitamente dai siti Web di Toyota. La direzione avrebbe dovuto leggerlo già, ma a quanto pare non lo hanno fatto. Leggilo, digeriscilo, fai leggere al management. Per ispirazione, posso davvero consigliare di leggere Lezioni da Toyota Long Drive (vale la pena spendere qualche soldo per ottenere il PDF).

Answer 7

Forse se fai in modo che alcuni dei tuoi colleghi programmatori ti sostengano, la gestione sarà un po 'più disposta ad ascoltare. Non è necessario essere un genio per rendersi conto che una base di codice enorme e ingombrante è indicativa di un ampio margine di miglioramento.

Answer 8

Consulta il libro di Joel

Answer 9

Se il tuo management non ritiene che il QA sia importante, qualcosa di così ovvio e "buon senso" al punto che qualsiasi profano sarebbe d'accordo, quindi non penso che mettere un mucchio di documenti accademici, o qualsiasi altra cosa, facciano la differenza.

La tua unica speranza è probabilmente quella di provare a mettere insieme un documento che mostri i risparmi sui costi, ma dubito che sarebbe di aiuto in questo caso.

Answer 10

Ho lavorato in un dipartimento in cui un pool comune ruotava tra attività di sviluppo e test. Ciò ha compiuto due cose:

• tester altamente qualificati ed efficienti, che nella peggiore delle ipotesi sapevano cosa stava cercando di fare il codice e come
• sviluppatori che sapevano che il loro turno stava per fare test o che erano appena tornati dai test. Quindi era noto il dolore del test del codice errato, così come il piacere del test del buon codice.

Il ragazzo più rispettato di tutto il gruppo era uno spietato tester e, durante lo sviluppo, avrebbe prodotto software a zero difetti.