Varför programvaruprojektförseningar inte bör ignoreras

Publicerad

( 23 okt 2020)

En titt på de mest framträdande utmaningar som team står inför när det gäller leverans av programvara – och förslag på hur de kan hantera dessa problem för att hålla projekt på rätt spår.

När dagens företag tävlar om att digitalisera är programvaruutvecklingsteam under ökat tryck för att leverera nya funktioner i hög hastighet . Som ett resultat blir förseningar av mjukvaruprojekt oundvikliga. Det blir ett problem när dessa förseningar behandlas som en “normal” del av livscykeln för programvaruutveckling. Medan en enstaka fördröjning inte nödvändigtvis är orsak till större oro bör förseningar som inträffar om och om igen tas på allvar, eftersom de ofta är ett symptom på en större och farligare orsak.

Programvaruprodukt utveckling är ett komplext, dynamiskt system. I ett välbalanserat system, när nya förfrågningar läggs till produktstocken, i samma takt förvandlas de befintliga förfrågningarna till funktioner som är tillgängliga för kunden. När takten för inkommande förfrågningar är högre än takten för utgående funktioner kommer systemet ur balans. Om vi ​​ignorerar det kommer denna obalans att utvecklas ytterligare och så småningom leda till ett systemfel.

Här är några vanliga orsaker som jag ofta ser i praktiken:

Planering som är för optimistisk

Vi är vanligtvis för optimistiska till sin natur och överskattar hur mycket vi kan göra under en viss tidsperiod. Det här är inte nödvändigtvis en dålig sak. Men om det händer ofta visar det att tidsfrister inte tas på allvar. En viktig smidig princip är att endast programvaruutvecklarna är ansvariga och ansvariga för uppskattningen av ansträngningen. Ännu mer, det är en bra praxis för varje smidigt team att spåra skillnaden mellan det arbete som görs i en sprint och det faktiska arbetet som utförts efter sprinten. Målet är att observera hur framgångsrikt teamet gör förutsägelser över tiden.

Med tanke på komplexiteten i implementeringen

När du planerar de nya sprintfunktionerna är det lätt att förbise de komplexiteter som uppstår under implementeringen. Ganska ofta är dock den förbisedda komplexiteten ett direkt resultat av en komplex programvarudesign. När programvaran har en komplex struktur och det inte finns några tydliga mönster för hur mjukvarumoduler beror på varandra är det omöjligt att ha en bra mental förståelse för hur programvaran fungerar. Detta gör det omöjligt att planera realistiskt. Tyvärr är detta ofta inte lätt att lösa; det kräver dock att man undersöker hållbara sätt att renovera och förbättra programvaran.

Oväntade högprioritetsfel

En defekt i produktionen (ett funktionsfel, prestanda eller säkerhetsproblem) har verkligen hög prioritet och måste åtgärdas omedelbart. Men när den här typen av problem alltför ofta kommer i vägen för att bygga nya funktioner är det ett alarmerande tecken på att något måste förbättras. Detta är ett symptom på betydande tekniska skulder (dvs. kodkvalitetsproblem) som ackumulerats över tiden. Att minska denna tekniska skuld bör ha hög prioritet. annars är det mycket troligt att systemets beteende och produktiviteten i utvecklingen kommer att försämras ytterligare.

Väntar på inmatning från ett annat team

Programvaruprodukter byggs vanligtvis av flera team, där ett team producerar input som krävs av ett annat. Arbetet ska fördelas mellan team på ett sätt som möjliggör ett stadigt informationsflöde i systemet. Fördröjningar orsakade av att vänta på andra lag indikerar att det behövs en bättre lagorganisation för att minimera beroenden mellan dem. Att ha en bra produktledare är central här, någon som övervakar utvecklingen av hela produkten och prioriterar effektivt.

Denna lista är verkligen inte uttömmande och det kan finnas många andra orsaker till förseningar i leverans av programvara. Ändå är frekventa förseningar ett tecken på att du saktar ner lite, hittar orsaken till problemet och får systemet i balans igen.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *