Agile onderzoek

 
30 januari 2011

Onderzoeksvaardigheden zijn belangrijk in ons vakgebied. Helaas wordt onder het uitvoeren van onderzoek vaak een vrij lang (lees: maanden) proces verstaan met uitgebreide wetenschappelijke verslaglegging. Plaatjes als hieronder worden vaak gebruikt om dit te illustreren. Het is dan ook voor vele collega’s vaak zo’n onderwerp van “dat heb ik tijdens mijn studie gehad maar doe ik nu niks meer mee”.

Echter, besef je eens hoeveel onderzoek er wel niet komt kijken bij je dagelijks werk als software engineer of consultant. Je vormt eigenlijk continu hypotheses en probeert deze te staven. Daarnaast is er vaak een heel stuk exploratief/creatief onderzoek nodig om uit te vinden wat requirements zijn. Maar zelfs het proces waar we toch het vaakst mee bezig zijn, het analyseren van code omdat er iets niet naar wens verloopt, is eigenlijk een vorm van onderzoek.

Vaardigheden die er komen kijken bij het uitvoeren van dit soort onderzoek zijn voor software engineers dus eigenlijk essentieel. Erg belangrijk is het om je te beseffen dat alvorens je een probleem oplost je zult moeten onderzoeken wat mogelijke oplossingsrichtingen zijn, diverse bronnen moeten raadplegen, en zul je een bepaalde hypothese moeten opstellen. Anders ben je aan het schieten met hagel in een bijna lege ruimte en zal je niet snel tot een gedegen oplossing komen.

Probeer dan ook in je dagelijks werk eens de volgende eenvoudige stappen voor jezelf uit te voeren bij bijvoorbeeld het oplossen van een bug, zodat je wellicht wat gestructureerder te werk kunt gaan:
1. Identificeer je probleem, pinpoint de locatie(s) waar het zich bevindt.
2. Reproduceer je probleem (zo plaatselijk mogelijk), verifieer dat het bestaat; min of meer idem aan hypothesevorming.
3. Los het probleem op binnen het kader van de context die je hebt bepaald in de reproductiestap (dus niet daarbuiten).
4. Herhaal stap 2 totdat het probleem niet meer te reproduceren is.
5. Verifieer dat het probleem ook opgelost is buiten je experimentele context, en of het geen nieuwe problemen introduceert.
6. Documenteer / verslaglegging (bijv. wiki, issue tracking, etc).

Enig idee welke tools/technieken we m.b.t. software kunnen gebruiken voor stap 2,4 en 5? Juist: Unit Testing :).

Dan rest mij nog een stukje literatuur over onderzoek aan te raden: Doing Research van Nel Verhoeven.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development


Reactie

  • Andries Nieuwenhuize schreef:

    Nog een tip: doe een spiegelgevecht met collegae! Die hebben soms verdraaid handige inzichten en ervaringen. Ik zou ‘m tussen punt twee en drie hangen. Eerst het probleem helder hebben en dan jouw oplossingen spiegelen. Er zijn helaas nog steeds teveel it-ers die naar de naam Remi luisteren.

    Geplaatst op 01 februari 2011 om 10:45 Permalink