Il Project Manager chiede la completa fiducia al 100% ogni volta che impegna il codice

Como devo responder à sua pergunta neste caso, sem parecer incompetente? Honestamente, nunca tenho 100% de confiança em todo o site, mas tenho confiança nos meus métodos de teste. E, como programador, também sei que não é invulgar que bugs inesperados surjam mais tarde a partir destas alterações centrais.

O gestor de projecto não compreende o software suficientemente bem, e certamente não compreende os testes suficientemente bem. Talvez ele precise de ser educado.

Se tivesse um Departamento de GQ profissional, eu dizia-lhe para pedir o apoio do Gestor de GQ para explicar a este Gestor de Projecto a natureza do software, a natureza dos bugs, e a natureza dos testes. Eu pediria ao QA Manager para indicar porque é que simplesmente não é possível testar todas as condições, e como o lançamento/não lançamento é uma actividade comercial auxiliada pelos resultados dos testes, mas nunca pela informação perfeita.

Pode desejar obter uma cópia do excelente livro de Gerald Weinberg “* Perfect Software and other illusions about testing **”. No capítulo 3 (“Why Not Just Test Everything?”), Weinberg tem uma secção chamada “There are a infinite number of possible tests”

Ele fala de uma porta traseira colocada num programa altamente seguro onde a protecção da palavra-passe normal poderia ser contornada digitando W seguido de três espaços, depois M seguido de três espaços, depois J seguido de exactamente mais 168 teclas sem usar uma vez a letra L.

Depois ele escreve: “Já percebeu o ponto por esta altura? Se não adivinhou que o número de testes necessários para testar exaustivamente o software é infinito, ou pelo menos "um número maior do que eu poderia correr na minha vida”, não percebeu o objectivo deste capítulo. Agora sim"

Explique ao seu Gestor de Projecto que cada dia de testes adicionais irá melhorar um pouco a sua confiança no seu código, no entanto nunca poderá chegar aos 100%. Diga-lhe que terá todo o prazer em continuar a testar à custa do seu outro trabalho produtivo. Depois pergunte-lhe quantos dias mais gostaria que passasse a testar e qual dos seus outros trabalhos deve ser adiado.

Se o seu Gestor de Projecto ainda não o tiver, e se se sentir um pouco recuado, pergunte-lhe se está 100% confiante que cada estimativa que publica está exactamente correcta e que os prazos nunca serão perdidos. Pergunte-lhe se ele está 100% confiante que nenhum e-mail que ele escreva de agora até sempre terá uma gralha. Pergunte-lhe se está 100% confiante de que nunca irá cometer um erro - agora e no futuro.

Capo: Sei sicuro al 100% che questa correzione non romperà alcuna funzionalità esistente o causerà effetti negativi sull'esperienza dell'utente?

Me: No. Dal momento che non abbiamo una suite di test di copertura al 100% non c'è modo di verificare che qualsiasi modifica del codice eviterà la rottura dell'applicazione o gli effetti negativi. Tuttavia, ho eseguito le seguenti azioni per garantire che sia improbabile che si verifichi in modo non intenzionale:

• Ho limitato la portata della modifica al solo modulo che interessa
• Ho letto e aggiornato la documentazione di conseguenza
• Ho eseguito i test unitari per questo modulo e per i moduli interessati
• Ho creato test unitari per verificare le nuove funzionalità aggiunte, e test deprecati non più rilevanti a causa della modifica

Mentre non posso darvi esattamente il 100% di garanzia, ho fornito quanta più garanzia possibile entro il tempo che ritengo ragionevole per l'implementazione di questa funzionalità. In realtà ho già raggiunto il punto di diminuire i rendimenti. Posso dedicare altre 5 ore per darvi un'altra garanzia dello 0,1%, ma è già una probabilità talmente bassa che un tale sforzo non è giustificato. Comunque, lei è responsabile del progetto e dei tempi, quindi mi faccia sapere quanto tempo ancora dovrei dedicare a questa funzione.

Ora la palla è nel suo campo. Se vuole davvero che io sposti la mia stima personale da, diciamo, 95% sicuro al 95,1% sicuro per qualche ora di lavoro in più, allora ehi - posso farlo.

Se continua ad essere odioso a riguardo, avrò una conversazione via email con lui e con il “proprietario” del progetto su questo requisito “100% testato”, e quali risorse credo siano necessarie per soddisfarlo.

Come sviluppatore, state testando le modifiche al vostro codice da parte della UNIT. Secondo me (come sviluppatore), cioè per controllare che non ci siano errori evidenti, tutto si compila, tutti gli errori sono intrappolati. Non hai modo di sapere quali scenari si incontreranno una volta che il codice sarà attivo (dati cattivi, input inattesi, cambiamenti nel software client, la lista è infinita)

Per avere la certezza al 100% che un cambiamento non influirà su nulla, avresti bisogno di un ambiente di test che rispecchi l'ambiente live ESATTAMENTE (dati, hardware, permessi, connettività) e di una suite di script di test che coprano ogni singolo scenario. Questo, come è noto, è un ambiente virtualmente impossibile da creare per vari motivi

Se si aspetta il 100% di fiducia, allora deve fornire l'ambiente e la manodopera per sostenere le sue aspettative

È un po’ come quando i project manager e i clienti chiedono che le cose siano a prova di futuro!

Sembra che sia caduto in una cattiva abitudine. Sta facendo una domanda che sa che, a un certo livello, è stupida. Ma c'è un elemento un po’ compulsivo. La mia ipotesi è che stia agendo su un'ansia di fondo, e fare una domanda irragionevole lo fa sentire più in controllo.

In questo tipo di situazioni cerco di diffondere la dinamica essendo fiducioso e iniettando un po’ di umorismo. Se capisci che la sua domanda non proviene dal ragionamento, ma dall'ansia, allora puoi affrontarla meglio indirettamente che direttamente.

In situazioni come questa, di solito placo i timori del management presentando tutte le misure che ho adottato per garantire la qualità. Dopotutto è il cliente, e ha bisogno di sapere che le vostre priorità sono in linea con le sue. Guardate questi test unitari. Guardate questo monitoraggio. Guardate come il codice è strutturato per mantenere i cambiamenti locali e modulari. ecc. Se trasmettete un senso di fiducia e di controllo, questo allevierà la sua ansia e probabilmente sarete in grado di avere una conversazione più razionale.

È qui che entra in gioco l'arte di questo business. Non solo “funziona”, ma fa sentire bene il cliente.

In definitiva, però, è un rapporto d'affari. Se l'accordo contrattuale è comodo e redditizio per voi, allora vale la pena sopportare questa mania. Non sembra che sia così serio, solo un po’ insistente. Come ho detto, ha sviluppato un'abitudine fastidiosa. Se comincia a reagire negativamente e il tono diventa più ostile, allora l'equilibrio dell'accordo commerciale potrebbe renderlo inutile per voi. Ma dalla tua breve descrizione, mi sembra che tu possa ancora gestire il rapporto in modo efficace.

Molte persone hanno descritto questo come un problema educativo, e non sto dicendo che si sbagliano.

È anche possibile che sia un problema politico. Quello che la domanda potrebbe in realtà significare, è che il project manager vuole essere esonerato dalla responsabilità di eventuali errori. Riceve da lei una dichiarazione giurata su cui ritiene di poter “ragionevolmente” fare affidamento, quindi se qualcosa va male dice che ha fatto tutto il possibile per evitarlo ma lei ha fallito.

Questa non è una buona gestione e non è nemmeno garantito al 100% di metterlo al sicuro se si verificano dei problemi.

Ammetto che questa è una speculazione da parte mia, ma gli esercizi per coprire il culo non sono affatto rari nella vita professionale e bisogna affrontarli. Quindi, se questo suona vero, allora quello che bisogna fare per risolvere il problema non è solo educare il manager che la fiducia al 100% è impossibile. Bisogna anche convincerlo che un bug non è un disastro - per lui personalmente o per l'azienda.

Questo potrebbe significare, ad esempio, fornire esempi di bug che vengono affrontati a costi ragionevoli e senza colpe. Potrebbe significare guardare alla sua cultura aziendale, se c'è qualcun altro nell'azienda che si prepara ad addossargli un'ingiusta colpa se qualcosa va storto. Potrebbe anche significare mettere in atto procedure per affrontare i futuri bug nel modo più rapido ed economico possibile. Se l'azienda fosse davvero sicura al 100% del codice, allora tali procedure sarebbero inutili perché sarebbe disposta a scommettere somme di denaro arbitrariamente elevate sul fatto che non ci siano futuri bug!

Come sanzione finale, se lui (il datore di lavoro) chiede a voi (l'appaltatore) di vendergli una garanzia che non potete dare sul vostro lavoro, e nulla gli farà cambiare idea su questo punto, allora tutto quello che potete fare è dichiarare chiaramente che non siete in grado di fornire tale garanzia, e che è il benvenuto ad assumere qualcun altro se pensa che ci sia qualcuno in grado di farlo. Naturalmente è una strada lunga, ma tanto vale che tu conosca il tuo BATNA prima di iniziare.

In senso stretto, non si può mai essere sicuri al 100% che un commit non rompa un programma.

Anche con tutti i tipi di test possibili (test di unità, integrazione, componente, sistema, manuale, interfaccia utente, fuzz, sicurezza, penetrazione… si fa un nome). Ciò è dovuto ad un Problema di arresto . Segue un estratto rilevante della Wikipedia:

Nella teoria della computabilità, il problema dell'arresto può essere dichiarato come segue: “Data la descrizione di un programma per computer arbitrario, decidere se il programma finisce di funzionare o continua a funzionare per sempre”. Ciò equivale al problema di decidere, dato un programma e un input, se il programma si fermerà quando viene eseguito con quell'input, o continuerà a funzionare per sempre.

Alan Turing ha dimostrato nel 1936 che non può esistere un algoritmo generale per risolvere il problema dell'arresto per tutte le possibili coppie programma-input. Una parte fondamentale della prova era una definizione matematica di un computer e di un programma, che divenne nota come macchina di Turing; il problema dell'arresto è indecidibile sulle macchine di Turing.

Se il vostro PM si preoccupa del valore e della consegna stabile e prevedibile, potete forse convincerlo a dare un'occhiata a SCRUM framework .

Altri hanno dato molti consigli interessanti su come interagire con il vostro PM. Personalmente, vi consiglierei di organizzare un incontro con il vostro PM e con il team dove potrete discutere dei vostri processi. Sono fortemente a favore della SCRUM, quindi questo sarebbe in gran parte legato alla SCRUM.

Proverei a spiegare, che un obiettivo del 100% è sfuggente. Non può essere raggiunto. Mai. In tutto l'universo. La storia ha visto molti esempi di questo tipo, demo del rilascio di Windows 95 per esempio. Molto tempo fa? Beh, vedi quanti build rossi su un server CI pubblico per progetti open source; effettua il login come ospite se non hai un account lì. Quindi un risultato di questo - il software fallirà.

Secondo, consiglierei di adottare una pratica, in cui si può fornire valore, invece della fiducia di un commit. Qualcosa a cui i clienti tengano. Iterativamente, ripetutamente e in modo affidabile. Ora, potete spostare il punto di vista del vostro PM dalla sicurezza al 100% a qualcosa che conta davvero. Cioè: il software è in uso, il vostro prodotto sta migliorando e il team fornisce valore al cliente.

In terzo luogo, la definizione di “fatto” dovrebbe essere una definizione di “fatto”. Qualcosa che viene fuori da un team di sviluppo. Questo può includere: documentazione, implementazione, test, test, cancelli di qualità, ecc. Questo è molto importante, poiché ora è possibile spostare la soggettività (cioè “sei sicuro al 100%?”) a obiettività (cioè tutti i punti chiave della definizione di fatto sono completati).

Ci sono altri passi molto importanti che SCRUM promuove. Ma tutte queste misure consentirebbero agli sviluppatori di mitigare tale frustrazione, e permetterebbero loro di fornire risultati oggettivamente quantificabili, rispetto alla certezza soggettiva.

La risposta abituale per questo tipo di obiettivo è la revisione tra pari e il test di regressione.

1) Non impegnate nulla nel flusso di codice di produzione fino a quando non solo l'autore, ma anche uno o più altri programmatori, non l'hanno controllato per assicurarsi che cambi solo ciò che è necessario, che soddisfi tutti i criteri concordati per una buona pratica di codifica, che venga fornito con un test che vi dia una probabilità decente di rilevare se un cambiamento successivo rompe di nuovo la logica, e così via.

2) Non impegnate nulla nel flusso di codice di produzione fino a quando TUTTI i test di regressione non sono stati rieseguiti ed è stato dimostrato che non rompe nulla per cui il test è stato eseguito. Se si verifica un qualsiasi guasto durante quel test, la modifica deve essere fatta marcia indietro fino a quando non si può stabilire chiaramente che non ha causato il problema.

3) Alfa e beta-test precocemente e spesso con scenari reali del cliente. I clienti faranno con il vostro codice cose che non vi sareste mai aspettati.

Nessuno di questi è al 100%, né la loro combinazione. Ma vi avvicinano notevolmente. Richiedono un investimento non banale di risorse aggiuntive. Rallentano lo sviluppo rispetto agli skunkworks “fatelo e lo sistemeremo quando si rompe” la pratica della codifica. Ma se si vuole davvero un codice privo di bug, riconoscere che gli esseri umani sono fallaci e mettere in atto pratiche per aiutare a catturare i fallimenti prima che raggiungano i clienti può valere più di quei costi.

Mi è stato detto che non c'è stato never un bug riportato nel codice che IBM ha scritto per la NASA – perché è stato revisionato e testato a morte durante la progettazione, durante lo sviluppo e prima di essere rilasciato.

Se si sta facendo qualcosa di fondamentale per la vita, vale ovviamente la pena di investire. Se stai facendo qualcosa che è un'infrastruttura per grandi aziende, vale l'investimento; non vuoi essere quello il cui bug abbatte i processi di business di un'azienda da un miliardo di dollari.

Sì, fa impazzire i buoni programmatori. Fino alla prima volta che si salva il loro didietro.

La verità è che si tratta di una prova scarsa. La realtà è che un'azienda non disposta a investire in un team di QA avrà dei test scadenti. Un buon test è costoso e richiede tempo. L'azienda ha accettato il rischio non autorizzando il tempo e il denaro.

Neanche un team di QA può garantire che ogni possibilità sia testata perché i percorsi possibili attraverso un programma complesso sono fondamentalmente infiniti. Tuttavia, vi porteranno molto più vicino di quanto non lo siate ora. Uno dei motivi è l'impossibilità per uno sviluppatore di testare adeguatamente il proprio codice. Sanno cosa fa, quindi tendono a progettare test intorno a ciò che pensano debba fare. Si perdono i casi limite, si perdono le cose stupide che gli utenti fanno che uno sviluppo non farebbe mai perché sanno come funziona, a volte interpretano il requisito in modo errato, ma tutti i loro test rifletteranno la loro interpretazione originale errata. Spesso mancano errori nel requisito e fanno quello che gli viene chiesto di fare, ma non quello che avrebbero dovuto fare (questa è la causa di un numero enorme di bug che si trovano solo dopo che gli utenti reali [che troppo spesso non vengono consultati nella definizione del requisito] provano ad usare il software). Mancano gli effetti sulle parti dell'applicazione che non hanno mai avuto motivo di lavorare, in particolare le parti che sono fatte da specialisti (come un cambio di tabella che ha senso per l'applicazione ma che interrompe un processo di importazione automatizzato o un rapporto.)

Se vuole una qualità superiore dovrà pagarla sia in tempo che in denaro. Anche con un QA completo non si può arrivare al 100%, anche se certamente la NASA e i suoi appaltatori ci vanno vicini. Essi spendono anche un grande affare più denaro di quanto la vostra azienda stia spendendo. Anche allora, sono riusciti a mancare completamente MARS una volta.

Se quello che vuole è la garanzia che qualsiasi problema non gli causerà danni con i clienti, allora parlagli del tuo processo per i test (Mostragli l'elenco dei test che hai eseguito.), di cosa pensi che ne risentirebbe e di come li hai controllati, del tuo processo per come potresti invertire una cattiva spinta e del tuo processo per la registrazione degli errori in modo che li vedrai prima che la maggior parte dei clienti se ne accorga. Dagli la certezza che anche se c'è un problema, può essere risolto. Parlate del valore di ottenere il codice (nuova funzione o correzione) in modo rapido e veloce, per evitare il tempo supplementare che ci vorrebbe per testarlo in modo più approfondito. Parlate dei rischi di non riuscire a tirarlo fuori rapidamente.

Potete anche chiedergli di fornire il test di regressione completo del sistema ogni volta che fate un cambiamento, perché non è possibile per uno sviluppatore testare completamente il proprio lavoro (sapete quali sono le vostre ipotesi, se non sono giuste, non lo verifichereste mai). Assicuratevi che sappia che dovrà testare ogni singola pagina dell'applicazione e ogni singola cosa che potrebbe essere fatta su una pagina in ogni ordine possibile. Oh sì, testare anche le importazioni / esportazioni, i rapporti, i lavori automatizzati. E tutte le applicazioni correlate che potrebbero essere interessate. Una volta che avrà provato ad esercitare a fondo il sistema una volta, si renderà conto del perché non si può fare quella garanzia.

Un'altra cosa da provare è dirgli in anticipo che no non si può fare quella garanzia, ma se lui autorizza X ore di test, ci si può avvicinare a fare quella garanzia. Dategli un elenco dettagliato dei test aggiuntivi e delle ore necessarie per progettare ed eseguire ognuno di essi. Ditegli quale percentuale di fiducia avreste dopo aver eseguito tutti questi test e quale percentuale di fiducia avete in questo momento.

Per questo motivo ditegli quanto tempo ci vorrebbe solo per eseguire tutti i test unitari attuali che avete, indipendentemente dal fatto che siano o meno legati a questo problema. Quindi, se attualmente avete 1000 test unitari e ognuno di essi richiede cinque minuti per impostare ed eseguire e valutare i risultati che sarebbero 83 ore. Chiedetegli l'autorizzazione ad andare avanti e a spendere quel tempo.

Se lui vi sta di fatto microgestire e vi guarda alle spalle durante tutto il processo di costruzione del progetto, c'è un modo semplice per assicurarsi che possiate ‘garantire’ la vostra fiducia al 100% senza che lui ve ne parli in seguito.

Faglielo approvare lui stesso

Per essere chiari, non dovreste fare questo come una richiesta, ma piuttosto come un suggerimento, che se lui vuole veramente un codice perfetto al 100%, allora dovrebbe guardare quello che state facendo lui stesso e approvare ogni cambiamento che state facendo lungo la strada. Questo non significa che dovrebbe letteralmente leggere il codice, ma piuttosto vederlo in azione e confermare “sì, è così che dovrebbe agire”.

Se sei l'unico tester del tuo codice, questo non è irragionevole - sei già completamente concentrato sul progetto, e se vuole la perfezione, dovrebbe assumersi la responsabilità di assicurare la perfezione lui stesso.

Inoltre, prendi nota di tutto ciò che approva, in modo che più tardi, quando inevitabilmente si rompe, puoi indicare la tua documentazione che dimostra che l'ha approvata.

Se, per qualsiasi motivo, pensate che questo non andrebbe bene (per esempio, se chiedergli di fare più lavoro è qualcosa che già sapete che sarebbe disastroso), tutto quello che potete fare in realtà è fare più test di errore possibile, scrivere nei vostri rapporti tutto quello che sapete che funziona correttamente, e dargli la garanzia al 100% che, “entro i limiti dei miei test, sono fiducioso al 100% in questi cambiamenti”.

Purtroppo, potreste essere nella posizione di avere un ‘capo’ la cui comprensione del vostro lavoro è limitata, il che è sempre un dolore quando si cerca di spiegare come la correzione degli errori sia impossibile da mantenere con il 100% di fiducia. Quindi, per riassumere, la vostra migliore possibilità potrebbe essere quella di fare il meglio che potete, registrare tutto, e far capire che state facendo ciò che potete entro i vostri limiti.

Qui ci sono delle belle risposte, il Primo Ministro ha decisamente bisogno di essere educato e di imparare un po’ cosa significa scrivere software.

Non voglio ripetere nulla di tutto ciò, ma buttarci dentro un'altra idea piuttosto insolita. Questo metodo è piuttosto rischioso e dipende molto da quanto è alta la vostra reputazione, da quanto sono buone le vostre capacità (o meglio da come sono percepite), e sia la vostra personalità che quella del vostro PM. Presumo che tu non l'abbia frainteso, e lui intende davvero il 100% (spesso vedo gente che dice 100%, ma in realtà significa “fai il meglio che puoi”)

Ha funzionato per me una volta, e questa è l'unica ragione per cui ne parlo qui. Siete stati avvertiti. Questo è per lo più un modo possibile per educare un PM se tutti gli altri mezzi falliscono.

A volte, un PM (o qualsiasi altro manager) non vuole ascoltare, quindi devi fare in modo che da qualche parte lo faccia (o il team) sbattere contro un muro per fermarsi un attimo a pensare. In questo scenario significa: Lavorate il più possibile, cercate di testare il più possibile. Date il meglio di voi stessi e poi dite: “Sì, sono sicuro al 100% che funzionerà”.

Se siete estremamente fortunati, non si verificherà mai nessun bug e tutti sono contenti; ma in realtà quello che succederà è: c'è un bug. Cosa farete ora? Ammetti di aver commesso un errore. Fai un collegamento con i bug e l'errore di essere sicuro al 100%. Gli esseri umani sono imperfetti e possono creare bug nel software. Gli umani sono imperfetti e creano bug nei test. Di conseguenza, gli esseri umani sono imperfetti e possono “creare bug” nella loro percezione di essere sicuri al 100% che non ci sia nessun bug.

Presentate questo pozzo, e a tenuta stagna al 100% (haha, j/k, di nuovo il 100%). Assicuratevi che dopo tutto questo, il messaggio che è andato oltre è “Non posso essere sicuro al 100% nei miei test”. Se il PM non riesce a fare il passo logico di “Questo sarà lo stesso per tutti gli sviluppatori” allora tutte le speranze sono probabilmente perse…

Ma per favore, provate prima altre cose!

L'indicatore chiave è che si tratta di un cambiamento recente. Qualcosa (o qualcuno) ha probabilmente dato al vostro PM una brutta esperienza, e ora è nervoso ogni volta che qualcosa cambia. O forse ha letto qualcosa in un libro o in una rivista.

Se riuscite a farvi raccontare la sua storia dal PM (forse a causa della sua bevanda preferita) allora potete simpatizzare, e lui potrebbe diventare ricettivo all’“innovazione”, ovvero una sana pratica di software-engineering.

Questa è la vostra occasione per parlare dell'errore umano e dei modi che questa industria ha trovato per aumentare i livelli di fiducia nei nostri progetti e nel nostro codice. Per parlare dei compromessi in termini di fiducia, qualità, risorse e tempi che derivano da diversi approcci ai test, alla revisione del codice tra pari, ai metodi formali (alias correttezza per costruzione).

Parla il suo linguaggio: Usa la metafora per illustrare la dimensione del problema. Sono 40.000 linee di codice? Digli che è come un giallo di 600 pagine in una lingua straniera. Se vuoi cambiare qualcosa a metà del capitolo 12, come ti assicuri che non causi una rottura di continuità con il resto della storia?

Cerca di trovare il modo di aumentare la fiducia verso un obiettivo accettabile entro limiti economici ragionevoli. Non riuscirete ad implementare il SEI Capability Maturity Model livello 5 da un giorno all'altro. Ma si potrebbe passare dalla domanda attuale a “la suite di test di regressione automatica passa?” e “come si esprime questo nuovo requisito nel sistema di test di regressione?

Risponderei nel modo più matematico possibile, considerando che chiede una probabilità con una confidenza del 100%, e ignorando completamente l'effetto che le distribuzioni statistiche avrebbero su tale numero: dovreste dargli 2 o 3 numeri, con la confidenza associata: 1 settimana al 90%, 2 settimane al 95%, 6 mesi al 100%. L'ultimo numero era un'esagerazione, ma sono sicuro che hai capito il punto.

Vedi l'articolo di Wikipedia su Confidence Intervals per ulteriori letture.