Share
Agile eller Agile Development - vi hører disse ordene oftere i disse dager. Men vet vi virkelig hva det handler om? Hvordan kan det hjelpe oss å bli mer effektive, mens vi har mye moro å utvikle programvare? Hvordan kan vi bruke den til å kommunisere med forretningsfolk og gjøre denne kommunikasjonen enkel og konstruktiv for begge sider?
Det var en haug med svært talentfulle og erfarne karer som utviklet noen seriøs programvare. Disse utviklerne observert andre selskaper og utviklingsgrupper, og hvordan deres prosesser gjorde sitt arbeid enklere. De samlet sine observasjoner for å skape Agile Manifesto. Og de sa:
Vi oppdager bedre måter å utvikle programvare ved å gjøre det og hjelpe andre å gjøre det. Gjennom dette arbeidet har vi kommet til å verdsette:
Det er, mens det er verdi i elementene til høyre, verdsetter vi varene til venstre mer.
I denne artikkelen vil jeg presentere tolv teorier og teknikker for Agile Development. Dette er bare det første skrittet til den nye verden av programvareutvikling.
Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlig og kontinuerlig levering av verdifull, men ikke fullverdig, programvare. Dette betyr at vi utvikler programvare og legger til minst én funksjon, per iterasjon.
La oss forestille oss at vi vil lage en bloggmotor; det kan vi gjøre ved å bruke følgende prosess:
Det er en enkel tilnærming, men kunden ser den virkelige fremgangen av programvaren hans og gir deg umiddelbar tilbakemelding på hver ny funksjon. Det kan være perfekt eller kreve tweaking, men du kan raskt svare på endringer: en vinn-vinn-situasjon.
Selv sent i utviklingssyklusen, gir Agile-prosesser deg velkommen til å bytte for kundens konkurransefortrinn.
Kunden ønsker at prosjektet er ferdig raskt og så nært som mulig i designet. Dette oppnås enkelt ved å bare lytte til inngangen og være klar for endringer. Hvis vi er i stand til å reagere raskt på endrede krav, er vi sannsynligvis det beste valget vår klient noensinne har gjort. Agile handler om kommunikasjon og endringer. Vi gjør tingene som vi blir bedt om å gjøre, slik at programvareutviklingsprosessen blir raskere. Dette oppnås fordi vi utvikler små stykker programvare, og en endring i kravene påvirker ikke oss virkelig.
Vi bør levere oppdateringer fra et par uker til et par måneder; jo kortere tidspunkter, desto bedre.
kunder føler seg mer selvsikker i oss og vårt produkt som det er oppdatert
Fra mine erfaringer føler kundene mer selvsikkerhet i oss og vårt produkt som det er oppdatert - noe som er viktig for vårt forhold til dem. En annen fordel er tilbakemeldingen fra vår klient; slik at vi kan reagere ved å endre klasser, funksjoner, moduler eller til og med arkitekturen. Vi vil ikke våkne opp etter dager eller måneders arbeid, bare for å se at alt går inn i søpla. La oss vurdere en hypotetisk situasjon:
Du har blitt bedt om å lage en modul som vil vise noen enkel tekst i en innholdshåndtering. Plutselig endres kravene, og du må legge til et skjema som skal sende en e-post til en konfigurert adresse. I tillegg skal skjemaet tilpasses slik at brukeren kan legge til nye felt og definere validatorer. Så, du må i utgangspunktet glemme det opprinnelige enkle tekstkravet. Hvor snart vil du vite om denne endringen?
Hvis du jobber med et prosjekt med kunden din og leverer ofte, vil du vite om disse endringene raskere, og endringer som dette vil bli enklere for dere begge..
Dette kan vise seg å være det vanskeligste prinsippet å bli vant til, hvis du har utviklet programvare i den gamle fossstilen. Du, som utvikler, snakker vanligvis ikke det samme språket som klienten, men du kan finne måter å opprettholde meningsfull kommunikasjon med dem. En av de beste måtene er etter min mening å beskrive alt med en enkel historie som forteller oss, utvikleren, for hvem funksjonen er, hva dens ansvar er og hvorfor vi trenger det i det hele tatt. Selvfølgelig blir dette lettere jo mer vi jobber med kunden vår. En annen nyttig tilnærming er Behavior Driven Development (BDD), men det er et emne for en annen artikkel.
Gi folkene du jobber med miljøet og støtten de trenger, og fremfor alt stoler på at de skal få jobben gjort.
Det er viktig å gi en engasjerende atmosfære og alle verktøyene som er nødvendige for å skape god programvare. Bedrifter mister sine beste arbeidere for det meste fordi de ikke virkelig bryr seg om dem. Troen på at utviklere kan skrive, teste og distribuere programvare på en hvilken som helst server ved hjelp av en FTP-klient og redigere levende produksjonsfiler, har mistet et sted. Hvis du ikke har fordømt de gamle skolevaner, gjør du det bedre nå.
Å beholde ansatte er bare en fordel; Du kan også utvikle bedre og større programvare i et raskere tempo. Bare tenk på det: å skrive gjenbrukbar kode, automatiserte tester og automatisert distribusjon på en hvilken som helst server (blant annet) kan positivt påvirke utviklings tiden. Vi tror vanligvis at vi drar ned et prosjekt fordi vi må lære å bruke nyttige verktøy, som Jenkins, GIT, SVN, Gerrit, Behat, etc. Vi gjør det ærlig, men vi kan da bruke disse verktøyene og konseptene i fremtidige prosjekter.
Det er den mest effektive og effektive metoden for å formidle informasjon til våre kunder og utviklings team.
Hvem har ikke blitt overveldet og / eller sint ved å se 6,255,384 e-postmeldinger i innboksen din, fordi din bedrift krever at alle samtaler blir "på papir"? Jeg har personlig sett det et par ganger i mitt liv, og jeg anbefaler ikke å jobbe i et selskap med slike vaner. Ansikt til ansikt samtaler gjør kommunikasjonen lettere og jevnere, og tillater oss å gi mer informasjon. Vi kan bruke verbale og nonverbal kommunikasjonsmåter for å vise våre lagkamerater hva vi tenker. Det er åpenbart raskere enn å sende e-post til hverandre.
Men fremfor alt må vi stole på hverandre; tillit er lett oppnådd i et miljø som oppfordrer ansikt til ansiktskommunikasjon.
Dette er en av mine favorittregler; det lar oss fritt arbeide i henhold til våre egne prosesser. Programvareutviklere er forskjellige enn andre ansatte; så naturlig bør de behandles som sådan. Fra min personlige erfaring har jeg lært ikke å dømme noen fra utviklingslaget så lenge jobben er ferdig. Utviklere ønsker ikke å lage dårlig programvare, og de er mindre sannsynlig å gjøre det hvis vi la dem jobbe i henhold til deres egne preferanser. Tross alt er kunden lykkelig så lenge arbeidet de har bestilt er gjort riktig; de bryr seg ikke hvordan det ble gjort.
Agile prosesser fremmer bærekraftig utvikling, slik at et konstant tempo kan opprettholdes på ubestemt tid.
Agile mest kjente fordeler (som aksept av endring av krav, rask reaksjon på tilbakemelding osv.) Blir mye verdsatt, men den beste fordelen er etter min mening muligheten til å nøyaktig bestemme hvor lang tid et prosjekt eller en funksjon vil forbruke. Etter noen få leveranser vil dev-laget produsere det mest verdifulle forretningsnummeret: kapasitet. Kapasitet er mengden arbeid laget kan gjøre i en iterasjon. Kapasitetsnummeret er stabilt etter noen få iterasjoner, og vi kan unngå de latterlige tidsfrister og tidsrammer som er "trukket ut av en lue" mens vi presenterer vårt selskaps tilbud til kunden.
Mange sier at det er umulig og planlegging viser seg å være mer nøyaktig. Jeg er uenig; tidsplanen antar at det ikke vil være noen feil eller uunngåelige forsinkelser.
Det er en perfekt plan for et perfekt lag, og det eksisterer ikke.
Kontinuerlig oppmerksomhet til vår bransje øker smidigheten.
Vi forventes å utvikle seg og gjøre fremgang. Vi må fortsette å lære hver dag, fordi næringen beveger seg i et så raskt tempo. Da både maskinvare og programvare blir bedre, må vi holde oss oppdatert; Ellers vil vi finne oss tapt i "Sea of New", og det vil være vanskelig å komme tilbake på sporet.
Refactoring er løsningen på de fleste problemer. Ved stadig refactoring (når det er nødvendig), kan vi enkelt bruke nye teknikker og bedre vår programvarearkitektur.
Bill Gates sa en gang:
Hvis jeg har noe komplisert arbeid å gjøre, vil jeg gi det til den skitseste personen jeg har, fordi de vil finne den enkleste måten å gjøre det på.
Enkelhet er den gylne regelen. Dette betyr ikke at du må være lat, men det betyr at utviklere kompliserer sitt eget arbeid mesteparten av tiden. Hvis du bare gjør jobben, vil klienten, uten ytterligere funksjoner og forbedringer, din arbeidsbelastning lyse, og du vil oppnå dine mål. Til slutt, det er alt kunden bryr seg om.
De beste arkitekturene, kravene og designene kommer fra selvorganiserende lag.
Vi er bare mennesker; Vi kan ikke forutsi alt.
Har du noen gang vært i en situasjon der du utviklet en stor og tidkrevende søknad, og etter å ha brukt utallige timer foran skjermen, skrev tusenvis av kodelinjer og leser artikler, opplæringer og bøker, du satte deg ned og se på noen dårlige (men arbeider) kode tanke, "Nå vet jeg hvordan jeg skal skrive det bedre"? Jeg tror vi har alle hatt disse øyeblikkene.
Det er her den ellevte regelen kommer inn. Vi har et team av utviklere som kan følge prinsippene for Test Driven Development (TDD), der refactoring er en del av prosessen. På noen magisk måte er vår programvare nyttig, vakker, godt skrevet, testet og opprettet raskt. Vi er bare mennesker; Vi kan ikke forutsi alt.
Alt dette kommer fra ideen om et selvorganiserende team, hvor hvert medlem har en rolle - ikke gitt eller tvunget - men en som har oppstått etter litt tid sammen. Det er skjønnheten i lagarbeidet.
Med jevne mellomrom må dev-teamet ditt reflektere over hvordan man skal bli mer effektiv, og justere sin oppførsel, tilsvarende.
Dette kan kreve noen utviklingssykluser, men laget vil fungere i perfekt harmoni. Selv å legge til nye mennesker til dette laget ville ikke være skadelig. En Agile utviklingsgruppe handler om å få jobben gjort. Hvis de jobber i et vennlig miljø, finner de "arbeidets melodi", og du får se hvor raskt programvareutvikling kan være.
Det er noen metodologier avledet av og bygget på Agile-prinsipper. Jeg vil ikke beskrive dem alle fordi hver metode kan dekkes i sin egen artikkel. Jeg vil imidlertid skissere noen av de mer kjente Agile-tilnærmingene. En ting å huske er at det ikke finnes en metode for å herske dem alle. Velg en som passer best til dine behov, og til og med "konfigurere" den slik at den passer til dine spesifikke krav.
Skrevet av Ken Schwaber og Jeff Sutherland, er SCRUM et forretningsmessig rammeverk for å administrere programvareutviklingsprosesser. Det finnes mange forskjellige typer SCRUM; Bare husk at hovedmålet er å jobbe effektivt, effektivt og ikke å holde fast i regler.
Opprettet av Kent Back, er XP en liste over beste praksis som utviklere bør følge mens du lager programvare. Det kalles ofte "utvidelsen av SCRUM". Denne metodikken for utviklingsorienterte regler ble født, på grunn av at SCRUM var ganske næringsrettet.
To av Leans hovedprinsipper er: DALAP (Bestem så sent som mulig) og DAFAP (Lever så raskt som mulig). Jeg anbefaler personlig å lese mer om denne metoden, da det kan være veldig nyttig.
Det finnes flere metoder i Agile-familien; Jeg har rett og slett referert til de mest populære alternativene. Hvis du bestemmer deg for å bruke Agile i utviklingsprosessen, må du vite hva disse metodene er, for å velge den rette for deg.
Fungerer Agile teknikker virkelig?
Fungerer Agile teknikker virkelig, og er metodene virkelig så magiske som alle sier? Ikke alltid.
Problemet jeg opplevde i selskaper, hvor Agile-metodene ikke ga resultater (eller til og med gjort ting verre), var en dårlig valgt metodikk og mangel på overbevisning blant brukerne (forretningsmedlemmer, utviklingslaget, osv.). Det er derfor, i denne forfatterens oppfatning, at du må være sikker på at alle involverte i prosessen forstår reglene, og de vet "hva det handler om."
Takk for at du leste!
Accentsconagua