Når det kommer til softwareudvikling, er der altid et spørgsmål om millioner dollars: hvilken metode der skal bruges, Vandfald eller Agile? Alle har en mening om det, og ofte betyder det at foretrække en metode at se bort fra den anden som en gyldig mulighed. Waterfall kom først, Agile dukkede op for nylig, men vi er langt fra at nå til enighed om, hvad der bedre passer til udviklingsbehov.
Er Waterfall død? Har Agile bestemt taget sin plads? Er den ene bedre end den anden?
Fra det helt grundlæggende vil vi rydde den aktuelle tilstand for begge metoder inden for softwareudvikling og besvare nogle af de mest almindelige spørgsmål vedrørende hver. Alt i alt vil det også blive forklaret, hvorfor vi hos Imaginary Cloud har valgt Agile i stedet for Waterfall i vores udviklingsproces.
Den Vandfaldsmetodik blev opkaldt efter dens sekventielle faser arrangeret på en nedadgående måde (svarende til faktiske vandfald), der repræsenterer de forskellige trin i softwareudvikling fra den ene ende til den anden. Det blev udgivet i 1970 af computerforskeren Winston Walker Royce, og det overvejede oprindeligt fem forskellige faser: krav, design, implementering, verifikation og vedligehold.
Nogle variationer af den originale model opstod i de følgende årtier, men logikken bag Waterfall forblev den samme. Når en fase er afsluttet, bliver dens output input til den næste, som starter umiddelbart efter førstnævnte. Det overvejer alle de væsentlige punkter, der komponerer softwareudvikling, og dens enkelhed gjorde det meget let at forstå og vedtage med det samme.
Vandfald sikrer, at hver fase er afsluttet, inden man går videre til den næste. Årsagen? For at undgå at starte udviklingen inden designarbejdet er afsluttet, hvilket kan give plads til mulige uoverensstemmelser i begge ender. Derudover er det muligt at estimere hele projektets omkostninger og indsats lige fra starten i kravfasen gennem denne model.
Mens Waterfall-modellen langt fra var den eneste mulige tilgang til softwareudvikling, var det først i 2001, at den oplevede et grundlæggende paradigmeskift. Hvad forårsagede det? Agil softwareudvikling.
Principperne for inkrementel softwareudvikling blev allerede brugt gennem forskellige spredte processer. Alligevel var det først i 2001 med Manifest for agil softwareudvikling, at Agile softwareudvikling (som vi ved) blev introduceret og populariseret. Dette meget ligetil dokument, sammensat af en gruppe udviklere i Utah, brød helt sikkert konventionerne og begrænsningerne i softwareudvikling og gav et reelt alternativ til Waterfall-metoden.
Ovenfor står et perfekt eksempel på, hvad Agile sigter mod at være. De forskellige cyklusser - konventionelt navngivet sprinter - søge kumulativt at levere værdi ved at være en del af et større billede, der fører til projektets afslutning. Det er her, det adskiller sig mest fra vandfaldsmetoden.
Agile søger at være mere fleksibel, muliggøre regelmæssige stigninger og minimere den tid, der kræves til planlægning ved at fokusere på kortere tidskasser. Hver iteration tilføjer værdi til produktet og leverer fungerende software, når det afsluttes, og planlægger det nærmeste trin mere detaljeret end de andre, der følger.
Forskellige undergrupper vedtager Agile som en filosofi, svarende til hvad der skete med variationerne af Waterfall. DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), XP (Extreme Programming) og, sandsynligvis den mest populære, Scrum, trækker alle fra Agile til at udføre softwareudviklingsprocesser.
Uanset forskellige meninger er det en kendsgerning, at Agile ændrede hvordan softwareudviklere besluttede deres tilgang til nye projekter. Ved at vide, hvad hver metode repræsenterede, hvad betød dette for Waterfall?
Næsten lige så mange mennesker siger, at Waterfall er død, som dem, der siger, at Agile er en ubetydelig tendens. Der er ikke noget galt med at have forskellige meninger, men lad os komme ned til fakta her:
Den Stack Overflow-undersøgelse billedet ovenfor viser, hvordan Agile utvivlsomt er det førende valg for softwareudviklere. Udover at være det første valg, der bruges af 85,4,9% af samfundet, indtager den populære undergruppe Scrum andenpladsen med 62,7%. Længere nede ligger vandfaldet på sjettepladsen med 15,1% forbrug.
Ved første øjekast ser det ikke godt ud for Waterfall. Vi kan tydeligt sige, at Agile er den mest populære metode, og der er ingen måde at argumentere imod disse tal. Det er dog en fejl at ignorere en så høj procentdel af udviklere, der bruger Waterfall. Vi vil ikke sige, som en analogi, at Huawei er et irrelevant brand, fordi det kun har 14,6% af markedsandelen i mobiltelefonindustrien bag Apple og Samsung.
Det er dog en kendsgerning, at Agile afslørede et par svagheder og mangler ved Waterfall-modellen ved at påpege, hvor svært det er at løse problemer i tidligere faser, og hvordan det tager en hel proces at have fungerende software. Alt dette med en stor usikkerhed imellem.
Efterhånden som budskabet spredte sig, blev det sejt at være Agile, alle ville have et stykke af det, og alle processer blev Agile som følge heraf. Ingen praler af deres vandfaldsprocesser. Fra markedsføring og økonomi til software design og udvikling, enhver virksomhed ønsker, at alle skal vide, at de er agile, selvom de ikke selv ved, hvad det betyder. Det er det, der forårsager hele fejlslutningen, der understøtter argumentet om, at Waterfall nu er irrelevant.
Alle ser ud til at savne pointen: hverken Waterfall er død, eller Agile er det universelt overlegne metodologi til softwareudvikling. At adoptere den ene over den anden for at blive bedre er bare en illusion, der ofte maskerer manglende eksistens af en ordentlig proces.
Waterfall er bestemt det bedste valg til stabile projekter, da der i første omgang udføres tung planlægning, idet man regner med alle aspekter (både interne og eksterne), der kan påvirke projektets gennemførelse. Uanset projektets dimension, Vandfald er det mest egnede valg, når det ydre miljø er stabil og usandsynlig at lide ændringer gennem hele planen.
For denne type projekter var Waterfall den bedste tilgang, før Agile kom ind i billedet, og det er det stadig som i dag. Hvis du kan planlægge et projekt fremad i et miljø med lav risiko, er der ingen reel fordel i at opdele det i flere sprints for at levere værdi hver uge. Det er bedst at fokusere på slutresultatet med det samme.
Alternativt, Agile er vejen at gå for projekter, der kræver en mere fleksibel proces i betragtning af deres ustabile og uforudsigelige karakter. Med andre ord, hvis produktvisionen og respektive kan ændre sig på grund af eksterne faktorer (f.eks. Markedsdynamik osv.), så er det bedre at bygge og tilpasse produktet ved hjælp af Agile. Det er også den bedste metode til at sikre, at projektet ikke forbliver under udvikling i flere måneder, før der præsenteres noget resultat. Ved afslutningen af hver sprint vil der være et kontrolpunkt, hvor produktejer kan teste og godkende det afsluttede arbejde.
I skiftelige projekter, der anvender Waterfall, skaber manglen på korrekte kontrolpunkter risiko, da det er sværere at løse mulige problemer, der er fundet ved afslutningen af udviklingen. Den ekstra tid, der afsættes til planlægning af hele projektet, sikrer ikke, at design- og udviklingsfaserne kører problemfrit indtil slutningen, da de fleste problemer er lige så uønskede som uforudsigelige.
Valg af enten Vandfald vs Agile Det skal være mere end blot et markedsføringstiltag. Det bør overveje alle de aspekter, der kan påvirke et projekt, og hvor veldefineret a priori et produkt er. At vælge det forkerte værktøj til jobbet kan føre til ekstra omkostninger til tid og kræfter.
Hver softwareudviklingsudfordring har sine særegenheder, og normalt er kravfasen i enhver metode det punkt, hvor kortene lægges på bordet. Før du hopper lige i aktion, er der dog et par spørgsmål vedrørende projektets art, du bør vide.
Metoder som Vandfald og Agile findes som forskellige tilgange til at løse variationer af de samme problemer. Afhængigt af deres særlige forhold kan flere projekter være bedre udviklet og mere egnede med enten det ene eller det andet.
Alt i alt, hvorfor foretrækker vi Agile frem for Waterfall? I betragtning af det, vi har set indtil nu, er vi forhåbentlig alle tidligere forklaringer som „Waterfall er død, længe leve Agile.“ Som hovedregel er den ene ikke bedre end den anden, og de fleste gange er det en fejl at tro andet. Vi har prøvet Waterfall i lang tid og har skiftet til Agile, da vi - i betragtning af arten af de fleste af vores projekter - fandt, at det var det bedste valg.
I vores Agil udviklingsproces, vi vedtog en Scrum-metode, en undergruppe af Agile, og lavede et par justeringer for at imødekomme vores kunders specifikke behov. Vi finder dette som den bedre mulighed for vores projekter, da vi overvejer både muligheden for at afslutte det med en MVP (Minimum Viable Product) - som ville falde ind under Proof of Concept-fasen - eller gå videre gennem et sæt sprints, der vil tilføje inkrementel værdi til produktet.
Endnu en gang ville det være en fejl at tro, at dette er den bedst mulige proces at vedtage i hvert projekt, og det er grunden til, at vi gennemgår og tilpasser den, så den passer til vores behov, når det er nødvendigt. Det var det, der fik os til at flytte fra Waterfall til Agile i første omgang, og hvis det var nødvendigt, vil der blive foretaget yderligere forbedringer. Det er dog aldrig et spørgsmål om at skabe universelle løsninger, da et sådant koncept aldrig vil eksistere i softwareudvikling.
Det er krystalklart, at Waterfall ikke er død, og Agile er ikke den bedste vælger. Det er den nemmere måde at se på det og den farligste måde at håndtere softwareudvikling på. Det hele kommer ned til dine specifikke behov og den bedste måde at opfylde de ønskede mål på. Enhver yderligere diskussion om det skaber unødvendig støj.
Hvad der er sket de sidste par år er, at det at være Agile ses som en fordel. En bemærkelsesværdig egenskab, som en virksomhed kan blive forbundet med, der øjeblikkeligt beviser dens kvalitet. Det er hverken alle, der er agile, og ingen ved, hvad Agile er. Alligevel gør al opstanden det sværere for nogen virkelig at forstå, hvad metoder kan lide Vandfald og Agile handler om.
Den bedste måde at gå ud over udseendet og faktisk gøre en forskel med en softwareudviklingsproces er at virkelig forstå hvert projekts behov, vælge den metode, der passer bedst til det og tilpasse sig i overensstemmelse hermed.
Indholdsadministrator, teksteditor, og præsentator for strategiske ideer, sammen med at være en ivrig fan af filmkunst og visuel historiefortælling.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
