Feeds:
Berichten
Reacties

Archive for februari, 2007

Een van de tools die je in mijn special report leert is de process behaviour chart.

Wat is een process behaviour chart?

De process behaviour chart is rond 1920 door Dr. Walter Shewart bedacht en wordt gebruikt om onderscheid te kunnen maken tussen natuurlijk en bijzondere oorzaken van variatie in processen.

Elk proces heeft een zekere mate van variatie. Wanneer je 10 programmeurs hetzelfde probleem voorlegt zullen ze verschillend presteren. Met andere woorden: niet iedereen zal even veel of weinig fouten maken en niet iedereen zal er even lang of kort over doen. Zelfs wanneer ze een gelijkwaardige opleiding en ervaring achter de rug hebben.

En nu komt het.

Deze variatie in prestaties heeft 2 oorzaken: natuurlijke oorzaken en bijzondere oorzaken en dit onderscheid is cruciaal om je proces te kunnen verbeteren.

Waarom?

Bijzondere oorzaken van variatie maken je proces onbeheersbaar en dit is synoniem met onvoorspelbaar. Voor een onvoorspelbaar proces kun je geen betrouwbare planning maken. En harder werken heeft geen zin. Onvoorspelbaar betekent dat je geen controle over je proces hebt: hoe hard of hoe lang je ook werkt.

Wanneer planningen niet gehaald worden heeft het waarschijnlijk hiermee te maken. Komt het vaker voor dat planningen niet kloppen of gaandeweg moeten worden bijgesteld dan is dit met zekerheid de oorzaak. Hetzelfde geldt voor de kwaliteit van de output (in dit geval de software) en de kosten.

Natuurlijke oorzaken van variatie geven aan dat je je proces onder controle hebt en dat je prestaties voorspelbaar zijn. Maar vergis je niet. Voorspelbaar wil niet zeggen dat je tevreden c.q. gelukkig hoeft te zijn met de prestaties die je proces in staat is te leveren.

Welke zijn de consequenties van variatie?

  1. een proces met natuurlijke oorzaken van variatie kun je verbeteren
  2. een proces met bijzondere oorzaken van variatie kun je nog NIET verbeteren

De strategie die je volgt om je softwareproces te verbeteren is afhankelijk van de oorzaken van variatie. Heb je te maken met bijzondere oorzaken van variatie dan kun je maar een ding doen: deze oorzaken een-voor-een elimineren om je proces weer onder controle te krijgen.

Heb je echter te maken met natuurlijke oorzaken van variatie dan is er een verandering in je proces aan de orde. De meest gevolgde strategie is in dit geval dat onderdeel van je proces dat de meeste problemen veroorzaakt aan te pakken.

Samenvattend: process behaviour charts bestaan al bijna 100 jaar en zijn het meest effectieve en meest beproefde tool voor het verbeteren van processen. Jammer genoeg worden ze niet of nauwelijks toegepast in de software/IT industrie.

Wat hier ook de oorzaak van moge zijn, het is de hoogste tijd hier iets aan te veranderen. Mijn special report kan hier de eerste aanzet toe geven.

Dit is wat de Jappaners zo succesvol hebben gemaakt en ook Six Sigma maakt op grote schaal van process behaviour charts gebruik. Je ondermijnt ernstig je kansen op succes wanneer je probeert te verbeteren zonder kennis te hebben of gebruik te maken van dit tool.

Kies je er toch voor process behaviour charts te negeren, dan loop je het risico voor de verkeerde verbeter strategie te kiezen en de grootst mogelijk blunder te begaan die in process management mogelijk is, namelijk: natuurlijke en bijzondere oorzaken van variatie met elkaar te verwarren.

In mijn special report ga ik uiteraard dieper in op het hoe en wat van de pbc.
Zo geef ik je stap voor stap instructies om zelf een pbc te construeren en vertel ik je hoe je natuurlijke van bijzondere oorzaken van variatie van elkaar onderscheidt.

Tot meer proces controle,
“Black Belt” Kelly
Coherent Systems
kwg@coherentsystems.nl

Read Full Post »

Gister heb ik je verteld dat mijn boek:

Zijn software ontwikkelaars uit India nu werkelijk zo goed
of beschikken ze over kennis waar wij geen toegang toe hebben?

dat later deze week uitkomt.

Wat dit boek zo bijzonder maakt is dat het enkele critische onderwerpen m.b.t. software engineering aan de orde stelt en afrekent met een aantal mythen die je kansen op succes ondermijnen.

Het benadert software engineering vanuit een niet-traditionele hoek die de traditie op haar kop zet en software engineering voor altijd zal veranderen.

Dit boek is bestemd voor:

  1. iedereen die leiding geeft aan software/IT projecten c.q. organisaties
  2. software ontwikkelaars die hun effectiviteit willen verdubbelen
  3. quality professionals die verantwoorelijk zijn voor de kwaliteit van software c.q. het softwareproces
  4. iedereen die betere prestaties van software/IT verwacht

 

 

Morgen heb ik meer niews. Tot dan.

“Black Belt” Kelly
Coherent Systems
kwg@coherentsystems.nl

Read Full Post »

Vandaag geen nieuw artikel, maar een aankondiging.
En deze is bestemd voor alle bezoekers van mijn blog en het gaat over een boek dat ik net af heb.

Is dit boek interessant voor jou?

Misschien wel, misschien niet.

Als je in de ICT werkzaam bent, tevreden met je huidige prestaties en het liefst alles bij het oude laat, dan is dit boek definitief niet voor jou.

Ben je echter bij het ontwikkelen van software betrokken, geef je leiding aan softwareprojecten, verantwoordelijk voor het verbeteren van het softwareproces of de kwaliteit van software en sta je open voor nieuwe ideeen, dan is mijn boek zeker de moeite waard.

Laat me je in het kort vertellen waarom.

Dit is eigenlijk geen boek in de traditionele zin, maar een 90 dagen plan om je te helpen:

  1. een doorslaggevende bijdrage te leveren aan het succes en de winstgevendheid van je bedrijf of je opdrachtgever
  2. meer te presteren met minder stress en minder inspanning

Te mooi om waar te zijn?

Ik kan me een dergelijke reactie voorstellen en ik heb daar een antwoord op.

Dit antwoord en alle informatie omtrent dit boek vind je vanaf maandag hier.

Tot dan.

Black Belt Kelly
Coherent Systems
kwg@coherentsystems.nl

Read Full Post »

In mijn vorige blog heb ik het er over gehad dat quality assurance zich richt op het voorkomen van defecten en dus ook op het minimaliseren van testen. Immers minder defecten, betekent minder testen.
Ik heb je toen ook beloofd dieper in te gaan op de toepassing van QA iun software. So, here we go!

Het zal je niet verbazen wanneer ik je vertel dat specificaties de zwakste schakel en de meest onzekere factor vormen in software engineering en het succes van je softwareprojecten kunnen maken of breken.

 

En hierin ligt de sleutel: complete en correcte specificaties.

Yep, that’s it.

Ik heb enige jaren terug de term adecurate specificaties hiervoor bedacht. Adecuraat is een samenvoeging van adequaat (voldoende) en accuraat (correct). Dit zijn de twee belangrijkste eisen die aan specificaties gesteld moeten worden. Want laten we eerlijk zijn: het is onmogelijk een goed systeem te ontwikkelen met incorrecte c.q. inadequate specificaties of specificaties die tijdens de uitvoering van een project worden aangevuld c.q. gecorrigeerd. En er bestaat, voor zover ik weet, nog geen tool of programmeur die van incorrecte c.q. onvolledige specificaties het gewenste systeem kan engineeren.

Maar is het dan mogelijk specificaties 100% correct en 100% compleet te krijgen?

Nee, dat zal nooit lukken, want ook informatici zijn mensen. Maar het is wel mogelijk zowel het specificatiesproces als het resultaat van dit proces aanzienlijk te verbeteren als je maar weet hoe.
Dit is exact wat ik je zo dadelijk zult leren.

Laten we eerst even samenvatten wat je tot nog toe geleerd hebt:

  • QA is gericht op het voorkomen van defecten
  • hoe minder defecten des te minder hoef je te testen
  • de vereiste testinspanning is een goede indicatie voor de aan- of afwezigheid van QA

Kun je je nog de kwaliteitsmeter uit mijn vorige blog herinneren? Wat daaruit naar voren komt is de relatie tussen QA en QC. Deze relatie behelst dat je niet aan QA kunt beginnen alvorens je QC hebt geimplementeerd. Om concreter te zijn betekent dit dat je 3-sigma controle over je proces, in dit geval je softwareproces, hebt. Is dit het geval dan is je proces nog niet rijp voor QA. Je doet er in dit geval beter aan een stap terug te doen en eerst met QC te beginnen.

Dit is een keiharde eis waar je niet aan ontkomt.

Laten we nu dieper ingaan op wat adecurate specificaties inhouden.

Laat me beginnen met vast te stellen dat ik niet pretendeer dat er zoiets als volmaakte specificaties bestaan. Wat ik claim is dat het mogelijk is met aanzienlijk betere (=completere + correctere) specificaties voor de dag te komen. En dat het mogelijk is je proces zo in te richten dat je tekortkomingen in de specificaties bijna uitsluit of anders vrijwel direct identificeert en corrigeert. Dat is wat echte QA inhoudt. En daar wordt iedereen beter van.

Eén van de grootste fouten die we project na project maken is aannemen dat gebruikers precies weten wat ze willen. Dit zou dan betekenen dat ze hun situatie grondig hebben geanalyseerd en precies weten welke mogelijkheden IT hen biedt. Het traditionele softwareproces is ook op deze aanname gebaseerd. Het zal je nu niet meer verbazen dat ik deze aanname sterk in twijfel trek.Bovendien moet software voldoen aan de specificaties die gelden NA oplevering van het systeem.

Gebruikers kunnen je alleen vertellen wat ze gister en vandaag deden, maar niet wat ze na oplevering van het systeem zullen (moeten) doen.

Een andere misvatting is dat de persoon die de gebruiker interviewt precies weet welke vragen hij moet stellen en …. precies weet wanneer de laatste vraag gesteld is. Deze veronderstelling moet ook onjuist zijn. Hoe is het anders te verklaren dat tijdens de uitvoering van een project nog nieuwe specificaties boven water komen? Sterker; zelfs tijdens het testen worden er nog nieuwe specificaties geformuleerd. En wat te zeggen van alle incidenten tijdens de eerste twee maanden na uitrol?

Mijn ervaringen de afgelopen 30 jaar in meer dan 50 organisaties in 7 landen (incl. Japan en Amerika) op 4 continenten en een kleine 100 projecten hebben mij anders geleerd.

Ik claim dat adecurate specificaties het resultaat zijn van een ontdekproces en veel minder van een interviewproces.

Laat me dit toelichten.

Soorten specificaties

Om je klant c.q gebruikers tevreden te stellen en hun verwachtingen te overtreffen veronderstelt dat je een diep inzicht hebt in wat ze willen en hoe het vervullen van hun wensen hun tevredenheid beinvloed.

Dit kun je allen maar wanneer je je bewust bent van het feit dat er twee groepen specificaties bestaan.

  1. de impliciete en
  2. de expliciete specificaties

Laten we met de tweede groep beginnen want deze ligt het meest voor de hand. Dit zijn de specificaties waar de gebruiker en de interviewer zich van “bewust” zijn en die in het interview aan bod komen.

Met de eerste groep is het wat lastiger, want deze ligt minder voor de hand en daarom komen ze in het interview niet aan bod. Om het nog complexer te maken. Deze groep kan weer onderverdeeld worden in drie subgroepen:

  • de vanzelfsprekende,
  • de toekomstige en
  • de attractieve specificaties

Zoals de naam van aangeeft zijn de vanzelfsprekende specificaties voor de gebruiker zo vanzelfsprekend dat ze er niet op komt ze in het interview ter sprake te brengen. Ze gaat er van uit dat de interviewer die immers de expert is en het verloop van het interview dicteert wel weet dat deze specificaties bij het systeem horen. Zelfs wanneer een samenvatting van het interview naar de geinterviewde wordt gestuurd gaat er geen lampje branden. Dat is typerend voor deze subgroep.

De toekomstige specificaties zijn de specificaties die zullen gelden na opleveren van het systeem. De gebruikers van je systeem weten wat ze vandaag doen, maar hebben geen notie van wat ze morgen nodig zullen hebben. Zo kijken ze niet tegen hun werk aan. Wanneer je ze dus interviewt vertellen ze je wat ze in het verleden deden. Jij bouwt echter aan een systeem dat moet voldoen aan de eisen die gelden NA oplevering van het systeem.Begin je nu de omvang van het probleem te onderkennen?

De attractieve specificaties zijn specificaties die de gebruiker niet kan weten, want dat zijn oplossingen voor problemen waar ze zich niet eens van bewust zijn of elegante toepassingen van de technologie waardoor ze dingen kunnen die ze vroeger niet konden.

De samenhang tussen specificaties en tevredenheid van de gebruiker

Vervulling van de expliciete specificaties leidt tot wat ik zou willen noemen evenredige tevredenheid.

Dit wil zeggen dat de tevredenheid toeneemt naarmate er meer expliciete specificaties worden vervuld en afneemt naarmate er minder worden vervuld. Ontbrekende expliciete specificaties worden vrij snel ontdekt en kunnen eenvoudig worden aangepast.

Het vervullen van de toekomstige specificaties zal de gebruiker je niet al te sterk aanrekenen, omdat niet van je geëist kan worden dat je ze wist. Ze weten ook dat het om dingen gaat die ze niet gevraagd hebben. Het verhelpen van ontbrekende toekomstige specificaties kan daarom met recht tot
onderhoud gerekend worden.

Het niet vervullen van de vanzelfsprekende specificaties is een regelrechte ramp en leidt tot ernstige ontevredenheid. Heb je wel eens een gebruiker horen klagen dat ze het systeem niet kan gebruiken?
Dan heb je met deze subgroep van doen. Het nare is dat het tot de confrontatie van de gebruiker met
het systeem duurt voordat het aan het licht treedt dat ze ontbreken.Dit is buitengewoon tragisch, omdat het alsnog honoreren van deze subgroep een “pijnlijk” proces is in de zin van bewerkelijk en duur.
Bovendien kan het systeem niet live, zolang dit euvel niet is opgelost.

Vanzelfsprekende specificaties kun je niet via reguliere interviews vastleggen enze maken of breken het succes van je project. Toch er is geen enkele voorziening in het traditionele softwareproces om hier verbetering in aan te brengen.

Voor zover ik objectief kan oordelen en het kan overzien is Quality Function Deployment het enige quality management systeem met voorzieningen en een complete toolset om zowel toekomstige als vanzelfsprekende specifdicaties te ontdekken.

QFD wordt sinds 1982 met indrukwekkende resultaten in Japan gebruikt om software te ontwikkelen en sinds 1992 in Amerika.

Om je een beeld te geven van de kracht van QFD in software te geven: in 1987 wordt de Deming price for Quality voor het eerst toegekend aan een softwarebedrijf dat met QFD tot de volgende resultaten bereikte:

  1. een gemiddelde versnelling van haar softwareprojecten met 520%
  2. het terugbrengen van haar onderhoudsinspanning tot 1 correctie per2.000.000 regels uitvoerbare code gedurende het eerste jaar na implementatie (dit was in 1987)
  3. vrijwel volledige eliminatie van testen. Als je bijna geen fouten maakt is het ook niet nodig veel tijd aan testen te besteden

Een vereiste bij preventie is dat alle lekken in je proces zijn opgespoord en gedicht. Je processen zijn dus a.h.w. waterdicht en laten uitsluitend nog menselijke fouten door.

Menselijke fouten zijn nooit uit te sluiten, ook niet door een QA systeem. Maar … ik heb een geruststellende statistiek voor je.

Mensen die het absoluut kunnen weten (dr. Deming) en die we gerust kunnen vertrouwen beweren met klem dat slechts 6% van wat er in organisaties fout gaat (en misschien geldt dit in nog sterkere mate voor s/w projecten) aan mensen ligt.

En de resterende 94%? Wees gerust, want daar kunnen jij noch ik iets aan doen. Ze zijn het logische gevolg van gebreken aan de processen waarmee we werken.

Een absolute eis van een QA systeem is dus dat het je fouten moet helpen voorkomen. Anders gezegd: een QA systeem moet je helpen je proces zo in te richten dat het uitsluitend uit activiteiten bestaat die de kwaliteit van software garanderen en de noodzaak voor testen minimaliseren.

Anders is het geen QA systeem.

Testen of beter gezegd: de tijd en de inspanning die je achteraf kwijt bent met het opsporen, lokaliseren en corrigeren van fouten die nooit gemaakt hadden mogen worden zijn de enige en beste graadmeter voor het QA gehalte van je proces.

En als je nog steeds niet overtuigd bent dan heb ik de volgende vragen voor je:

Heb je ooit meegemaakt dat de eigenaar van een nieuw huis eerst 10 sterke schouders van de plaatselijke sportschool inhuurt om zo hard mogelijk tegen de muren te duwen voordat hij zijn nieuw huis durft betreden?

Heb je ooit meegemaakt dat de brandweer op last van de eigenaar van een nieuw huis moest uitrukken om het dak te besproeien om te testen of het binnen droog blijft tijdens een regenbui?

Dit is wat testen eigelijk is. Wat is er mis? Kan het zijn dat het softwareproces niet minder geschikt is voor wat het moet doen?

Tot de volgende blog,
“Black Belt Kelly”
Coherent Systems
kwg@coherentsystems.nl

p.s. wil je weten hoe QFD je kan helpen je succes als ITC-er te maximaliseren en onmisbaar te worden in de winstgevendheid van je onderneming of klant? Stuur me een email.

 

 

 

Read Full Post »