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

Nogle gange hører jeg råb som "Gantt er død", "du skal køre det på den agile måde" eller endda "projektstyring er død". Selvom mange af dem bare er eksempler på markedsføringssnak, støder jeg ofte på porteføljemanagere, scrum masters og andre projektstyringsprofessionelle, der seriøst vil diskutere Agile vs. Vandfaldsteknikker (Gantt). Dette indlæg er en kort introduktion til emnet. Jerntrianglen inden for projektstyring er faktisk en meget simpel repræsentation af de nøgleelementer, der er nødvendige for succesfuld projektplanlægning. Omfang, tid og omkostninger/ressourcer. Ressourcer er de eneste og/eller kritiske elementer i prisen i mange brancher. Mennesker er den mest værdifulde ressource, der ikke bare kan øges, reduceres eller multipliceres. På samme måde har maskiner en vis produktionskapacitet og kan ikke ændres med et enkelt klik. Men hvordan passer jerntrianglen ind i det overordnede billede? Meget belejligt. Den giver os et simpelt, men effektivt svar på, hvornår vi skal bruge planlægning efter Vandfaldsmetoden, og omvendt, hvornår vi skal vælge en agil tilgang. Vandfaldsmetoden er bedst egnet til et projekt, hvor omfanget er præcist defineret og er et nøgleelement i projektet, f.eks. byggeri af fast ejendom, konferenceplanlægning eller implementering af Easy Redmine-software. Teknikken er, at 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 stedet eller emnet for en konference osv. Projektets tid er en begrænsende faktor, enten absolut (f.eks. konferencer) eller næsten absolut (f.eks. softwareimplementering). Med et nøje defineret omfang er hovedopgaven for en projektleder eller porteføljemanager at planlægge alle typer ressourcer på tidslinjen på tværs af parallelle projekter og tage hensyn til den nødvendige rækkefølge af handlinger (opgaver) i de enkelte projekter. Overvej f.eks. byggeriet af et hus: Arbejdere, der er ansvarlige for cementlevering, skal udføre deres arbejde rettidigt, fordi forsinkelser forårsaget af mangel på cementressourcer kan forhindre murere i at fuldføre deres egne opgaver. Når betonen er tilstrækkelig fast, kan de allerede være på en anden byggeplads. En agil tilgang er nyttig for projekter, hvor tiden er nøje defineret, ressourcer er afgørende faktorer, og omfanget er underlagt planlægning (prioritering). Et godt eksempel kunne være softwareudvikling (sprints), udgivelsesaktivitet (tidspunkt for udgivelse af magasin/avis) eller markedsføringsindhold (kampagne). Teknikken er, at scrum masters eller planlæggere i lignende roller prioriterer opgaver til næste sprint. Normalt har scrum master forskellige backlog'er og scrum boards til forskellige typer ressourcer, f.eks. udviklere, der ønsker at rette fejl og håndtere anmodninger om nye funktioner, og på den anden side journalister inden for politik eller sportsmedier.

Hvad betyder det?

Åbenlyst drejer hele spørgsmålet om projektstyring sig stadig om den jerntriangel. Driftsplanlægning fokuserer kun mere på forskellige dele af det samme. Så hvad kan vi drage af det?

1. I stort set hver organisation vil vi finde typer af projekter, hvor det er nødvendigt at bruge begge projektstyringsteknikker for at skabe effektive arbejdsprocesser. Den ene metode er ikke bedre end den anden, den adresserer bare forskellige udfordringer.
   
   
2. Kvalitetsplanlægning af ressourcer i forbindelse med tidsplanen er afgørende for hvert Waterfall-projekt, især for porteføljeplanlægning af projekter. Det samme gælder for Easy Redmine-projekter.
   
   
3. Styring af agile projekter: Styring af prioriteter sker normalt gennem forskellige værktøjer. Ofte er der et problem med præcis ressourceallokering til en bestemt backlog. Så i den henseende anbefaler jeg stærkt, at du kortlægger og allokerer 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 backlogs vil du dog ikke være i stand til at planlægge prioriterede leverancer, og scrum-masteren vil konstant skulle løse uoverensstemmelser mellem disse prioriteter. En anden ubehagelig konsekvens vil være forsinket frigivelse af nye nøgleproduktfunktioner som f.eks. fejlrettelser eller funktionskrav, der udnytter strategiske udviklingsressourcer.

Kombination af begge styringsmetoder

Som du kan se på billedet nedenfor, har vi et grundlæggende Waterfall-projekt, der inkluderer en softwareudviklingsplan, der viser sekvenser og afhængigheder. Dog kan holdene involveret i dette projekt (sælgere, tekniske forfattere) håndtere 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