Waterfall vs. Agile: Vilken metodologi ska du välja till dina Redmine-projekter?

Vissa gånger hör jag råb som "Gantt är död", "du ska köra det på den smidiga sättet" eller till och med "projektstyrning är död". Även om många av dem bara är exempel på marknadsföringssnak, stöter jag ofta på porteføljemanagere, scrum masters och andra projektstyringsprofessionelle, där seriøst vill diskutera Agile vs. Vandfaldteknikker (Gantt). Detta inlägg är en kort introduktion till ämnet. Jerntrianglen inden för projektstyrning är faktiskt en mycket enkel presentation av nyckelelement, vilket är nödvändigt för framgångsrik projektplanering. Omfang, tid och kostnader/resurser. Resurser är de enda och/eller kritiska element i priset i många brancher. Människor är den mest värdefulla resurs, som inte bara kan öka, reducera eller multiplicera. På samma sätt har maskiner en vis produktionskapacitet och kan inte ändras med ett enkelt klick. Men hur passerar jerntrianglen i det överordnade bilden? Mycket belejligt. Den ger oss ett enkelt, men effektivt svar på, när vi ska använda planläggning efter Vandfaldsmetoden, och omvänt, när vi ska välja en agil användning. Vandfaldsmetoden är bäst anpassad till ett projekt, varvid omfattningen är exakt definierad och ett nyckelelement i projektet, t.ex. byggeri av snabb fastighet, konferensplanläggning eller implementering av Easy Redmine-programvara. Tekniken är definierad (snabb). I vårt exempel betyder det, att jag inte kan ändra valutan av fönster i min fastighet, jag kan inte ändra stället eller ämnet för en konferens osv. Projektets tid är en begränsad faktor, antingen absolut (f.eks. konferenser) eller nästan absolut (f.eks. mjukvaruimplementering). Med ett noggrant definierat omfång är huvuduppgiften för en projektledare eller porteføljemanager att planlägga alla typer av ressourcer på tidslinjen på tvärs av parallella projekter och ta hänsyn till den nödvändiga räckvidden av handlinger (uppgifter) i de enskilda projekter. Overvej f.eks. byggeriet af et hus: Arbejdere, der är ansvariga för cementleverans, skall utföra sitt arbete rettidigt, eftersom fördröjning orsakat av mangel på cementressourcer kan förhindra murere i at fuldføre deras egna uppgifter. När betonen är tillräckligt snabb, kan de redan vara på en annan byggplats. En smidig tillgång är användbar för projekter, varvid tiden är noggrann definierad, resurserna är avgörande faktorer, och omfattningen är underlagsplanläggning (prioritering). Ett gott exempel kan vara mjukvaruutveckling (sprints), udgivelsesaktivitet (tidspunkt för utgivning av magasin/avis) eller marknadsföringsinnehåll (kampanj). Teknikken är, at scrum masters eller planlæggere i liknande roller prioriterar uppdrag till nästa sprint. Normalt har scrum master olika backlog'er och scrum boards för olika typer av resurser, t.ex. utvecklare, vill ha rätt fel och handlägga om nya funktioner, och på den andra sidan journalister inom politik eller sportsmedier.

Vad betyder det?

Åbenlyst vrider hela frågor om projektstyrning och stadigt om den jerntriangel. Driftsplanläggning fokuserar endast på olika delar av det samma. Så vad kan vi dra af det?

1. I stort sett varje organisation vill vi hitta typer av projekter, där det är nödvändigt att använda begge projektstyrningstekniker för att skapa effektiv arbetsprocesser. Den ena metoden är inte bättre än den andra, den adresserar bara olika utmaningar.
   
   
2. Kvalitetsplanlægning af ressourcer i förbindelse med tidsplanen är avgörande för varje Waterfall-projekt, särskilt för porteføljeplanlægning af projekter. Det samma gäller för lätt Redmine-projekter.
   
   
3. Styring av agila projekter: Styrning af prioriteter sker genom olika teknik. Ofta är det ett problem med exakt ressourceallokering till en bestämd backlog. Så i den henseende rekommenderar jeg stærkt, at du kortlægger och allokerer dine ressourcer konsekvent. Till exempel kan en softwareudvikler användas med flera backlogs på samma tid (f.eks. felrettelser vs. funktionsanmodninger på samma språk). Uten att definiera kvantitativ ressourceallokering till eftersläpningar vill du inte vara i stand till att planlægge prioritera leverancer, och scrum-masteren vill konstant lösa uoverensstemmelser mellan dessa prioriteter. En annan negativ konsekvens vil vara forsinket frigivelse af nya nyckelproduktfunktioner som f.eks. felrettelser eller funktionskrav, der utnyttjar strategiska utvecklingsressourcer.

Kombination af begge styringsmetoder

Som du kan se på bilden nedan, har vi ett grundläggande Waterfall-projekt, där det ingår en mjukvaruutvecklingsplan, visar sekvenser och beroenden. Dog kan hållane involvera i detta projekt (sälgere, tekniska författare) hanterar deras egna leverancer i deras avdelning som inte bara vistas i detta exempel, men också på ett smidigt sätt.

Easy Redmine Gantt - Vandfaldsprojekt exempel