Smidig metodikk: Betydning, fordeler, ulemper og mer

Den smidige metodikken er en programvareutviklingsfilosofi som tar sikte på å levere bedre verdi til kundene ved å bruke kortere utviklingssykluser og samtidig inkludere konstante revisjoner.

Programvareutvikling vokste fra feltene matematikk og naturvitenskap. Så den inkorporerte opprinnelig de vitenskapelige metodene fra disse feltene.

Disse metodene utviklet seg til fossefallstilnærmingen på 1970-tallet for å imøtekomme dagens krav. Datamaskiner og deres programvare på den tiden var store, komplekse og designet for å vare i flere tiår. Så fossefallsmetoden passet godt.

Men på slutten av 1990-tallet forandret internett verden dramatisk, og en ny tilnærming ble nødvendig. Slik ble den smidige metodikken levende.

Følgende er en nærmere titt på denne programvareutviklingsbevegelsen og hvordan den kan hjelpe deg og teamet ditt.

Historien om den smidige utviklingsmetoden

Smidig programvareutvikling vokste fra internett og dets umettelige behov for applikasjoner under boomårene på 1990-tallet og begynnelsen av 2000-tallet.

Dette var også en periode da mange utviklere uten informatikkbakgrunn gikk over til nettutvikling på grunn av det enorme behovet for nettsteder som henvender seg til ulike grupper og bransjer.

Naturligvis var de fleste oppstartene små. Så de fleste utviklingene skjedde i små team, med det endelige målet ofte å være en rask time-to-market. Som å være sent innebar det å miste markedsandeler.

For å motvirke begrensningene som fossefallsmodellen ga for å få produkter på markedet så raskt som mulig, kom forskjellige utviklere opp med forskjellige metoder i løpet av 1990-tallet. De inkluderer Rapid Application Development (RAD), Scrum, Extreme Programming (XP), Kanban og andre.

Så, en gang i 2001, kom 17 utviklere som praktiserte den ene eller den andre formen for tidlig smidig utvikling, sammen i Utah, USA. Deretter avsluttet de møtet med å publisere 'Manifest for smidig programvareutvikling.

Dette manifestet er basert på 4 verdier og 12 prinsipper.

De 4 verdiene og 12 prinsippene for smidig utvikling

Fra erfaringene de trakk sammen under møtet, kom de 17 utviklerne til enighet om et sett med verdier for å skape programvare mer effektivt.

Disse fire verdiene er som følger:

1. Individer og interaksjoner over prosesser og verktøy. Dette betyr at det er viktig å utvikle programvare med verktøy mens du følger en bestemt prosess. Men det er viktigere å ha kompetente mennesker som jobber mer effektivt sammen.
   
   
2. Fungerende programvare over omfattende dokumentasjon. Denne angriper fossefallsmetoden med å først designe programvare og skrive dokumentasjon for den før selve programvareutviklingsprosessen.
   
   
3. Kundesamarbeid over kontraktsforhandling. Det er kun ved å jobbe tett med kunden eller brukeren man kan lære og utvikle akkurat det kunden trenger. Dette skaper mer verdi.
   
   
4. Reagerer på endring over å følge en plan. Det er viktig å følge en prosjektplan. Men planen må ikke være for rigid. Den må tilpasses endringer for å møte interessentenes forventninger.

Disse Agile Manifesto-verdiene ovenfor er basert på 12 prinsipper og de er som følger:

1. Kundetilfredshet ved tidlig og kontinuerlig levering av verdifull programvare.
2. Velkommen til skiftende krav, selv i sen utvikling.
3. Lever fungerende programvare ofte (uker i stedet for måneder)
4. Tett, daglig samarbeid mellom forretningsfolk og utviklere
5. Prosjekter er bygget rundt motiverte individer, som man bør stole på
6. Samtale ansikt til ansikt er den beste formen for kommunikasjon (samlokalisering)
7. Fungerende programvare er det primære målet på fremgang
8. Bærekraftig utvikling, i stand til å holde et konstant tempo
9. Kontinuerlig oppmerksomhet på teknisk fortreffelighet og god design
10. Enkelhet – kunsten å maksimere mengden arbeid som ikke er utført – er avgjørende
11. De beste arkitekturene, kravene og designene kommer fra selvorganiserende team
12. Regelmessig reflekterer teamet over hvordan de kan bli mer effektive og justerer deretter

Iterasjoner eller sprints

Iterasjoner eller sprints i smidig programvareutvikling er korte perioder på vanligvis 1 til 4 uker, hvor utviklingsarbeidet brytes inn. Dette gjør ting enklere å administrere, da det krever mindre planlegging.

Hvert team består også typisk av medlemmer med ulike funksjoner, og disse kan inkludere planlegging, analyse, design, koding og testing.

Teamet jobber med programvaren ved hver iterasjon eller sprint sammen. Og de produserer et fungerende produkt på slutten. Denne fungerende programvaren er et mål på sann fremgang, ifølge Agile Manifesto.

Avhengig av produktet og kundens behov, kan en iterasjons produkt slippes ut på markedet eller ikke. Så det tar ofte mange iterasjoner for en enkelt utgivelse.

Fordelene med smidig utvikling

Som du kan forestille deg, gir den smidige metodikken mange fordeler. De er som følger:

1. Raskere implementering av ideer
2. Mer fleksibilitet enn fossefallet
3. Forbedret produktivitet med administrerte iterasjoner
4. Bedre produkter gjennom brukerinteraksjoner
5. Feil blir raskt identifisert og eliminert

Ulemper med Agile-metodikken

Det er også noen ulemper ved å jobbe med en smidig utviklingsmetode. Og de kan inkludere:

1. Det kan være vanskelig å vurdere hele kostnadene i begynnelsen
2. Det krever mye kundeinnspill
3. Innebærer mye uplanlagt arbeid
4. Ingen klart definert prosjektslutt

Når skal man bruke smidige metoder

1. Når du ikke kan anslå hva programvaren krever
2. Du har nok tilgang til kunder
3. Du utvikler en nettapp eller et system som er enkelt å oppdatere
4. Du må raskt ta markedsandeler med en tidlig utgivelse

Populære Agile utviklingsrammer

Det er mange populære smidige utviklingsrammer. Noen startet langt før Agile Manifesto i 2001, mens andre kom senere.

Målet med et rammeverk er ganske enkelt å definere reglene for en metode. Så selv om de mest populære rammene er oppført nedenfor for referanse, er det mange flere. Og du står også fritt til å lage ditt eller endre et eksisterende rammeverk for å passe til teamet ditt.

1. Scrum: Dette rammeverket er designet for lag med 10 eller færre medlemmer. Arbeidet er delt ned i sprints på 2-4 uker med daglige 15-minutters møter.
   
   
2. Kanban: Kanban stammer fra Toyota, og er et japansk ord som betyr reklametavle og er svært nyttig for team som setter pris på visuelle hjelpemidler. Oppgaver flyttes fra ett trinn til et annet ved hjelp av visuelle representasjoner som klistrelapper eller apper.
   
   
3. Rask applikasjonsutvikling RAD: Denne setningen kan både referere til smidig programvareutvikling generelt eller James Martin-metoden. RAD fokuserer på brukergrensesnittkrav og er avhengig av prototyping.
   
   
4. Slank oppstart: Dette rammeverket er for de som trenger å utvikle et produkt eller en tjeneste, men først må bestemme deres markedslevedyktighet. Det innebærer bruk av eksperimentering for å se hva som fungerer og hva som ikke gjør det.

Andre bemerkelsesverdige rammeverk inkluderer ekstrem programmering (XP), adaptiv programvareutvikling, smidig modellering, dynamisk systemutviklingsmetode og skalert smidig rammeverk.

De smidige vs fossemetodene

Her er en side-ved-side titt på de smidige og fossemetodene for utvikling av programvare. Det kan hjelpe å vite hvordan hver metode står opp mot den andre. Så du kan enkelt velge de beste verktøyene for jobben din.

Agile	Waterfall
Inkrementell og iterativ tilnærming	Lineær og sekvensiell livssyklusmodell
Fleksibel å endre	Rigide implementeringer
Tester og vurderinger pågår	Det er bare én testfase etter ferdigstillelse
Kravene kan endres	Krav fastsettes etter planlegging
En samling av mange mindre prosjekter	Ett enkelt prosjekt
Mer kundeinvolvering	Mindre kundeinvolvering

Adaptiv vs prediktiv utvikling

Målet med smidig programvareutvikling er å tilpasse seg endringer i den virkelige verden. Og disse er ofte et resultat av en kundes eller brukers behov. Tilpasning står i sterk kontrast til fossefallmodellens prediktive karakter.

Da er det fornuftig å bruke smidige metoder når man utvikler systemer som man ikke er så sikker på hvordan ting vil slå ut. Eller når det er konstante endringer og utvikling i en bransje. Internett er et stort eksempel.

Ellers hvis du utvikler for et system eller marked som du vet alt om, og som knapt endrer seg eller er immun mot endringer. Da kan den prediktive naturen til fossefallsfilosofien være til hjelp.

Programvarehåndverk

Software Craftsmanship er en annen filosofi som bygger på smidige utviklingsprinsipper, og den fokuserer på å fremheve ferdighetene til programvareutviklerne som er involvert i et prosjekt.

Software Craftsmanship-bevegelsen har også et manifest og det heter:

Som ambisiøse programvarehåndverkere hever vi standarden for profesjonell programvareutvikling ved å praktisere det og hjelpe andre med å lære håndverket. Gjennom dette arbeidet har vi kommet til verdi: · Ikke bare fungerende programvare, men også godt utformet programvare · Ikke bare reagere på endringer, men også stadig tilføre verdi · Ikke bare enkeltpersoner og interaksjoner, men også et fellesskap av profesjonelle · Ikke bare kunder samarbeid, men også produktive partnerskap. Det vil si at i jakten på elementene til venstre har vi funnet at elementene til høyre er uunnværlige.  © 2009, undertegnede. Denne erklæringen kan fritt kopieres i enhver form, men bare i sin helhet gjennom denne kunngjøringen

Konklusjon

Når vi kommer til slutten av vår titt på smidig metodikk og programvareutvikling, kan du se at det er så mange alternativer der ute.

Hvert lag er forskjellig. Og akkurat som forskjellige team utviklet sine forskjellige metoder for å tilpasse seg skiftende tider. Du må også tilpasse deg ved å enten gå med et allerede etablert rammeverk eller ved å tilpasse det for å passe teamet ditt.