Definisjon av V-syklusen
V-syklusen i prosjektledelse stammer fra fossen-modellen som ble teoretisert på 1970-tallet, noe som gjør det mulig å representere utviklingsprosesser på en lineær måte og i påfølgende faser.
Denne modusen for prosjektledelse ble utviklet på 1980 -tallet og anvendt på feltet industrielle prosjekter, deretter utvidet til IT -prosjekter. Det ble satt i tvil fra begynnelsen av 2000-tallet, under effekten av akselerasjonen av teknologiske endringer, og favoriserte mer såkalte "smidige" metoder.
Bokstaven V refererer til det skjematiske synet på denne syklusen, som har form av en V: en synkende fase etterfulgt av en stigende fase. V-syklusen knytter en valideringsfase til hver implementeringsfase, som vist i diagrammet nedenfor:
Fordeler med denne metodikken
Den største fordelen med V-syklusen er at den unngår å gå tilbake igjen og igjen for å omdefinere de opprinnelige spesifikasjonene, som en skralle. Hver designfase krever utarbeidelse av presis og uttømmende dokumentasjon, der hvert punkt må valideres av sluttproduktet. Når et trinn er validert, går vi ikke tilbake og går videre til neste trinn på en solid basis; dette er hovedstyrken til V-syklusen.
På grunn av sitt strenge og intuitive aspekt, er V-syklusen fortsatt en enkel prosess å implementere. Forarbeidet med å definere spesifikasjonene ved prosjektets start betyr at alle trinnene er kjente for de ansatte når de først er startet, og som lett finner veien rundt prosjektets tidsramme og kjenner formålet med oppgavene. På samme måte kan dokumentasjonen som kreves for hvert trinn replikeres fra ett prosjekt til et annet i strukturen (spesifikasjoner, testspesifikasjoner, etc.).
Generelt er V-syklusen mer egnet for strukturer på flere steder, fordi den ikke krever daglige møter, men bare styremøter for å fungere som en overgang fra en fase til en annen. Det lineære aspektet åpner derfor for en fragmentert geografisk organisasjon, der arbeid sammen med ansatte ikke er sentralt i prosessen.
Ulemper
Den største ulempen ved V-syklusen kan oppsummeres i to ord: tunneleffekten. Etter en fase med presis definisjon av produktet som teamet må fullføre, lanseres prosjektet i en "tunnel" som består av fasene nevnt ovenfor. Men hva om de originale spesifikasjonene overskrides? Hva om kundens behov endres, eller har blitt dårlig uttrykt? V-syklusen takler derfor ikke godt endringer, som både er styrken og hoved svakheten.
Det gir dermed mindre reaktivitet i forhold til den teknologiske og økonomiske konteksten, til kundeforespørsler, til uventede hendelser; risikotaking vil være systematisk begrenset. Tunneleffekten induseres også av det omfattende arbeidet med å produsere dokumentasjon ved prosjektstart, som ikke kan korrigeres deretter. Til slutt illustrerer bildet av tunnelen (noen ganger veldig) lang tid mellom behovsuttrykk og oppskriften på sluttproduktet.
V syklus vs. smidige metoder
Generelt kan det sies at V-syklusen fokuserer på prosessen, mens de smidige metodene favoriserer produktet.
Som en del av smidige metoder (Scrum, XP, RAD, …), er prosjektet raffinert av iterasjoner gjennom gjentakelse av en syklus med operasjoner ( sprint som en del av Scrum -metoden). Som vi har sett, definerer V-syklusen hele sluttproduktet i de tidlige stadiene, og etterlater lite rom for tilpasning senere i syklusen.
Deretter gjør smidige metoder det mulig å utvikle produktet etter økning . Vi produserer litt mer hver gang, bit for bit, for å oppnå det endelige resultatet. V-syklusen konsentrerer i stedet realiseringen av helheten i en enkelt fase, som er fullstendig designet oppstrøms og verifisert nedstrøms.
Denne mangelen på tilpasning og fleksibilitet i V-syklusen har nettopp ført til fremveksten av smidige metoder, spesielt innen programvare og markedsføring, for å reagere på stadig hurtigere endringer i teknologier og forbrukernes krav.
Implementering av V-syklusen
For hvilke prosjekter?
På grunn av elementene som presenteres ovenfor, favoriserer følgende elementer bruk av V-syklusen:
- Svært spesifikke krav utstedt av kunden, for eksempel i sammenheng med en utlysning.
- Tilstedeværelsen av en tjenesteleverandør, som kontrollerer alle implementeringstrinnene og krever dermed mindre kommunikasjon mellom de forskjellige aktørene.
- Muligheten for å følge uendrede spesifikasjoner fra start til sluttn, etter produktets eller prosjektets art.
- Et prosjekt der det teknologiske miljøet endrer seg veldig liteog begrenser dermed risikoen for etterslep i tunneleffekten.
En avgjørende fase: designet
Klientens behov må samles på en omfattende og streng måte. Funksjonelle spesifikasjoner må være gjenstand for en oppfølging og endelig validering. De må syntetisere kundens forespørsler mens de dekker hele prosjektprogrammet.
Beskrivelsen av virkemidlene for å oppnå det endelige produktet, på sin side, bør bare gripe inn på det tekniske spesifikasjonsstadiet (generell design), for å forhindre at midler definerer enden!
Hvem validerer?
Sist men ikke minst som standard definerer V-syklusen stadier uten å definere sine roller eller ansvar. Det er derfor tilrådelig i starten av prosjektet å utpeke menneskene eller enhetene som skal spille rollen som (ved å øke detaljnivået):
- Prosjektledelse (funksjonell), eller MOA
- Prosjektledelse (system), eller MOE
- Arkitektteamet eller generell design (teknisk, forretningsmessig)
- Utviklingsteamet (etter komponent)
Roller er angitt med V-ringsekvens i diagrammet ovenfor.
