Datorindustrin är full av tvetydigt språk, hård jargong och komplexa idéer som är svåra att förstå och som kan få ditt sinne till ett frenesi av beräkningsbuffring.
Vattenfall? Klunga? Vig?
Om dessa fraser är helt främmande för dig, oroa dig inte; ditt hjälpsamma team av HashDork-tekniknördar är här för att hjälpa dig att förstå skillnaderna mellan dessa avgörande stadier av utvecklingsprocessen så att du kan bli kunnig.
De smidiga, scrum- och vattenfallsteknikerna kommer alla att behandlas i det här blogginlägget, tillsammans med hur var och en kan hjälpa ditt team som helhet.
Låt oss börja med det smidiga, så tar vi med oss resten.
Vad är Agile?
Agil mjukvaruutveckling följer en iterativ, inkrementell metod. Snarare än omfattande förberedelser i början av ett projekt, är Agila tekniker flexibla för förändrade behov över tid och främjar kontinuerlig feedback från slutanvändare.
Tvärfunktionella team arbetar med produktiterationer över tid, och detta arbete kategoriseras i en backlog och prioriteras utifrån affärs- eller kundvärde. Syftet med varje iteration är att skapa en användbar produkt.
Ledarskap främjar samarbete, ansvar och kommunikation ansikte mot ansikte i agila metoder.
Affärsintressenter och utvecklare måste samarbeta för att säkerställa att produkten uppfyller konsumentens krav och företagets mål.
Frasen "agil utveckling" syftar på en mängd olika metoder och ramverk som är baserade på de ideal och grundsatser som beskrivs i Agile manifest.
Experter rekommenderar att man följer agila principer och värderingar och använder dem som en guide för att besluta om de rätta åtgärderna att vidta i en viss miljö samtidigt som man närmar sig mjukvaruutveckling.
Det samarbetande och självorganiserande teamet är de viktigaste fokusområdena för den agila mjukvaruutvecklingsgemenskapen.
Team får självständigt bestämma hur de ska tackla ett visst projekt, men det betyder inte att handledare inte finns. Agila team är därför tvärfunktionella.
I ett agilt paradigm är chefer fortfarande nödvändiga. De ser till att varje gruppmedlem har eller förvärvar de nödvändiga förmågorna för projektet.
Chefer i ett agilt ramverk arbetar genom att främja en atmosfär som för fram det bästa i teamet. Men istället för att ta ledningen tar de ofta en baksäte och låter teamet bestämma hur de ska leverera saker.
Chefer blir bara involverade när team upprepade gånger försöker lösa problem utan att lyckas.
Agil utvecklingscykel
Stadierna i den agila utvecklingscykeln listas nedan. Det är viktigt att komma ihåg att dessa faser inte bör ske i ordning eftersom de är flexibla och ständigt förändras. Många av dessa stadier äger rum samtidigt.
- Planering: Efter att ett projektteam har bestämt att en idé är praktisk och genomförbar börjar de leta efter funktioner. Denna fas syftar till att prioritera varje funktion och tilldela den till en iteration efter att ha brutit ner idén i mindre arbetsstycken (funktionerna).
- Kravanalys: För att fastställa affärskrav innebär detta steg flera diskussioner med chefer, intressenter och användare. Vem som kommer att använda produkten och hur de kommer att använda den är bland de detaljer som teamet måste samla in. Dessa standarder måste vara specifika, tillämpliga och kvantitativa.
- Designa: Kraven i föregående steg används för att förbereda system- och mjukvarudesignen. Överväganden för produktens eller lösningens utseende måste göras av teamet. En strategi eller plan för testet tas också fram av testteamet.
- Implementering, kodning eller utveckling: Fokus för det här steget är att bygga och utvärdera funktioner och planera utbyggnaden av iterationer (efter den iterativa och inkrementella utvecklingsmetoden [IID]). Eftersom det inte finns några funktioner som tillhandahålls, börjar iteration 0 av utvecklingsperioden. Genom att slutföra aktiviteter som kontraktering, inrättande av inställningar och finansiering ger denna iteration grunden för framtida tillväxt.
- Testning: Efter att koden har skapats testas den mot kraven för att säkerställa att produkten verkligen uppfyller användarnas krav och uppfyller affärsmålen. Enhets-, integrations-, system- och acceptanstestning utförs i detta skede.
- konfiguration: Efter testning skickas produkten till kunder så att de kan använda den. Projektet är dock inte avslutat efter implementeringen. Kunder kan stöta på ytterligare problem efter att de börjar använda produkten, vilket kommer att behöva projektteamet för att hitta en lösning.
Fördelar
- Snabbare leverans av högre kvalitet: Genom att dela upp projektet i iterationer (hanterbara enheter) kan teamet koncentrera sig på samarbete, utveckling och testning av högre kvalitet. När testning görs med varje iteration hittas problem och åtgärdas snabbare. Dessutom, med ständiga, efterföljande revisioner, kan denna högkvalitativa programvara levereras snabbare.
- Förändring välkomnas: Även om planeringscyklerna är kortare är det enkelt att acceptera och ta emot ändringar när som helst i projektet. Eftersläpningen kan alltid förbättras och omprioriteras, vilket gör att teamen kan göra ändringar i projektet inom ett par veckor.
- Slutmålet kanske inte är känt: Agile är utmärkt för projekt när slutmålet inte är klart definierat. När projektet går längre kommer målen att bli tydliga och utvecklingen kommer att kunna tillgodose dessa förändrade behov.
- Kontinuerlig förbättring: Agila program främjar input från användare och team i alla skeden av projektet, vilket möjliggör tillämpning av det som lärts för att förbättra nästa iteration.
- Kundernas åsikter värdesätts: Det finns flera möjligheter för kunder att se arbetet slutföras, ge feedback och verkligen påverka det slutliga resultatet. Genom att interagera så intimt med projektteamet kan de utveckla en känsla av ägarskap.
- Starkt lagarbete: Agile betonar betydelsen av regelbunden kommunikation och personliga möten. Människor kan ta ansvar och äga vissa projektkomponenter när de arbetar i team.
Nackdelar
- Teammedlemmar måste ha kunskape: Agila team är ofta små. Lagmedlemmarna måste alltså ha ett brett utbud av färdigheter. Dessutom måste de förstå och känna sig bekväma med den valda Agile-tekniken.
- Planeringen kan vara mindre exakt: Det kan ibland vara svårt att fastställa ett exakt leveransdatum. Agile är byggt på tidsinställd leverans och projektledare omarrangerar ofta uppgifternas prioriteringar. Det är därför troligt att vissa av de leveranser som ursprungligen var planerade för leverans inte kommer att bli klara i tid. Dessutom kan fler sprints läggas till när som helst under hela projektet, vilket förlänger hela schemat.
- Dokumentation kan komma att ignoreras: Vissa teammedlemmar kanske tror att det är mindre viktigt att koncentrera sig på dokumentation eftersom Agile Manifesto gynnar fungerande programvara framför noggrann dokumentation. Agila team bör hitta den idealiska balansen mellan dokumentation och dialog, även om noggrann dokumentation inte kan garantera projektframgång i sig.
- Slutresultatet kan skilja sig mycket: Det kanske inte funnits en tydlig strategi för det initiala Agile-projektet, och därför kan det färdiga resultatet förändras avsevärt från vad som först förväntades. En väsentligt annorlunda slutresultat kan bli resultatet av att lägga till nya iterationer baserat på ändrad klientinmatning, eftersom Agile är så anpassningsbar.
- Utvecklares tidsåtgång: Utvecklingsteamet måste vara helt engagerat i projektet för att agilt ska vara effektivt. Den agila metoden, som tar längre tid än ett konventionellt tillvägagångssätt, kräver ständigt aktivt deltagande och samarbete. Dessutom innebär det att utvecklarna måste förbinda sig till hela projektets längd.
Vad är vattenfall?
Den mest populära iterationen av systemets utvecklingslivscykel (SDLC) för programvaruteknik och IT-projekt är känd som "vattenfallsmetoden", som följer en sekventiell, linjär procedur.
Ett Gantt-diagram, en form av stapeldiagram som visar start- och slutdatum för varje jobb, används ibland för att planera det.
Utvecklingsteamet avancerar till följande nivå efter att en av de åtta faserna är klar. Teamet kan inte återgå till ett tidigare skede utan att behöva starta om hela proceduren.
Dessutom kan klienten behöva utvärdera och acceptera kraven innan teamet kan gå till nästa nivå.
Vattenfallsmodellen utvecklades i de välorganiserade miljöerna inom tillverknings- och byggsektorerna, där justeringar kan vara oöverkomligt dyra eller till och med omöjliga.
Vattenfallstekniken heter så eftersom den är avsedd att flyta i bara en riktning – nedåt – precis som ett vattenfall. Dess faser inkluderar analys, igångsättning, testning, design, byggnad, driftsättning, underhåll och testning.
Vattenfallstekniken har flera fördelar, precis som alla andra strategier. En är att faserna för projektering och design är mer väletablerade.
Kunder och utvecklingsteamet är mer samstämmiga när det gäller projektleveranser när de använder vattenfallsmjukvaruutveckling. Eftersom du är medveten om projektets omfattning från början gör vattenfallsutveckling det också enklare att följa framstegen.
Vattenfallsprocessen använder specialister, utvecklare, analytiker och testare för att koncentrera sig på sina jobb i projektet snarare än att låta hela teamet betona ett steg.
Stadier av vattenfallet
Vattenfallets sex steg måste alla ske efter varandra:
- Krav på insamling och förvaring: Du bör samla grundlig kunskap om vad detta projekt kräver just nu. Det finns flera tekniker för att samla in denna data, inklusive intervjuer, undersökningar och brainstorming. Projektbehoven bör vara uppenbara när denna fas är över, och ditt team bör ha fått en kopia av kravdokumentet.
- Ett systems design: Systemet är designat av ditt team med förutbestämda specifikationer. Under detta skede görs ingen kodning, men teamet ställer krav på hårdvara eller programmeringsspråk.
- Genomförande: Detta steg involverar kodning. Föregående stegs data används av programmerare för att bygga en användbar produkt. Kod implementeras ofta i små bitar som kombineras vid slutet av en fas eller början av en annan.
- Testning: Produkten kan börja testas efter att koden är klar. Eventuella problem hittas och rapporteras noggrant av testare. Ditt projekt kan behöva gå tillbaka till fas ett för omvärdering om betydande problem dyker upp.
- Leverans/installation: Produkten är färdig vid denna tidpunkt och ditt team skickar in leveranserna för distribution eller release.
- Underhåll: Kunden har tagit emot produkten och använder den. Ditt team kan behöva utveckla korrigeringar och uppdateringar när problem dyker upp för att åtgärda dem. Återigen kan betydande problem kräva en återgång till steg ett.
Fördelar
- Enkel att använda och hantera: Vattenfallsmetoden är enkel att använda och förstå eftersom varje projekt hanteras på samma sekventiellt sätt. Innan du påbörjar ett vattenfallsprojekt behöver teamet inte ha någon tidigare expertis eller utbildning. Vattenfallsmetoden är mycket strikt; varje steg har en uppsättning leveranser och en granskning, vilket gör det enkelt att administrera och underhålla.
- En väldokumenterad metodik krävs: Den dokumentation som krävs av vattenfallsmetodik hjälper till att förtydliga resonemanget bakom testerna och koden. Dessutom skapar det ett pappersspår om intressenter vill ha ytterligare information om en viss fas eller för framtida initiativ.
- Upprätthållande av disciplin: Varje steg i ett vattenfallsprojekt har en början och ett slut, vilket gör det enkelt att kommunicera framsteg till intressenter och kunder. Teamet kan minska möjligheten att missa en deadline genom att sätta krav och design först innan kod tas fram.
Nackdelar
- Det kan vara svårt att få ihop exakta krav: Att prata med konsumenter och intressenter för att fastställa deras behov är ett av de inledande stadierna av ett vattenfallsprojekt. I detta tidiga skede av projektet kan det vara utmanande att fastställa deras specifika krav. Kunder lär sig ofta om sina krav när projektet utvecklas snarare än att uttrycka dem i förväg.
- Förändringar är svåra att hantera: Besättningen kan inte återuppta arbetet efter att ha avslutat en fas. Det är väldigt svårt och dyrt att gå tillbaka och reparera det om de under testfasen får veta att funktionalitet saknades under kravprocessen.
- Programvaran tillhandahålls efter dess förfallodatum: Två till fyra faser av projektet måste avslutas innan den riktiga kodningen kan starta. Intressenter kommer inte att se funktionell programvara förrän sent i livscykeln som ett resultat.
Vad är Scrum?
Ett av de mest omtyckta processramverken för att omsätta Agile i praktiken är Scrum, som är en delmängd av Agile.
Det är ett iterativt paradigm för att hantera skapandet av komplex programvara och produkter. Sprints, som är iterationer med fast längd som löper en till två veckor, gör det möjligt för teamet att släppa mjukvara på ett regelbundet schema.
Intressenter och gruppmedlemmar träffas för att diskutera nästa steg efter varje sprint. Rollerna, ansvaret och mötena i Scrum förblir konstanta.
Till exempel specificerar Scrum sprintplaneringen, den dagliga stand-upen, sprintdemon och sprint retrospektiv som de fyra ritualerna som ger varje sprintstruktur.
Teamet kommer att använda visuella artefakter som aktivitetstavlor eller burndown-diagram under varje sprint för att visa framsteg och få inkrementell feedback.
I scrum arbetar teamet och produktägaren nära tillsammans för att identifiera och prioritera systemfunktionalitet. De uppnår detta genom att skapa en produktbacklog, som innehåller alla de uppgifter som krävs för att producera mjukvara som fungerar som avsett.
Felkorrigeringar, icke-funktionella krav och funktioner bör alla inkluderas i kön. Tvärfunktionella team måste uppskatta och registrera sig för att leverera mjukvaruökningar under kontinuerliga Sprints, som vanligtvis pågår i 30 dagar, när målen har fastställts.
Endast teamet kan lägga till funktionalitet till sprinten efter att ha begått eftersläpningen för den sprinten.
Nästa sprintleverans bedöms produktbackloggen och omprioriteras vid behov, och följande leveransuppsättning väljs att vara en del av följande sprint.
Scrum process
- Produkt eftersläpning: För att beställa artiklarna i produktbackloggen träffas Product Owner och Scrum Team (arbetet med produktbackloggen kommer från användarberättelser och krav). Produktbackloggen är en lista över alla önskade funktioner för produkten snarare än en lista över uppgifter som behöver slutföras. Efter det väljer utvecklingsteamet uppgifter från produktbackloggen att utföra under varje sprint.
- Sprintplanering: Före varje sprint levererar produktägaren till teamet de översta punkterna i backloggen vid ett sprintplaneringsmöte. Gruppen väljer sedan objekt från produktbackloggen som de kan avsluta under sprinten och flyttar dem till sprintbackloggen (som är en lista över uppgifter som ska utföras i spurten).
- Förfining/grooming av eftersläpningen: För att säkerställa att eftersläpningen är förberedd för följande sprint, träffas teamet och produktägaren vid avslutningen av en sprint. Teamet kan kassera användarberättelser som inte längre är relevanta, lägga till nya, ändra ordningen i vilken de ska behandlas eller dela upp användarberättelser i mindre uppgifter. Under detta ”grooming”-möte kommer man att se till att eftersläpningen endast omfattar sådant som är relevant, djupgående och i linje med projektets mål.
- Scrum möten varje dag: I ett 15-minuters stand-up möte som kallas Daily Scrum diskuterar varje teammedlem sina mål och eventuella problem som har uppstått. Varje dag under hela sprinten deltar teamet i Daily Scrum, som håller alla på uppgiften.
- Möte för att bedöma sprintent: Teamet presenterar sitt arbete vid ett sprintgranskningsmöte i slutet av varje sprint. Istället för en rapport eller en PowerPoint-presentation bör detta möte innehålla en riktig demonstration.
- Retrospektiv sprintmöte: Teamet diskuterar eventuella ändringar som behöver göras i följande sprint samt hur väl Scrum fungerar för dem i slutet av varje sprint. Teamet kan diskutera sprintens positiva, negativa aspekter och förbättringsområden.
Fördelar
- Mer ansvar från teamet: Det finns ingen projektledare som instruerar scrum-teamet om vad de ska göra och när. Arbetet som kan avslutas i varje sprint bestäms istället av laget som helhet. De samarbetar alla och ger varandra en hand, vilket förbättrar lagarbetet och främjar individualitet hos varje gruppmedlem.
- Förbättrad projektsynlighet och transparens: Det finns färre missförstånd och osäkerhet eftersom alla i teamet är medvetna om sitt ansvar tack vare täta stand-up-möten. Teamet kan hantera problem innan de blir utom kontroll eftersom problem upptäcks i förväg.
- Förbättrade kostnadsminskningar: Konstant kommunikation håller teamet informerat om eventuella problem eller förändringar så snart de inträffar, vilket hjälper till att spara kostnader och förbättra kvaliteten. Mindre funktionsbitar ger kontinuerlig feedback och möjliggör tidig felkorrigering innan större fel blir för dyra att åtgärda.
- Enkel att anpassa till förändringar: Det är enklare att hantera och anpassa sig till förändringar när det finns täta återkopplingsslingor och korta spurter. Som en illustration, om teamet stöter på en helt ny användarberättelse under en sprint, kan de snabbt lägga till den funktionen i följande sprint vid eftersläpningsmötet.
Nackdelar
- Räckvidd krypfara: På grund av avsaknaden av ett fastställt slutdatum kan vissa Scrum-projekt möta omfattningskrypning. Intressenter kan lockas att fortsätta kräva fler funktioner om det inte finns någon deadline för färdigställande.
- En dålig Scrum Master kan spåra ur allt: En projektledare är inte detsamma som en scrum master. Scrum Mastern måste lita på teamet de övervakar och aldrig ge dem instruktioner. Scrum Master har inte makt över laget. Projektet kommer att misslyckas om scrummastern försöker hantera teamet.
- Noggrannhetsproblem kan bero på dåligt angivna uppgifter: Om uppgifterna inte är tydligt specificerade kommer projektkostnader och scheman inte att vara korrekta. Planeringen blir utmanande och spurter kan ta längre tid än förväntat om de initiala målen inte är definierade.
- Erfarenhet och engagemang är nödvändigt för ett team: För att teamet ska bli framgångsrikt måste roller och uppgifter vara tydligt definierade. Scrum-teamet kräver teammedlemmar med teknisk kompetens eftersom det inte finns några tydligt definierade roller (alla gör allt). Teamet måste också förbinda sig att delta i de dagliga Scrum-sessionerna och hålla ihop under hela projektets liv.
Agile vs Scrum
Även om Agile och Scrum använder samma metodik finns det vissa variationer mellan de två. Agile Manifesto beskriver en uppsättning principer för att skapa programvara genom iterativ utveckling.
Scrum, å andra sidan, är en uppsättning riktlinjer som måste följas när man gör agil mjukvaruutveckling. Agile är ett koncept, medan Scrum är en teknik för att omsätta det i praktiken.
Scrum är en metod för att implementera Agile, därför har de båda många saker gemensamt. Båda metoderna är iterativa, prioriterar tidig och frekvent mjukvaruleverans och accepterar förändringar. De stödjer också öppenhet och kontinuerlig utveckling.
Agile vs vattenfall
Rigid vs. flexibel beskriver bäst skillnaderna mellan vattenfallsprocessen och Agile. Även om Agile är flytande och ständigt förändras, är Waterfall en mycket stramare och stelare metodik.
Dessa ytterligare distinktioner mellan dem är följande:
- Agile kräver inte ett linjärt tillvägagångssätt, medan Waterfall är sekventiellt.
- Även om behov ofta är fördefinierade i vattenfallsprojekt, förväntas de förändras och anpassas i agila initiativ.
- I motsats till Agile tillåter inte Waterfall-projekt att ändringar görs på arbete som slutförts i ett tidigare skede.
- Vattenfallet är en organiserad procedur där du måste avsluta varje steg innan du går vidare till nästa. Agile är dock en flexibel metod som låter dig fortsätta med projektet i din egen takt.
Agile vs Waterfall vs Scrum
- Vattenfallet ökar förtroendet för det som kommer att tillhandahållas mycket snart efter det är planerat. Agile förlitar sig på en utvecklingsmiljös bästa praxis. Här kan ett antal projektrisker hanteras väl genom att resultaten kontinuerligt utvärderas.
- Waterfall räknar inte med att teamet och projektet kommer att vara baserat på samma plats. Medan scrum och agilt behöver samlokalisering av anställda.
- Agile fokuserar på att minska projektomarbetning och uppmuntrar förändringar att införlivas mycket tidigare. Till skillnad från vattenfallet, som reagerar annorlunda, möjliggör scrum också tidig upptäckt av förändringar.
- En mer kompakt ritning för slutprodukten tillhandahålls av agile och scrum. Detta skapar problem med de löften som ges till köparen. Däremot ger vattenfallsgrafiken kunder och utvecklare ett bättre intryck av det färdiga resultatet.
- Var och en av dessa tekniker har en uppsättning verktyg för att organisera och simulera de uppgifter som är involverade i deras skapande.
Slutsats
Om du har följt med hittills och är säker på din kunskap om skillnaderna mellan processerna Waterfall, Agile och Scrum, bör du redan veta vilken strategi som fungerar bäst för dig och ditt team.
Vattenfallstekniken, som är avsedd för projekt med en bestämd omfattning, tidsram och budget, kan vara ditt bästa alternativ om du gillar hårda regler och procedurer och tycker att de ger klarhet.
Å andra sidan, om friheten och anpassningsförmågan som Agile erbjuder inspirerar dig, kan det vara där du bör lägga din uppmärksamhet.
Scrum är dock vägen att gå om du vill ha lite disciplin inom ett flexibelt ramverk.
Du måste dock överväga dessa tillvägagångssätt i ljuset av det projekt du arbetar med och ditt slutliga resultat.
Kommentera uppropet