Vattenfall vs. Agile: Vilken metodologi ska du välja för dina Redmine-projekt?

Ibland hör jag utrop som "Gantt är död," "du måste köra det på det agila sättet," eller till och med "projektledning är död." Även om många av dem bara är exempel på marknadsföringsstrunt, stöter jag ofta på portföljchefer, scrum masters och andra projektledningsproffs som vill argumentera seriöst om Agilt vs. Vattenfallstekniker (Gantt). Det här inlägget är en kort introduktion till ämnet.

Projektledningens järntrekant

Järntrekanten är faktiskt en mycket enkel representation av de viktigaste elementen som behövs för framgångsrik projektplanering. Omfattning, tid och kostnad/resurser. Resurser är de enda och/eller kritiska elementen i priset inom många branscher. Människor är den mest värdefulla tillgången som inte kan ökas, minskas eller förökas på enkelt vis. På samma sätt har maskinresurser en viss produktionskapacitet och kan inte ändras med en enkel klickning.

Easy Redmine - The iron triangle #1

Men hur passar järntrekanten in i helhetsbilden? Mycket bekvämt. Den ger oss ett enkelt men effektivt svar på när vi bör använda planering enligt Vattenfallsmetodiken och, tvärtom, när vi ska välja ett agilt tillvägagångssätt.

Redmine Vattenfallsprojektledning

Vattenfallsmetodiken passar bäst för ett projekt vars omfattning är exakt definierad och är en nyckelfaktor i projektet, som till exempel fastighetsbyggande, konferensplanering eller Easy Redmine-programimplementering.

Teknik: Projektets omfattning är definierad (fast). I vårt exempel innebär detta att jag inte kan ändra antalet fönster i min fastighet, jag kan inte ändra platsen eller ämnet för en konferens, osv. Projekttiden är en begränsande faktor antingen absolut (t.ex. konferenser) eller nästan absolut (t.ex. programimplementering). Med en tydligt definierad omfattning är huvuduppgiften för en projektledare eller portföljchef att schemalägga alla typer av resurser på tidslinjen över parallellt pågående projekt och ta hänsyn till den nödvändiga följd av åtgärder (uppgifter) i enskilda projekt.

Tänk till exempel på byggandet av ett hus: arbetare som ansvarar för cementleverans måste slutföra sitt arbete i rätt tid eftersom förseningar orsakade av brist på cementresurser kan förhindra murare från att slutföra sina egna uppgifter. När betongen är tillräckligt fast kan de redan vara på en annan plats.

Easy Redmine - The iron triangle #2

Redmine Agil projektledning

Ett agilt tillvägagångssätt är användbart för projekt där tiden är tydligt definierad, resurser är en avgörande faktor och omfattningen är föremål för planering (prioritering). Ett bra exempel kan vara programutveckling (sprintar), publiceringsverksamhet (tidskrift/tidningsutgivningsdatum) eller marknadsföringsinnehåll (kampanj).

Teknik: scrum masters eller planerare i liknande roller prioriterar uppgifter för nästa sprint. Vanligtvis har scrum mastern olika backloggar och scrum boards för olika typer av resurser, som utvecklare som vill åtgärda buggar och hantera begäranden om nya funktioner och, å andra sidan, journalister inom politik eller sportmedia.

Easy Redmine - The iron triangle #3

Vad betyder det?

Uppenbarligen kretsar hela frågan om projektledning fortfarande kring järntriangeln. Operativ planering fokuserar bara mer på olika delar av samma sak. Vad kan vi dra från det?

1. I nästan varje organisation skulle vi hitta typer av projekt där det är nödvändigt att använda båda projektledningsteknikerna för att skapa effektiva arbetsprocesser. En metodologi är inte bättre än den andra, den hanterar bara olika utmaningar.
   
   
2. Kvalitetsplanering av resurser som är kopplade till tidslinjen är avgörande för varje Waterfall-projekt, särskilt för projektportföljplanering. Samma sak gäller för Easy Redmine-projekt.
   
   
3. Hantering av agila projekt: Hantering av prioriteringar görs vanligtvis genom olika verktyg. Ofta finns det problem med exakt resursallokering för en specifik backlog. Så, i detta avseende rekommenderar jag starkt att du kartlägger och allokerar dina resurser konsekvent. Till exempel kan en programutvecklare användas med flera backlogs samtidigt (t.ex. felkorrigeringar vs. funktionsförfrågningar på samma språk). Utan att definiera kvantitativ resursallokering till backlogs kommer du dock inte att kunna schemalägga prioriterade leveranser, och scrum master kommer att behöva kontinuerligt lösa avvikelser mellan dessa prioriteringar. En annan obehaglig konsekvens kommer att vara försenad lansering av nya viktiga produktfunktioner som felkorrigeringar eller funktionskrav, som utnyttjar strategiska utvecklingsresurser.

Kombination av båda ledningsmetoderna

Som du kan se på bilden nedan har vi ett grundläggande Waterfall-projekt som inkluderar en viss programutvecklingsplan som visar sekvenser och beroenden. Dock kan teamen som är involverade i detta projekt (säljare, tekniska skribenter) hantera sina egna leveranser i sin avdelning inte bara som visas i detta exempel utan också på ett agilt sätt.

Easy Redmine Gantt - Waterfall-projektexempel