Blogg | Knowit

Felet med RUP

Skriven av Staffan Melin | Apr 9, 2014 10:00:00 PM

Rational Unified Process, eller RUP som det ofta kallas, är knappast något nytt. Det är en mjukvaruutvecklingsapproach som är tänkt att vara iterativ och väldigt use case-fokuserad. Den går att beskriva på en mängd andra sätt också och frågar du två personer vad RUP är får du antagligen inte samma svar. Att använda sig av en strukturerad process är alltid bra och det finns många fördelar med RUP, vilket troligen är anledningen till att så många företag fortfarande stödjer sig på RUP i sin utvecklingsprocess. Men det finns en sak som jag verkligen stör mig på.

Det här är hämtat från "The Rational Unified Process made easy", Per Kroll & Philippe Kruchten:

”Stay focused on executable software. Documents, designs and plans are all good, but they are a poor indication of true progress because their evaluation is subjective and their importance is secondary compared to the code itself. Executable code that compiles and successfully passes tests is the best indication of progress.”

Fokus på kod är något jag inte alls gillar. Först och främst tar man helt bort fokus från det som är viktigt – levererat värde till intressenter. De bryr sig inte ett dugg om koden i sig, de bryr sig om vad den gör för att förbättra deras tillvaro. Men det är inte det enda problemet. Levererade funktioner är inte värda ett dugg om ingen vill ha dem. Man kan leverera hur mycket fungerande kod som helst utan att möta ett enda av intressenternas behov.

Att mäta framgång i levererad fungerande kod är inte ett sätt att fokusera på värdeskapande. Jag vill gå så långt som att påstå att det snarare motverkar möjligheten till värdeskapande för intressenterna. Det här är en stor anledning till att IT-projekt blir försenade och drar över budget. Det sker en massiv överutveckling av funktioner som ingen är beredd att betala för, eftersom fokus ligger på levererad fungerande kod. Det finns flera undersökningar som visar att nästan hälften av all funktionalitet som utvecklas aldrig används. Aldrig. Hälften av allt som utvecklas borde alltså aldrig ha utvecklats. Man inser lätt hur mycket tid och resurser man kunde sparat på det.

Allting vi utvecklar måste kunna kopplas till ett ökat värde för våra intressenter. Därför är det också där vi ska lägga vårt fokus och det är det vi ska mäta.

/Staffan Melin, Require AB