Vassfall vs. Smidig: Kva metodikk ska du välje för dina Redmine-prosjekt?

Ibland hör jag rop som "Gantt er död", "du måste köra det på ett smidigt sätt" eller till och med "projektledelse är död". Själv om många av dem bara är exempel på marknadsföringssvada, möter jag ofta projektporteføljeförvaltere, scrum-mestere och andra projektledelsesprofessionella som vill diskutera seriøst om Smidig vs. Vannfall (Gantt) tekniker. Detta inlägg är en kort introduktion till ämnet. Jerntriangelet för projektledelse är faktiskt en väldigt enkel representation av de viktiga elementen som behövs för framgångsrik projektplanlegging. Omfang, tid och kostnad/resurser. Ressurser är de enda og/eller kritiska elementene i priset i många bransjer. Människor är den mest värdefulla delen som inte kan ökas, reduceras eller multipliceras enkelt. På samma sätt har maskinresurser och viss produktionskapacitet och kan inte ändras med ett enkelt klicka. Men hur passerar jerntriangelet inn i det stora bilden? Veldig praktisk. Det ger oss ett enkelt, men effektivt svar på när vi bör använda planlegging av Vannfallsmetodikken och när vi däremot bör välja en smidig tillnärming. Vannfallsmetodikken passerar bäst till ett projektomfång är presist definierade och är nyckelelement i projektet, till exempel fastighetsbyggnad, konferensplanlegging eller implementering av Easy Redmine-programvare. Teknik: Omfanget av projektet är definierat (snabbt). I vårt exempel betyder detta att jag inte kan ändra antalet fönster i fastigheter min, jag kan inte ändra platsen eller ämnet för en konferens osv. Prosjektets tid är en begränsad faktor antingen absolutt (f.eks. konferenser) eller nästan absolutt (f.eks. programvaraimplementering). Med ett tydligt definierat omfång är huvuduppgiften till en projektledare eller porteføljeförvalter att planera alla typer av resurser på tidslinjen för parallella projekt och ta hänsyn till den nödvändiga rekkeföljen av hanteringen (uppgiften) i individuella projekter. Tenk till exempel på byggnaden av och hus: arbetare ansvariga för sementleveranser måste fullføre arbetet sitt i rätt tid, eftersom fördröjning orsakat av brist på sementresurser kan hindra murare i att fullgöra sina egna uppgifter. När betongen är snabb nok, kan de redan vara på en annan byggplats. En smidig tillnärming är användbar för projekter där tid är noggrann definierad, resurser är en lösningsfaktor och omfattning som återställs för planlegging (prioritering). Ett gott exempel kan vara programutveckling (sprint), publiseringsaktivitet (data för utgivning av magasin/avis) eller marknadsföringsinnhold (kampanj). Teknik: Scrum-mestere eller planerare i liknande roller prioriterade uppgifter för nästa sprint. Vanligvis har scrum-mesteren olika uppgiftslister och scrum-boards för olika typer av resurser, t.ex. utvecklare som vill hitta fel och hantera ledare för nya funktioner, och på andra sidan journalister i politiska eller sportsmedia.

Kva betyder det?

Upplagt, hela problemstillinga med projektleiing dreiar seg framleis runt den jarntriangelet. Operationell planläggning fokuserar mer på olika delar av detsamma. Kva kan vi dra ut av det?

1. Nesten i vår organisation vill vi hitta ett typprojekt där det är nödvändigt att använda både projektledningstekniker för att skapa effektiva arbetsprocesser. Den ene metoden är inte bättre än den andre, den handterer berre olika utmaningar.
   
   
2. Kvalitetssäkring av resursplanlegging som används för tidslinjen är väsentligt för ett vattenfallsprojekt, speciellt för projektportföljplanlegging. Det samma gäller för lätt Redmine-projekt.
   
   
3. Styrning av smidigt projekt: Styrning av prioritering görs genom olika verktyg. Ofta är det ett problem med mycket ressursallokering för en specifik eftersläpning. Så, i denna samanhengen, rekommenderar t.ex. sterkt att du kartlegg och allokerer ressursane dina konsekvent. Til dømes kan ein programutviklar bli använd med fleire backlogs samtidig (f.eks. feilrettingar vs. funksjonsforespurnader på samma språk). Men utan att definiera kvantitativ resursallokering till eftersläpningar, vill du inte kunna planera prioriterade leveranser, och scrum masteren måste ständigt avvika mellan dess prioritering. En annan ohellig konsekvens kommer att vara forseinka lansering av nya viktiga produktfunktioner som f.eks. felrettingar eller funktionskrav, som utnyttar strategiska utvecklingsressursar.

Kombination av begge styringsmetodane

Som du kan se på biletet nedanför, har vi ett grundläggande Waterfall-projekt som innehåller ett programutvecklingsplan som visar sekvenser och beroendeheiter. Men teama som är involverade i detta projekt (seljarar, tekniska skribentar) kan handtere sina eigne leveransar i deira avdelningen inte berre slik det är vist i detta exempel, men också på ett smidigt sätt.

Lätt Redmine Gantt - Vattenfall-projekteksempel