Vattenfall vs. Agile: Vilken metodologi ska du välja för ditt 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. Resourcer ä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 och viss produktionskapacitet och kan inte ändras med en enkel klickning.

Easy Redmine - Järn triangeln #1

Men hur passar järntrekanten 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 Enkel Redmine-programimplementering.

Teknik: Projektets omfattning definieras (snabbt). 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änsad faktor antingen absolut (t.ex. konferenser) eller nästan absolut (t.ex. programimplementering). Med en tydlig 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 med hänsyn till nödvändiga följder 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 brist på cementresurser kan skydda murare från att slutföra sina egna uppgifter. När betongen är tillräckligt snabb kan de redan vara på en annan plats.

Easy Redmine - Järn triangeln #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 (prioritera). 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 utvecklas som vill åtgärda buggar och hantera begäran om nya funktioner och andra sidan, journalister inom politik eller sportmedia.

Easy Redmine - Järn triangeln #3

Vad betyder det?

Uppenbarligen kretsar hela frågan om projektledning fortfarande kring järntriangeln. Operativ planering fokuserar bara mer på olika 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 lätt Redmine-projekt.
   
   
3. Hantering av agila projekt: Hantering prioritering görs generellt 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 sekvenser och beroende. Dock kan teamen som är involverade i detta projekt (säljare, tekniska skribenter) hantera sina egna leveranser i sin avdelning inte bara som visa i detta exempel utan också på ett agilt sätt.

Easy Redmine Gantt - Waterfall-projektexempel