Vassfall vs. Smidig: Kva metodikk skal du velje for dine Redmine-projekt?

Nogle gange hører jeg rop som "Gantt er død", "du må køre det på den smidige måde" eller til og med "projektledelse er død". Selv om mange af dem bare er eksempler på markedsføringssvada, møder jeg ofte projektporteføljeforvaltere, scrum-mestere og andre projektledelsesprofessionelle som ønsker at diskutere seriøst om Smidig vs. Vannfall (Gantt) teknikker. Dette indlæg er en kort introduktion til emnet. Jerntriangelet til projektledelse er faktisk en meget enkel repræsentation af de vigtige elementer, der er nødvendige for en vellykket projektplanlægning. Omfang, tid og omkostning/ressourcer. Ressurser er de eneste og/eller kritiske elementer i prisen i mange bransjer. Mennesker er den mest værdifulde egenskab som ikke kan øges, reduceres eller multipliseres enkelt. På samme måde har maskinressourcer en vis produktionskapacitet og kan ikke ændres med et enkelt klik. Men hvordan passer jerntriangelet inn i det store billede? Veldig praktisk. Det giver os et enkelt, men effektivt svar på, når vi bør bruge planlægning af Vannfallsmetodikken og når vi derimod bør vælge en smidig tilnærming. Vannfallsmetodikken passer bedst til et projekt, hvis omfang er presist defineret og er et nøgleelement i projektet, for eksempel ejendomsbygning, konferenceplanlægning eller implementering af Easy Redmine-programvare. Teknikk: Omfanget af projektet er defineret (hurtigt). I vores eksempel betyder dette, at jeg ikke kan ændre antallet af vinduer i eiendommen min, jeg kan ikke ændre stedet eller emnet for en konference osv. Prosjektets tid er en begrænset faktor enten absolutt (f.eks. konferencer) eller næsten absolutt (f.eks. softwareimplementering). Med et tydeligt defineret omfang er hovedopgaven til en projektleder eller porteføljeforvalter at planlægge alle typer ressourcer på tidslinjen for parallelle projekter og hensyn til den nødvendige rækkefølgen af ​​handlinger (opgaver) i individuelle projekter. Tenk for eksempel på bygningen af ​​et hus: arbejdere ansvarlige for sementlevering må fuldføre arbeidet sitt i rett tid, fordi forsinkelser forårsaget af mangel på sementressourcer kan hindre murere i at fuldføre sine egne opgaver. Når betongen er hurtig nok, kan de allerede være på en anden byggeplads. En smidig tilnærming er nyttig for projekter, der er nøje defineret, ressourcer er en kompleks faktor og omfang er genstand for planlægning (prioritering). Et godt eksempel kan være softwareudvikling (sprint), udgivelsesaktivitet (data for udgivelse af magasin/avis) eller markedsføringsinnhold (kampagne). Teknikk: Scrum-mestere eller planleggere i lignende roller prioriterer opgaver for næste sprint. Vanligvis har scrum-mesteren forskellige oppgavelister og scrum-boards for forskellige typer ressourcer, for eksempel udviklere som ønsker at få fejl og håndtere forespørsler om nye funktioner, og på andre siden journalister i politiske eller sportsmedier.

Kva betyder det?

Oplagt, hele problemstillinga med projektleiing dreiar sig framleis rundt den jarntriangelet. Operationelle planlægning fokuserer mere på forskellige dele af det samme. Kva kan vi dra ud af det?

1. Næsten i en organisation vil vi finde type projekt, der det er nødvendigt at bruge både projektledelsesteknikker for at skabe effektive arbejdsprocesser. Den ene metodikken er ikke bedre end den andre, den håndterer berre ulike udfordringer.
   
   
2. Kvalitetssikring af ressourceplanlægning knytt til tidslinjen er essentiel for hvert Waterfall-projekt, specielt til projektporteføljeplanlægning. Det samme gjeld for Easy Redmine-projekt.
   
   
3. Styring af agilt projekt: Styring af prioriteringer bliver udført gennem forskelligt værktøj. Ofte er det et problem med nøjagtig ressursallokering for en specifik backlog. Så, i denne samanhengen, anbefaler eg sterkt at du kartlegg og allokerer ressursane dine konsekvent. Til dømes kan ein programudviklar blive brugt med fleire backlogs samtidig (f.eks. feilrettingar vs. funktionsforespurnader på samme sprog). Men uden at definere kvantitativ ressourceallokering til efterslæb, vil du ikke kunne planlægge prioriterede leveringer, og scrum masteren må stadig løses mellem disse prioriteringer. En anden uheldig konsekvens vil være forseinka lansering af nye vigtige produktfunktioner som f.eks. fejlrettinger eller funktionskrav, som udnytter strategiske udviklingsressursar.

Kombination af begge styringsmetodane

Som du kan se på biletet nedenfor, har vi et grundlægt Waterfall-projekt som omfatter en softwareudviklingsplan, som viser sekvenser og afhængigheder. Men teama som er involveret i dette projekt (seljarar, tekniske skribentar) kan håndtere sine egne leveringer i deira avdeling ikke berre sådan det er vist i dette eksempel, men også på en smidig måde.

Easy Redmine Gantt - Waterfall-projekteksempel