Citat:
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