[Wojt]

Jepp det är dyrt i Sverige.

Har man ork att gå igenom utlandet med mycket inkompetens för att hitta guldklimpen så finns det duktiga utvecklare som knackar för 150-200 kr per timma där.

Men det krävs ganska mycket jobb, och du bör även kunna granska koden/arbete själv och inte förlita dig på att de gör rätt. Men den regeln tror jag gäller även i Sverige.

[nosnaj]

Ursprungligen postat av ConnyWesth

Om man ser till större företag så brukar en aktivitet vara i storleksordningen 200 mantimmar i den löpande förvaltningen av applikationer och det är först när man kommer upp i manår (ett manår är ca 1200-1250 mantimmar beroende på bolag) som man brukar lägga upp en "projekt" för en samlad grupp aktiviteter.

När man hyr in konsulter så brukar man specificera ett antal aktiviteter för varje konsult men man är ofta fler personer som jobbar paralellet med olika delar av ett projekt, ibland delar man även upp aktiviteter så det är fler som jobbar med dem. Men det är att föredra att man allokerar en person för varje aktivitet.

Personligen föredrar jag att en aktivitet sk delas upp så den räknas i några dagar eller helt inte mer än någon vecka. Men det beror på vad det gäller för uppgift.

Enligt metoderna Toyotas Lean, Rational/IBMs RUP och KanBan så kan aktiviteterna variera i storlek och även iterationerna, SCRUM har inte den flexibiliteteten utan där har man bestämt att en "sprint" (SCRUMS namn på en iteration) alltid ska vara exakt en viss längd (tror det var 2 veckor).

Jag tycker att en kombination av Lean (generella principer för att hitta och undvika flaskhalsar i produktionsprocesser), RUP (Utvecklingsmetod), PROPS (projektstyrningsmetod) och KanBan(projektstyrningsmetod) är mest intressant. SCRUM (projektstyrningsmetod) är en "hjärnskadad" metod som inte borde användas.

SCRUM fungerar bra om du kan jobba relativt nära med kunden då möten hålls såpass frekvent. Fördelen med denna metod är att man är mer flexibel och kan svänga projektet, något som ofta sker inom webbprojekt. Möjligt det inte fungerar lika bra på stora projekt där man är många utvecklare...har bara erfarenhet upp till ~10st och då var det inga problem.

[tartareandesire]

Ursprungligen postat av ConnyWesth

Vi är nog helt överens om att ett 25-timmars-uppdrag och ett 2 500-timmars-uppdrag har helt olika upplägg.

Men jag hävdar ju dessutom att när vi pratar om ett 25-timmars-uppdrag, så är det knappast frågan om "utveckling", utan mer om installation, konfiguration, support. Det är knappast "utvecklare" som jobbar med den typen av uppdrag utan snarare tekniker- eller support-personal om man ser till hur verksamheten är organiserad i en lite större organisation.

I ett litet små-skutte-företag så gör samma person många olika arbetsuppgifter så bara för att man ägnar 1 timme av ett 25-timmars-uppdrag åt att kopiera 10 rader javaScript-kod och ändra en connectionsträng eller skruva på några CSS-värden för att justera färg och form på en webbsite så blir man inte utvecklare för det. Man är då snarare en installationstekniker. Det är inget fel eller nedvärderande i det (det är bara helt olika yrken) men jag anser inte att det är "utveckling".

Om man tar som jämförelse skillnaden mellan en bilmekaniker och en utvecklare av nya bilmodeller på Volvo eller Wolksvagen, båda yrkesgrupperna arbetar med bilar men de har helt olika yrkesroller, den ena arbetar med bilens underhåll medan den andre "utvecklar" nya bilmodeller (jag gör fortfarande inte någon "nedvärdering" av endera yrket, men man måste ändå skilja dem åt för det är helt olika kompetenser som krävs).

Okej, det kanske mest handlar om en definitionsfråga då. Jag kallar det för utveckling oavsett om det handlar om ett stort projekt byggt från grunden eller om det gäller vidareutveckling eller nyutveckling av ett fåtal funktioner. Även i större koncerner så är det idag ganska vanligt med bred kompetens och växlande arbetsuppgifter då de ofta är uppdelade på ett stort antal mindre bolag. Så är det exempelvis inom de större mediekoncernerna idag vilka äger de flesta större webbplatser.

[pelmered]

Ursprungligen postat av ConnyWesth

Om man ser till större företag så brukar en aktivitet vara i storleksordningen 200 mantimmar i den löpande förvaltningen av applikationer och det är först när man kommer upp i manår (ett manår är ca 1200-1250 mantimmar beroende på bolag) som man brukar lägga upp en "projekt" för en samlad grupp aktiviteter.

När man hyr in konsulter så brukar man specificera ett antal aktiviteter för varje konsult men man är ofta fler personer som jobbar paralellet med olika delar av ett projekt, ibland delar man även upp aktiviteter så det är fler som jobbar med dem. Men det är att föredra att man allokerar en person för varje aktivitet.

Personligen föredrar jag att en aktivitet sk delas upp så den räknas i några dagar eller helt inte mer än någon vecka. Men det beror på vad det gäller för uppgift.

Enligt metoderna Toyotas Lean, Rational/IBMs RUP och KanBan så kan aktiviteterna variera i storlek och även iterationerna, SCRUM har inte den flexibiliteteten utan där har man bestämt att en "sprint" (SCRUMS namn på en iteration) alltid ska vara exakt en viss längd (tror det var 2 veckor).

Jag tycker att en kombination av Lean (generella principer för att hitta och undvika flaskhalsar i produktionsprocesser), RUP (Utvecklingsmetod), PROPS (projektstyrningsmetod) och KanBan(projektstyrningsmetod) är mest intressant. SCRUM (projektstyrningsmetod) är en "hjärnskadad" metod som inte borde användas.

Jag har mycket stor respekt för ditt kunnande inom det mesta Conny, men när det gäller utvecklingsmetodik har du en väldigt ålderdomlig syn.

Mer eller mindre hela IT-branschen har anammat agila utvecklingsmetoder där man jobbar i små utvecklingsteam och i korta iterationer. Av alla utvecklingsmetoder är Scrum den mest utbredda och en av mest hyllade. Att säga att det är en hjärnskadad metod visar bara din ignorans på det här området. En viktig sak att poängtera är att de flesta av dessa utvecklingsmetoder bara är ramverk för hur man ska lägga upp saker och det finns väldigt stora möjligheter att anpassa metoderna efter verksamheten och den kompetens man har i teamet. I Scrum är det t.ex. inga problem att välja den sprintlängd som passar bäst, det kan vara allt mellan 1 vecka till 1 månad, eller i undantagsfall ännu längre. Scrum ÄR väldigt flexibelt.

RUP är däremot en väldigt föråldrad utvecklingsmetod även om det finns många bra delar som fortfarande är väldigt användbara, men inte riktigt på samma sätt. RUP förespråkar till stor del vattenfallsmodellen(även om det utvecklats en hel del iom agil-vågen) som de allra flesta har dömt ut på grund av dess inflexibilitet och för att det blir väldigt mycket oproduktivt arbete som inte skapar värde(waste/muda i lean terminologi). Man kan plocka ut guldkornen ut RUP och använda dem agilt. T.ex. kan ett klassdigram vara ett levande dokument som gör ändringar i allteftersom man implementerar klasserna istället för att försöka tänka igenom allt på förhand och spika det innan man börjar med implementationen. RUP har givetvis flera tillämpningsområden och passar väldigt bra i vissa projekt. Jag tänker främst på stora projekt där man vet vad man vill ha och det inte finns så mycket osäkerhet eller risk för att kraven kommer att ändras, t.ex. banksystem. Vid utveckling av nya innovativa lösningar måste man vara mer lättrörlig så att man hantera ändrade förutsättningar och därmed krav på ett effektivt sätt med minimalt med spill och bortkastat arbete.
Innovativa företag som t.ex. Facebook och Google måste jobba väldigt agilt för att kunna upprätthålla innovationskraften medan banker oftast inte jobbar speciellt agilt eftersom det viktigaste där är stabilitet och att lösningarna är väldigt välgenomtänkta och vältestade.

Att kombinera Scrum och Kanban är ofta en enormt lyckad kombination. Här är en kort video om det: http://www.youtube.com/watch?v=0EIMxyFw9T8

[Conny Westh]

Ursprungligen postat av ITisGood.se

Jag har mycket stor respekt för ditt kunnande inom det mesta Conny, men när det gäller utvecklingsmetodik har du en väldigt ålderdomlig syn.

Mer eller mindre hela IT-branschen har anammat agila utvecklingsmetoder där man jobbar i små utvecklingsteam och i korta iterationer. Av alla utvecklingsmetoder är Scrum den mest utbredda och en av mest hyllade. Att säga att det är en hjärnskadad metod visar bara din ignorans på det här området. En viktig sak att poängtera är att de flesta av dessa utvecklingsmetoder bara är ramverk för hur man ska lägga upp saker och det finns väldigt stora möjligheter att anpassa metoderna efter verksamheten och den kompetens man har i teamet. I Scrum är det t.ex. inga problem att välja den sprintlängd som passar bäst, det kan vara allt mellan 1 vecka till 1 månad, eller i undantagsfall ännu längre. Scrum ÄR väldigt flexibelt.

RUP är däremot en väldigt föråldrad utvecklingsmetod även om det finns många bra delar som fortfarande är väldigt användbara, men inte riktigt på samma sätt. RUP förespråkar till stor del vattenfallsmodellen(även om det utvecklats en hel del iom agil-vågen) som de allra flesta har dömt ut på grund av dess inflexibilitet och för att det blir väldigt mycket oproduktivt arbete som inte skapar värde(waste/muda i lean terminologi). Man kan plocka ut guldkornen ut RUP och använda dem agilt. T.ex. kan ett klassdigram vara ett levande dokument som gör ändringar i allteftersom man implementerar klasserna istället för att försöka tänka igenom allt på förhand och spika det innan man börjar med implementationen. RUP har givetvis flera tillämpningsområden och passar väldigt bra i vissa projekt. Jag tänker främst på stora projekt där man vet vad man vill ha och det inte finns så mycket osäkerhet eller risk för att kraven kommer att ändras, t.ex. banksystem. Vid utveckling av nya innovativa lösningar måste man vara mer lättrörlig så att man hantera ändrade förutsättningar och därmed krav på ett effektivt sätt med minimalt med spill och bortkastat arbete.
Innovativa företag som t.ex. Facebook och Google måste jobba väldigt agilt för att kunna upprätthålla innovationskraften medan banker oftast inte jobbar speciellt agilt eftersom det viktigaste där är stabilitet och att lösningarna är väldigt välgenomtänkta och vältestade.

Att kombinera Scrum och Kanban är ofta en enormt lyckad kombination. Här är en kort video om det: http://www.youtube.com/watch?v=0EIMxyFw9T8

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.

[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.

[tartareandesire]

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".

Fel. Det är samma ord (från latinets ignorare) och kan användas på samma sätt i bägge språken även om det i vardagligt tal fått en liten annan utveckling i Sverige.

Ursprungligen postat av ConnyWesth

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.

I så fall är det förmodligen inte systemutveckling enligt din definition som de flesta av oss här på WN arbetar med dagligen helt enkelt. Din spetskompetens har legat utanför webben medan det omvända gäller majoriteten här. Då blir det ganska naturligt en del skilda åsikter eftersom det har varit två vitt skilda världar (som dock närmat sig varandra under senare år). När en fråga ställs här gällande utveckling så handlar det med största sannolikhet om webben om inget annat anges. Därför blir det en del "vilda" reaktioner när du applicerar för denna verksamhet tämligen irrelevanta arbetssätt. Var sak har sin plats helt enkelt.

[P3N]

Snacka om att detta blev en höna av en fjäder...
Men om det nu redan gått som det har. Så kan ju jag ha lite kul och skriva av mig också :-)

Min syn på timpengen:
Det är ju bara är att konstatera att alla uppdrag är olika och behöver olika kompetens. Ju svårare att få tag i kompetensen ju dyrare lär det ju vara speciellt om personen som behövs vet om dess egna specifika värde... Att sätta ett pris på en timpeng blir ju därmed också tämligen svårt. Då det givetvis beror på uppgiften och om personen som tillfrågas vet om att behovet är större än tillgången osv osv. Dvs, vi är tillbaka på den gamla regeln om tillgång och efterfrågan :-).

Min syn på olika processer:
Vad gäller olika sätt att jobba kan jag bara konstatera att det finns ett otal sätt att tjäna pengar på genom att sälja processer med instruktioner på hur företag skall jobba. Ja, det är Big Business... Med många aktörer som vill ha sin del av kakan för att lära ut DERAS arbetssätt för att få jobbet gjort. Finns en hel del företag som lever enbart på detta. Och det mesta de lär ut är egentligen bara common sense/logik. En företagsidé med väldigt låga kostnader men med oförskämt bra payback... Samtidigt kräver oftast dessa processer en massa extra arbete framförallt initialt för ett företag. Men med en stark ledning kan den med tiden slimmas för att passa det som företaget egentligen behöver... Finns en massa exempel på att de processer som lärs ut faktiskt inte alltid bara är av godo eller på något sätt felfria (exempelvis Toyotas återkallning av bilar efter försäljning... Trots att de använt "perfekt" metodik sen lång tid tillbaka).
Ibland har man en känsla av att företag tror att de blir mer konkurrenskraftigt om de jobbar som någon annan gör. Men det ligger i sakens natur att vi alla är olika och därmed också inte kan passa in i en och samma process. Sen kan man ju också konstatera att för att vara unik och lyckas lite extra kan man inte vara som alla andra... Så varför eftersträva det då?

Ta godbitarna ur processerna och gör det som passar. Lägg sen till lite eget "salt" så lär det "smaka" bättre :-)

Så, då har jag fått prata av mig också :-)

[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.

[Conny Westh]

Jag föreslår att metodiktfrågorna flyttas till en ny tråd....
Detta meddelande kan raderas efter åtgärd (utan att jag blir sur eller känner mig kränkt)....