Vandfald vs. Agile: Hvilken metode skal du vælge til dine Redmine-projekter?

Nogle gange hører jeg råb som "Gantt er død," "du er nødt til at køre den adræt måde," eller endda "projektledelsen er død." Selvom mange af dem blot er et eksempel på marketingskrald, støder jeg ofte på projektporteføljemanagere, scrum-mestre og andre projektledelsesprofessionelle, der seriøst vil skændes om Agile vs. Waterfall (Gantt) teknikker. Dette indlæg er en kort introduktion til emnet.

Projektledelsens jerntrekant

Jern trianglen er faktisk en meget enkel fremstilling af de nøgleelementer, der er nødvendige for en vellykket projektplanlægning. Omfang, tid og omkostninger/ressourcer. Ressourcer er de eneste og/eller kritiske elementer i prisen i mange brancher. Mennesker er det mest værdifulde aktiv, som ikke blot kan øges, reduceres eller multipliceres. På samme måde har maskinressourcer en vis produktionskapacitet og kan ikke ændres med et enkelt klik.

Easy Redmine - Iron trianglen #1

Men hvordan passer jerntrekanten ind i det samlede billede? Meget bekvemt. Det giver os et enkelt, men effektivt svar, hvornår vi skal bruge planlægningen af ​​Waterwall-metoden og tværtimod, hvornår vi skal vælge en smidig tilgang.

Redmine Waterfall projektledelse

Vandfaldsmetoden er bedst egnet til et projekt, hvis omfang er præcist defineret og er et nøgleelement i projektet, såsom ejendomsbyggeri, konferenceplanlægning eller Nem Redmine-softwareimplementering.

Teknik: Projektets omfang er defineret (fast). I vores eksempel betyder det, at jeg ikke kan ændre antallet af vinduer i min ejendom, jeg kan ikke ændre sted eller emne for en konference mv. Projektet er en begrænsende faktor enten absolut (f.eks. konferencer) eller næsten absolut (f.eks. softwareimplementering). Med et stramt defineret omfang er hovedopgaven for en projektleder eller porteføljemanager at planlægge alle typer ressourcer på tidslinjen på tværs af parallelt løbende projekter og tage højde for den nødvendige rækkefølge af handlinger (opgaver) i individuelle projekter.

Overvej f.eks. Opførelsen af ​​et hus: Arbejdstagere med ansvar for cementlevering skal færdiggøre deres arbejde rettidigt, fordi forsinkelser forårsaget af mangel på cementressourcer kan forhindre murerarbejde i at udføre deres egne opgaver. Når betonen er fast nok, kan de allerede findes på et andet websted.

Easy Redmine - Iron trianglen #2

Redmine Agile projektledelse

En fleksibel tilgang er nyttig til projekter, hvor tiden er fast defineret, ressourcer er en afgørende faktor og omfanget er underlagt planlægning (prioritering). Et godt eksempel kunne være softwareudvikling (sprints), udgivelsesaktivitet (magasin/avisudgivelsesdato) eller marketingindhold (kampagne).

Teknik: scrum masters eller planlæggere i lignende roller prioriterer opgaver til næste sprint. Normalt har scrum master forskellige forskelle og scrum boards for forskellige typer af ressourcer, såsom udviklere søger at rette fejl og håndtere anmodninger om nye funktioner og på den anden side journalister i politiske eller sportsmedier.

Easy Redmine - Iron trianglen #3

Hvad betyder det?

Det er klart, at hele spørgsmålet om projektstyring stadig vender sig om jernstrikken. Operationsplanlægning fokuserer kun mere på forskellige dele af det samme. Så hvad kan vi tegne af det?

1. Næsten i hver organisation, ville vi finde typer projekter, hvor det er nødvendigt at bruge begge projektledelsesteknikker for at skabe effektive arbejdsprocesser. En metode er ikke bedre end den anden, den retter sig lige mod forskellige udfordringer.
   
   
2. Kvalitetsplanlægning af ressourcer forbundet med tidslinjen er afgørende for hvert vandfaldsprojekt, især for projektporteføljeplanlægning. Det samme gælder for Easy Redmine projekter.
   
   
3. Ledelse af agile projekter: Styring af prioriteter sker normalt gennem forskellige værktøjer. Ofte er der et problem med nøjagtig ressourceallokering til et specifikt efterslæb. Så i denne henseende anbefaler jeg stærkt, at du kort og allokere dine ressourcer konsekvent. For eksempel kan en softwareudvikler bruges med flere backlogs på samme tid (f.eks. fejlrettelser vs. funktionsanmodninger på samme sprog). Uden at definere kvantitativ ressourceallokering til efterslæb, vil du dog ikke være i stand til at planlægge prioriterede leverancer, og scrummasteren skal løbende løse uoverensstemmelser mellem disse prioriteter. En anden ubehagelig konsekvens vil være den forsinkede udgivelse af nye nøgleproduktfunktioner såsom fejlrettelser eller funktionskrav, som udnytter strategiske udviklingsressourcer.

Kombination af begge ledelsesmetoder

Som du kan se på billedet nedenfor, har vi et grundlæggende Waterfall-projekt, der inkluderer en softwareudviklingsplan, der viser sekvenser og afhængigheder. Teams involveret i dette projekt (sælgere, tekniske skribenter) kan dog styre deres egne leverancer i deres afdeling, ikke kun som vist i dette eksempel, men også på en agil måde.

Easy Redmine Gantt - Vandfaldsprojekt eksempel