Distribuerad agil mjukvaruutveckling

Distribuerad agil mjukvaruutveckling är ett forskningsområde som överväger effekterna av att tillämpa principerna för agil mjukvaruutveckling på en globalt distribuerad utvecklingsmiljö , med målet att övervinna utmaningar i projekt som är geografiskt fördelade.

Principerna för agil mjukvaruutveckling ger strukturer för att främja bättre kommunikation, vilket är en viktig faktor för att framgångsrikt arbeta i en distribuerad miljö. Men att inte ha interaktion ansikte mot ansikte tar bort en av de grundläggande agila principerna. Detta gör distribuerad agil mjukvaruutveckling mer utmanande än agil mjukvaruutveckling i allmänhet.

Historia / Forskning

Den ökande globaliseringen med hjälp av nya möjligheter som tillhandahålls av Internets tekniska effektivitet har lett till att företag inom mjukvaruutveckling offshore sina utvecklingsinsatser till mer ekonomiskt attraktiva områden. Detta fenomen började på 90-talet, medan dess strategiska betydelse förverkligades på 2000-talet. De flesta inledande relaterade studier härstammar också från omkring denna tid.

Under denna tid släpptes Agile Manifesto , som representerar en utveckling från de rådande tungviktsstrategierna för mjukvaruutveckling. Detta ledde naturligtvis till frågan "kan distribuerad mjukvaruutveckling vara agil?". En av de första omfattande recensionerna som försökte besvara denna fråga gjordes 2006. Genom att studera tre organisationer fann de att "noggrann inkorporering av smidighet i distribuerade mjukvaruutvecklingsmiljöer är avgörande för att ta itu med flera utmaningar för kommunikation, kontroll och förtroende mellan distribuerade team ”. Senare, 2014, gjordes en systematisk litteraturöversikt (SLR) för att identifiera huvudproblemen med att få agilt att arbeta på ett distribuerat sätt. Under 2019 gjordes en liknande SLR. Dessutom gjordes en allmän genomgång av ämnet i. Resultaten av en del av denna forskning kommer att diskuteras i avsnittet Utmaningar och risker.

Sammantaget förblir distribuerad agil mjukvaruutveckling ett mycket dynamiskt område. Forskning fortsätter att göras på alla dess aspekter, vilket indikerar att det erbjuder unika möjligheter och fördelar jämfört med mer traditionella metoder, men inte utan att medföra sina egna utmaningar och risker.

Möjligheter

I den distribuerade miljön kan man ha svårt att hålla reda på allas arbetsbelastning och bidrag till leveransen. Genom antagandet av agila principer och praxis görs synligheten tydligare eftersom det finns flera iterationer där man kan visualisera problem eller kritiska aspekter i de inledande skedena av projektet. Kontinuerlig integrering av programmeringskod, som är en av de centrala delarna av agil mjukvaruutveckling, tjänar dessutom till att minska konfigurationen av de verkställande frågorna. Att anta agila principer verkar positivt påverka korrespondensen mellan grupper eftersom framsteg i cykler gör det enklare för medlemmarna att se de kortsiktiga målen. Sprintrecensioner kan ses som en kraftfull metod för att förbättra extern korrespondens samtidigt som de hjälper till att dela data om funktionerna och förutsättningarna mellan partners eller intressenter. Agila metoder hjälper också till att bygga förtroende mellan olika team som är associerade med processen genom att stimulera konsekvent kommunikation och överföring av programmeringsresultat. Som framgår av en undersökning gjord av Passivara, Durasiewicz och, Lassenius, förbättras mjukvarans kvalitet och korrespondens och kommunikationen och samordnade ansträngningar är mer regelbundna jämfört med ett resultat av Scrum-metoden som används i företaget. Dessutom förklarades inspirationen från kollegor ha utökats. I enlighet med dessa linjer har det visat sig vara värdefullt att använda agila metoder i en distribuerad miljö för kvaliteten på projektet och dess genomförande. Dessa kan alltså ses som några av de fördelar som uppnås genom att kombinera agilt i distribuerad utveckling, dock är listan uttömmande. De viktigaste fördelarna kan listas enligt följande:

Förbättrad inter- och intrakulturell mångfald

Den distribuerade miljön skapar en känsla av globalt tänkesätt framför det lokala tänkesättet, där teamet kan utbyta och acceptera den andras idéer, uppfattningar, kultur, estetik etc. Medlemmar från ett brett spektrum av kulturer får möjlighet att få och dela kunskap från sina medarbetare, från en alternativ synvinkel. På detta sätt kan de genomföra nya planer till uppgiften genom att överväga ur lådan.

Flexibla arbetsplaner

Teammedlemmarna kan dras nytta av riklig frihet och möjligheter på sättet att arbeta, med det enda syftet att slutföra uppgifterna och lämna in leveranserna i tid. Detta ger också plats för en utökad plikt gentemot organisationen. På så sätt kan medarbetarna balansera både sitt yrkesliv och privatliv, och därmed kan balansen mellan arbete och privatliv också uppnås på det sättet.

Att korsa tidszoner

Lagen kan sträcka sig över flera tidszoner, på detta sätt tillgång så länge som 24-timmarsgränsen kan uppnås. Detta ökar produktiviteten eftersom människor anställs över hela världen. Jobbet som ska göras stoppas aldrig eftersom det alltid finns någon i närheten för att hantera problemet. Detta säkerställer också att arbetet utförs 24/7 runt solen och att det nästan inte finns några stillestånd. Eftersom en distribuerad miljö fokuserar mer på produktivitet och prestanda, hjälper överlämnandet av arbetet till att utföra uppgiften.

Individer med funktionshinder och rörelsehinder

Som nämnts lägger den distribuerade agila miljön större vikt vid produktivitet och prestanda, snarare än närvaro. Detta gynnar personer med funktionsnedsättning eftersom de har friheten att arbeta i en miljö som är bekväm för dem och som bidrar till leveransen. Detta scenario är också tillämpligt när den anställde inte kan vara närvarande på kontoret och klocka in timmarna, han kan arbeta hemifrån för att slutföra uppgifterna, vilket inte påverkar leveransen.

Ökade nivåer av välstånd

Att arbeta i en distribuerad agil miljö säkerställer en ökad nivå av välstånd och välbefinnande, både för individer och för företaget. Detta beror på att det inte är mycket stress för endast en individ att slutföra arbetet eftersom arbetet distribueras till flera personer över hela världen. Detta säkerställer alltså fysiskt och psykiskt välbefinnande. Dessutom, eftersom flera personer bidrar med sin del och det går igenom ett antal iterationer, förbättras slutkvaliteten på arbetet, vilket är fördelaktigt för företaget. Därför är det en win-win-situation för både företaget och dess anställda.

Minskade resekostnader

Att arbeta i en distribuerad miljö tar ofta upp behovet av diskussioner och möten om mål, deadlines, arbete etc. Detta antagande av agila principer och praxis i en distribuerad miljö hjälper dock till att minska resekostnaderna eftersom det öppnar upp plattformen för att kommunicera via videokonferenser och andra möjliga alternativ. Detta bryter ner behovet av fysisk närvaro och förstärker idén om öga mot öga interaktion, så att mötena kan genomföras från vilken del av världen som helst och göras tillgängliga för de andra i teamet.

Iterativ idé om smidig

Eftersom arbetets framsteg sker på ett iterativt sätt, kan en regelbunden kontroll göras för att spåra statusen för leveransen och om alla medlemmar är på samma sida i förståelsenivån. Detta sätt gör det också lättare att identifiera fel och buggar och kan korrigeras i tidigare skeden när processen går igenom flera iterationer. Den ökade insatsen i varje steg av arbetet resulterar i förbättrad kvalitet på leveransen.

Omfattande pool av HR

Eftersom samma arbete utförs i olika delar av världen, ökar det omfånget av förmågor hos gruppen genom att komma till en mer omfattande personalpool över hela världen. Detta introducerar behovet av att alla HR:er agerar som ett sinne för att genomdriva samarbeten och beslutsfattande i olika vertikaler och horisonter inom en organisation, samt för att kommunicera med intressenter och prioritera leveransen.

Minskar kontorsutrymmen

Den distribuerade agila miljön förstärker idén om distansarbete, varför behovet av att utöka kontorsytor för att rymma fler anställda inte längre behövs. De olika arbetsrelaterade sakerna som elektricitet, datorer, parkeringsplatser etc. är inte heller något större problem eftersom de anställda har friheten att arbeta utifrån sin önskade miljö. Detta är på ett sätt fördelaktigt eftersom det hjälper till att spara en enorm summa pengar som annars skulle spenderas på dessa omkostnader. Iterativ förbättring med kontinuerlig leverans till klienten är en central praxis i agila mjukvaruförbättringar, och en som legitimt identifierar en av de betydande svårigheterna med en offshore-händelse: minskad uppfattning om projektstatus. Regelbundna fysiska möten gör det möjligt för teamledare, projektledare, kunder och kunder att hålla reda på projektets framsteg genom det mått på fungerande programmering de har erhållit.

Utmaningar och risker

Distribuerad mjukvaruutveckling har sina egna inneboende utmaningar på grund av rumsliga, tidsmässiga och sociokulturella skillnader mellan distribuerade team. Att kombinera det med agila principer och praxis ökar i sin tur allvaret av riskerna, eftersom båda metoderna står i direkt kontrast till varandra. Agil mjukvaruutveckling designades ursprungligen för att användas av samlokaliserade team, eftersom den bygger på informell kommunikation och nära samarbete. Distribuerad utveckling kräver dock formell kommunikation, tydliga standarder, fastställda riktlinjer och stel struktur. Det här avsnittet beskriver de risker och utmaningar som är involverade i distribuerad agil mjukvaruutveckling till följd av ovannämnda kompatibilitetsproblem.

Utmaningar

Som ett resultat av den oförenlighet som man ställs inför när man kombinerar agila principer och metoder i en distribuerad miljö, är några av de utmaningar som kan uppstå som följer.

Dokumentation

Offshore-organisationer föredrar plandriven design där detaljerade krav skickas offshore för att byggas. Detta strider mot den vanliga praxisen hos agila team som ger dokumentation lägre prioritet. Resultatet av denna situation är att missförstånd är mycket mer benägna att uppstå.

Parprogrammering

Parprogrammering, där två programmerare arbetar sida vid sida för att arbeta med ett visst problem är en vanlig agil praxis. Det har visat sig ge bättre produkter på kortare tid samtidigt som det håller programmerarens innehåll i processen. På grund av avståndet mellan lagen är detta mycket svårare att uppnå.

Olika tidszoner

Beroende på tidszonen för varje distribuerat team gör det det mer utmanande att arrangera möten vid tidpunkter då båda lagen är tillgängliga. Det kan lätt uppstå en situation där en gruppmedlem är tillgänglig och den andra inte är för möten. Detta är särskilt ett problem om en omedelbar uppgift har komponenter i programmet som är tätt kopplade, i ett sådant fall skulle det ena laget inte kunna fortsätta utan feedback från det andra.

Undervisning

I en distribuerad miljö känns nackdelen med att inte kunna träna nära kommunikation mest med oerfarna utvecklare som behöver gå igenom en utbildningsfas. Att utbilda anställda som inte är samlokaliserade är utmanande, tänk på skillnaderna i bakgrund och kulturella skillnader som gör det svårt att få fart på dessa oerfarna teammedlemmar. På grund av detta måste alternativa undervisningssätt övervägas.

Fördelning av arbete

När det gäller fördelning av arbete vill vi undvika att arkitekturen speglar teamets geografiska fördelning genom att fördela arbetet baserat på platsen. Det är bättre att fördela uppgifter relaterade till en enskild användarberättelse över hela teamet och tänka i termer av berättelserna, inte komponenterna. Överspecialisering efter geografisk plats och/eller komponent är ett tecken på att ditt team hanterar de kommunikationsutmaningar som de distribuerade teamen ställer sig dåligt på. Denna överspecialisering har den oavsiktliga konsekvensen att produkten ändras för att passa utvecklingen, inte kundens krav.

Risker

En studie gjord 2013 har försökt konsolidera litteraturen om riskhantering i distribuerad agil utveckling. En mer omfattande studie har försökt kategorisera riskfaktorerna för distribuerade Agile-projekt i, detta gjordes med hjälp av både forskningslitteratur och verklig erfarenhet från tretton IT-organisationer. För korthetens skull utelämnas den fullständiga listan med 45 riskfaktorer, med motsvarande hanteringstekniker. Istället ges en kort sammanfattning av huvudkategorierna och övergripande ledningstekniker.

Livscykel för mjukvaruutveckling

Denna kategori omfattar riskfaktorer relaterade till olika aktiviteter inom mjukvaruutveckling som kundspecifikation av krav och planering, modellering, konstruktion och distribution av mjukvaruapplikationer. Många av riskfaktorerna i denna kategori härrör från ineffektivt kunskapsutbyte. Otydliga mål, krav, skillnader i praxis för standardprocesser eller inkonsekvenser över design för att nämna några. Många av dessa risker kan hanteras genom att se till att kunskap delas effektivt. Mer specifikt, se till att målet med projektet är kristallklart över teamen, såväl som kraven. Automatisera och standardisera så mycket av utvecklingscykeln som möjligt, så att varje team arbetar med samma teknikstack och infrastruktur. Kort sagt, se till att alla är på samma sida.

Projektledning

Projektledning avser uppgifter som projektplanering, projektorganisering, projektbemanning, projektledning och kontroll. Denna kategori innebär risker på grund av interaktioner mellan utvecklingsaktiviteter och ledningsaktiviteter. Antagandet av distribuerad agil utveckling kommer att förändra det sätt på vilket projektet behöver hanteras. Om detta inte görs noggrant kan riskerna inkludera en lägre initial hastighet, lag som omorganiserar varje sprint eller brist på enhetlighet i multisite teams kapacitet.

Gruppmedvetenhet

Riskfaktorer relaterade till bristande gruppmedvetenhet grupperas i denna kategori. Gruppmedvetenhet kräver intensiv kommunikation, koordination, samarbete och förtroende bland gruppmedlemmarna. Samlokaliserade team uppnår denna medvetenhet lättare, eftersom den flödar mer naturligt från att vara på samma fysiska plats. För att hantera de risker som är förknippade med bristande gruppmedvetenhet, måste rumsligt spridda team använda ett mer disciplinerat tillvägagångssätt i kommunikationen med de senaste tekniska verktygen. Praxis som att samlokalisera initialt, för att sätta spår för projektet, har visat sig vara effektiva för att hantera risker.

Externt intressentsamarbete

Dessa faktorer relaterar till samarbetet med kunder, leverantörer och tredjepartsutvecklare. Att hantera sina risker handlar om att se till att samordningen och kommunikationen med dessa externa aktörer sker effektivt och tydligt.

Teknikinställning

Riskfaktorer som uppstår på grund av olämplig verktygsanvändning grupperas i denna kategori. Till exempel kan en brist på kommunikationsstruktur lösas genom att ge teamen möjlighet att göra videokonferenssamtal. Utöver det är det viktigt att välja rätt verktyg att använda under ett projekt. Detta kan variera mellan projekt, team och användningsfall, så en analys i förväg av de verktyg som ska användas rekommenderas.

Verktyg och bästa praxis

Kommunikation

En av de viktigaste faktorerna för att övervinna utmaningarna med distribuerad agil mjukvaruutveckling är att förbättra kommunikationen. Detta innebär att minimera tiden det tar att sätta upp och riva en kommunikationssession och gynna videokonferenser framför röstkonferenser om det är tillgängligt.

Möjligheter till kontakt ansikte mot ansikte med hela teamet bör uppmuntras för att hjälpa till att bygga relationer. Det är fördelaktigt att göra detta i början för att lägga upp en plan som teamet kan följa under hela projektet. Dessutom är det också fördelaktigt under de sista iterationerna innan den slutliga leveransen släpps.

Tidszonsskillnader

Ett alternativ när det gäller att hantera problemet med tillgänglighet för möten på grund av tidszoner är att utse en representant för teamet som fungerar som mellanhand för de två teamen som har skapat goda relationer med båda. Ett annat alternativ är att använda kapslade Scrum med flernivårapportering och flera dagliga Scrum-möten.

En lösning för att ha Scrum-möten i team som hanterar tidszonsskillnader är att skilja mellan lokala teammöten och globala Scrum-möten. Varje team har ett lokalt möte i början av dagen och ett globalt möte vid en annan tid på dagen. Detta är endast möjligt om deras arbetsdagar har överlappande tid.

Att hålla jämna steg med agila metoder

På grund av den distribuerade naturen kan ett team avvika från fast etablerade agila metoder. Därför bör det finnas någon med rollen som tränare som håller laget på rätt spår. De bör också ta på sig att tänka på alternativ för den distribuerade arbetsmiljön med hjälp av agila metoder.

För att hålla varje gruppmedlem informerad om den antagna agila strategin är det viktigt att upprätthålla dokumentation för projektet. Detta förbättrar gruppsamarbetet när det gäller att använda agila principer och metoder i en miljö med distribuerad mjukvaruutveckling. För detta kan olika verktyg användas som stödjer teamet i att underhålla dokumentationen.

Användning av verktyg

Olika verktyg och plattformar kan användas för att förbättra kommunikationen i en distribuerad miljö. Dessa är ännu viktigare än i en icke-distribuerad miljö för att minimera det virtuella avståndet mellan de distribuerade teamen.

Kommunikation

Det finns olika verktyg tillgängliga för att stödja kommunikation vid distribuerad mjukvaruutveckling . Asynkrona verktyg som e-post, synkrona verktyg som ljud- och videokonferensprogram och hybridverktyg som snabbmeddelanden ger teammedlemmarna möjlighet att ha de nödvändiga mötena och kommunikationerna. Ett annat exempel är verktyg som stödjer sociala nätverk för att skapa en delad upplevelse mellan teammedlemmar på olika platser.

Projektledning

För att vägleda projektet och se till att alla team och teammedlemmar har en tydlig vision om vilket arbete som måste utföras, bör projektledningsplattformar som ärendehanteringsverktyg användas.

Utvecklings verktyg

För att ge en delad upplevelse för varje teammedlem bör varje teammedlem ha tillgång till samma verktyg för sin utveckling. Att ha samma verktyg för hantering av mjukvarukonfigurationer kopplade till projektledningsverktyg gör det möjligt för utvecklare att arbeta i samma takt och kommunicera om utvecklingen på ett liknande sätt.

Kunskapshantering

För att ge varje gruppmedlem tillgång till samma kunskap om produkten och utvecklingen kan verktyg som Wiki-mjukvara eller kunskapsbaser användas.

Kompatibilitet med Agile Manifesto

Värdena och principerna för Agile Manifesto har utforskats i deras tillämpbarhet i en distribuerad arbetsmiljö i 12 fallstudier. Studierna har följt programvaruföretag som tillämpat distribuerad agil mjukvaruutveckling i sina projekt. Bland de 12 fallen fanns 10 onshore-företag i USA och sju offshore-företag i Indien. Resultaten sammanfattas i följande tabell:

Egenskaper som främjas av Agile Manifesto	Fall 1	Fall 2	Fall 3	Fall 4	Fall 5	Fall 6	Fall 7	Fall 8	Fall 9	Fall 10	Fall 11	Fall 12
Värderingar
Individer och interaktioner över processer och verktyg	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Fungerande programvara över omfattande dokumentation	✓	✓	✓	✓	✓			✓	✓	✓	✓	✓
Kundsamarbete kring avtalsförhandling				✓	✓	✓			✓
Svara på byte efter en plan	x				x	x					✓
Principer
Tidig och kontinuerlig leverans av värdefull programvara	✓	✓	✓	x	x	x		✓			✓
Välkomna ändrade krav även sent i utvecklingen
Leverera fungerande programvara ofta	✓	✓	✓				✓	✓	✓	✓	✓	✓
Affärsmän och utvecklare arbetar tillsammans under hela projektet	✓			✓	✓	✓			✓
Bygg projekt kring motiverade individer och stötta och lita på dem				✓	✓	✓		✓
Konversation ansikte mot ansikte inom utvecklingsteamet	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Fungerande mjukvara är det primära måttet på framsteg	✓	✓	✓	✓	✓	✓	✓		✓	✓		✓
Främja hållbar utveckling för att upprätthålla konstant takt på obestämd tid		✓	✓							✓	✓	✓
Kontinuerlig uppmärksamhet på teknisk spetskompetens och bra design			✓	✓	✓			✓		✓
Enkelhet är viktigt											✓
Självorganiserande team			✓				✓			✓	✓
Teamet justerar regelbundet beteendet för att öka effektiviteten										✓	✓

Av detta lär vi oss att alla fallstudier betonade det första värdet av Agile Manifesto som säger att individer och interaktioner ska värderas framför processer och verktyg. Agile Manifesto föredrar fungerande mjukvara framför omfattande dokumentation utan att nödvändigtvis helt förneka dokumentationen. Detta värde återspeglas också i flertalet fall. Endast fyra fall har identifierats som betonar vikten av kundsamarbete framför avtalsförhandling. Som tydligt framgår av tabellen har det fjärde värdet antagits minst av alla värderingar av mjukvaruföretagen: "istället för att strikt följa de agila utvecklingsmetoderna som allmänt definieras, justerar företagen dem kontinuerligt för att passa de växande behoven hos sina projekt”. När det gäller agila principer är det inte en överraskning att samtal ansikte mot ansikte med utvecklingsteamet har värderats av alla studier. Detta simulerades elektroniskt mellan onshore- och offshore-teamen. Om man skulle vara öppen för att ändra krav även sent i utvecklingen, lämnade inget av mjukvaruföretagen i studien detaljer. Med detta kan vi anta att det inte ansågs lika viktigt som några av de andra principerna.

externa länkar