12.0 Vattenfall vs. cyklisk projektledning (del 5) – Villkor för att hantera cykliska projekt

Användare/kunder deltar aktivt #

Varje cykel av cyklisk projektledning involverar utveckling av krav, design, utförande och testning. Detta innebär att många val måste göras under loppet av en cykel. Om programmet ska representera kundens önskemål korrekt måste kunden vara en aktiv medlem i projektgruppen.

Kunder måste kommunicera sina krav till programmerare och designers så tydligt som möjligt. Detta innebär ofta deltagande i projektgruppen varje vecka (eller åtminstone varannan vecka).

Inom ett projekt bidrar konsumenterna till definitionen av nödvändiga funktioner och cykelplanering. De samarbetar vid acceptanstest, godkänner eller förkastar interimistiska resultat och bidrar till projektets övergripande inriktning. Dessutom resulterar aktivt kundengagemang i förbättrade resultat vid användning av vattenfallsmetoden.

Teamet har befogenhet att göra val. #

Inom en cykel måste projektgruppen ha befogenhet att fatta sina egna beslut. Om projektgruppen saknar denna behörighet kommer den cykliska modellen för projektledning inte att fungera. Om konstant godkännande från överordnade krävs under en cykel kan detta resultera i stagnation. Dessutom är utomstående ofta omedvetna om vad som händer eftersom de inte är aktivt involverade i projektgruppen; detta gör det svårt för dem att fatta rationella beslut.

Projektets produktion (mjukvara) kan delas upp i mindre komponenter. #

Cyklisk projektledning är en metod för att hantera projekt där delar av projektet slutförs i en serie cykler. Detta är endast möjligt om mjukvaran som utvecklas är nedbrytbar i ett antal mer eller mindre distinkta komponenter.

Ledningens krav på programvara för projektledning är i första hand globala; ledningen ställer inte direkta, konkreta eller specifika krav. En av fördelarna med cyklisk projektledning är det nära samarbetet mellan kunden, designers, programmerare och eventuella testare under cyklerna. Om specifika och konkreta krav ställs i början av ett projekt, begränsar detta projektgruppens förmåga att använda sitt bästa omdöme när de gör designval. Många krav på ett projekt visar sig vara i behov av anpassning under processen och bör därför inte vara (för) fast etablerade i början.

Kunden förstår aktiviteterna. #

Om betydande tekniskt arbete som är svårt att förstå för kunden måste ske inom en cykel finns det en risk att kunden inte kan bidra effektivt till teamet. I en sådan situation har kunden väldigt lite att säga till om i de designbeslut som måste fattas.

En liknande risk föreligger när kunden inte är medveten om framstegen. Till exempel kan mycket av arbetet ägnas åt kodning, med lite uppmärksamhet åt användargränssnittet. Det är avgörande för kunderna att ha tillräcklig insikt om innehållet och utvecklingen av en cykel för att undvika att hamna på sidan.

Det ska vara möjligt att gå tillbaka i sina steg. #

Även i cyklisk projektledning följer team då och då vägar som visar sig vara felaktiga. Det borde vara möjligt att ta ett steg bakåt i ett sådant fall. Om en ny modul skapad under en cykel visar sig vara otillräcklig, måste det vara möjligt att återuppta arbetet med den föregående modulen. Detta ställer krav, framför allt för arkivering och dokumentation av projektmaterial. CVS och Subversion är två användbara verktyg för dessa uppgifter (se bilaga 3 för en komplett lista över verktyg).

Tillsammans med programmeringskunskaper bör programmerare kunna interagera effektivt med kunder och vice versa. Teammedlemmar måste vara intellektuella tänkare. Disciplin krävs för att fortsätta med jobbet.

Organisationen där projektet bedrivs måste också ge tillräckligt stöd för detta verksamhetssätt. Tidsregistrering, arkivering och schemaläggning krävs för att stödja projekten. Dessa registreringssystem ger den nödvändiga öppenheten för att garantera en rättvis fördelning av resurser över projekt och tidsperioder.

Prioritering #

Projekt bör ges tillräcklig betydelse och gruppmedlemmar bör göras tillgängliga för dem. Att kräva att teammedlemmar arbetar med för många uppgifter samtidigt är ineffektivt. Om en organisation inte är tillräckligt anpassad för projektbaserat arbete kommer den cykliska projektledningsflexibiliteten sannolikt att resultera i kaos. Dessutom drar vattenfallstekniken nytta av ett organiserat förhållningssätt till projektledning (se Wijnen, 2004, s. 111).

Direktören för en mjukvaruutvecklingsfirma, som var mer visionär än chef, hade en fantastisk idé nästan varje månad och initierade ständigt nya initiativ i sitt företag. Som ett resultat av detta slutfördes aldrig äldre projekt och arbetare arbetade med så många som fem projekt samtidigt. Den karismatiske regissören hade precis läst klart en bok om snabb applikationsutveckling (RAD) och var väldigt exalterad över det – särskilt det “snabba” inslaget. Han tejpade de grundläggande idéerna med RAD på kopiatorn och förväntade sig sedan att alla skulle börja arbeta med dessa föreställningar. Det var trots allt en utmärkt teknik.

Risker med cyklisk projektledning #

Cyklisk projektledningsteknik lämnar ibland otillräcklig tid för att utföra nödvändiga funktioner. Eftersom projektets varaktighet är fast kommer färre funktioner med största sannolikhet att läggas till än vad som ursprungligen förväntades.

Även om detta är ett berättigat problem, är det också inneboende i vattenfallsstrategin . Det definierande steget i vattenfallsansatsen innebär en djupgående granskning av kraven. Denna analys kommer sannolikt att resultera i förbättrad tidshantering. Detta är ofta inte fallet i verkligheten, av de skäl som anges ovan.

Dessutom utelämnas funktioner i detta tillvägagångssätt på grund av brist på medel för att utveckla dem.

Krav hanteras pragmatiskt i cykelansatser. Till exempel kan behov i cykler klassificeras med hjälp av MoSCoW-kriterierna (Stapleton, 2003) enligt följande:

  • Måste ha: systemkritiska krav
  • Bör ha: kritiska behov som användarna verkligen önskar
  • Kan ha: önskvärda behov som lätt kan ignoreras
  • Vill ha: krav som inte kommer att uppfyllas den här gången: krav som kan vänta till senare

Oavsett om vissa förmågor inte längre finns tillgängliga, anser DANS projektledare att cykliskt arbete ger högre kundnöjdhet än vattenfallsmetoden. I vilket fall som helst kontrolleras förväntningarna regelbundet mer effektivt och projekt ger rutinmässigt resultat som fungerar, även om de är mindre komplexa än vad man först tänkt sig.

Förstå potentiella nackdelar #

En nackdel som ofta nämns med XP är att betydande makt överförs till programmerare. Om de missbrukar denna behörighet kan de utnyttja kundens bristande tekniska expertis till sin fördel. För att undvika detta scenario krävs en projektledare som kan se till både programmerarnas och kundens intressen. Dessa projektledare hjälper sina kunder att välja och planera cykler, att göra den tekniska grunden för sina val begriplig och att tillhandahålla administration och rapportering.

Slutligen är en annan nackdel med XP att metodens implementering kräver en hög inlärningskurva för programmerare, chefer och konsumenter.