Projectmanager vraagt om volledig 100% vertrouwen telkens als ik code

Hoe moet ik in dit geval op zijn vraag reageren, zonder dat het lijkt alsof ik onbekwaam ben? Eerlijk gezegd heb ik nooit 100% vertrouwen in de situatie, maar ik heb wel vertrouwen in mijn testmethoden. En, als ontwikkelaar weet ik ook dat het niet ongewoon is dat er later onverwachte bugs uit deze kernveranderingen voortkomen.

De projectmanager begrijpt software niet goed genoeg, en begrijpt het testen zeker niet goed genoeg. Misschien moet hij wel opgeleid worden.

Als je een professionele QA afdeling had, zou ik je vertellen dat je de QA Manager moet inschakelen om de aard van de software, de aard van de bugs en de aard van het testen uit te leggen aan deze projectmanager. Ik zou de QA Manager laten aangeven waarom het simpelweg niet mogelijk is om elke conditie te testen, en hoe het vrijgeven/niet vrijgeven een zakelijke activiteit is die wordt ondersteund door de bevindingen van het testen, maar nooit door perfecte informatie.

Misschien wilt u een exemplaar van Gerald Weinberg’s uitstekende boek “* Perfecte Software en andere illusies over het testen van **” krijgen. In hoofdstuk 3 (“Waarom niet gewoon alles testen?”), heeft Weinberg een sectie genaamd “Er zijn oneindig veel mogelijke testen.”

Hij heeft het over een achterdeur die in een zeer veilig programma is geplaatst waarbij de gewone wachtwoordbeveiliging kan worden omzeild door W te typen, gevolgd door drie spaties, dan M gevolgd door drie spaties, dan J gevolgd door precies 168 meer toetsaanslagen zonder een keer de letter L.

te gebruiken Dan schrijft hij: “Begrijpt u het nu wel? Als je niet had geraden dat het aantal tests dat nodig is om software uitputtend te testen oneindig is, of in ieder geval "een getal dat groter is dan ik in mijn leven zou kunnen uitvoeren”, dan begreep je het punt van dit hoofdstuk niet. Nu wel"

Leg aan uw Project Manager uit dat elke dag van extra testen uw vertrouwen in uw code enigszins zal verbeteren, maar dat het nooit 100% kan bereiken. Zeg hem dat u graag verder zou willen testen ten koste van uw andere productieve werk. Vraag hem dan hoeveel dagen hij nog wil dat u aan het testen bent en welk van uw andere werkzaamheden moet worden uitgesteld.

Als uw Project Manager het nog steeds niet snapt, en u zich een beetje luchthartig voelt, vraag hem dan of hij er 100% zeker van is dat elke schatting die hij publiceert precies juist is en dat u nooit de deadlines zult missen. Vraag hem of hij er 100% zeker van is dat geen enkele e-mail die hij vanaf nu tot in de eeuwigheid schrijft ooit een typefout zal hebben. Vraag hem of hij er 100% zeker van is dat hij nooit een fout zal maken - nu en in de toekomst.

Boss: Bent u er 100% zeker van dat deze oplossing geen bestaande functies zal breken of nadelige gevolgen zal hebben voor de gebruikerservaring?

Me: Nee. Aangezien we geen 100% dekkingstestpakket hebben, is er geen manier om te controleren of een codewijziging het breken van toepassingen of nadelige gevolgen zal voorkomen. Ik heb echter de volgende acties uitgevoerd om er zeker van te zijn dat het onwaarschijnlijk is dat het op een onbedoelde manier zal presteren:

• Ik heb de reikwijdte van de wijziging beperkt tot alleen de module waarop de wijziging betrekking heeft
• Ik heb de documentatie dienovereenkomstig gelezen en bijgewerkt
• Ik heb de eenheidstests voor deze module en de betrokken modules uitgevoerd - Ik heb eenheidstests gemaakt om nieuwe toegevoegde functionaliteit te controleren, en afgeschreven tests die niet langer relevant zijn als gevolg van de wijziging

Hoewel ik u niet exact 100% zekerheid kan geven, heb ik zoveel mogelijk zekerheid gegeven binnen het tijdsbestek dat naar mijn mening redelijk is voor de implementatie van deze functionaliteit. In feite heb ik al het punt bereikt dat mijn rendementen afnemen. Ik kan u nog 5 uur lang een zekerheid van 0,1% geven, maar de kans is nu al zo klein dat een dergelijke inspanning niet gerechtvaardigd is. U heeft echter de leiding over het project en het tijdsbestek, dus laat me weten hoeveel tijd ik nog moet besteden aan deze functie.

• *

Nu is de bal aan zijn hof. Als hij echt wil dat ik mijn persoonlijke inschatting verschuif van, zeg maar, 95% zeker naar 95,1% zeker voor een paar uur werk, dan kan ik dat doen.

Als hij er nog steeds onaangenaam over is, zal ik een e-mailgesprek met hem en de “eigenaar” van het project hebben over deze “100% geteste” eis, en welke middelen er volgens mij nodig zijn om eraan te voldoen.

Als ontwikkelaar test u bij UNIT de wijzigingen in uw code. Naar mijn mening (als ontwikkelaar) is dat om te controleren of er geen duidelijke fouten zijn, alles wordt gecompileerd, alle fouten zitten vast. Je hebt geen enkele manier om te weten welke scenario’s je tegenkomt als de code eenmaal live gaat (slechte data, onverwachte input, verandering in client software, de lijst is eindeloos)

Om 100% vertrouwen te hebben dat een verandering niets zal beïnvloeden, heb je een testomgeving nodig die de live-omgeving EXACTLY weerspiegelt (data, hardware, permissies, connectiviteit) en een suite van testscripts die elk afzonderlijk scenario afdekken. Dit is, zoals bekend, een vrijwel onmogelijke omgeving om te creëren om verschillende redenen

Als hij 100% vertrouwen verwacht, dan moet hij de omgeving en mankracht leveren om zijn verwachtingen

te ondersteunen Het is een beetje zoals wanneer projectmanagers en klanten vragen om dingen die toekomstbestendig zijn!

Het klinkt alsof hij een slechte gewoonte heeft. Hij stelt een vraag waarvan hij weet dat die op een bepaald niveau dom is. Maar er zit een beetje een dwangmatig element in. Mijn gok is dat hij handelt op basis van een onderliggende angst, en het stellen van een onredelijke vraag geeft hem meer controle.

In dit soort situaties probeer ik de dynamiek te verspreiden door zelfverzekerd te zijn en een beetje humor te injecteren. Als je begrijpt dat zijn vraag niet voortkomt uit redeneren, maar uit angst, dan kun je dat beter indirect aanpakken dan direct.

In dit soort situaties neem ik meestal de angst van het management weg door alle maatregelen te presenteren die ik heb genomen om de kwaliteit te waarborgen. Hij is immers de klant en hij moet weten dat je prioriteiten in lijn liggen met die van hem. Kijk eens naar deze unit tests. Kijk naar deze bewaking. Kijk hoe de code is gestructureerd om veranderingen lokaal en modulair te houden… Als je een gevoel van vertrouwen en controle overbrengt, zal het zijn angst wegnemen en kun je waarschijnlijk een rationeler gesprek voeren.

Dat is waar de kunst van deze business in het spel komt. Niet alleen “werkt het”, maar voelt de klant zich er ook goed bij.

Uiteindelijk is het echter een zakelijke relatie. Als de contractering voor u comfortabel en winstgevend is, dan is het de moeite waard om deze eigenaardigheid te accepteren. Het klinkt niet alsof hij het allemaal zo serieus neemt, gewoon een beetje volhardend. Zoals ik al zei, hij heeft een vervelende gewoonte ontwikkeld. Als hij negatief begint te reageren en de toon wordt vijandige, dan kan de balans van de zakelijke regeling het niet de moeite waard voor u maken. Maar uit uw korte beschrijving klinkt het voor mij alsof u de relatie nog steeds effectief kunt managen.

Veel mensen hebben dit beschreven als een onderwijsprobleem, en ik zeg niet dat ze het mis hebben.

Het is ook mogelijk dat het een politiek probleem is. Wat de vraag eigenlijk zou kunnen betekenen, is dat de projectmanager vrijgesproken wil worden van verantwoordelijkheid voor eventuele fouten. Hij krijgt van jou een gezworen verklaring dat hij voelt dat hij “redelijk” kan vertrouwen, dus als er iets mis gaat zegt hij dat hij alles heeft gedaan om het te voorkomen, maar jij faalde.

Dit is geen goed management en het is ook niet 100% gegarandeerd dat het hem duidelijk maakt of er problemen zijn.

Ik geef toe dat dit speculatie is van mijn kant, maar butt-covering oefeningen zijn helemaal niet ongewoon in het professionele leven en je hebt er mee te maken. Dus als dit waar is, dan is wat je moet doen om het probleem op te lossen niet alleen om de manager op te voeden dat 100% vertrouwen onmogelijk is. Je moet hem er ook van overtuigen dat een bug geen ramp is – voor hem persoonlijk of voor het bedrijf.

Dit kan bijvoorbeeld betekenen dat je voorbeelden moet geven van bugs die worden aangepakt tegen redelijke kosten en zonder dat er enige blaam treft. Het kan betekenen dat hij naar zijn eigen bedrijfscultuur moet kijken, of er iemand anders in het bedrijf is die zich opstelt om hem onrechtvaardig de schuld te geven als er iets mis gaat. Het kan ook betekenen dat er procedures moeten worden ingesteld om toekomstige bugs zo snel en goedkoop mogelijk aan te pakken. Als het bedrijf echt 100% vertrouwen had in de code, dan zouden dergelijke procedures zinloos zijn omdat het bereid zou zijn om willekeurig grote hoeveelheden geld in te zetten op het feit dat er geen toekomstige bugs zijn!

Als de ultieme sanctie, als hij (de werkgever) jou (de aannemer) vraagt om hem een zekerheid te verkopen die je niet kunt geven over je werk, en niets zal hem op dit punt van gedachten doen veranderen, dan kun je alleen maar duidelijk stellen dat je niet in staat bent om die zekerheid te geven, en dat hij welkom is om iemand anders in dienst te nemen als hij denkt dat er iemand is die dat wel kan. Dat is natuurlijk een heel eind op weg, maar je kunt net zo goed je BATNA kennen voordat je begint.

** Strikt genomen kan men er nooit 100% zeker van zijn dat een commit een programma niet breekt.**

Zelfs met alle mogelijke soorten testen (unit testing, integratie, component, systeem, handleiding, UI, fuzz, beveiliging, penetratie… noem maar op). Dit is te wijten aan een Stilleggingsprobleem . Hieronder volgt een relevant uittreksel uit de Wikipedia:

In de berekenbaarheidstheorie kan het stopprobleem als volgt worden vermeld: “Als je een beschrijving van een willekeurig computerprogramma krijgt, beslis dan of het programma klaar is met draaien of voor altijd doorgaat”. Dit staat gelijk aan het probleem om, gegeven een programma en een ingang, te beslissen of het programma uiteindelijk zal stoppen met draaien met die ingang, of voor altijd zal blijven draaien.

Alan Turing bewees in 1936 dat een algemeen algoritme om het stopprobleem voor alle mogelijke programma-inputparen op te lossen, niet kan bestaan. Een belangrijk onderdeel van het bewijs was een wiskundige definitie van een computer en programma, dat bekend werd als een Turing machine; het stopprobleem is onbeslist over Turing machines.

Als je PM waarde en stabiele voorspelbare levering belangrijk vindt, kun je hem misschien overtuigen om eens te kijken naar SCRUM raamwerk .

Anderen hebben veel interessante adviezen gegeven over hoe om te gaan met je PM. Persoonlijk zou ik adviseren om een vergadering met uw premier en het team op te zetten waar u uw processen kunt bespreken. Ik ben een groot voorstander van SCRUM, dus dit zou grotendeels gerelateerd zijn aan de SCRUM.

Ik zou proberen uit te leggen, dat een doel van 100% ongrijpbaar is. Het kan niet worden bereikt. Nooit. In het hele universum. De geschiedenis heeft veel van dit soort voorbeelden gezien, demo van de release van Windows 95 bijvoorbeeld. Lang geleden? Nou, kijk eens hoeveel rood er voortbouwt op een openbare CI-server voor open-sourceprojecten; log in als gast als je daar geen account hebt. Dus een uitkomst hiervan - software zal falen.

Ten tweede zou ik adviseren om een praktijk aan te nemen, waarbij je waarde kunt leveren, in plaats van het vertrouwen van een commit. Iets, waar klanten om geven. Iteratief, herhaaldelijk en betrouwbaar. Nu kunt u het perspectief van uw PM verschuiven van de 100%-verzekering, naar iets dat er echt toe doet. Dat wil zeggen: software is in gebruik, je product wordt beter en het team levert waarde aan de klant.

Ten derde, het zou een definitie van gedaan moeten zijn. Iets, waar een ontwikkelteam mee komt. Dit kan zijn: documentatie, implementatie, testen, kwaliteitspoorten etc. Dit is erg belangrijk, omdat je nu de subjectiviteit (dat is “ben je 100% zeker?”) kunt verschuiven naar objectiviteit (dat zijn alle bullet points van de definitie van done zijn voltooid).

Er zijn andere zeer belangrijke stappen die SCRUM promoot. Maar ze zouden de ontwikkelaars allemaal in staat stellen om dergelijke frustraties te verzachten, en hen in staat stellen om objectief kwantificeerbare resultaten te leveren, in vergelijking met subjectieve zekerheid.

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.

De waarheid is dat het een slechte beproeving is. De realiteit is dat een bedrijf dat niet wil investeren in een QA-team, slechte testen gaat krijgen. Goed testen is duur en kost tijd. Het bedrijf heeft het risico geaccepteerd door de tijd en het geld niet te autoriseren.

Zelfs een QA team kan niet garanderen dat elke mogelijkheid wordt getest omdat de mogelijke paden door een complex programma in principe oneindig zijn. Ze brengen je echter veel dichterbij dan je nu bent. Een van de redenen hiervoor is dat het onmogelijk is voor een ontwikkelaar om zijn eigen code adequaat te testen. Ze weten wat het doet, dus ze hebben de neiging om tests te ontwerpen rond wat ze denken dat het moet doen. Ze missen randgevallen, ze missen domme dingen die gebruikers doen die een dev nooit zou doen omdat ze weten hoe het werkt, ze interpreteren de eis soms verkeerd, maar al hun tests zullen hun oorspronkelijke verkeerde interpretatie weergeven. Ze missen vaak fouten in de requirement en doen wat hen gevraagd wordt om niet te doen wat ze hadden moeten doen (dit is de oorzaak van een enorm aantal bugs die pas gevonden worden nadat de feitelijke gebruikers [die maar al te vaak niet geraadpleegd worden bij het definiëren van de requirement] de software proberen te gebruiken). Ze missen effecten op onderdelen van de applicatie die ze nooit reden hebben gehad om te werken in vooral onderdelen die door specialisten worden gedaan (zoals een tabelwijziging die zinvol is voor de applicatie maar een geautomatiseerd importproces of een rapport verbreekt)

Als hij een hogere kwaliteit wil, zal hij er zowel in tijd als in geld voor moeten betalen. Zelfs met volledige QA kun je niet tot 100% komen, hoewel NASA en zijn aannemers zeker in de buurt komen. Ze geven ook een grote deal meer geld uit dan uw bedrijf uitgeeft. Zelfs dan zijn ze erin geslaagd om MARS een keer volledig te missen.

Als hij de zekerheid wil dat eventuele problemen hem geen schade toebrengen bij de klanten, praat dan over uw proces voor het testen (laat hem de lijst met testen zien die u heeft uitgevoerd.), wat u denkt dat er zou worden beïnvloed en hoe u dat hebt gecontroleerd, uw proces voor hoe u een slechte push zou terugdraaien en uw proces voor het loggen van fouten, zodat u ze zult zien voordat de meeste klanten ze opmerken. Geef hem het vertrouwen dat zelfs als er een probleem is, het kan worden opgelost. Praat over de waarde van het krijgen van de code (nieuwe functie of fix) uit snel ondeugd de extra tijd die het zou duren om meer grondig te testen. Praat over de risico’s van het niet snel eruit krijgen.

Je kunt hem ook vragen om de grondige regressietest van het systeem te leveren elke keer als je een verandering maakt, omdat het niet mogelijk is voor een dev om zijn eigen werk volledig te testen (je weet wat je aannames waren, als ze niet juist zijn, zou je dat nooit testen). Zorg ervoor dat hij weet dat hij elke pagina van de applicatie moet testen en alles wat op een pagina kan worden gedaan in elke mogelijke volgorde. Oh ja, test ook alle importen/exporten, rapporten, geautomatiseerde banen. En alle gerelateerde toepassingen die kunnen worden beïnvloed. Als hij eenmaal heeft geprobeerd om het systeem grondig te oefenen, zal hij zich realiseren waarom je die zekerheid niet kunt geven.

Een ander ding om te proberen is om hem op voorhand te vertellen dat je die garantie niet kunt geven, maar als hij toestemming geeft voor X-testuren, kun je dichter bij het maken van die garantie komen. Geef hem een gespecificeerde lijst van de extra tests en de uren die nodig zijn om elke test te ontwerpen en uit te voeren. Vertel hem welk percentage vertrouwen u zou hebben na het uitvoeren van al die tests en welk percentage vertrouwen u nu hebt.

Vertel hem trouwens hoe lang het zou duren om alle huidige unit tests die u hebt uit te voeren, ongeacht of ze gerelateerd zijn aan deze kwestie of niet. Dus als je op dit moment 1000 unit-testen hebt en elke test duurt vijf minuten om de resultaten op te stellen en uit te voeren en te evalueren, dan zou dat 83 uur zijn. Vraag hem om de toestemming om door te gaan en die tijd te besteden.

Als hij je in feite micro-manager is en over je schouder kijkt tijdens het hele proces van het bouwen van het project, dan is er een makkelijke manier om ervoor te zorgen dat je 100% vertrouwen kunt ‘garanderen’ zonder dat hij je daar later over hoeft te vertellen.

Laat hem het zelf goedkeuren

Om duidelijk te zijn, moet je dit niet als een eis stellen, maar eerder als een suggestie, dat als hij echt 100% perfecte code wil, hij moet kijken naar wat je zelf doet en elke verandering die je onderweg maakt, moet goedkeuren. Dit wil niet zeggen dat hij de code letterlijk moet lezen, maar eerder om hem in actie te zien en te bevestigen ‘ja, zo moet hij handelen’.

Als je de enige tester van je eigen code bent, is dit niet onredelijk - je bent al volledig gefocust op het project, en als hij perfectie wil, moet hij zelf de verantwoordelijkheid nemen voor die perfectie.

Ook moet je aantekeningen maken bij alles wat hij goedkeurt, zodat je later, als het onvermijdelijk breekt, kunt wijzen op je documentatie die aantoont dat hij het heeft goedgekeurd.

Als je om welke reden dan ook denkt dat dit niet goed zou gaan (bijvoorbeeld als je hem vragen om meer werk te doen iets is waarvan je al weet dat het rampzalig zou zijn), dan kun je in je rapporten alles wat je weet dat het correct werkt opschrijven, en hem 100% zekerheid geven dat, ‘binnen de grenzen van mijn testen, ik 100% vertrouwen heb in deze veranderingen’.

Helaas kunt u in de positie komen dat u een ‘baas’ heeft wiens begrip van uw werk beperkt is, wat altijd een pijn is als u probeert uit te leggen hoe foutcorrectie niet met 100% vertrouwen kan worden volgehouden. Dus om samen te vatten, je beste inzet zou kunnen zijn om gewoon het beste te doen wat je kunt, alles vast te leggen, en te laten begrijpen dat je doet wat je kunt binnen je eigen grenzen.

Nogal aardige antwoorden hier, de PM moet zeker opgeleid worden en een beetje leren over wat het betekent om software te schrijven.

Ik wil daar niets van herhalen, maar er een ander, nogal ongebruikelijk idee in gooien. Deze methode is nogal riskant en hangt sterk af van hoe hoog je reputatie is, hoe goed je vaardigheden zijn (of meer hoe ze worden waargenomen), en zowel je persoonlijkheid als die van je PM. Ik neem aan dat je hem niet verkeerd begrepen hebt, en hij bedoelt echt 100% (ik zie vaak dat mensen 100% zeggen, maar echt “doe het beste wat je kunt”)

Het werkte voor mij een keer, en dat is de enige reden dat ik het hier noem. Je bent gewaarschuwd. Dit is meestal een mogelijke manier om een PM op te voeden als alle andere middelen falen.

Soms wil een PM (of een andere manager) gewoon niet luisteren, dus moet je hem (of het team) ergens tegen een muur laten botsen om even te stoppen en na te denken. In dit scenario betekent het: Werk zo goed als je kunt, probeer zo goed als je kunt te testen. Doe je best, en zeg dan “Ja, ik ben er 100% zeker van dat dit zal werken”.

Als je extreem veel geluk hebt, zal er nooit een bug optreden en is iedereen blij; maar in werkelijkheid is wat er zal gebeuren: er is een bug. Wat ga je nu doen? Je geeft toe dat je een fout hebt gemaakt. Maak een verband met bugs en de fout om 100% zeker te zijn. Mensen zijn onvolmaakt en kunnen bugs in software maken. Mensen zijn onvolmaakt en creëren bugs in tests. Bijgevolg zijn mensen imperfect en kunnen ze “bugs creëren” in hun perceptie van 100% zeker zijn dat er geen bug is.

Presenteer dit goed, en 100% waterdicht (haha, j/k, de 100% opnieuw). Zorg ervoor dat na dit alles de boodschap die overging is “ik kan niet 100% zeker zijn van mijn testen”. Als de PM dan niet de logische stap kan maken van “Dit zal voor alle ontwikkelaars hetzelfde zijn” dan is alle hoop waarschijnlijk verloren…

Maar probeer alsjeblieft eerst andere dingen!

De belangrijkste indicator is dat dit een recente verandering is. Iets (of iemand) heeft je PM waarschijnlijk een slechte ervaring gegeven, en nu staat hij op scherp elke keer als er iets verandert. Of misschien leest hij iets in een boek of tijdschrift.

Als je de PM zijn verhaal kunt laten vertellen (misschien over zijn drankje naar keuze) dan kun je meevoelen, en kan hij ontvankelijk worden voor “innovatie” oftewel een goede software-engineering praktijk.

Dit is je kans om te praten over menselijke fouten en de manieren die deze industrie heeft gevonden om het niveau van vertrouwen in onze ontwerpen en code te verhogen. Om te praten over de compromissen in vertrouwen, kwaliteit, middelen en planning die voortkomen uit verschillende benaderingen van testen, peer code review, formele methoden (ook wel correctheid-voor-bouw).

Spreek zijn taal: Gebruik metafoor om de omvang van het probleem te illustreren. Is het 40.000 regels code? Vertel hem dat het een 600 pagina’s tellend moordmysterie is in een vreemde taal. Als je iets wilt veranderen in het midden van hoofdstuk 12, hoe zorg je er dan voor dat het niet leidt tot een breuk in de continuïteit met de rest van het verhaal?

Zoek naar buy-in op manieren om het vertrouwen in een acceptabel doelwit te vergroten binnen redelijke economische grenzen. U zult niet in staat zijn om SEI Capability Maturity Model niveau 5 van de ene op de andere dag te implementeren. Maar misschien kunt u wel van de huidige vraag naar “slaagt de geautomatiseerde regressietestsuite” en “hoe drukken we deze nieuwe eis uit in het regressietestsysteem”?

Ik zou het op de meest wiskundige manier beantwoorden, gezien het feit dat hij vraagt om een waarschijnlijkheid met 100% vertrouwen, en volledig voorbijgaat aan het effect dat statistische verdelingen zouden hebben op zo'n getal: Je zou hem 2 of 3 getallen moeten geven, met bijbehorend vertrouwen: 1 week op 90%, 2 weken op 95%, 6 maanden op 100%. Het laatste getal was een overdrijving, maar ik weet zeker dat je het punt hebt.

Zie Wikipedia’s artikel over Vertrouwensintervallen voor meer informatie.