9.0 Vattenfall vs. cyklisk projektledning (del 2) – Uppskattning av tid och resurser

Vattenfallstekniken är indelad i etapper. Projektledare måste inkludera uppskattningar för hur mycket tid (och därmed pengar) som krävs för varje steg i sina projektplaner. Vi har tidigare konstaterat att tidsuppskattningar i sig är problematiska för alla projekt, mycket mer när de måste sättas tidigt i projektets livslängd. Det är helt enkelt inte möjligt för programvaruprojekt. Överväg möjligheten att en kvalitativt godtagbar lista över förmågor kan sammanställas under definitionsfasen. I princip bör detta göra det möjligt för projektgruppen att ge en realistisk uppskattning av den tid som krävs för att utveckla varje funktion. Men i verkligheten finns det för många osäkerheter för att ge en rättvis uppskattning:

Men i verkligheten finns det för många osäkerheter för att ge en rättvis uppskattning:

  • Ofta, efter att en funktion har utvecklats, upptäcks det att klienten inte behöver den. Därför kan timmarna som ägnas åt att utveckla denna funktion anses vara förgäves.
  • Under hela projektets gång kan kraven ändras.
  • Ska kapaciteten tillhandahållas till en hög kostnad eller till en låg kostnad? Det finns många implementerings- och realiseringstekniker.
  • Hur kommer funktionaliteten att utformas tekniskt? Designen påverkar i hög grad hur lång tid som krävs för att skapa den.
  • I vilken utsträckning måste funktionen vara av hög standard? Till exempel, ska en webbapplikation vara helt tillgänglig hela tiden, eller ska den få ligga nere några timmar per år?
  • Den tid som krävs för att upptäcka och korrigera programvaruproblem varierar från minuter till veckor.
  • Hur lång tid tar den nya mjukvaran att installera och integrera med kundens nuvarande system?
  • Brist på information om potentiella lösningar påverkar ytterligare tidsuppskattningar. Dessutom är det utmanande att uppskatta den tid som krävs för att skaffa den nödvändiga expertisen.

Listan ovan visar att en mängd olika variabler kan påverka hur lång tid det tar att utveckla en ny mjukvara. Uppskattningar av den tid som krävs för att utveckla en funktion i början av ett projekt är ofta fyra gånger för låga eller fyra gånger för höga. Detta innebär att tidsåtgången kan vara fyra gånger mer eller fyra gånger kortare än en felaktig uppskattning. Allt eftersom projektet utvecklas blir dessa uppskattningar mer exakta. Efter att den funktionella designen är klar minskas marginalen till 25 % för mycket eller för lite. Först när funktionen har utvecklats är det möjligt att ge en uppskattning med hög grad av tillförsikt.

Programvarorisker #

Programvara för projektledning kommer aldrig att vara helt felfri. Även för välkända program som används ofta (t.ex. Word, Excel, Explorer, OS X, PHP och Flash) har Internet listor över kända brister. Regelbundet görs nya versioner tillgängliga på marknaden som fixar programvarubuggar. Kunder kräver ibland att programvaran ska vara felfri. Men i verkligheten skulle ett sådant mål göra det omöjligt att slutföra en mjukvara. Dessutom är programvarufel ofta inte inneboende i programmet.

Flash användes för att skapa ett instruktionsspel. Klienten gick med på att hämta spelet som en fil och installera det på sin egen server. Under projektets gång bad kunden att en funktion med höga poäng skulle läggas till spelet för att förbättra spelarens konkurrenskraft. Detta skulle behöva lite PHP-skriptkod. Spelutvecklarna utvecklade och testade skriptkoden på sin egen server som kör Linux. Det var lyckat. Klienten fick spelet och skriptkoden. Klienten använde dock en Windows-server och av någon anledning slutade skriptet att fungera korrekt. De bästa betygen behölls inte. Programmeraren behöver i slutändan en vecka för att åtgärda problemet. Det visar sig att PHP och Windows inte alltid fungerar bra tillsammans. Manuset i sin helhet hade inga misstag alls! Han kunde få det att fungera med hjälp av ett hack, och alla var nöjda – men vem skulle betala för den extra veckans arbete?

Ett annat mjukvaruutvecklingsprojekt inkluderade också skapandet av instruktionsapplikationer. Problemet var att programvaran fungerade utmärkt för utvecklarna men inte bra för klienten. Efter att ha uttömt alla andra möjligheter, bestämde sig programmeraren för att besöka kunden. Det visade sig att kunden körde en Pentium III-maskin från början av 1990-talet. Datorns långsamhet bidrog till programvarans dåliga prestanda. Dessutom testade programmerarna programvaran på en Pentium III, och det fungerade bra. Ytterligare undersökningar visade att kundens dator gick långsamt på grund av en virus- och spionprograminfektion.

Hantera osäkerheter i projektutveckling #

Osäkerheten som visas av fallen ovan komplicerar processen för utveckla projektplaner . Dessutom försvårar det förhandlingarna mellan parterna. Någon måste bära de risker som är förknippade med det extra arbete som måste utföras. Om betalning sker per timme står kunden för all risk. När man kommer överens om en fast avgift (som är fallet med bidragsfinansierade projekt) står mjukvaruutvecklaren för risken. När det är fler än två personer inblandade blir situationen mer komplex. Vem ska i detta scenario stå för kostnaden för de extra timmarna som arbetats med projektet?

Det uppstår ofta tvister om vem som ska hållas ansvarig för förseningar. Ofta är den ansvarige personen svår att identifiera. Det är mycket tänkbart att ingen av de inblandade parterna är skyldiga, eftersom “förseningen” orsakades av en felaktig initial uppskattning av antalet timmar som krävs. Överdrivna projekttimmar och frågan om vem som ska betala är vanliga orsaker till stridigheter inom informationsteknologibranschen.