Ga naar de inhoud

Aanpak

Van vraagstuk naar werkende software.

Een softwareproject begint zelden met een volledig uitgewerkt antwoord. We brengen eerst in kaart hoe de huidige werking eruitziet, wie met de software werkt en welke systemen en beperkingen een rol spelen.

Daarna maken we technische keuzes expliciet en bouwen we in stappen die we kunnen testen, gebruiken en bijsturen.

Iemand loopt over een verlicht, gebogen pad naar de skyline van een stad in de avondschemering.

Van context naar realisatie

Begrijpen. Structureren. Bouwen.

Deze drie stappen zijn geen vast proces dat één keer van links naar rechts wordt doorlopen. Tijdens het bouwen komen nieuwe inzichten naar boven. Als die relevant zijn, gaan we terug naar een eerdere keuze en stellen we bij.

  1. Begrijpen

    Hoe werkt het vandaag en waar zit het echte probleem?

    We bekijken het proces, de gebruikers, bestaande software, gegevensstromen en technische randvoorwaarden. We proberen ook onderscheid te maken tussen wat vaststaat en wat nog moet worden onderzocht. Dat voorkomt dat een veronderstelde oplossing te vroeg het uitgangspunt wordt.

    Een gedeeld beeld van het probleem, de betrokken systemen en de scope die we verder moeten uitwerken.

  2. Structureren

    Hoe delen we het probleem technisch op?

    We bepalen welke verantwoordelijkheden waar thuishoren, welke systemen met elkaar moeten communiceren en welke keuzes gevolgen hebben voor verdere ontwikkeling. Waar meerdere oplossingen mogelijk zijn, maken we de belangrijkste verschillen expliciet. Niet alleen wat we kiezen is belangrijk, maar ook waarom.

    Een technische richting waarmee gericht gebouwd kan worden.

  3. Bouwen

    Werkt de gekozen richting ook in de praktijk?

    We vertalen de gemaakte keuzes naar werkende software, liefst in voldoende kleine stappen om tussentijds te kunnen testen, integreren en feedback te verzamelen. Tijdens de implementatie worden aannames concreet. Als een API anders reageert, bestaande data uitzonderingen bevat of gebruikers anders werken dan verwacht, gebruiken we die informatie om de oplossing bij te sturen.

    Werkende software en meer kennis over wat de volgende stap nodig heeft.

Technische keuzes

Iedere technische keuze heeft consequenties.

Er bestaat zelden één architectuur, framework of oplossing die in iedere situatie de juiste keuze is. Daarom kijken we naar de gevolgen voor de toepassing, het team dat ermee werkt en de verdere ontwikkeling.

  • Behouden of veranderen

    Bestaande software wordt niet vervangen omdat nieuwere technologie beschikbaar is. We bekijken eerst wat goed functioneert, waar de echte beperkingen zitten en welke verandering voldoende waarde oplevert om de extra complexiteit te verantwoorden.

  • Eenvoud of flexibiliteit

    Software moet kunnen evolueren, maar niet iedere mogelijke toekomstige behoefte hoeft vandaag al in de architectuur verwerkt te worden. Te vroeg abstraheren kan evenveel complexiteit veroorzaken als te weinig structuur.

  • Snelheid of robuustheid

    Een prototype, interne toepassing en bedrijfskritische integratie stellen andere eisen. Hoeveel testing, foutafhandeling, logging en documentatie nodig is, hangt mee af van het risico en de verwachte levensduur.

Samenwerken

Domeinkennis en technische expertise horen bij elkaar.

De mensen binnen een organisatie kennen hun processen, gebruikers en dagelijkse uitzonderingen. Truecoded brengt technische analyse, architectuur en software-engineering in. Goede keuzes ontstaan wanneer die kennis samenkomt.

De opdrachtgever

  • doelen, prioriteiten en domeinkennis
  • toegang tot gebruikers en bestaande werking
  • organisatorische randvoorwaarden

Samen

  • scope en prioriteiten
  • keuzes met functionele gevolgen
  • tussentijdse resultaten en acceptatie

Truecoded

  • technische analyse en consequenties
  • architectuur en implementatie
  • de afgesproken technische bijdrage en oplevering

Technische beslissingen worden niet onnodig bij de opdrachtgever gelegd, terwijl Truecoded zakelijke of domeinkeuzes niet maakt zonder de mensen die de context kennen.

Kwaliteit en oplevering

Code schrijven is maar een deel van de oplevering.

Wat “klaar” betekent hangt af van wat we bouwen. Een kleine interne tool vraagt iets anders dan een integratie waarop meerdere toepassingen vertrouwen.

  • Het afgesproken functionele gedrag werkt.
  • Relevante automatische en technische tests zijn aanwezig.
  • Belangrijke foutscenario’s zijn behandeld.
  • De afgesproken route naar build en deployment werkt.
  • Noodzakelijke documentatie, beperkingen en kennisoverdracht zijn geregeld.

Niet ieder project heeft op elk punt dezelfde diepgang nodig. We bepalen vooraf wat voor de betreffende software verantwoord is. Kwaliteit zit daarmee in de architectuur, de code, de tests en de manier waarop software wordt opgeleverd.

Waar beginnen?

Niet ieder softwarevraagstuk moet met development starten.

Soms is voldoende duidelijk wat er moet gebeuren. Soms zijn er eerst technische vragen die de volgende stap bepalen.

De richting is voldoende duidelijk

Een eerste ontwikkelstap afbakenen.

We maken functionaliteit, technische scope, verantwoordelijkheden en acceptatiecriteria voldoende concreet om een eerste versie of uitbreiding te realiseren.

  1. Vraagstuk
  2. scope
  3. realisatie

Er zijn nog belangrijke technische vragen

Eerst gericht verkennen.

We onderzoeken bijvoorbeeld bestaande code, architectuur, integraties, gegevensstromen of technische alternatieven en gebruiken die informatie om de volgende ontwikkelstap beter af te bakenen.

  1. Vraagstuk
  2. technische verkenning
  3. richting

Een eerste gesprek dient om te bepalen welk vertrekpunt past. Wanneer grondige analyse of onderzoek nodig is, maken we dat expliciet onderdeel van de opdracht.

Volgende

Hoe ziet dat eruit in echte projecten?

Bekijk geselecteerde projecten en de technische bijdrage binnen verschillende softwarecontexten.