Feeds:
Berichten
Reacties

Mijn nieuwe website

Sinds kort is mijn nieuwe website in de lucht. Deze website geeft een beter beeld in mijn inzichten en de concepten die ik hanteer om het softwareproces te ontdoen van alle overtollig vet en waste.

Uiteindelijk is dit een voorwaarde om je bijdrage en die van je afdeling aan het succes en de winstgevendheid van je onderneming te expanderen en het stressnivo bij softwareontwikkelaars te reduceren.

De url van mijn site is: http://www.coherentsystems.nl

Groet,
“Black Belt” Kelly
http://www.coherentsystems.nl

Ik heb het eerder aangekondigd. Mijn boek. Het is er echter nog niet van gekomen. Maar vandaag heb ik goed nieuws. Neen, het is geen boek. Het is een MANIFESTO: het software engineering MANIFESTO!De titel?

De grootste  hindernis in uw softwareproces en hoe het onderkennen en elimineren hiervan de kosten en duur van uw softwareprojecten dramatisch reduceren en de winstgevendheid van
uw onderneming stimuleren!

Dit manifesto komt donderdagmorgen 12:00 uur officieel in digitale (PDF) vorm uit.

Het legt de dieperliggende gebreken, inconsistenties en misvattingen van het traditionele softwareproces bloot en adresseert ze. Tevens introduceer ik een innovatieve, pro-actieve aanpak die:

  • het testen van software bijna overbodig maakt
  • ontwikkelaars de volledige controle teruggeeft over de specificaties. Dus: nooit meer gebruikers die niet weten wat ze willen, c.q. incomplete c.q. incorrecte specificaties die aan het eind van het traject worden aangevuld c.q. gecorrigeerd
  • het eerstejaars onderhoud bijna elimineert
  • de doorlooptijd van softwareprojecten halveert
  • een eind maakt aan structureel overwerken om een project op tijd af te leveren
  • en nog meer

En nu volgt het beste … als je voor vrijdag a.s. een copie aanvraagt, krijg je het als eerste en …. GRATIS! Je hoeft er geen cent voor te betalen.

Maar ik waarschuw je: de informatie is controversieel en zal veel stof doen opwaaien.

De inhoud is geen oude wijn in nieuwe zakken. Het zijn onconventionele, verstrekkende en soms zelfs tegendraadse concepten en inzichten die je niet vaak zult tegenkomen. Dit wordt de eerste keer dat ik deze concepten, inzichten en tools die ik tussen 1988 en 2001 in Japan en Amerika heb geleerd met een groot publiek deel. Het manifesto is slechts enkele dagen gratis. Vraag het daarom meteen aan.

Hoe kun je jouw copie van dit manifesto aanvragen?

Door een email voorzien van je correcte voornaam, achternaam en email-adres te sturen naar: gratis-manifesto@coherentsystems.nl

What’s the catch?

  • gratis email adressen zijn uitgesloten
  • de bereidheid een kort schriftelijk oordeel over de inhoud van het manifesto te geven die ik op mijn blog en website mag publiceren
  • je email voor een gratis copie moet uiterlijk vrijdagmiddag 12:00 uur binnen zijn. Daarna is het NIET langer GRATIS!

Groet,
“Black Belt” Kelly

p.s. hoe eerder je email binnen is, des te eerder ontvang je het manifesto!

Je mening gevraagd

Vorge week belandde ik onverwacht midden in een TV programma op een Nederlandse zender dat ging over de Indiase software industrie. Concreter gezegd: over het enorme succes van de Indiase software industrie.

Wat mij vooral opviel was het zelfvertrouwen en de enorme gedrevenheid van vooral Indiase studenten.

Ik kan me dit zelfvertrouwen voorstellen, want Indiase software ontwikkelaars zijn gewild over de hele wereld. Uit de reportage bleek dat Indiase universiteiten jaarlijks recruiters van de grootste en meest succesvolle software bedrijven uit vooral Amerika op bezoek krijgen.

En studenten zijn vaak voor hun afstudereen verzekerd van de meest lucratieve droombanen bij deze bedrijven.

Wat ook opviel was dat Indiase software ontwikkelaars zich zonder uitzondering en zonder enige bescheidenheid beter zeggen te voelen dan software ontwikkelaars uit b.v. Nederland.

Is dit volgens jou terecht?

Ik vraag me af waar dit succes uit voortkomt. Ik heb een mening en een valide verklaring, maar wil graag op deze blog een discussie hierover opstarten.

Wie geeft zijn of haar mening?

Groet,
“Black Belt” Kelly

Wanneer je een software professional of een deskundige bent op het gebied van kwaliteitszorg in software of IT(beheer) of leiding geeft aan softwareprojecten of een ITC afdeling en open staat voor unieke, niet-alledaagse inzichten die je onmisbaar voor je opdrachtgever ofwerkgever maken, dan nodig ik je uit deze en de volgende blogs serieus te bestuderen.

Wanneer je dit doet staat je een bijzonder aangename verrassing te wachten. Met de informatie die in deze blogs langskomt zul je in staat zijn 100% beter te presteren met 50% minder inspanning.

Nee, dit is geen typfout. Je kunt je prestaties verdubbelen met de helft van de inspanning die je nu levert. En het is niet eens zo moeilijk, als je maar weet hoe!

Beter gezegd, als je maar weet:

  1. wat je ANDERS moet doen,

  2. wat je NIET meer moet doen,

  3. waar je MEER van moet doen

Dat is precies de informatie die ik de komende blogs me je ga delen.

Laat me eerst beginnen met op te merken dat veel van de dingen die we bij het ontwikkelen van software doen zo vanzelfsprekend lijken dat we ze voor zoete slikken en niet ter discussie stellen. Neem bijvoorbeeld het traditionele softwareproces.

Wanneer ik dit proces kritisch analyseer stel ik vast dat het op vele punten te kort schiet en betere prestaties zelfs belemmert. Ergo, voor mij is het een regelrecht wonder dat we ondanks dit proces tot goede prestaties in staat zijn.

Maar je kunt beter, vele, vele malen beter!

Laten we bij het begin beginnen en het onderliggende softwareproces model nader bekijken. Deze bestaat uit de volgende stappen:

  1. vraag de gebruiker wat ze wil

  2. maak wat de gebruiker gevraagd heeft

  3. test het

  4. implementeer het

  5. onderhoud het

Wat is er mis met dit proces? Veel, maar ik zal me hier beperken tot een kleine selectie. Voordat ik echter hier toe overga, eerst het volgende: als je bovengenoemde stappen van het software procesmodel bestudeert dan moet het je opvallen dat ze verdacht veel lijken op het model dat Henri Ford een kleine 100 jaar geleden toepaste om auto’s te fabriceren. Dit model is decennia lang toonaangevend geweest bij de fabricage van industriële producten. Het is daarom te begrijpen dat Dr. Royce sterk door dit model is beïnvloed, alleen zitten wij nu opgescheept met de ongewenste bijeffecten. In zekere zin kun je zeggen dat we door deze dwaling software ontwikkelen zoals Henri Ford dat een kleine 100 jaar geleden zou hebben gedaan. Alsof er sindsdien geen nieuwe, baanbrekende ontwikkelingen geweest zijn.

Terug naar het software proces model: dit model gaat uit van enkele vooronderstellingen die soms verre van juist zijn. De eerste is dat de gebruikers in staat zijn hun sitiuatie grondig te analyseren, precies weten wat ze willen en dit in staat zijn helder te verwoorden. Verder gaat het uit van de impliciete vooronderstelling dat de gebruiker alle mogelijkheden die de technologie biedt kent en optimaal weet te benutten.

Na 30 jaar en een kleine 100 softwareprojecten in meer dan 50 organisaties durf ik deze vooronderstelling te bestrijden. En iedereen die een softwareproject van nabij heeft meegemaakt zal dit kunnen beamen. Wensen en eisen van gebruikers blijken keer op keer, project na project, verre van correct c.q. compleet c.q. stabiel.

En het komt in elk project voor dat zelfs tijdens het testen nieuwe specificaties worden opgehoest c.q. eerder geformuleerde specificaties worden herzien. Wat zijn jouw ervaringen?

Een andere vooronderstelling is dat de analist in staat is de juiste vragen te stellen. Maar zelfs wanneer ze dat zou kunnen ben je er nog niet: het is namelijk niet voldoende de juiste vragen stellen, het is noodzakelijk ALLE vragen te stellen om de specificaties sluitend te krijgen.

Dit zijn slechts 2 van de problemen die nauw met het softwareproces model samenhangen en ik kan moeiteloos nog een hele rij noemen.

Nog een voorbeeld? Dit proces is een kleine 40 jaar geleden door Dr. Winston Royce geconcipieerd en het is best interressant je even af te vragen welk probleem hij met dit proces heeft willen oplossen.

Toen de eerste computers hun intrede in het bedrijfsleven deden waanden programmeurs zich kunstenaars die hun gang konden gaan. Van projecten was nooit zeker hoe lang ze zouden duren, wat ze gingen kosten en of ze aan de wensen voldeden. Dit tot groot ongenoegen van het management. De oplossing voor dit probleem is het proces van Dr. Royce.

Dit proces is dus primair bedoeld geweest om management inzicht te verschaffen in de voortgang van softwareprojecten c.q. in te grijpen c.q. het roer om te gooien. Maar er is meer.

De omstandigheden in 2007 zijn anders. De wereld is dynamischer, de technologie is met reuzenstappen vooruit gegaan, de eisen die we nu stellen zijn volstrekt anders en de concurrentie is veel heviger.

En wat is de implicatie hiervan?

Toen Dr. Royce met zijn proces ten tonele verscheen was automatisering primair bedoeld om handmatig werk door de computer te laten overnemen. Niets meer en niets minder. En wie wisten het beste hoe het werk uitgevoerd werd?

Pas veel later drong het inzicht door dat computers de mogelijkheid openden werk veel slimmer in te richten. Anno 2007 zijn alle handmatige processen inmiddels geautomatiseerd. Softwareprojecten richten zich niet langer op het automatiseren van handmatig werk, maar op het ondersteunen van nieuwe producten c.q. diensten. Deze processen zijn nieuw en moeten als het ware uitgevonden worden. Bovendien moet het nu veel sneller, beter en moet het nog minder kosten, ook.

Allemaal eisen die het antieke softwareproces niet aan kan, omdat het hier niet voor bedoeld is. Alle inspanningen en goede bedoelingen van de afgelopen decennia (nieuwe tools, nieuwe methoden, initiatieven om de kwaliteit van het softwareproces te verbeteren, enz.) ten spijt.

Waarom?

Omdat geen van deze maatregelen de kern van het probleem oplost. Wat ze doen is symptomen bestrijden.

Vandaag heb ik een deel van de kern van het probleem geraakt. De komende weken zal ik hier verder mee gaan, totdat je over voldoende inzicht beschikt om het probleem in haar volle omvang te overzien en te adresseren.

Ik hoop nu dat je uit je schulp kruipt en jouw mening laat horen. Reageer en laat merken wat je van mijn inzichten vindt. Reageer met eventuele vragen c.q. opmerkingen.

Groet,
Black Belt Kelly
Coherent Systems
kwg@coherentsystems.nl

p.s. dit is een excerpt van mijn eerste boek uit een serie van vier dat binnenkort uitkomt.

Je voornaamste reden deze blog te bezoeken is dat je professioneel betrokken bent bij kwaliteitszorg in software/IT, een ambitieuze software ontwikkelaar bent of leiding geeft aan softwareprojecten of software organisaties.

Bovendien sta je open voor vernieuwende ideeën die je prestaties kunnen verdubbelen en je bijdrage aan het succes en de winstgevendheid van je werkgever kunnen expanderen.

Wanneer het bovenstaande op jou van toepassing is zit je goed.

Maar het wordt nog beter: de komende weken ben ik van plan enkele innovatieve ideeën, concepten en inzichten met je te delen die de grootste en meest fatale misverstanden in software engineering adresseren.

Houd deze blog de komende weken dus scherp in de gaten en surf elke dag naar:
http://blackbeltkelly.wordpress.nl

Met respect,
Kelly “Black Belt” Anches
kwg@coherentsystems.nl

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

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