Auteur Topic: De sleutel naar een succesvolle methodologie  (gelezen 114 keer)

Offline Axel

  • Algemene moderator
  • Nieuweling
  • *****
  • Berichten: 7
    • Bekijk profiel
    • Taurus Enterprise Engineering
De sleutel naar een succesvolle methodologie
« Gepost op: 17 augustus 2017, 19:17:30 »
Vele softwareontwikkelingsprojecten worden als gefaald beschouwd. Daar deze onlosmakelijk verbonden zijn met methodologieën, wordt deze laatste al snel als boosdoeners aangewezen. Methodologieën worden vaak allerhande gebreken aangewreven. De huidige methodologieën worden dan al gauw verdreven en onze geest staat open voor een nieuwe. We koesteren de hoop om eindelijk de methodologie te vinden die ons naar succesvolle projecten zal leiden. Deze redenering is echter gebaseerd op een erg oppervlakkig inzicht in software engineering, en in het bijzonder in methodologieën. De sleutel naar de methodologie die een project succesvol zal ondersteunen is nochtans voor de hand liggend. Laten we dit van dichterbij bekijken.

De kern van een methodologie is een algemene omschrijving van een proces. De aard van het te bouwen product of van het te bekomen resultaat is de meest bepalende factor die het project en zijn proces bepaalt. Projecten die een gelijkaardig product creëren hebben bijgevolg heel wat gemeen. Deze gemeenschappelijkheden werden dan gesynthetiseerd en geformaliseerd in een methodologie. De methodologie kan verder nog verrijkt worden met elementen die nuttig kunnen zijn voor projecten.


Het fundamenteel doel van de methodologie is bij te dragen aan het succes van toekomstige projecten. Ditzelfde doel geldt ook voor alle andere elementen, principes, aspecten en componenten uit de methodologie.


De ontwikkeling van een kleine softwaretoepassing is doorgaans vrij eenvoudig. Men kan deze ontwerpen, ontwikkelen en testen in één trek zonder veel voorbereidend werk. Dit stelt geen echte uitdaging voor en is dus ook geen valabele test voor een methodologie. De situatie ligt anders bij grotere en complexere softwaresystemen die bijvoorbeeld functioneel en architecturaal geïntegreerd zijn in een overkoepelend systeem en die tevens een algemene coherentie en standaardisatie nastreven terwijl ze door verschillende gebruikersgroepen worden gebruikt die informatie uit diverse domeinen delen voor verschillende doeleinden. Bij het bouwen van een wolkenkrabber zal men andere problemen tegenkomen dan bij het bouwen van een schuurtje. Beide vereisen een verschillende aanpak. Het is bij de ontwikkeling van grotere en complexere systemen dat een methodologie pas haar nut bewijst en dit over een langere periode, zoals een decennium. Ze kunnen echter een zegen of een vloek zijn.


Sinds de jaren ‘70 tot vandaag zijn de te bouwen softwaresystemen sterk geëvolueerd. Hun grootte, hun complexiteit en hun connectiviteit zijn aanzienlijker geworden. Ook de omgevingen van de softwaretoepassingen zijn sterk veranderd. Deze evolutie stelde projecten telkens voor belangrijkere uitdagingen en voor nieuwe problemen. Het is door hieraan een antwoord te bieden dat projecten, hun aanpak en de methodologieën evolueerden. Elk onderdeel van de methodologie heeft een rede van bestaan, een doel, een nut, een functie. Dit alles bestaat dus niet zonder rede en men mag hier niet lichtzinnig over gaan.

Methodologieën kunnen ook het resultaat zijn van een nieuw inzicht, via de introductie van nieuwe principes of uit experimentele projecten.

De keuze van de methodologie


Het is de verantwoordelijkheid van het projectteam om de gepaste methodologie te kiezen. Het creëren van een nieuw administratief softwaresysteem, de aanpassing van een dergelijk systeem, een datamigratie, de fusie van bestaande softwaresystemen, de ontwikkeling van online games, de ontwikkeling van websites, de ontwikkeling van robotsoftware of van een wetenschappelijke softwaretoepassing, de implementatie van een ERP-systeem zijn allemaal totaal verschillende types van projecten. Het is de verantwoordelijkheid van het team om de methodologie te selecteren die voor hun specifiek project het meest geschikt is. Dit gaat niet om een keuze op basis van voorkeur of smaak, maar van geschiktheid. Zelfs indien de keuze ongelukkig is, kan het project nog slagen. Het kan wel wat moeilijker worden.

Aanpassing van de methodologie


Eenmaal gekozen, worden vele methodologieën trouw gevolgd. Het volgen van een methodologie is noch een doel, noch een verplichting. Dit zou immers fundamenteel onlogisch en zinloos zijn. Het kan zelfs niet eens worden aangeraden.


Verwachten dat door het trouw volgen van een methodologie het gewenst resultaat bereikt kan worden is een grote illusie. Een procedure zal, doorgaans, het bedoeld resultaat opleveren indien het stipt uitgevoerd wordt. Echter, een methodologie is geen procedure. Dit is zo belangrijk dat het dient te worden herhaald: “een methodologie is geen procedure”. Een methodologie is een synthese van een patroon die in gelijkaardige projecten voorkomt. Het is een algemeen proces. Echter, elk project is verschillend. Het is dus weinig waarschijnlijk dat een methodologie perfect beantwoordt aan de noden van een project. In tegenstelling tot een procedure, zal het strikt volgen van een methodologie veel eerder het succes van het project ondermijnen.


Een methodologie is geen oplossing. Het is geen kant-en-klaar of afgewerkt proces. Het is een vertrekbasis waaraan moet worden gesleuteld. Het is een suggestie van een template. Zo kunnen taken worden herschikt, toegevoegd of weggelaten. Elk aspect van de methodologie kan en moet worden aangepast aan het project en zelfs aan de individuele situaties binnen een project. Voor elke aanpassing, dient men te weten waarom de aanpassing noodzakelijk is.

Omdat het doel van elke methodologie er uit bestaat om bij te dragen tot het succes van het project, heeft het ook geen zin om taken uit te voeren of documenten te produceren die voor het specifiek project, voor het product of voor de organisatie geen toegevoegde waarde betekenen, ook rekening houdend met bijvoorbeeld langere termijn of risico’s.

Stellen dat een methodologie ook maar iets zou opleggen gaat regelrecht in tegen de geest van een methodologie. In een onderneming, kunnen mensen wel bepaalde verplichtingen opleggen aan projecten, zoals de verplichting om een PID (Project Initiation  Document) op te stellen. Maar dit zijn mensen die verplichtingen via de methodologie doorgeven. Het is niet de methodologie zelf die iets oplegt.

Competenties


Een methodologie biedt steun aan projectleiders, architecten, analisten en engineers. Maar het leidt hen niet. Het vertelt hen niet wat ze moeten doen. Dit moeten ze zelf bepalen. Het is geen substituut of excuus voor het niet nemen van bepaalde verantwoordelijkheden.


Een methodologie vervangt de kunde en inzicht in softwareontwikkeling niet, noch ontheft de projectleden van het autonoom en kritisch denken. Deze competenties zijn nog steeds broodnodig. Projectleden moeten immers de methodologie aanpassen aan het project. Dit vereist een diepgaand inzicht in software engineering. De teamleden zouden in staat moeten zijn om een project succesvol uit te voeren door een hele methodologie en projectorganisatie zelf vanaf nul te bepalen zonder gebruik te maken van een bestaande methodologie. Indien het team hiertoe niet in staat is, loopt het project een ernstig risico.

Conclusie


Methodologieën doen projecten niet falen en kunnen dit ook niet. Het zijn de mensen en situaties die projecten kunnen doen falen. Het kan hoogstens een project in meer of in mindere mate ondersteunen. De sleutel tot een methodologie is de juiste methodologie te selecteren en deze aan te passen aan het project. Dit vereist het juist identificeren en begrijpen van de noden van het project. Verder vereist dit ook autonoom denken en stevige inzichten en competenties in softwareontwikkelingen en het kundig kunnen omspringen met het project.


Axel Vanhooren
Freelance Consultant Business Informatics
« Laatst bewerkt op: 21 augustus 2017, 22:31:42 door Axel »
Axel.