MINIMUM VIABLE PRODUCT

Het “Minimum Viable product” (MVP) werd populair gemaakt door Eric Ries bij de publicatie van het boek “The Lean Start-up” in 2008. Het kernconcept van MVP is zeer geschikt voor de filosofie achter agile software ontwikkeling. In de afgelopen jaren is deze filosofie erg populair geworden, vooral bij tech start-ups.

We zien dat het tempo van getalenteerde start-ups die zich aan deze filosofie houden, veel van de kernservices bedreigt die voorheen eigendom waren van bedrijven, bijvoorbeeld in de financiële sector. Omdat ze zich bewust zijn van dit verstoringrisico, proberen de ondernemingen steeds meer het concept en de mindset over te nemen, omdat een korte “time to market” cruciaal is om concurrerend te blijven.

De video hieronder geeft een zeer goede introductie tot MVP geïllustreerd door 3 voorbeelden:

TECHNISCHE SCHULD

In onze eerste video zagen we hoe de ontwikkelaar de keuze maakte om slechts een deel van de databaselaag te doen die nodig was om de relevante functionaliteit te leveren. Dergelijke beslissingen kunnen misschien goed zijn, maar het kan ook leiden tot het potentiële gevaar dat te veel niet-afgewerkte onderdelen in de algehele systeemarchitectuur een “technische schuld” hebben.

Technical Debt is een concept geïntroduceerd door een van de Agile Manifesto auteurs, Ward Cunningham. Zoals gezegd, het nemen van korte doorsneden om bijv.  sneller een product op de markt brengen kan een goede beslissing zijn, maar zoals de metafoor impliceert, moet men zich ervan bewust zijn dat er vroeg of laat een schuld moet worden betaald, simpelweg omdat de snelste oplossing in een kort perspectief zelden de meest optimale zal zijn op lange termijn.

Als er geen reden is om een codering short-cut te maken en een snelle en vuile oplossing niet wordt geïmplementeerd om bedrijfswaarde te bereiken, maar simpelweg omdat het team niet ambitieus of bekwaam genoeg is, heeft technische schuld niets te maken met agile methoden en zakelijk denken, dan is het gewoon slecht werk!

In onze ervaring zijn software ontwikkelaars die niet over voldoende vaardigheden beschikken en gericht zijn op kwaliteit de grootste reden voor technische schuld. We zien ook dat de rente op technische schulden enorm is. Door het verhogen van de technische schuld worden wijzigingen in een softwareproduct steeds moeilijker te implementeren, wat gelijk staat aan het doden van het product, omdat een statisch softwareproduct niet kan overleven.

Hier is een inleiding tot technische schuld: