Meny

Agile Manifesto: Förstå agila värden och principer

  • Huvud
  • Övrig
  • Agile Manifesto: Förstå agila värden och principer

agile manifesto understanding agile values

Prova Vårt Instrument För Att Eliminera Problem

Agile Manifesto Introduktion:

Vår tidigare handledning om Agil metodik förklarade oss allt om Agile modeller och metoder i detalj.

Men hittills handlar det inte om varför det fanns ett behov av smidig i första hand och hur smidig övervunnit bristerna i befintliga programvaruutvecklingsmetoder som vattenfallsmodellen.

I denna handledning kommer vi att gå djupare in i detaljerna om agile och det agila manifestet. Vi får se vad manifestet säger och vilka värden och principer som finns i det.

smidigt manifest

Vad du kommer att lära dig:

Introduktion

Som vi såg i vår föregående handledning , tidigare utvecklingsmetoder tog för mycket tid och när mjukvaran var redo att distribueras, skulle företagskraven ha förändrats och därmed inte tillgodose de nuvarande behoven.

Den förändringshastighet som saknades vid den tiden orsakade många problem. När ledarna för olika utvecklingsmetoder träffades för att bestämma sig för vägen framåt, och de kunde komma överens om en bättre metod och kunde också slutföra formuleringen för manifestet.

Detta fångades som fyra värden och 12 principer för att hjälpa utövarna att förstå, hänvisa till det och omsätta det i praktiken. Och vid den tidpunkten kunde ingen av dem ha föreställt sig vilken inverkan detta skulle få på framtiden för projektledning.

Agile Manifesto

Manifestet har varit mycket noggrant formulerat för att fånga essensen av smidig i minsta ord och det lyder som nedan -

”Vi avslöjar bättre sätt att utveckla en programvara genom att göra det och hjälpa andra att göra det. Genom detta arbete har vi kommit till nedanstående värde:

  • Individer och interaktioner över processer och verktyg.
  • Arbetsprogramvara över omfattande dokumentation.
  • Kundsamarbete över kontraktsförhandlingar.
  • Svarar på förändring efter en plan.

Det vill säga, medan det finns värde i objekten till höger värdesätter vi objekten till vänster mer. ”

Som vi kan se är dessa ganska kortfattade och enkla uttalanden och gör det mycket tydligt som vad grundarna ville främja. Vanligtvis är traditionella projektplaner styva och de betonar procedurer och tidslinjer, men det agila manifestet sprider exakt motsatta saker.

Det föredrar:

  • människor
  • Produkt
  • Kommunikation och
  • Lyhördhet

Vi kommer att utforska detta nya paradigm som grundarna ville främja i detalj genom att få en djupare förståelse för de agila värdena och principerna.

De 4 smidiga värdena

De fyra värdena tillsammans med de 12 principerna styr den smidiga programvaruleveransen. Vi kommer att diskutera vart och ett av värdena i detalj nu.

Smidiga värden

# 1) Individer och interaktioner över processer och verktyg

Individer och interaktioner föredras framför processer och verktyg eftersom det gör processen mer lyhörd. Om individerna är inriktade och när de förstår varandra kan teamet lösa eventuella problem med verktygen eller processerna.

Men om lagen insisterar på att blindt hålla fast vid processerna kan det orsaka missförstånd bland individerna och skapa oväntade spärrar och därmed resultera i projektförseningar.

Därför är det alltid att föredra att ha interaktioner och kommunikation mellan gruppmedlemmarna snarare än blindt beroende på processer för att styra vägen framåt. Ett av sätten att uppnå detta är att ha en involverad produktägare som arbetar och kan fatta beslut i samarbete med utvecklingsteamet.

Att låta individer bidra på egen hand gör det också möjligt för dem att visa fritt som vad de kan ta med sig till bordet. När dessa teaminteraktioner är inriktade på att lösa ett vanligt problem kan resultaten bli ganska kraftfulla.

vilket företag är för närvarande ledande inom molnbaserade webbhotell?

# 2) Arbetsprogramvara över omfattande dokumentation

Traditionell projektledning innebar omfattande dokumentation som innebar en försening på månader. Detta påverkade tidigare projektleveransen negativt och de resulterande förseningarna var oundvikliga.

Den typ av dokumentation som skapades för dessa projekt var mycket detaljerad och så många dokument skapades att många av dem inte ens hänvisades till under projektförloppet. Detta var en onödig ondska som projektgrupperna brukade leva med.

Men detta förvärrade också leveransproblemen. Fokus låg på dokumentation i en sådan utsträckning eftersom lagen ville sluta med en färdig produkt som var 100% enligt specifikationerna. Det var därför fokus låg på att fånga alla specifikationer i detalj.

Men ändå brukade slutprodukten vara helt annorlunda än förväntningarna eller skulle ha tappat relevansen. Det är därför agile säger att en fungerande programvara är ett mycket bättre alternativ för att mäta kundernas förväntningar än massor av dokumentation.

Detta innebär inte att dokumentationen inte är nödvändig. Det betyder bara att en fungerande produkt när som helst är en bättre indikator för anpassning till kundernas behov och förväntningar än ett dokument som skapades för månader sedan. Det innebär också att lagen är lyhörda och redo att anpassa sig till förändringar efter behov och samtidigt visa arbetsprogramvaran för klienten när sprinten slutar.

Underlåtenhet att testa produkten under sprintar tar flera fördelar och ansträngningar i nästa sprint. När funktionaliteten väl har implementerats ökar kostnaden för dessa ändringar avsevärt.

3. Kundsamarbete över kontraktsförhandlingar

Förhandling innebär att detaljerna fortfarande fångas upp och inte har slutförts. Det finns fortfarande utrymme för omförhandling. Men när förhandlingen är över kan det inte diskuteras. Det smidiga säger är att istället för förhandlingar, gå till samarbete.

Samarbete innebär att det fortfarande finns utrymme för diskussion och kommunikationen pågår.

Inte en engångs sak. Vad detta gör är att det ger två fördelar - medan det hjälper teamet att göra en kurskorrigering om det behövs i ett tidigare skede, men det hjälper klienten att också förfina sin vision och omdefiniera deras krav om det behövs under projekt.

Den andra aspekten är att medan traditionella programvaruutvecklingsmodeller involverar kunden innan utvecklingen börjar under dokumentations- och förhandlingsfasen, och de är inte lika involverade under projektutvecklingen.

När kraven har frusits ​​får de bara se produkten när produkten är klar. Agile bryter också igenom denna barriär genom att möjliggöra kundengagemang under hela livscykeln.

Detta hjälper de smidiga lagen att anpassa sig bättre till kundens behov. Ett av sätten att uppnå detta är genom en dedikerad och engagerad produktägare som kan hjälpa teamet i realtid för förtydliganden och anpassa arbetet till kundens prioriteringar

4. Att svara på förändring efter en plan

Den vanliga tankeprocessen är att förändringarna är en dyr affär och vi bör undvika förändringar till varje pris. Det är det onödiga fokuset på dokumentation och utarbetade planer att leverera genom att följa tidslinjerna och produktspecifikationerna.

Men som erfarenheten lär oss är förändringar mestadels oundvikliga och istället för att springa ifrån det bör vi försöka omfamna det och planera för det.

Agile tillåter oss att göra denna övergång. Vad agilt tycker är att förändring inte är en kostnad, det är en välkommen feedback som hjälper till att förbättra projektet. Det ska inte undvikas utan i stället tillför det värde.

Med de korta sprint som föreslås av agile kan lagen få en snabb feedback och flytta prioriteringar med kort varsel. Nya funktioner kan läggas till från iteration till iteration.

Varför gör vi det här? Eftersom de flesta av funktionerna som utvecklats med vattenfallet används aldrig. Detta beror på att vattenfallsmodellen följer planen medan det är den fas när vi vet minst.

Agile planerar också, men det följer också just-in-time-metoden där planering görs tillräckligt när det behövs. Och planerna är alltid öppna för att förändras när sprinten fortskrider.

De 12 smidiga principerna

Det finns 12 agila principer som har lagts till efter skapandet av manifestet för att hjälpa och vägleda team övergång till smidig och kontrollera om de metoder som de följer är i linje med den smidiga kulturen.

Nedan följer texten till de ursprungliga 12 principerna, som publicerades 2001 av Agile Alliance:

# 1) Vår högsta prioritet är att tillfredsställa kunden genom en tidig och kontinuerlig leverans av en värdefull programvara.

#två) Välkommen till förändrade krav, även sent i utveckling. Agile processer utnyttjar förändring för kundens konkurrensfördel.

# 3) Leverera arbetsprogramvara ofta, från ett par veckor till ett par månader, med en preferens framför kortare tidsskala.

# 4) Affärsmän och utvecklare måste arbeta tillsammans dagligen under hela projektet.

hur man lägger till svn-plugin i förmörkelse

# 5) Bygg projekt kring motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem att få jobbet gjort.

# 6) Den mest effektiva och effektiva metoden för att förmedla information till och inom utvecklingsteamet är en konversation ansikte mot ansikte.

# 7) Arbetsprogramvara är det primära måttet på framsteg.

# 8) Agila processer främjar hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en konstant takt på obestämd tid.

# 9) Kontinuerlig uppmärksamhet på teknisk spetskompetens och god design ökar smidigheten.

# 10) Enkelhet - konsten att maximera mängden arbete som inte utförs är mycket viktigt.

#elva) De bästa arkitekturerna, kraven och designen framgår av självorganiserande team.

# 12) Med regelbundna mellanrum reflekterar teamet över hur man kan bli mer effektivt, ställer sedan in och justerar sitt beteende därefter.

Dessa smidiga principer ger praktisk vägledning för utvecklingsteamen.

Ett annat sätt att organisera de 12 principerna är att beakta dem i följande fyra olika grupper:

  • Kundnöjdhet
  • Kvalitet
  • Lagarbete
  • Projektledning

# 1) Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara - Kunder kommer uppenbarligen att vara glada över att se en fungerande programvara levereras varje sprint snarare än att behöva gå igenom en tvetydig väntetid i slutet av vilken bara de får se produkten.

Här kan kunden definieras som projektsponsorn eller den person som betalar för utvecklingen. Slutanvändaren av produkten är också en kund men vi kan skilja mellan de två eftersom slutanvändaren kallas en användare.

#två) Välkommen till förändrade krav, även sent i utveckling. Agila processer utnyttjar förändringar för kundens konkurrensfördel - Ändringar kan införlivas utan stora förseningar i de övergripande tidslinjerna.

Eftersom de smidiga teamen tror på kvalitet framför allt, skulle de hellre införliva förändringar och leverera enligt kundens krav än att undvika förändringar och leverera en produkt som inte tillgodoser affärsbehovet.

# 3) Leverera arbetsprogramvara ofta, från ett par veckor till ett par månader, med en preferens framför kortare tidsskala - Detta tas hand om av team som arbetar i sprints. Eftersom sprints är tidsbokade iterationer och levererar en fungerande programvara i slutet av varje sprint får kunder regelbundet en uppfattning om framstegen

# 4) Affärsmän och utvecklare måste arbeta tillsammans dagligen under hela projektet - Bättre beslut fattas när båda arbetar tillsammans och det finns en konstant återkopplingsslinga mellan de två för kurskorrigering och förändringsfunktion. Kommunikation mellan intressenterna är alltid nyckeln till smidig.

# 5) Bygg projekt kring motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem att få jobbet gjort - Du måste stödja, lita på och motivera lagen. Ett motiverat team är mer sannolikt att lyckas och kommer att leverera en överlägsen produkt än olyckliga team som inte är villiga att ge sitt bästa.

Ett av sätten att göra detta är att ge utvecklingsgruppen möjlighet att vara självorganiserad och fatta sina egna beslut.

# 6) Den mest effektiva och effektiva metoden för att förmedla information till och inom utvecklingsteamet är en konversation ansikte mot ansikte - Kommunikationen är bättre och mer effektfull om lagen är på samma plats och kan mötas ansikte mot ansikte för diskussioner. Det hjälper till att bygga förtroende och ger förståelse bland olika intressenter.

# 7) Arbetsprogramvara är det primära måttet på framsteg - En fungerande programvara slår alla andra KPI: er och är den bästa indikatorn på utfört arbete.

# 8) Agila processer främjar hållbar utveckling. Sponsorerna, utvecklarna och användarna bör kunna hålla en konstant takt på obestämd tid - Konsistens vid leverans betonas. Teamet ska kunna behålla sin takt under hela projektets längd och inte bränna ut efter de första sprintarna.

hur man öppnar en jar-fil med java

# 9) Kontinuerlig uppmärksamhet på teknisk spetskompetens och god design ökar smidigheten - Teamet ska ha alla färdigheter och en bra produktdesign för att hantera förändringarna och producera en högkvalitativ produkt samtidigt som de kan införliva förändringar

# 10) Enkelhet - Konsten att maximera mängden arbete som inte utförts är väsentlig och är tillräckligt för att uppfylla definitionen av gjort.

#elva) De bästa arkitekturerna, kraven och designen framgår av självorganiserande team - Självorganiserade team bemyndigas och tar ägandet av sitt arbete. Detta leder till öppen kommunikation och regelbundet utbyte av idéer bland teammedlemmarna.

# 12) Med regelbundna mellanrum reflekterar teamet över hur man kan bli mer effektivt, ställer sedan in och justerar sitt beteende därefter - Självförbättring leder till snabbare resultat och mindre omarbetning.

Slutsats

Kundens inriktning och fokus på kommunikation har lett till framgång för agil som är synlig idag.

Det är en beprövad teknik med implikationer inte bara för leverans av programvara utan även för andra industrier och idag har det blivit en bransch i sig själv.

Vår kommande handledning i denna serie kommer att förklara mer om Scrum Team tillsammans med deras roller !!

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^