Ik begon bij Nefit/Bosch als opdracht van Capgemini om de softwareontwikkeling (Matlab/Simulink) voor hun CV-ketels te versnellen. Naast de ontwikkeling van de applicatie nam ik de taak op me om de softwarearchitectuur te verbeteren voor een betere leesbaarheid, ik werd de verantwoordelijke voor het opstellen van de applicatie-eisen en leidde het team door de verschillende interne Quality Gates.
Situatie schetsen op basis van de STAR methodologie
[2024] Bewijs van implementatie van de klanteisen
Situatie – Vanwege bijgewerkte richtlijnen van Bosch moest er bewijs van de implementatie van de klantvereisten worden geleverd. Eerder was het voldoende om de complete set documentatie van de applicatie te tonen. In eerste instantie werden de klantvereisten verwerkt tot productvereisten (inclusief hardware, firmware en software) en werd de software component-gewijs beschreven in functionele beschrijvingen.
Taak – Koppel de productvereisten aan de functionele beschrijvingen, zodat de klantvereisten via de productvereisten gekoppeld zijn.
Actie – De productvereisten waren te hoog niveau om direct aan de functionele beschrijvingen te koppelen. Daarom heb ik een extra laag van applicatievereisten gemaakt op basis van de functionele beschrijvingen (bottom-up). De reden voor de bottom-up aanpak was dat de functionele beschrijvingen het enige was waarvan we zeker wisten dat deze compleet was (aangezien deze eerder als bewijs waren gebruikt). Zodra alle functionele beschrijvingen een upstream applicatievereiste hadden, koppelde ik de applicatievereisten aan de productvereisten. Dit resulteerde in meerdere nieuwe productvereisten, die voornamelijk de basisfunctionaliteit beschreven (bijvoorbeeld, aangezien de klantvereisten waren opgesteld voor een lopend project, waren er geen vereisten geschreven voor het daadwerkelijk activeren van de brander; alleen de veiligheidsscenario’s werden besproken).
Resultaat – Met de extra laag waren de klantvereisten nu gekoppeld aan de implementatie. Door de bottom-up aanpak werden de productvereisten completer.
[2024] Halen van Quality Gates
Situatie – Tegelijkertijd met het werken aan de vereisten (zie eerdere situatieschets) sloot ik me aan bij het Quality Gate-team, dat verantwoordelijk was voor het beheren van de projectdocumentatie en het doorlopen van de Quality Gates. Toen ik begon, zag ik dat de voortgang van het team traag was, met als belangrijkste reden ineffectieve vergaderingen (elk onderwerp werd in elke vergadering opnieuw besproken) en dat mensen de werkzaamheden voor dit team niet prioriteerden (iedereen was ook onderdeel van het applicatieontwikkelingsteam).
Taak – Mijn taak was om deel uit te maken van het lopende team en me te concentreren op de documentatie met betrekking tot de vereisten.
Actie – Omdat het team veel onderwerpen opnieuw opende, begon ik met het maken van notulen van de vergaderingen, met focus op beslissingen en actiepunten. Al snel leidde ik het Quality Gate-team en de vergaderingen, waarbij ik de vorige actiepunten als richtlijn gebruikte.
Resultaat – Door de vastgelegde beslissingen en het herinneren van mensen aan hun actiepunten steeg de productiviteit aanzienlijk. Hoewel de snelheid laag was voordat ik begon, werden alle kwaliteitspoorten binnen de vereiste tijdslijn gehaald.