Wat we voor je oplossen
Drie manieren waarop we een project draaien
Er is geen enkel juist proces — alleen het proces dat past bij het werk dat voor je ligt. We draaien projecten in drie vormen, en we vertellen je bij de start welke vorm we voor het jouwe zien.
Agile / SCRUM
Iteratief opleveren in korte cycli: een werkende toevoeging, jouw feedback, dan de volgende. De juiste vorm wanneer de details gaandeweg ontdekt worden in plaats van vooraf vaststaan.
Waterval
Een vastgelegde scope die vóór de start op schrift wordt afgesproken en volgens die specificatie wordt opgeleverd. De juiste vorm wanneer de eisen echt vooraf bekend zijn en iedereen ze eerst dichtgetimmerd wil hebben.
Ad-hoc voor start-ups
Minimale ceremonie, maximale beweging — het doel is uitvinden of het idee überhaupt werkt. De juiste vorm wanneer proces meer kost dan het oplevert, en het antwoord belangrijker is dan het plan.
Hoe een project verloopt
Verkenning
We brengen je doelen, randvoorwaarden en het bestaande systeem in kaart voordat er één regel code wordt geschreven.
Bouwen & itereren
Korte feedbackloops en al vroeg werkende software — geen black boxes, geen verrassingen.
Livegang & support
Een nette overdracht met documentatie, en we blijven beschikbaar lang na de livegang.
Hoe we weten dat het gewerkt heeft
Een proces vertelt je hoe het werk georganiseerd is. Het vertelt je niet of het resultaat beter is dan wat er was. Die vraag vraagt om cijfers — en die cijfers moeten ergens vandaan komen waar het team geen invloed op heeft.
Het duidelijkste voorbeeld dat we je kunnen laten zien is er een van onszelf: Raku++, onze open-source compiler. Alles hieronder is openbaar en controleerbaar.
- Getoetst aan een externe suite. Correctheid wordt gemeten tegen de testsuite die de gemeenschap van de taal zelf onderhoudt — niet een suite die we voor onszelf schreven. Op dit moment slagen 196.395 van de 217.060 individuele tests.
- Geen release met een regressie. Elke wijziging draait eerst tegen de volledige suite, en een release die terrein verliest gaat niet uit.
- Elk gesloten defect wordt een test. Inmiddels 149 stuks, bij elke release opnieuw gedraaid, zodat een opgeloste bug opgelost blijft.
- Vijf automatische release-poorten, waaronder één die performance opnieuw meet tegen een vastgelegde basislijn en de build laat falen als die is weggezakt.
- Het onflatteuze cijfer wordt gepubliceerd. Er zijn drie verdedigbare manieren om dat slagingspercentage te berekenen. Wij noemen de strengste, en schrijven op hoe hij berekend wordt.
Dat is één project, en een ongewoon goed meetbaar project — een compiler heeft een externe specificatie om aan getoetst te worden, en de meeste software niet. Wat wél overdraagbaar is, is de gewoonte: zoek een meetlat buiten het team, leer hoeveel hij wiebelt vóórdat je bewegingen als vooruitgang leest, en zet er automatisch een poort op in plaats van te vertrouwen op iemand die eraan denkt te kijken.
De volledige methode, met de echte dashboards en grafieken: Gemeten, niet gegokt — ontwikkeling gestuurd door cijfers. Het project waar het uit voortkwam: Raku++ bouwen.
Wat je krijgt
- Het juiste ritme voor je project, van Agile tot vaste scope
- Zichtbare voortgang en al vroeg werkende software
- Heldere communicatie en voorspelbare oplevering
- Een flexibele aanpak voor zowel start-ups als grote organisaties