Een transparante projectaanpak

Deze bestaat uit een duidelijk gedefinieerde set van bijna 200 activiteiten die we bij ieder project trachten uit te voeren. Alleen op die manier kan je zeker zijn dat ieder project goed loopt en er geen problemen opduiken. Alleen zo kan je op ieder project een gelijkaardig niveau van kwaliteit leveren.

Maar we verliezen hierbij de agile principes niet uit het oog. Het is geen benauwend keurslijf. Ieder project is ten dele anders, en zijn er bepaalde activiteiten op een bepaald project niet nodig, worden ze ook niet uitgevoerd. Belangrijkste is dat er wel over nagedacht wordt.

Dat ‘productieproces’ is niet in steen gebeiteld: het wordt gedragen en continu verder ontwikkeld door onze teams op basis van bijkomende inzichten. Het is een kapstok waarrond veel kennisdeling plaatsvindt tussen de teams. Dit is de enige manier om te voorkomen dat ieder team alles moet leren door alle problemen in de praktijk zelf aan den lijve te ondervinden.

Bovendien moet het proces kunnen omgaan met wijzigingen in de klantbehoeften in de loop van een project, en dat er bijgevolg vaak bijgestuurd zal moeten worden.

Tenslotte dient het volledig transparant te zijn waardoor je ‘shared understanding’ creëert en je in vertrouwen kan samenwerken.

... waarvan hier een overzicht

We ontdekken high-level de behoefte van de klant.

We schatten het analysewerk in, nodig voor een inschatting van de implementatie.

We werken een functionele en technische analyse uit met aandacht voor een goede UX.

We maken inschattingen naar tijd en budget voor de implementatie.

De ontwikkeling vindt plaats volgens Scrum of Kanban principes.

Na de ontwikkeling voorzien we nazorg en ondersteuning op maat van het project.

Intakegesprek

We ontdekken high-level de behoefte van de klant.

Offerte voor analyse

We schatten het analysewerk in, nodig voor een inschatting van de implementatie.

Analyse

We werken een functionele en technische analyse uit met aandacht voor een goede UX.

Offerte voor implementatie

We maken inschattingen naar tijd en budget voor de implementatie.

Implementatie

De ontwikkeling vindt plaats volgens Scrum of Kanban principes.

Nazorg

Na de ontwikkeling voorzien we nazorg en ondersteuning op maat van het project.

We onderscheiden volgende blokken:

1 Intakegesprek

In eerste instantie organiseren we een intakegesprek van maximaal een halve dag om een beeld te vormen van de klantvraag.

2 Offerte voor analyse

Op basis hiervan stellen we een offerte voor analyse op die de effort beschrijft die we nodig achten om een gefundeerde inschatting te kunnen maken van de kostprijs en timing van de implementatie van het project.

3 Analyse

Na goedkeuring van deze offerte kan de analyse fase van start gaan. Hierin gaan we een analyse uitvoeren van de gewenste functionaliteiten en indien nodig kijken we hiervoor naar de huidige situatie (AS-IS) en omgeving. Er worden workshops gehouden om een goed beeld te vormen van de requirements op functioneel gebied. We werken een high-level “product backlog” uit van functionaliteiten of “user stories”. Indien het om een project gaat met een gebruikersinterface, nemen we ook al een UX-design mee in deze fase.

Hierna volgt een technische analyse om te bepalen hoe we de oplossing willen bouwen. Naast de applicatie architectuur wordt hier ook de nodige aandacht besteed aan het inpassen van de nieuwe applicatie in het bestaande IT-landschap van de klant, of er nood is aan datamigratie, de securitycontext waar we mee te maken hebben enz…

Eventueel voorzien we een proof of concept om vb. een nieuwe technologie die mogelijks nuttig is af te toetsen naar bruikbaarheid.

Hoe ver de analyse moet gaan, is steeds een evenwichtsoefening tussen net voldoende informatie hebben om een goede budgetinschatting te kunnen maken en niet te diep te gaan in de details omdat dit tijdrovend is maar vooral ook de wet van het voortschrijdend inzicht in de weg staat.

Belangrijk is alvast dat de mogelijke risico’s, de scope en het technisch ontwerp gekend zijn. Qframe zal daartoe ook een replay-sessie met de klant houden, zodat er gemeenschappelijk begrip, inzicht en consensus is over de project scope.

4 Offerte voor implementatie

Het resultaat van deze fase is een offerte voor implementatie die bestaat uit de output van de analyse (functionele analyse aka. product backlog, technisch ontwerp, UX-mockups …) maar vooral een gefundeerde inschatting van kostprijs en timing van de implementatie. We gaan hier niet over één nacht ijs, want dit is natuurlijk één van de meest cruciale stappen in het ganse proces.

Onze geprefereerde manier van samenwerken is een vast budget flexibele scope context waarbij een gezond evenwicht wordt gevonden tussen de noodzakelijke behoefte aan het kennen van een budget vóór aanvang van het project enerzijds en het natuurlijk laten groeien van de software op een iteratieve Agile manier anderzijds.

5 Implementatie

We starten met de effectieve implementatie van het project.
Merk trouwens op dat we – zeker voor grotere projecten – altijd zullen proberen om die op te splitsen in meerdere fasen of modules. Dit om de risico’s aan beide kanten te beperken en toe te laten het wederzijds vertrouwen langzaam op te bouwen.

Onze werkwijze tijdens de implementatiefase is gebaseerd op de Scrum methodologie en de Agile principes. Zo stellen we het incrementeel opleveren van werkende en waardevolle software voor de klant, voortschrijdend inzicht, samenwerking en open feedback in de aanpak centraal.

Volgens de Scrum principes wordt de ontwikkeling opgedeeld in ‘sprints’ met een vaste tijdsduur en kent dit een cyclisch verloop. Voor elke sprint bepaalt de Product Owner de prioriteit van de gewenste stories op basis van business value. Bedoeling is om op het einde van de sprint een bruikbaar ‘product’ te hebben voor de ‘business’, dat kan geëvalueerd, getest of in gebruik genomen worden. De scope zelf en de prioriteit wordt bij elke sprint herbekeken of verder verfijnd en uitgewerkt, zodat het project kan bijgestuurd worden bij een wijzigende context of door nieuwe inzichten. Elke sprint heeft een aantal communicatiemomenten zoals de sprint planning, de dagelijkse stand-ups met het ontwikkelteam, de sprint demo’s en de retrospectives waarbij teruggekeken wordt op wat goed ging en wat nog beter kan in de volgende sprints. Samenwerking, betrokkenheid en openheid zijn duidelijk de sleutelelementen in deze sprints.

6 Nazorg

Na oplevering van het project voorzien we nazorg en ondersteuning. De concrete invulling is afhankelijk van het al dan niet aanwezig zijn van developers van de klant in het projectteam. Alleszins zorgen wij voor beschikbaarheid van (een deel van het) team om bugs die na oplevering nog naar boven komen aan te pakken zolang nodig is.
Merk op dat dankzij de agile projectaanpak en de nauwe samenwerking tijdens de implementatie zelf hier typisch veel minder issues naar boven komen dan bij een ‘klassieke’ projectaanpak.

Rollen

Hieronder geven we een overzicht van alle rollen die van nut zijn in een project. De groene worden idealiter opgenomen door mensen van de klant. De rode door ons Project Team.

De rol van Product Owner en alle rollen van het Project Team zijn cruciaal en kunnen niet worden geskipped. We noemen ze kernrollen.

Een persoon kan meerdere rollen opnemen als hij over de nodige skills beschikt. In kleinere projecten is dat ook het meest efficiënt. In grotere Project Teams (+10 personen) wordt toch vaak elke rol door een andere persoon ingevuld. Eén rol kan ook door verschillende personen worden opgenomen, zo zijn er altijd meerdere developers op een team.

Product Owner

Bepaalt wat er gebouwd wordt en de prioriteiten naar scope en timing. Is het aanspreekpunt van de klant voor het Qframe team.

Samenwerken met ons?

Interesse om met ons of voor ons te werken?
Vertel ons wat je zoekt en wat we voor je kunnen doen.

Contact