När det gäller mjukvaruutveckling finns det alltid den miljonfrågan: vilken metod som ska användas, Vattenfall eller Agile? Alla har en åsikt om det, och ofta innebär att föredra en metod att bortse från den andra som ett giltigt alternativ. Waterfall kom först, Agile dök upp på senare tid, men vi är långt ifrån överens om vilket som bättre passar utvecklingsbehov.
Är Waterfall död? Har Agile definitivt tagit sin plats? Är det ena bättre än det andra?
Med utgångspunkt från grunderna kommer vi att rensa det nuvarande tillståndet för båda metoderna inom mjukvaruutveckling och svara på några av de vanligaste frågorna angående var och en. Sammantaget kommer det också att förklaras varför vi på Imaginary Cloud har valt Agile istället för Waterfall i vår utvecklingsprocess.
Den Vattenfallsmetodik fick sitt namn efter dess sekventiella faser arrangerade på ett nedåtgående sätt (liknande faktiska vattenfall), som representerar de olika stegen i mjukvaruutveckling från ena änden till den andra. Den publicerades 1970 av datavetenskapsmannen Winston Walker Royce, och den övervägde ursprungligen fem distinkta faser: krav, design, implementering, verifiering och underhåll.
Vissa variationer av den ursprungliga modellen uppstod under de följande decennierna, men logiken bakom Waterfall förblev densamma. När en fas är klar blir dess utgång ingången för nästa, som startar omedelbart efter den förra. Den överväger alla väsentliga punkter som komponerar mjukvaruutveckling, och dess enkelhet gjorde det mycket lätt att förstå och anta omedelbart.
Vattenfall säkerställer att varje fas är klar innan du går vidare till nästa. Anledningen? För att undvika att påbörja utvecklingen innan designarbetet är klart, vilket kan ge plats för eventuella inkongruiteter i båda ändarna. Dessutom är det möjligt att uppskatta hela projektets kostnad och ansträngning som behövs redan från början i kravfasen genom denna modell.
Medan Waterfall-modellen långt ifrån var det enda möjliga tillvägagångssättet för mjukvaruutveckling, var det inte förrän 2001 som den upplevde ett grundläggande paradigmskifte. Vad orsakade det? Agil mjukvaruutveckling.
Principerna för inkrementell mjukvaruutveckling användes redan genom olika spridda processer. Ändå var det först 2001 med Manifest för agil mjukvaruutveckling, att Agile mjukvaruutveckling (som vi vet) introducerades och populariserades. Detta mycket enkla dokument, sammanställt av en grupp utvecklare i Utah, bröt säkert konventionerna och begränsningarna för mjukvaruutveckling, vilket gav ett verkligt alternativ till Waterfall-metoden.
Ovan står ett perfekt exempel på vad Agile syftar till att vara. De olika cyklerna - konventionellt namngivna sprintar - sträva efter att kumulativt leverera värde, vara en del av en större bild som leder till projektets slutförande. Det är där det skiljer sig mest från vattenfallsmetoden.
Agile strävar efter att vara mer flexibel, tillåta regelbundna inkrement och minimera den tid som krävs för planering genom att fokusera på kortare tidslådor. Varje iteration tillför värde till produkten och tillhandahåller fungerande programvara när den avslutas, och planerar närmaste steg mer detaljerat än de andra som kommer att följa.
Olika delmängder antar Agile som en filosofi, liknande vad som hände med variationerna av Waterfall. DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), XP (Extreme Programming) och, förmodligen den mest populära, Scrum, drar alla från Agile för att utföra mjukvaruutvecklingsprocesser.
Oavsett olika åsikter är det ett faktum att Agile förändrade hur mjukvaruutvecklare bestämde sin inställning till nya projekt. Att veta vad varje metod representerade, vad betydde detta för Waterfall?
Nästan lika många säger att Waterfall är död som de som säger att Agile är en obetydlig trend. Det är inget fel med att ha olika åsikter, men låt oss gå ner till fakta här:
Den Stack Overflow-undersökning bilden ovan visar hur Agile utan tvekan är det ledande valet för mjukvaruutvecklare. Förutom att vara det första valet som används av 85,4,9% av samhället, tar den populära delmängden Scrum andra platsen med 62,7%. Längre ner finns vattenfall på sjätte plats, med 15,1% användning.
Vid första anblicken ser det inte bra ut för vattenfall. Vi kan tydligt säga att Agile är den mest populära metoden, och det finns inget sätt att argumentera mot dessa siffror. Det är dock ett misstag att ignorera en så hög andel utvecklare som använder Waterfall. Vi skulle inte säga, som en analogi, att Huawei är ett irrelevant varumärke eftersom det bara har 14, 6% av marknadsandelen inom mobiltelefonindustrin, bakom Apple och Samsung.
Det är dock ett faktum att Agilt avslöjade några svagheter och brister i Waterfall-modellen genom att påpeka hur svårt det är att fixa problem i tidigare faser och hur det tar en hel process att ha fungerande programvara. Allt detta med stor osäkerhet däremellan.
När budskapet spred sig blev det coolt att vara Agile, alla ville ha en bit av det, och alla processer blev Agile som en konsekvens. Ingen skryter om sina vattenfallsprocesser. Från marknadsföring och ekonomi till mjukvara design och utvecklingVarje företag vill att alla ska veta att de är agila, även om de inte själva vet vad det betyder. Det är det som orsakar hela felaktigheten som stöder argumentet att Waterfall nu är irrelevant.
Alla verkar sakna poängen: varken Waterfall är död eller Agile är det universellt överlägsna metodik för mjukvaruutveckling. Att anta det ena över det andra för att bli bättre är bara en illusion som ofta maskerar bristen på en riktig process.
Waterfall är definitivt det bästa valet för stabila projekt eftersom tung planering görs initialt och räknar med alla aspekter (både interna och externa) som kan påverka projektets genomförande. Oavsett projektets dimension, Vattenfall är det lämpligaste valet när den yttre miljön är stabil och osannolikt att drabbas av förändringar genom hela planen.
För dessa typer av projekt var Waterfall det bästa tillvägagångssättet innan Agile kom in i bilden, och det är fortfarande som idag. Om du kan planera ett projekt framåt i en miljö med låg risk finns det ingen verklig fördel med att dela upp det i flera sprints för att leverera värde varje vecka. Det är bäst att fokusera på slutresultatet direkt.
Alternativt, Agilt är vägen att gå för projekt som kräver en mer flexibel process, med tanke på deras instabila och oförutsägbara karaktär. Med andra ord, om produktvisionen och respektive kan förändras på grund av externa faktorer (t.ex. marknadsdynamik, etc), är det bättre att bygga och anpassa produkten med Agile. Det är också den bästa metoden för att säkerställa att projektet inte stannar under utveckling i flera månader innan det presenteras något resultat. I slutet av varje sprint kommer det att finnas en kontrollpunkt där produktägare kan testa och godkänna det färdiga arbetet.
I föränderliga projekt som använder Waterfall skapar bristen på korrekta kontrollpunkter risk eftersom det är svårare att åtgärda eventuella problem som upptäcks i slutet av utvecklingen. Den extra tid som avsatts för planering av hela projektet säkerställer inte att design- och utvecklingsfaserna kommer att löpa smidigt fram till slutet, eftersom de flesta frågor är lika oönskade som oförutsägbara.
Välja antingen Vattenfall vs Agile Det borde vara mer än bara en marknadsföringsrörelse. Det bör överväga alla aspekter som kan påverka ett projekt och hur väldefinierad a priori en produkt är. Att välja fel verktyg för jobbet kan leda till extra kostnader för tid och ansträngning.
Varje mjukvaruutvecklingsutmaning har sina särdrag och vanligtvis är kravfasen i vilken metod som helst den punkt där korten läggs på bordet. Men innan du hoppar direkt i aktion finns det några frågor angående projektets art du bör känna till.
Metoder som Vattenfall och Agile finns som olika metoder för att lösa variationer av samma problem. Beroende på deras särdrag kan flera projekt vara bättre utvecklade och mer lämpliga med antingen det ena eller det andra.
Allt som allt, varför föredrar vi Agile framför Waterfall? Med tanke på vad vi har sett fram till nu är vi förhoppningsvis alla tidigare förklaringar som ”Vattenfall är död, länge leve Agile.” Som en allmän regel är den ena inte bättre än den andra och, de flesta gånger, det är ett misstag att tänka annorlunda. Vi har provat Waterfall länge och gjort övergången till Agile när vi - med tanke på arten av de flesta av våra projekt - tyckte att det var det bästa valet.
I vår Agil utvecklingsprocess, vi antog en Scrum-metodik, en delmängd av Agile, och gjorde några justeringar för att möta våra kunders specifika behov. Vi tycker att detta är det bättre alternativet för våra projekt eftersom vi överväger både möjligheten att avsluta det med en MVP (Minimum Viable Product) - som skulle falla under Proof of Concept-fasen - eller gå vidare genom en uppsättning sprints som kommer att ge inkrementellt värde till produkten.
Återigen skulle det vara ett misstag att tro att detta är den bästa möjliga processen att anta i varje projekt, och det är anledningen till att vi granskar och anpassar den för att passa våra behov när det behövs. Det var det som ledde till att vi flyttade från Waterfall till Agile i första hand, och om det behövs kommer ytterligare förbättringar att göras. Det handlar dock aldrig om att skapa universella lösningar, eftersom ett sådant koncept aldrig kommer att existera i mjukvaruutveckling.
Det är kristallklart att Waterfall inte är död, och Agile är inte det bästa valet. Det är det enklare sättet att titta på det och det farligaste sättet att hantera mjukvaruutveckling. Allt beror på dina specifika behov och det bästa sättet att möta de önskade målen. All ytterligare diskussion om det skapar onödigt buller.
Det som har hänt under de senaste åren är att det att vara Agile ses som en fördel. En anmärkningsvärd egenskap som ett företag kan associeras med som omedelbart bevisar dess kvalitet. Det är varken alla som är agila, och ingen vet vad Agile är. Ändå gör allt uppståndelse det svårare för någon att verkligen förstå vad metoder gillar Vattenfall och Agile handlar om.
Det bästa sättet att gå bortom utseende och faktiskt göra skillnad med en mjukvaruutvecklingsprocess är att verkligen förstå varje projekts behov, välja den metod som passar det bäst och anpassa därefter.
Innehållshanterare, textredigerare, och presentatör av strategiska idéer, tillsammans med att vara en ivrig beundrare av filmkonst och visuellt berättande.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
