[pelmered]

Ursprungligen postat av ConnyWesth

För det första Ignorera betyder att strunbta i på svenska, att vara ignorant betyder att vara en person som struntar i något (på svenska).

På engelska betyder "Ignorant" att man är "okunnig" eller "saknar kompetens".

Din beskrivning av RUP bevisar bara att du inte har en aning om vad du pratar om! RUP var en föregångare när det gäller korta utvecklingscykler, iterativ och inkrementell utveckling. RUP är extremt flexibel som metod och det finns inte ett spår av vattenfallsmodell inom RUP. RUP är även en verktygslåda med färdiga definitioner som man kan använda OM MAN VILL. Men det finns inte mycket man MÅSTE göra annat än iterationer, inkrementellt och iterativt utvecklingsarbete, samt att man levererar s.k. artefakter (leverabler). Ett viktigt dokument i RUP är SAD (Software Architecture Document).( Se detaljer om metoden på Wikipedia: http://sv.wikipedia.org/wiki/Rational_Unified_Process )

Det finns faser där man fokuserar på olika saker men de är i högsta grad flytande från projekt till projekt.

SCUM har by definition satt in Timeboxing så att man alltid måste hålla samma längd på sprintarna vilket gör att man "by definition" måste skapa ganska krystade leveranser och om du följer med i nyhetsforumen på internet så klagar folk på just detta som ett stort problem med SCRUM. Om du anpassar längden på en sprint så följer du inte SCRUM-metoden och bör inte hävda det. Då har du ju insetta tt den inte funkar som den är "out-of-the-box" som det hävdas att den ska göra utan du måste anpassa den så den blir mer likt RUP med sin flexibla inställning till hela utvcklings-processen.

Agile RUP: http://www.agilemodeling.com/essays/...odelingRUP.htm (RUP ur en agil synvinkel)
Se detaljer om Toyota LEAN Production: http://sv.wikipedia.org/wiki/Lean_production
Se detaljer om KanBan: http://www.crisp.se/gratis-material-och-guider/kanban
Se detaljer om SCRUM: http://sv.wikipedia.org/wiki/Scrum

Jag är specialist på systemutveckling och systemutvcklingsmetoder så kom inte med idiotiska kommentarer om att jag inte vet vad jag pratar om eller att jag har ett förlegat synsätt på arbetsmetoder inom systemutveckling. Då gör du dig själv bara till åtlöje.

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:

IBM Rational Software menar att etableringsfasen är den viktigaste av de fyra faserna. Vid fasens avslutande är analys och design av systemet färdigställt. Val görs om det är möjligt och rimligt att gå vidare med konstruktions- och överlämningsfaserna. Precis som i förberedelsefasen bör projektet avbrytas eller tänkas igenom igen om inte fasen avslutas på ett fullgott sätt.

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.