Meny

Agile Manifesto: Forstå smidige verdier og prinsipper

  • Hoved
  • Annen
  • Agile Manifesto: Forstå smidige verdier og prinsipper

agile manifesto understanding agile values

Prøv Instrumentet Vårt For Å Eliminere Problemer

Agile Manifesto Introduksjon:

Vår forrige opplæring om Agil metodikk forklarte oss alt om Agile modeller og metoder i detalj.

Men inntil nå handler vi ikke om hvorfor det var et behov for smidig i utgangspunktet, og hvordan smidig overvant manglene ved eksisterende programvareutviklingsmetoder som fossemodellen.

I denne opplæringen vil vi gå dypere inn i detaljene om smidig og smidig manifest. Vi får se hva manifestet sier og hva er verdiene og prinsippene som er nedfelt i det.

smidig manifest

Hva du vil lære:

Introduksjon

Som vi så i vår forrige opplæring , tidligere utviklingsmetoder tok for lang tid, og da programvaren var klar for distribusjon, ville forretningskravene ha endret seg og dermed ikke imøtekomme dagens behov.

Endringshastigheten som manglet på den tiden forårsaket mange problemer. Da lederne for forskjellige utviklingsmetoder møttes for å bestemme seg for veien videre, og de var i stand til å bli enige om en bedre metode og også var i stand til å fullføre ordlyden for manifestet.

Dette ble fanget som 4 verdier og 12 prinsipper for å hjelpe utøverne til å forstå, henvise til det og sette det ut i livet. Og på det tidspunktet kunne ingen av dem forestille seg hvilken innvirkning dette ville ha på fremtiden for prosjektledelse.

Agile manifest

Manifestet har blitt veldig nøye formulert for å fange essensen av smidig i minimumsord, og det lyder som nedenfor -

“Vi avdekker bedre måter å utvikle en programvare på ved å gjøre det og hjelpe andre til å gjøre det. Gjennom dette arbeidet har vi kommet til verdien nedenfor:

  • Enkeltpersoner og interaksjoner over prosesser og verktøy.
  • Arbeidsprogramvare over omfattende dokumentasjon.
  • Kundesamarbeid over kontraktsforhandlinger.
  • Svar på endring etter en plan.

Det vil si at mens det er verdi i elementene til høyre, verdsetter vi elementene til venstre mer. '

Som vi kan se, er dette ganske konsise og enkle uttalelser og gjør det veldig klart som det grunnleggerne ønsket å fremme. Vanligvis er tradisjonelle prosjektplaner stive, og de legger vekt på prosedyrer og tidslinjer, men det smidige manifestet forplanter nøyaktig det motsatte.

Det foretrekker:

  • Mennesker
  • Produkt
  • Kommunikasjon og
  • Respons

Vi vil utforske dette nye paradigmet som grunnleggerne ønsket å promotere i detalj ved å få en dypere forståelse av de smidige verdiene og prinsippene.

hva er best mp3 downloader for android

De 4 smidige verdiene

De fire verdiene sammen med de 12 prinsippene styrer smidig programvarelevering. Vi vil diskutere hver av verdiene i detalj nå.

Smidige verdier

# 1) Enkeltpersoner og interaksjoner over prosesser og verktøy

Enkeltpersoner og interaksjoner foretrekkes fremfor prosesser og verktøy fordi det gjør prosessen mer responsiv. Hvis individene er på linje og når de forstår hverandre, kan teamet løse eventuelle problemer med verktøyene eller prosessene.

Men hvis teamene insisterer på å holde seg til prosessene blindt, kan det føre til misforståelser blant individene og skape uventede veisperringer og dermed føre til forsinkelser i prosjektet.

Derfor er det alltid å foretrekke å ha interaksjoner og kommunikasjon mellom teammedlemmene i stedet for blindt, avhengig av prosesser for å lede veien videre. En av måtene å oppnå dette på er å ha en involvert produkteier som jobber og kan ta beslutninger i samarbeid med utviklingsteamet.

Å tillate enkeltpersoner å bidra på egenhånd lar dem også vise fritt som det de kan bringe til bordet. Når disse teaminteraksjonene er rettet mot å løse et vanlig problem, kan resultatene være ganske kraftige.

# 2) Arbeidsprogramvare over omfattende dokumentasjon

Tradisjonell prosjektledelse innebar omfattende dokumentasjon som medførte en forsinkelse på flere måneder. Dette hadde en negativ innvirkning på prosjektleveransen, og de resulterende forsinkelsene var uunngåelige.

Dokumentasjonstypen som ble opprettet for disse prosjektene var veldig detaljert, og det ble opprettet så mange dokumenter at mange av dem ikke engang ble henvist til under prosjektfremdriften. Dette var en unødvendig ondskap som prosjektlagene pleide å leve med.

Men dette forverret også leveringsproblemene. Fokuset var på dokumentasjon i en slik grad fordi teamene ønsket å ende opp med et ferdig produkt som var 100% i henhold til spesifikasjonene. Det var derfor fokuset var å fange opp alle spesifikasjonene i detaljer.

Men fortsatt, sluttproduktet pleide å være ganske annerledes enn forventningene eller ville ha mistet relevansen. Derfor sier agile at en fungerende programvare er et mye bedre alternativ for å måle kundens forventning enn masser av dokumentasjon.

Dette innebærer ikke at dokumentasjonen ikke er nødvendig. Det betyr bare at et fungerende produkt er en hvilken som helst dag en bedre indikator for tilpasning til kundens behov og forventninger enn et dokument opprettet for flere måneder siden. Det innebærer også at lagene er lydhøre og klare til å tilpasse seg endringer etter behov og samtidig vise programvaren til klienten når sprinten slutter.

Unnlatelse av å teste produktet under sprint koster mangfoldige kostnader og krefter i neste sprint. Når funksjonaliteten er distribuert, øker kostnadene for disse endringene i betydelig grad.

3. Kundesamarbeid over kontraktforhandling

Forhandling betyr at detaljene fremdeles fanges opp og ikke er avsluttet. Det er fortsatt rom for reforhandling. Men når forhandlingene er over, kan det ikke være noen diskusjon om det. Det smidige sier er at i stedet for forhandlinger, gå for samarbeid.

Samarbeid innebærer at det fremdeles er rom for diskusjon og kommunikasjonen pågår.

Ikke en engangs ting. Hva dette gjør er at det gir en fordobling av fordelen - mens det hjelper teamet å gjøre en kurskorrigering hvis det er nødvendig på et tidligere tidspunkt, hjelper det klienten å også finpusse sin visjon og omdefinere kravene hvis det er nødvendig i løpet av prosjekt.

Det andre aspektet er at mens tradisjonelle programvareutviklingsmodeller involverer kunden før utviklingen begynner i dokumentasjons- og forhandlingsfasen, og de er ikke like involvert under prosjektutviklingen.

Når kravene har blitt frosset, får de bare se produktet når produktet er klart. Agile bryter også gjennom denne barrieren ved å tillate kundeengasjement over hele livssyklusen.

Dette hjelper de smidige teamene bedre å tilpasse seg kundens behov. En av måtene å oppnå dette på er gjennom en dedikert og involvert produkteier som kan hjelpe teamet i sanntid for avklaringer og tilpasse arbeidet til kundens prioriteringer.

4. Svare på endring etter en plan

Standard tankeprosess er at endringene er en kostbar affære, og vi bør unngå endringer for enhver pris. Det er det unødvendige fokuset på dokumentasjon og forseggjorte planer for å levere ved å holde seg til tidslinjene og produktspesifikasjonene.

Men som erfaring også lærer oss, er endringer stort sett uunngåelige, og i stedet for å løpe fra den, bør vi prøve å omfavne den og planlegge for den.

Agile lar oss gjøre denne overgangen. Det smidige mener er at endring ikke er en kostnad, det er en velkommen tilbakemelding som bidrar til å forbedre prosjektet. Det skal ikke unngås, men i stedet tilfører det verdi.

Med de korte spurtene foreslått av agile, kan lagene få rask tilbakemelding og skifte prioriteringer på kort varsel. Nye funksjoner kan legges til fra iterasjon til iterasjon.

Hvorfor gjør vi dette? Fordi de fleste funksjonene som er utviklet ved hjelp av fossen, ikke brukes. Dette er fordi fossemodellen følger planen, mens det er den fasen når vi vet minst.

Agile planlegger også, men det følger også just in time tilnærming der planlegging gjøres akkurat nok når det er nødvendig. Og planene er alltid åpne for endring etter hvert som spurtene utvikler seg.

De 12 smidige prinsippene

Det er 12 smidige prinsipper som ble lagt til etter at manifestet ble opprettet for å hjelpe og veilede team overgang til smidig og kontrollere om praksisene de følger er i tråd med den smidige kulturen.

Følgende er teksten til de opprinnelige 12 prinsippene, publisert i 2001 av Agile Alliance:

#1) Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlig og kontinuerlig levering av verdifull programvare.

#to) Velkommen skiftende krav, selv sent i utvikling. Agile prosesser utnytter endring for kundens konkurransefortrinn.

# 3) Lever arbeidsprogramvare ofte, fra et par uker til et par måneder, med en preferanse fremfor kortere tidsskala.

# 4) Forretningsfolk og utviklere må jobbe sammen daglig gjennom hele prosjektet.

grunnleggende sql intervju spørsmål og svar for ferskere pdf

# 5) Bygg prosjekter rundt motiverte individer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort.

# 6) Den mest effektive og effektive metoden for å formidle informasjon til og innen utviklingsteamet er en ansikt til ansikt-samtale.

# 7) Arbeidsprogramvare er det primære målet for fremgang.

# 8) Agile prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne skal kunne holde et konstant tempo på ubestemt tid.

# 9) Kontinuerlig oppmerksomhet mot teknisk fortreffelighet og god design forbedrer smidighet.

# 10) Enkelhet - kunsten å maksimere arbeidsmengden er mye viktig.

#elleve) De beste arkitekturer, krav og design kommer fra selvorganiserende team.

# 12) Med jevne mellomrom reflekterer teamet over hvordan man kan bli mer effektivt, og stiller deretter inn og justerer oppførselen deretter.

Disse smidige prinsippene gir praktisk veiledning for utviklingsteamene.

En annen måte å organisere de 12 prinsippene på er å vurdere dem i følgende fire forskjellige grupper:

  • Kundetilfredshet
  • Kvalitet
  • Teamarbeid
  • Prosjektledelse

#1) Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlig og kontinuerlig levering av verdifull programvare - Kunder vil åpenbart være begeistret for å se at en fungerende programvare blir levert hver sprint i stedet for å måtte gå gjennom en tvetydig ventetid på slutten som bare de får se produktet.

Her kan kunden defineres som prosjektsponsor eller personen som betaler for utviklingen. Sluttbrukeren av produktet er også en kunde, men vi kan skille mellom de to ettersom sluttbrukeren blir referert til som en bruker.

#to) Velkommen skiftende krav, selv sent i utvikling. Agile prosesser utnytter endring for kundens konkurransefortrinn - Endringer kan innarbeides uten store forsinkelser i de samlede tidslinjene.

Siden de smidige teamene tror på kvalitet fremfor alt, vil de heller innlemme endringer og levere i henhold til kundens krav enn å unngå endringer og levere et produkt som ikke tjener forretningsbehovet.

# 3) Lever arbeidsprogramvare ofte, fra et par uker til et par måneder, med en preferanse for kortere tidsskala - Dette blir ivaretatt av lagene som jobber i sprint. Siden sprints er tidsbokse iterasjoner og leverer en fungerende programvare på slutten av hver sprint, får kundene regelmessig en ide om fremdriften

vennefunksjoner i c ++

# 4) Forretningsfolk og utviklere må jobbe sammen daglig gjennom hele prosjektet - Bedre avgjørelser tas når begge jobber sammen og det er en konstant tilbakemeldingssløyfe mellom de to for kurskorrigering og endringsfleksibilitet. Kommunikasjon mellom interessentene er alltid nøkkelen til smidig.

# 5) Bygg prosjekter rundt motiverte individer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort - Du må støtte, stole på og motivere lagene. Et motivert team er mer sannsynlig å lykkes og vil levere et overlegen produkt enn ulykkelige team som ikke er villige til å gi sitt beste.

En av måtene å gjøre dette på er å styrke utviklingsteamet til å være selvorganisert og ta sine egne beslutninger.

# 6) Den mest effektive og effektive metoden for å formidle informasjon til og i utviklingsteamet er en ansikt til ansikt-samtale - Kommunikasjon er bedre og mer innflytelsesrik hvis lagene er på samme sted og kan møtes ansikt til ansikt for diskusjoner. Det hjelper med å bygge tillit og gir forståelse blant ulike interessenter.

# 7) Arbeidsprogramvare er det primære målet for fremgang - En fungerende programvare slår alle de andre KPI-ene og er den beste indikatoren på utført arbeid.

# 8) Agile prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne skal kunne holde et konstant tempo på ubestemt tid - Konsistens i levering er vektlagt. Teamet skal være i stand til å opprettholde tempoet over prosjektets varighet og ikke brenne ut etter de første spurtene.

# 9) Kontinuerlig oppmerksomhet mot teknisk fortreffelighet og god design forbedrer smidighet - Teamet skal ha alle ferdighetene og et godt produktdesign for å håndtere endringene og produsere et høykvalitetsprodukt mens de er i stand til å innlemme endringer

# 10) Enkelhet - Kunsten å maksimere mengden arbeid som ikke er utført er viktig og er akkurat nok til å oppfylle definisjonen av gjort.

#elleve) De beste arkitekturer, krav og design kommer fra selvorganiserende team - Selvorganiserte team er bemyndiget og tar eierskap til arbeidet sitt. Dette fører til åpen kommunikasjon og regelmessig deling av ideer blant teammedlemmene.

# 12) Med jevne mellomrom reflekterer teamet over hvordan man kan bli mer effektivt, og stiller deretter inn og justerer oppførselen deretter - Selvforbedring fører til raskere resultater og mindre omarbeid.

Konklusjon

Kundesentrisitet og fokus på kommunikasjon har ført til suksess for smidig som er synlig i dag.

Det er en bevist teknikk med implikasjoner ikke bare i programvarelevering, men også i andre bransjer, og i dag har det blitt en bransje i seg selv.

Vår kommende opplæring i denne serien vil forklare mer om Scrum Team sammen med rollene deres !!

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^