Agile metoder og metoder til begyndere - Agile softwareudvikling og agile projektledelseseksempler

Agile er en metode til at nærme sig softwareudvikling. Den består af forskellige rammer som SCRUM eller Kanban, der hjælper udviklingshold med kontinuerligt at opbygge, teste og samle feedback på deres produkt.

Agile består af fire centrale principper:

  1. Enkeltpersoner og interaktioner over processer og værktøjer
  2. Arbejder software over omfattende dokumentation
  3. Kundesamarbejde over kontraktforhandling
  4. Svar på at skifte efter en plan

Jeg vil se på disse principper senere og gøre dem mere fornuftige. For at gøre det er det vigtigt at tage et skridt tilbage og forstå softwareudviklingspraksis, der tidligere blev brugt.

Vandfald

Vandfaldsudvikling er en meget lineær tilgang til at opbygge et produkt. Det har ringe eller ingen plads til feedback eller iteration, før produktet er helt bygget og testet.

Sådan fungerer det: hold bruger uger (og undertiden måneder) på at udarbejde produktkravsdokumenter.

Inden nogen kode faktisk skrives, vil produktledere, analytikere og designere sammensætte et massivt dokument, der skitserer produktkravene i ekstreme detaljer.

Dette er mildt sagt en lang og besværlig proces, hvor uundgåeligt nogle ting går glip af.

Her er et simpelt tankeeksperiment. Tænk på Google-søgning eller en klient-e-mail-finder.

Prøv nu at prøve at få vist kravene til disse produkter.

Uden tvivl vil vigtige ting gå glip af. Man kan simpelthen ikke forestille sig brugen eller omfanget eller omfanget af, hvordan disse produkter vil udvikle sig over tid.

Hvis du har bygget et produkt - som solo-builder eller som medlem af et team - kan du sandsynligvis forholde dig til denne påstand.

Når alt er aftalt, udleveres specifikationerne til ingeniørholdet, som derefter bygger produktet til specifikation, udnyttelse af kvalitative og kvantificerende data og input.

Når alt er kodet op, starter testen.

Hvis det er et komplekst produkt, kan test og fejlrettelse tage uger eller måneder, da hele produktet skal gennemgå streng gennemgang. Når testere og produktadministratorer underskriver testkravene, er produktet klar til levering til produktion.

Der er en række mangler ved udvikling af vandfald, og her er et par.

Mangel på indbyggede feedbackmekanismer

Hvad hvis udviklingsteamet følger specifikationerne nøjagtigt, og det viser sig, at det at se det komme til liv bare ikke er så overbevisende som produktteamet troede det var? Eller endnu værre, hvad hvis der var en fejl i specifikationsdokumentet?

I udviklingen af ​​vandfald kender du ikke svaret på disse spørgsmål, før produktet allerede er bygget.

Produktudvikling kan føre til store faste omkostninger. Hvis produktet ikke fungerer, kan disse omkostninger blive sunkne omkostninger.

Sunk-omkostninger er bygherrens fjende, fordi en sunkne omkostning er en omkostning, der allerede er afholdt og ikke kan inddrives.

Hvad hvis køreplanen ændres?

Dette sker hele tiden. Det sker på den computer, du bruger til at læse denne artikel, det sker i din virksomhed, og det sker hos teknologivirksomheder store og små.

Hvad hvis køreplanen ændres, og holdet har brug for at rette opmærksomheden mod noget andet? Under vandfald står du tilbage med et ubrugeligt produkt. Tænk: stivhed.

Igen, hvis du ikke kan forvandle dine faste omkostninger til noget fleksibelt, vil du have en stor regning og ikke meget at vise for det.

Alt det dedikerede arbejde, stressede deadlines, whiteboardkalendering og sene aftener fører ikke til de resultater, du ønskede i starten af ​​projektet.

Produktet opsamler støv, indtil det endelig sendes

I stedet for inkrementelle forbedringer, der leveres til produktionen over en periode, venter vandfaldsmetoden med at levere hele produktet til slutningen.

Selvom dette er en rimelig tilgang til at bygge en bil, er dette ikke en god tilgang til software.

Software, i modsætning til biler, er fleksibelt i designinputene.

Folk kan ikke bruge halvproducerede biler. Men vi bruger halvt bygget software hele tiden.

Indtast Agile

Agile hjælper med at løse disse problemer ved at lade produktudviklingsteam løbende opbygge funktioner, der tilføjer værdi. Det giver også holdene mulighed for konsekvent at få feedback på deres arbejde og foretage ændringer efter behov.

Med anvendelsen af ​​Agile-metoder sender hold konsekvent og forudsigeligt små stykker kode til produktion i hurtigt tempo.

Når de har gennemført nogen form for funktion, der tilføjer værdi, tester de og frigiver den til verden. Dette er en iterativ tilgang til teknologibygning.

I stedet for at tage måneder at bygge et slutprodukt og køre en end-to-end-test giver Agile-udvikling holdene mulighed for løbende at bygge mindre stykker af det endelige produkt og føje dem til produktionen over tid.

Det betyder, at test går hurtigere, da du kun tester kompatibiliteten af ​​det nyeste stykke kode. Dette betyder også, at brugere og interessenter er lykkeligere, fordi de løbende kan se og udnytte de nyeste produktforbedringer.

Overvej begge tilgange til et rigtigt ordeksempel på ombygning af et køkken. Lad os sige, at det vil tage seks måneder at udføre ombygningsjobbet godt.

Vandfald vil foreslå, at entreprenøren og hans eller hendes besætning genopbygger hele køkkenet og derefter afslører hele køkkenet for klienten, når de seks måneder er udløbet.

Mens jobbet bliver færdig i samme tid, er ejeren i mørket. Enkle spørgsmål som hvordan går det stort set ubesvaret. Værst af alt er det, at ejerne ikke kan bruge nogen dele af køkkenet indtil slutningen.

Med Agile ville entreprenøren i stedet finde ud af, hvad deres team kunne få gjort hvert par uger, og derefter lade deres klient se det og bruge det, mens de ombyggede resten af ​​det.

Måske kan de udskifte skabene i den første måned, bordpladerne i den anden måned, og inden den tredje måned installerer de et nyt køleskab og komfur. Ikke et dårligt resultat for begge parter!

I den anden tilgang får ejeren fordelen ved at bruge dele af køkkenet, før alt er færdigt. I stedet for at den nye komfur bare sidder der og samler støv, bliver den faktisk brugt, så snart den kan bruges.

Og måske vil køkkeneejeren bytte et skab ud til en hylde?  

Entreprenøren kan nu i det mindste planlægge den ændring, inden de seks måneder er gået, og lade ejeren vide, hvordan det vil påvirke projektets tidslinje.

Tilsyneladende kan begge parter arbejde sammen og kommunikere transparent for at sikre, at de rigtige resultater og arbejdet udføres.

Dette er nogle af de mange fordele ved Agile. Begge parter har det bedre.

Prøv at tage denne lektion fremad, når du lærer nye udviklingsevner på freeCodeCamp og anvender dine færdigheder på projekter.

Lad os overveje nogle andre eksempler i softwareverdenen

Når vi gennemgår de fire principper for Agile, kan vi nu begynde at finde eksempler på Agiles anvendelse i den virkelige og digitale verden.

Nu håber jeg, du kan se, hvordan disse principper er et direkte angreb på vandfaldsprocessen.

Princip # 1: Enkeltpersoner og interaktioner over processer og værktøjer

At have en solid proces og et sæt værktøjer er meget vigtigt i Agile. Værdiansættelse af enkeltpersoner og interaktioner over værktøjer muliggør dog mere værdiskabelse og output.

Individuelle teammedlemmer kan innovere.

I stedet for at tvinge folk til at overholde strenge ideer og specifikationer, kan du give dem mere båndbredde til at eksperimentere.

En del af placeringen af ​​enkeltpersoner over værktøjer er eksperimentering med nye arbejdsgange. Et eksempel, der er relevant for innovation inden for Agile softwareudvikling, er codec, et computerprogram, der koder eller afkoder en digital datastrøm eller signaler.

H266 / VVC-codec bruger ca. halvdelen af ​​dataene til at streame 4K-videoer. Og det er anerkendt som den mest effektive kodningsløsning til fremtidig 4K og endda 4K VR real-time streaming.

Hvordan blev denne opdagelse gjort? Det blev lavet af folk, der bruger Agile til at løse problemer med videokomprimering.

Specifikt blev det lavet, fordi enkeltpersoner fik frihed til at bygge, teste, eksperimentere og innovere over en periode. De fik ikke besked på at bygge køkkenet fra bunden og komme tilbage om seks måneder.

De tog små skridt i den rigtige retning. Dette resultat er lærerigt.

Her er et andet eksempel: Da Lastpass blev erhvervet af LogMeIn, var LogMeIn lige så interesseret i teknologien, som de var den kultur af design, som Lastpass havde implementeret for at bygge produkter.

Hvilken type kultur var det? En der prioriterede Agile.

Agile bringer ikke kun produkter hurtigere på markedet, men skaber kreative og synergistiske resultater, der er værdifulde.

At skabe værdi er indlejret i Agile-kulturen.

Princip # 2: Arbejdssoftware over omfattende dokumentation

Denne skal være indlysende nu. I stedet for detaljerede specifikationer og planlægning skal du bare skrive et par linier kode, der fungerer.

Test det. Få feedback om det. Send det.

Så gør det igen.

Gentage.

Et meget relevant eksempel på denne gentagelsesproces findes i Forms on Fire.

De oprettede software til at gøre indsamling af mobildata let. De skrev ikke hele deres firma, før de blev lanceret; de skrev et par linier kode, testede den og sendte den.

Da de fik fart, fremskyndede de deres test og iterative trin.

Og de gentog, hvad der fungerede, og kastede, hvad der ikke gjorde. Resultaterne taler for sig selv.

Princip # 3: Kundesamarbejde over kontraktforhandling

Agile fremmer en hurtig feedback-loop for at få feedback fra kunder og interessenter.

Hvad kan være bedre end at arbejde baglæns fra det, som rigtige brugere og kunder ønsker?

Jeg har en forretningsmentor, der rådede, at i stedet for at overanalyse, hvad kunderne ønsker gennem endeløs planlægning, skal det bare være enkelt. ”Afbøde distraktioner,” sagde han.

Jeg har skrevet om KISS-princippet i freeCodeCamp, og det råd gælder bestemt i Agile: opbygge noget lille, og se om dine kunder kan lide det.

Hvis de gør det, skal du fortsætte.

Princip # 4: Reagerer på skift efter en plan

Hurtige feedback-sløjfer får hurtige ændringer og justeringer. Det er dette, der gør Agile så god for udviklingsteams.

Det er derfor, du skal omfavne det.

Køreplaner ændres altid, dette er en kendt konstant. Ved hjælp af Agile metoder kan teams reagere på ændringer ved at lytte til kundefeedback og foretage de nødvendige justeringer.

Der er tidspunkter, hvor man reagerer på ændringer betyder at justere dit produkt eller ændre, hvordan du tænker på brugere eller konkurrencen.

Et klassisk eksempel, som studerende på agile kan se på i e-handelsområdet, sælger på Amazon. Hvordan tilpasser man sig hurtigt til konkurrencen? En måde er at opbygge lukkede samfund eller prøve forskellige produktlanceringsstrategier.

Det anbefales at implementere løsninger, der er taktiske og smidige.

Der er et vidunderligt ordsprog: ”Vi kan ikke ændre vindretningen. Vi kan kun justere vores sejl. ”

Når jeg tænker på Agile, tænker jeg på dette ordsprog.

Agile handler om læring, Agile handler om undervisning. Agile handler om fleksibilitet.

Du kan øve dig Agile i dit daglige arbejde eller tage online kurser for at udvikle dig videre.

Nogle mennesker er kloge nok til at forudsige, hvad deres kunde ønsker. De ved, hvilken vej vinden blæser.

Men for os dødelige er Agile en metode til at navigere rundt i vores mangler ved at forstå, hvad kunderne ønsker.

Det er systemet, der lader os konstant justere vores sejl.