Waarom vertragingen in softwareprojecten niet mogen worden genegeerd

( 23 oktober 2020)

Een blik op de meest prominente uitdagingen waarmee teams worden geconfronteerd bij het leveren van software – en suggesties voor hoe ze deze problemen kunnen beheren om projecten op schema te houden.

Terwijl de bedrijven van vandaag racen om te digitaliseren, staan ​​softwareontwikkelingsteams onder toenemende druk om nieuwe functies met hoge snelheid te leveren . Als gevolg hiervan worden vertragingen in softwareprojecten onvermijdelijk. Het wordt een probleem wanneer deze vertragingen worden behandeld als een “normaal” onderdeel van de levenscyclus van softwareontwikkeling. Hoewel een enkele vertraging niet per se reden tot grotere bezorgdheid hoeft te zijn, moeten vertragingen die keer op keer voorkomen serieus worden genomen, omdat ze vaak een symptoom zijn van een grotere en gevaarlijkere hoofdoorzaak.

Softwareproduct ontwikkeling is een complex, dynamisch systeem. In een goed uitgebalanceerd systeem worden, terwijl nieuwe verzoeken aan de productachterstand worden toegevoegd, in hetzelfde tempo de bestaande verzoeken omgezet in functies die beschikbaar zijn voor de klant. Wanneer het tempo van inkomende verzoeken hoger is dan het tempo van uitgaande functies, raakt het systeem uit balans. Als we het negeren, zal deze onbalans verder toenemen en uiteindelijk leiden tot een systeemfout.

Hier zijn enkele veelvoorkomende oorzaken die ik vaak in de praktijk zie:

Te optimistische planning

We zijn meestal te optimistisch van aard en overschatten hoeveel we kunnen doen in een bepaalde tijdsperiode. Dit hoeft niet per se een slechte zaak te zijn. Als het echter vaak gebeurt, toont het aan dat het halen van deadlines niet serieus wordt genomen. Een belangrijk agile principe is dat alleen de softwareontwikkelaars verantwoordelijk en aansprakelijk zijn voor de schatting van de inspanning. Sterker nog, het is een goede gewoonte voor elk agile team om het verschil bij te houden tussen het werk dat in een sprint moet worden gedaan en het daadwerkelijke werk dat na de sprint is gedaan. Het doel is om te zien hoe nauwkeurig het team voorspellingen doet in de loop van de tijd.

De complexiteit van de implementatie over het hoofd zien

Bij het plannen van de nieuwe sprintfuncties is het gemakkelijk om de complexiteit die tijdens de implementatie ontstaat over het hoofd te zien. Vaak is de over het hoofd geziene complexiteit echter een direct gevolg van een complex softwareontwerp. Als de software een complexe structuur heeft en er geen duidelijke patronen zijn over hoe softwaremodules van elkaar afhankelijk zijn, is het onmogelijk om een ​​goed mentaal begrip te hebben van hoe de software werkt. Dit maakt het onmogelijk om realistisch te plannen. Helaas is dit vaak niet eenvoudig op te lossen; het vereist echter zeker onderzoek naar haalbare manieren om de software te renoveren en te verbeteren.

Onverwachte defecten met hoge prioriteit

Een defect in de productie (een feature bug, prestatie of beveiligingsprobleem) heeft zeker een hoge prioriteit en moet onmiddellijk worden aangepakt. Maar wanneer dit soort problemen het bouwen van nieuwe functies te vaak in de weg staat, is dit een alarmerend teken dat er iets moet worden verbeterd. Dit is een symptoom van aanzienlijke technische schulden (d.w.z. problemen met de codekwaliteit) die in de loop van de tijd zijn opgebouwd. Het verminderen van deze technische schuld moet een hoge prioriteit hebben; anders is het zeer waarschijnlijk dat het systeemgedrag en de productiviteit van de ontwikkeling verder ernstig zullen verslechteren.

Wachten op input van een ander team

Softwareproducten worden meestal gebouwd door meerdere teams, waarbij het ene team input produceert die door een ander wordt gevraagd. Het werk moet zo onder de teams worden verdeeld dat er een gestage informatiestroom in het systeem mogelijk is. Vertragingen veroorzaakt door wachten op andere teams geven aan dat een betere teamorganisatie nodig is om de onderlinge afhankelijkheid te minimaliseren. Het hebben van een goede productleider staat hier centraal, iemand die toezicht houdt op de voortgang van het hele product en effectief prioriteiten stelt.

Deze lijst is zeker niet uitputtend, en er kunnen veel andere redenen zijn voor vertragingen bij de levering van software. Niettemin zijn regelmatige vertragingen een teken dat u wat langzamer gaat werken, de hoofdoorzaak van het probleem opspoort en het systeem weer in balans brengt.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *