Dataindustrien er full av tvetydig språk, tøff sjargong og komplekse ideer som er vanskelige å forstå og som kan sende tankene dine ut i et vanvidd av beregningsbasert buffering.
Foss? Scrum? Smidig?
Hvis disse frasene er helt fremmede for deg, ikke bekymre deg; ditt hjelpsomme team av HashDork-teknologinerder er her for å hjelpe deg med å forstå forskjellene mellom disse avgjørende stadiene i utviklingsprosessen, slik at du kan bli kunnskapsrik.
De smidige, scrum- og fosseteknikkene vil alle bli dekket i dette blogginnlegget, sammen med hvordan hver enkelt kan hjelpe laget ditt som helhet.
La oss begynne med det smidige, så tar vi med oss resten.
Hva er smidig?
Smidig programvareutvikling følger en iterativ, inkrementell tilnærming. Snarere enn omfattende forberedelser ved starten av et prosjekt, er smidige teknikker fleksible for endrede behov over tid og fremmer kontinuerlig tilbakemelding fra sluttbrukere.
Tverrfunksjonelle team jobber med produktiterasjoner over tid, og dette arbeidet er kategorisert i en backlog og prioritert basert på forretnings- eller kundeverdi. Formålet med hver iterasjon er å lage et brukbart produkt.
Ledelse fremmer samarbeid, ansvar og kommunikasjon ansikt til ansikt i smidige metoder.
Bedriftens interessenter og utviklere må samarbeide for å sikre at produktet oppfyller kravene til forbrukeren og bedriftens mål.
Uttrykket "smidig utvikling" refererer til en rekke metoder og rammer som er basert på idealene og prinsippene skissert i Agile manifest.
Eksperter anbefaler å følge smidige prinsipper og verdier og bruke dem som en guide for å bestemme de riktige handlingene i et bestemt miljø mens man nærmer seg programvareutvikling.
Det samarbeidende og selvorganiserende teamet er hovedfokusområdene for det smidige programvareutviklingssamfunnet.
Team har lov til å bestemme selv hvordan de vil takle et bestemt prosjekt, men det betyr ikke at veiledere ikke eksisterer. Agile team er derfor tverrfunksjonelle.
I et smidig paradigme er ledere fortsatt nødvendige. De sørger for at hvert teammedlem har eller tilegner seg de nødvendige evnene for prosjektet.
Ledere i et smidig rammeverk opererer ved å skape en atmosfære som bringer frem det beste i teamet. Men i stedet for å ta ledelsen, setter de seg ofte i baksetet og lar teamet bestemme hvordan de skal levere ting.
Ledere blir bare involvert når team gjentatte ganger prøver å løse problemer uten å lykkes.
Smidig utviklingssyklus
Stadiene i den smidige utviklingssyklusen er listet opp nedenfor. Det er viktig å huske at disse fasene ikke bør foregå i rekkefølge fordi de er fleksible og i stadig endring. Mange av disse stadiene finner sted samtidig.
- Planlegging: Etter at et prosjektteam har bestemt at en idé er praktisk og gjennomførbar, begynner de å lete etter funksjoner. Denne fasen tar sikte på å prioritere hver funksjon og tilordne den til en iterasjon etter å ha brutt ideen ned i mindre arbeidsstykker (funksjonene).
- Kravanalyse: For å bestemme forretningskrav, innebærer dette trinnet flere diskusjoner med ledere, interessenter og brukere. Hvem som skal bruke produktet og hvordan de skal bruke det er blant detaljene teamet må samle inn. Disse standardene må være spesifikke, anvendelige og kvantitative.
- utforming: Kravene funnet i forrige trinn brukes til å forberede system- og programvaredesign. Hensyn til produktets eller løsningens utseende må gjøres av teamet. En strategi eller plan for testen utvikles også av testteamet.
- Implementering, koding eller utvikling: Fokuset på dette stadiet er å bygge og evaluere funksjoner og planlegge utrullingen av iterasjoner (ved å følge den iterative og inkrementelle utviklingstilnærmingen [IID]). Fordi det ikke er noen funksjoner som tilbys, begynner iterasjon 0 av utviklingsperioden. Ved å fullføre aktiviteter som kontrakter, sette opp innstillinger og finansiering, gir denne iterasjonen grunnlaget for fremtidig vekst.
- Testing: Etter at koden er laget, testes den mot kravene for å sikre at produktet virkelig tilfredsstiller brukerkrav og oppfyller forretningsmål. Enhets-, integrasjon-, system- og akseptabilitetstesting utføres på dette stadiet.
- Utplassering: Etter testing sendes produktet til kundene slik at de kan bruke det. Prosjektet er imidlertid ikke ferdig etter distribusjon. Kunder kan støte på flere problemer etter at de begynner å bruke produktet, som vil trenge prosjektteamet for å finne en løsning.
Fordeler
- Raskere levering av høyere kvalitet: Ved å dele opp prosjektet i iterasjoner (håndterbare enheter), er teamet i stand til å konsentrere seg om samarbeid, utvikling og testing av høyere kvalitet. Når testing utføres med hver iterasjon, blir problemer funnet og fikset raskere. I tillegg, med konstante, påfølgende revisjoner, kan denne høykvalitets programvaren leveres raskere.
- Forandring er velkommen: Selv om planleggingssyklusene er kortere, er det enkelt å akseptere og imøtekomme endringer når som helst i prosjektet. Etterslepet kan alltid forbedres og omprioriteres, slik at teamene kan gjøre endringer i prosjektet i løpet av et par uker.
- Sluttmålet er kanskje ikke kjent: Agile er utmerket for prosjekter når sluttmålet ikke er klart definert. Etter hvert som prosjektet går videre, vil målene bli klare, og utviklingen vil lett kunne imøtekomme disse skiftende behovene.
- Kontinuerlig forbedring: Smidige programmer fremmer bruker- og teaminnspill i alle stadier av prosjektet, og gir mulighet for å bruke det som er lært for å forbedre neste iterasjon.
- Kundenes meninger blir verdsatt: Det er flere muligheter for kunder til å se arbeid fullføres, gi tilbakemeldinger og virkelig påvirke det endelige resultatet. Ved å samhandle så intimt med prosjektteamet, kan de utvikle en følelse av eierskap.
- Sterkt teamarbeid: Smidig understreker betydningen av regelmessig kommunikasjon og personlige møter. Folk kan ta ansvar og eie visse prosjektkomponenter når de jobber i team.
Ulemper
- Teammedlemmer må ha kunnskape: Smidige team er ofte små. Dermed må teammedlemmer ha et bredt spekter av ferdigheter. I tillegg må de forstå og føle seg vel ved å bruke den valgte Agile-teknikken.
- Planleggingen kan være mindre presis: Det kan av og til være utfordrende å bestemme en eksakt leveringsdato. Agile er bygget på tidsrammet levering, og prosjektledere omorganiserer ofte oppgavenes prioriteringer. Dermed er det sannsynlig at noen av leveransene som opprinnelig var planlagt for levering, ikke blir ferdige i tide. I tillegg kan flere sprints legges til når som helst gjennom prosjektet, noe som forlenger hele tidsplanen.
- Dokumentasjon kan ses bort fra: Noen teammedlemmer kan tro at det er mindre viktig å konsentrere seg om dokumentasjon siden Agile Manifesto favoriserer fungerende programvare fremfor grundig dokumentasjon. Smidige team bør finne den ideelle balansen mellom dokumentasjon og dialog, selv mens grundig dokumentasjon ikke kan garantere prosjektsuksess alene.
- Det endelige resultatet kan variere sterkt: Det kan ikke ha vært en klar strategi for det innledende Agile-prosjektet, og derfor kan det ferdige resultatet endre seg mye fra det som først var forventet. Et vesentlig annerledes sluttresultat kan oppstå ved å legge til nye iterasjoner basert på endret klientinndata, siden Agile er så tilpasningsdyktig.
- Utvikleres tidsforpliktelse: Utviklingsteamet må være fullt forpliktet til prosjektet for at agile skal være effektivt. Den smidige metoden, som tar lengre tid enn en konvensjonell tilnærming, krever konstant aktiv deltakelse og samarbeid. I tillegg innebærer det at utviklerne må forplikte seg til hele prosjektets lengde.
Hva er Waterfall?
Den mest populære iterasjonen av systemets utviklingslivssyklus (SDLC) for programvareteknikk og IT-prosjekter er kjent som "fossefallstilnærmingen", som følger en sekvensiell, lineær prosedyre.
Et Gantt-diagram, en form for stolpediagram som viser start- og sluttdatoene for hver jobb, brukes av og til for å planlegge den.
Utviklingsteamet går videre til følgende nivå etter at en av de åtte fasene er fullført. Teamet kan ikke gå tilbake til et tidligere stadium uten å måtte starte hele prosedyren på nytt.
I tillegg kan det hende at klienten må evaluere og akseptere kravene før teamet kan gå til neste nivå.
Fossmodellen ble utviklet i de svært organiserte miljøene i produksjons- og byggesektoren, der justeringer kan være uoverkommelig kostbare eller til og med umulige.
Fosseteknikken heter det fordi den er ment å strømme i bare én retning - nedover - akkurat som en foss. Fasene inkluderer analyse, igangsetting, testing, design, bygging, distribusjon, vedlikehold og testing.
Fosseteknikken har flere fordeler, akkurat som enhver annen strategi. Den ene er at fasene for prosjektering og design er mer veletablerte.
Kunder og utviklingsteamet er mer på linje når det gjelder prosjektleveranser mens de bruker fosseprogramvareutvikling. Fordi du er klar over prosjektets omfang fra begynnelsen, gjør fossefallsutvikling det også enklere å overvåke fremdriften.
Fosseprosessen bruker spesialister, utviklere, analytikere og testere til å konsentrere seg om jobbene sine i prosjektet i stedet for å la hele teamet vektlegge ett trinn.
Stadier av fossen
De seks trinnene til fossen må alle skje etter hverandre:
- Krav til innsamling og lagring: Du bør samle grundig kunnskap om hva dette prosjektet krever på dette tidspunktet. Det er flere teknikker for å samle inn disse dataene, inkludert intervjuer, undersøkelser og samarbeidende idédugnad. Prosjektbehovene bør være tydelige når denne fasen er over, og teamet ditt bør ha mottatt en kopi av kravdokumentet.
- Et systems design: Systemet er designet av teamet ditt ved å bruke forhåndsbestemte spesifikasjoner. I løpet av dette stadiet gjøres ingen koding, men teamet stiller krav til maskinvare eller programmeringsspråk.
- Gjennomføring: Dette stadiet involverer koding. Dataene til det foregående trinnet brukes av programmerere for å bygge et brukbart produkt. Kode implementeres ofte i bittesmå biter som kombineres ved avslutningen av en fase eller starten på en annen.
- Testing: Produktet kan begynne å bli testet etter at koden er fullført. Eventuelle problemer blir omhyggelig funnet og rapportert av testere. Prosjektet ditt må kanskje gå tilbake til fase én for revurdering hvis det dukker opp betydelige problemer.
- Levering/distribusjon: Produktet er ferdig på dette tidspunktet, og teamet ditt sender inn leveransene for distribusjon eller utgivelse.
- Vedlikehold: Kunden har mottatt produktet og bruker det. Teamet ditt må kanskje utvikle rettelser og oppdateringer når problemer dukker opp for å fikse dem. Igjen kan betydelige problemer gjøre det nødvendig å gå tilbake til trinn én.
Fordeler
- Enkel å betjene og administrere: Waterfall-tilnærmingen er enkel å bruke og forstå siden hvert prosjekt håndteres på samme sekvensielle måte. Før du starter et Waterfall-prosjekt, er det ikke påkrevd at teamet har noen tidligere ekspertise eller opplæring. Fossefallstilnærmingen er veldig streng; hvert trinn har et sett med leveranser og en gjennomgang, noe som gjør det enkelt å administrere og vedlikeholde.
- Det kreves en godt dokumentert metodikk: Dokumentasjonen som kreves av fossemetoden bidrar til å klargjøre resonnementet bak testene og koden. I tillegg skaper det et papirspor i tilfelle interessenter ønsker tilleggsinformasjon om en bestemt fase eller for eventuelle fremtidige initiativer.
- Håndhevelse av disiplin: Hvert trinn i et fossefallprosjekt har en begynnelse og en slutt, noe som gjør det enkelt å kommunisere fremgang til interessenter og kunder. Teamet kan redusere muligheten for å gå glipp av en deadline ved å sette krav og design først før de produserer kode.
Ulemper
- Det kan være vanskelig å samle presise krav: Å snakke med forbrukere og interessenter for å bestemme deres behov er en av de innledende stadiene av et Waterfall-prosjekt. På dette tidlige stadiet av prosjektet kan det være utfordrende å fastslå deres spesielle behov. Kunder lærer ofte om kravene deres etter hvert som prosjektet utvikler seg i stedet for å uttrykke dem på forhånd.
- Endringer er vanskelige å imøtekomme: Mannskapet kan ikke gjenoppta arbeidet etter endt fase. Det er veldig vanskelig og dyrt å gå tilbake og reparere den hvis de oppdager i testfasen at funksjonalitet manglet under kravprosessen.
- Programvaren leveres etter forfallsdatoen: To til fire faser av prosjektet må være ferdig før den virkelige kodingen kan starte. Som et resultat vil interessenter ikke se funksjonell programvare før sent i livssyklusen.
Hva er Scrum?
Et av de mest populære prosessrammene for å implementere Agile i praksis er Scrum, som er en undergruppe av Agile.
Det er et iterativt paradigme for å administrere opprettelsen av kompleks programvare og produkter. Sprints, som er gjentakelser med fast lengde som går en til to uker, gjør det mulig for teamet å gi ut programvare på en vanlig tidsplan.
Interessenter og teammedlemmer samles for å diskutere de neste trinnene etter hver sprint. Rollene, ansvaret og møtene i Scrum forblir konstante.
For eksempel spesifiserer Scrum sprintplanlegging, daglig stand-up, sprintdemo og sprintretrospektiv som de fire ritualene som gir hver sprintstruktur.
Teamet vil bruke visuelle artefakter som oppgavetavler eller nedbrenningsdiagrammer under hver sprint for å demonstrere fremgang og få inkrementell tilbakemelding.
I scrum jobber teamet og produkteieren tett sammen for å identifisere og prioritere systemfunksjonalitet. De oppnår dette ved å lage en produktbacklog, som inneholder alle oppgavene som er nødvendige for å produsere programvare som fungerer etter hensikten.
Feiloppdateringer, ikke-funksjonelle krav og funksjoner bør alle inkluderes i køen. Tverrfunksjonelle team må estimere og registrere seg for å levere programvareøkninger gjennom kontinuerlige Sprints, som vanligvis varer i 30 dager, når målene er etablert.
Bare teamet kan legge til funksjonalitet til sprinten etter å ha begått etterslepet for den sprinten.
Neste sprintlevering vurderes produktreserven og omprioriteres om nødvendig, og følgende leveransesett velges som en del av den påfølgende sprinten.
Scrum prosess
- Produktets tilbakeslag: For å bestille varene i produktbacklog møtes Product Owner og Scrum Team (arbeidet med produktbacklog kommer fra brukerhistorier og krav). Produktbacklog er en liste over alle ønskede funksjoner for produktet i stedet for en liste over oppgaver som må fullføres. Deretter velger utviklingsteamet oppgaver fra produktreserven som skal utføres gjennom hver sprint.
- Sprintplanlegging: Før hver sprint leverer produkteieren til teamet de øverste elementene i backloggen på et sprintplanleggingsmøte. Gruppen velger deretter elementer fra produktbackloggen som de kan fullføre i løpet av sprinten og flytter dem til sprintbacklog (som er en liste over oppgaver som skal fullføres i sprinten).
- Foredling/pleie av etterslepet: For å sikre at etterslepet er forberedt for påfølgende sprint, møtes team og produkteier ved avslutningen av en sprint. Teamet kan forkaste brukerhistorier som ikke lenger er relevante, legge til nye, revidere rekkefølgen de skal adresseres i, eller dele opp brukerhistorier i mindre oppgaver. Under dette «grooming»-møtet skal det sikres at etterslepet kun omfatter ting som er relevante, utdypende og i tråd med prosjektets mål.
- Scrum møter hver dag: I et 15-minutters stand-up møte kalt Daily Scrum, diskuterer hvert teammedlem sine mål og eventuelle problemer som har oppstått. Hver dag gjennom hele sprinten deltar teamet i Daily Scrum, som holder alle på oppgaven.
- Møte for å vurdere spurtent: Teamet presenterer arbeidet sitt på et sprintgjennomgangsmøte ved avslutningen av hver sprint. I stedet for en rapport eller en PowerPoint-presentasjon bør dette møtet inneholde en ekte demonstrasjon.
- Retrospektivt sprintmøte: Teamet diskuterer eventuelle modifikasjoner som må gjøres i den følgende sprinten, samt hvor godt Scrum fungerer for dem ved avslutningen av hver sprint. Teamet kan diskutere sprintens positive sider, negative sider og forbedringsområder.
Fordeler
- Mer ansvar fra teamet: Det er ingen prosjektleder som instruerer scrum-teamet om hva de skal gjøre og når. Arbeidet som kan fullføres i hver sprint bestemmes i stedet av laget som helhet. De samarbeider alle og gir en hånd til hverandre, forbedrer teamarbeid og fremmer individualitet i hvert teammedlem.
- Forbedret prosjektsynlighet og transparens: Det er færre misforståelser og usikkerhet siden alle i teamet er bevisst sitt ansvar takket være hyppige stand-up møter. Teamet kan håndtere problemer før de kommer ut av kontroll siden problemer oppdages på forhånd.
- Forbedrede kostnadsreduksjoner: Konstant kommunikasjon holder teamet informert om eventuelle problemer eller endringer så snart de skjer, noe som bidrar til å spare kostnader og forbedre kvaliteten. Mindre funksjonsbiter sørger for kontinuerlig tilbakemelding og muliggjør tidlig feilretting før større feil blir for dyre å rette.
- Enkel å tilpasse til endringer: Det er enklere å håndtere og tilpasse seg endringer når det er hyppige tilbakemeldingssløyfer og korte spurter. Som en illustrasjon, hvis teamet kommer over en helt ny brukerhistorie i løpet av en sprint, kan de raskt legge til denne funksjonen i den følgende sprinten på møtet for etterslep.
Ulemper
- Omfang krypfare: På grunn av mangelen på en fastsatt fullføringsdato, kan enkelte Scrum-prosjekter møte omfangskrypning. Interessenter kan bli lokket til å fortsette å kreve flere funksjoner hvis det ikke er noen frist for ferdigstillelse.
- En dårlig Scrum Master kan avspore alt: En prosjektleder er ikke det samme som en scrum master. Scrum Master må stole på teamet de overvåker og aldri gi dem instruksjoner. Scrum Master har ikke makt over laget. Prosjektet vil mislykkes hvis scrum-mesteren prøver å styre teamet.
- Nøyaktighetsproblemer kan skyldes dårlig oppgitte oppgaver: Hvis oppgavene ikke er tydelig spesifisert, vil prosjektutgifter og tidsplaner ikke være nøyaktige. Planlegging blir utfordrende og spurter kan ta lengre tid enn forventet hvis de første målene ikke er definert.
- Erfaring og engasjement er nødvendig for et team: For at teamet skal lykkes, må roller og plikter være klart definert. Scrum-teamet krever teammedlemmer med tekniske ferdigheter fordi det ikke er noen klart definerte roller (alle gjør alt). Teamet må også forplikte seg til å delta i de daglige Scrum-øktene og holde sammen for hele prosjektets levetid.
Agile vs Scrum
Selv om Agile og Scrum bruker samme metodikk, er det noen variasjoner mellom de to. Agile Manifesto skisserer et sett med prinsipper for å lage programvare gjennom iterativ utvikling.
Scrum, på den annen side, er et sett med retningslinjer som må følges mens du gjør Agile programvareutvikling. Agile er et konsept, mens Scrum er en teknikk for å sette det ut i livet.
Scrum er en metode for å implementere Agile, derfor har de begge mange ting til felles. Begge tilnærmingene er iterative, prioriterer tidlig og hyppig programvarelevering og aksepterer endringer. De støtter også åpenhet og kontinuerlig utvikling.
Smidig vs Foss
Rigid vs. fleksibel beskriver best forskjellene mellom Waterfall-prosessen og Agile. Mens smidig er flytende og i stadig endring, er Waterfall en mye strammere, mer rigid metodikk.
Disse ytterligere forskjellene mellom dem er som følger:
- Agile krever ikke en lineær tilnærming, mens Waterfall er sekvensiell.
- Mens behov ofte er forhåndsdefinert i Waterfall-prosjekter, forventes de å endre og tilpasse seg i Agile-initiativer.
- I motsetning til Agile, tillater ikke Waterfall-prosjekter endringer i arbeid som ble fullført i et tidligere stadium.
- Fossen er en organisert prosedyre der du må fullføre hvert trinn før du går videre til neste. Agile er imidlertid en fleksibel metodikk som lar deg fortsette med prosjektet i ditt eget tempo.
Agile vs Waterfall vs Scrum
- Fossen øker tilliten til det som skal gis veldig kort tid etter at det er planlagt. Agile er avhengig av et utviklingsmiljøs beste praksis. Her kan en rekke prosjektrisikoer styres godt siden resultatene evalueres kontinuerlig.
- Waterfall forventer ikke at teamet og prosjektet vil være basert på samme sted. Mens scrum og smidig trenger samlokalisering av ansatte.
- Agile fokuserer på å redusere prosjektomarbeiding og oppfordrer til å innarbeide endringer mye tidligere. I motsetning til fossen, som reagerer annerledes, muliggjør scrum også tidlig oppdagelse av endringer.
- En mer kompakt plan for sluttproduktet er gitt av smidig og scrum. Dette skaper et problem med løftene gitt til kjøperen. Fossgrafikken gir derimot klienter og utviklere et bedre inntrykk av det ferdige resultatet.
- Hver av disse teknikkene har et sett med verktøy for å organisere og simulere oppgavene som er involvert i opprettelsen.
konklusjonen
Hvis du har fulgt med så langt og er trygg på kunnskapen din om forskjellene mellom Waterfall-, Agile- og Scrum-prosessene, bør du allerede vite hvilken strategi som vil fungere best for deg og teamet ditt.
Waterfall-teknikken, som er for prosjekter med et bestemt omfang, tidsramme og budsjett, kan være det beste alternativet hvis du liker harde regler og prosedyrer og finner ut at de gir klarhet.
På den annen side, hvis friheten og tilpasningsevnen Agile tilbyr inspirerer deg, kan det være der du bør sette oppmerksomheten din.
Scrum er imidlertid veien å gå hvis du ønsker litt disiplin innenfor et fleksibelt rammeverk.
Du må imidlertid vurdere disse tilnærmingene i lys av prosjektet du jobber med og ditt endelige resultat.
Legg igjen en kommentar