[Conny Westh]

Ursprungligen postat av ITisGood.se

Det jag menade med "ignorant" var just det, att du inte vill ta till dig de nya metoderna som kommer, inte att du är okunnig eller saknar kompetens.

Angående RUP har du säkert rätt. Större delen av min erfarenhet av RUP som process kommer ifrån mina universitetsstudier och där fick jag en ganska negativ bild av det som en utvecklingsprocess. Men det kanske berodde på mer på utbildningens uppbyggnad än RUP som metod.

Min största invändning emot RUP är just det som beskrivs tydligt i Wikipedia-artikeln du länkade till - de fyra faserna som måste genomföras varje iteration och att fokuset enligt RUP ska ligga på de två första faserna (Inception och Elaboration). Det står ju till och med såhär i Wikipedia-artikeln:
Visst är det bra att undersöka saker innan men i RUP går det till överdrift. Hur kan förberedelsen inför en uppgift vara viktigare än själva uppgiften. Ett mycket bättre sätt för både projektet och beställaren(kunden) är, enligt mig, att lägga tiden på en prototyp, s.k. rapid protoyping. Det innebär att man snabbt slänger ihop en prototyp(gärna en klickbar) så att kunden kan få en bild av hur slutresultatet kan komma att se ut och att man redan här kan börja ta in feedback. Med RUP känns det som konstruktionsfasen sällan utgör mer än 50% av all arbetstid, medan man i Scrum förmodligen nästan alltid hamnar över 80%. Det skulle jag absolut inte vilja betala för som kund om man säger så.

Min andra invändning är kravet på att producera massa artefakter som i slutändan inte bidrar med speciellt mycket värde varken för kunden eller utvecklarna(massa dokument och modeller). Jag säger inte att det är dåligt med dokument, men jag tycker fokuset i RUP verkar vara att producera dokument och modeller snarare än att utveckla systemet många gånger vilket jag tycker är idiotiskt, eller "hjärnskadat" om man ska använda ditt uttryck. Att man sedan "måste" leverera dessa artefakter innan man kan börja implementera är ofta bortkastad tid. Jag ser mer värde i att dokumentera under tiden man jobbar eller efter när man vet hur systemet är uppbyggt än att man tvunget ska göra det innan man kan börja implementera för att testa sina antaganden emot verkligheten snarare än teorin.

Givetvis finns det problem med Scrum, men det gör det med alla metoder.
Scrum har inte några direkta regler utan man tar de metoder man gillar och ändrar på de man inte gillar. Det finns många anledningar till att man har fasta sprintlängder, t.ex. att man kan mäta scrum velocity med en burndown chart och att man får kontinuitet som gör det enklare att planera. Att ha daglig uppföljning och många leveranser gör också att att man blir mer motiverad. Vid leverans levererar man bara de user sories som är helt klara vilket gör att det inte blir så krystade leveranser, åtminstone inte om man planerar bra.
Vill man inte ha fasta sprintlängder finns en metod som kallas Scrum-ban, vilket är en kombination av Scrum och Kanban utan fasta sprinttider men där man har bland annat har scrummöten.

Problemet är att du helt har missuppfattat hur man kan använda RUP, faserna är inte det viktiga i sig, det är iterationerna i RUP som motsvarar sprintarna i SCRUM, faserna är mer en överblick för stora projekt för att visa på att man i olika faser jhar olika fokus, men som det TYDLIGT framgår i wikipediaatriklen om RUP så har man exempelvis kravhantering under HELA projektet, man har implementation (dvs i princip kodning) likväl under i stort sett hela projektet.

Inceptionfasen motsvarar begreppet Förstudie och det är vanligt att man har helt egna projekt för det. Det är vanligt att en förstudie aldrig kommer vidare och blir ett system, eftersom det kanske beräknas ge för liten avkastning på investeringen ellr innebär för stor risk. Eftersom man i RUP har inkluderat denna fas i metoden så täcker den en större del av ett systems livscykel än vad SCRUM gör. SCRUM verkar enbart vara inriktad på motsvarigheten till konstruktionsfasen i RUP. SCRUM har inte ens med detta i sitt koncept.

I RUP finns även Deployment med, det finns även ytterliagre en fas som kallas maintenance men den brukar inte tas med när man pratar om utvecklingen eftersom den är "förvaltningsfasen" (Men skateverket har enstor och viktig användning av den fasen eftersom de flesta sstem de har lever under så lång tid, men det sker ständiga förändringar).

Prototyping är en av hörnstenarna i RUP så att sätta prototyping och RUP i motsats till varandra är helt enkelt en missuppfattning.

Jag har även gått på systemutvecklingskurser på universitetet och de har en generel missuppfattning om vad RUP är och hur den fungerar. RUP är by definition mer flexibel än SCRUM för att ta ett exempel. Den lärare jag hade på universitetet förstod inte RUP så vi hamnade i konflikt om just det. Jag har nämligen gått utbildning i just RUP och då specifikt OOAD-kursen (OOAD => object Oriented Analysis and Design) och det kändes pinsamt att de på universitetet hade så dålig koll på en av nutidens mest kända och använda systemutvecklingsmetoder.

De använde samma argument som du använder, men det är många utav styrkorna med RUP att den är iterativ, inkrementell, och att man använder prototyping och TIDIGA leveranser, testa de högsta riskerna först m.m.

Faserna i RUP beskriver INTE en vattenfallsmodell, det är en helt felaktigt uppfattning. det är iterationerna som är grunden, med leverans av KÖRBARA program vid VARJE iterations slut.

Programkod är en artefakt! En artefakt är en leverabel, dvs programkod eller en exekverbar programfil, eller vad som önskas efter varje iteration. Ja fokus ligger på Leveranser av artefakter (dvs i princip körbara program).

RUP är dessutom så komplett och flexibelt byggt att det fungerar att skala upp från de minsta appar man utvecklar för mobilen till jätte-bauta-appar för USAs försvarsdepeartements logistiksystem (som i sig är en jätte-bauta-big app, det finns säkert fler som jag inte känner till).

RUP bygger dessutom på att ständigt ta in ny kunskap och nya erfarenheter (det är aktiv del av hela konceptet), något som kallas "Best Practises", dvs vilket betyder den bästa kunskap vi känner till just nu.

RUP är dessutom en "Systemutvecklingsmodell" vilket INTE SCRUM är, SCRUM är en "projektstyrningsmodell", det finns inte ett ord om HUR man ska bygga ett system i SCRUM. RUP är däremot mycket fokuserad på att beskriva HUR man ska bygga ett system för att det ska bli bra.