Vad är agil utveckling?

Agil utveckling är en term som används för att beskriva iterativ programvaruutveckling. Iterativ programvaruutveckling förkortar DevOps-livscykeln genom att slutföra arbetet i korta steg, vanligtvis kallat sprintar. Sprintar är vanligtvis en till fyra veckor långa. Agil utveckling kontrasteras ofta med traditionell utveckling eller vattenfallsutveckling, som planerar större projekt i förväg och slutför dem enligt planen.

För att leverera produktionskvalitetskod varje sprint måste agilt utvecklingsteam ta hänsyn till en snabbare takt. All kodning, testning och kvalitetsverifiering måste göras varje sprint. Om inte ett team har konfigurerats korrekt kan resultatet inte uppfylla förväntningarna. Även om dessa besvikelser erbjuder stora inlärningsmöjligheter är det bra att lära sig några viktiga lärdomar innan du kommer igång.

Den här artikeln beskriver några viktiga framgångsfaktorer för agila utvecklingsteam:

• Noggrann förfining av kvarvarande uppgifter
• Integrera tidigt och ofta
• Minimera tekniska skulder

Noggrann förfining av kvarvarande uppgifter

Ett agilt utvecklingsteam arbetar med en backlog av krav, som ofta kallas användarberättelser. Kvarvarande uppgifter prioriteras, med de viktigaste användarberättelserna högst upp. Produktägaren äger kvarvarande uppgifter och lägger till, ändrar och omprioriterar användarberättelser baserat på kundens behov.

En av de största nackdelarna med ett agilt teams produktivitet är en dåligt definierad backlog. Ett team kan inte förväntas leverera programvara av hög kvalitet varje sprint om de inte har tydligt definierade krav.

Produktägarens uppgift är att säkerställa att varje sprint, ingenjörerna har tydligt definierade användarberättelser att arbeta med. Användarberättelserna högst upp i backlogen bör alltid vara redo för teamet att börja på. Det här begreppet kallas förfining av kvarvarande uppgifter. Att hålla en kvarvarande information redo för ett agilt utvecklingsteam kräver arbete och disciplin. Lyckligtvis är det väl värt investeringen.

Kom ihåg följande viktiga aspekter när du förbättrar en arbetslista.

1. Att förfina användarberättelser är ofta en långvarig aktivitet. Eleganta användargränssnitt, vackra skärmdesigner och kundglädjande lösningar kräver tid och energi att skapa. Engagerade produktägare förfinar användarhistorier två till tre sprintar i förväg. De tar hänsyn till design iterationer och kundrecensioner. De arbetar för att säkerställa att varje användarberättelse är något som agilteamet är stolta över att leverera till kunden.

2. En användarhistoria förfinas inte om inte teamet säger att det är det. Teamet måste granska användarberättelsen och komma överens om att den är redo att arbeta med. Om ett team inte ser användarberättelsen förrän dag ett av en sprint kan problem sannolikt uppstå.

3. Användarberättelser längre ned i kvarvarande uppgifter kan förbli tvetydiga. Slösa inte tid på att förfina objekt med lägre prioritet. Fokusera på toppen av kvarvarande uppgifter.

Integrera tidigt och ofta

Kontinuerlig integrering och kontinuerlig leverans (CI/CD) konfigurerar ditt team för den snabba takten i agil utveckling. Automatisera bygg-, test- och distributionspipelines så snart som möjligt. Konfigurera automatiseringen som en av de första uppgifterna som ditt team tar itu med när du startar ett nytt projekt.

Med automatisering undviker teamet långsamma, felbenägna och tidsintensiva manuella distributionsprocesser. Eftersom team släpper varje sprint finns det inte tid att utföra dessa uppgifter manuellt.

CI/CD påverkar även din programvaruarkitektur. Det säkerställer att du levererar byggbar och distribuerad programvara. När team implementerar en svårdistribuerad funktion blir de genast medvetna om bygget och distributionerna misslyckas. CI/CD tvingar teamet att åtgärda distributionsproblem när de inträffar. Produkten är då alltid redo att levereras.

Det finns några viktiga CI/CD-aktiviteter som är mycket viktiga för effektiv agil utveckling.

1. Enhetstestning. Enhetstester är det första försvaret mot mänskliga fel. Överväg enhetstester som en del av kodningen. Kontrollera testerna med koden. Gör enhetstestning till en del av varje version. Misslyckade enhetstester innebär en misslyckad version.

2. Skapa automatisering. Byggsystemet bör automatiskt hämta kod och tester direkt från källkontrollen när byggen körs.

3. Förgrena och skapa principer. Konfigurera gren- och byggprinciper för att automatiskt bygga när teamet checkar in kod till en specifik gren.

4. Distribuera till en miljö. Konfigurera en versionspipeline som automatiskt distribuerar byggda projekt till en miljö som efterliknar produktion.

Minimera tekniska skulder

Med privatekonomi är det lättare att hålla sig borta från skulder än att gräva ut under den. Samma regel gäller för tekniska skulder. Teknisk skuld inkluderar allt som teamet måste ta itu med på grund av genvägar som togs tidigare. Om du till exempel har ett nära schema kan du offra kvalitet för att uppfylla en tidsgräns. Teknisk skuld är det pris du betalar senare, när du måste omstrukturera kod för att kompensera för den bristen på kvalitet. Exempel är korrigeringar för att åtgärda dålig design, buggar, prestandaproblem, driftproblem, tillgänglighetsproblem och andra problem.

Att hantera teknisk skuld kräver mod. Det finns många påtryckningar för att fördröja omarbetning av kod. Det känns bra att arbeta med funktioner och ignorera skulder. Tyvärr måste någon betala av den tekniska skulden förr eller senare. Precis som finansiella skulder blir den tekniska skulden svårare att betala av ju längre den finns. En smart produktägare arbetar med sitt team för att säkerställa att det finns tid att betala av tekniska skulder varje sprint. Att balansera en teknisk skuldminskning med funktionsutveckling är en svår uppgift. Lyckligtvis finns det några enkla tekniker för att skapa produktiva, kundfokuserade team.

Var alltid flexibel

Att vara flexibel innebär att lära sig av erfarenhet och ständigt förbättra. Flexibel utveckling ger fler inlärningscykler än traditionell projektplanering på grund av de snävare processlooparna. Varje sprint ger något nytt för teamet att lära sig.

Till exempel:

• Ett team levererar värde till kunden, får feedback och ändrar sedan sina kvarvarande uppgifter baserat på den feedbacken.
• De lär sig att deras automatiserade versioner saknar nyckeltester. De inkluderar arbete i nästa sprint för att ta itu med det här problemet.
• De upptäcker att vissa funktioner fungerar dåligt i produktionen, så de planerar att förbättra prestandan.
• Någon i teamet hör talas om en ny övning. Teamet bestämmer sig för att prova på några sprintar.

Team som precis har börjat med agil utveckling bör förvänta sig fler inlärningsmöjligheter. De är en ovärderlig del av processen eftersom de leder till tillväxt och förbättring.

Nästa steg

Det finns många sätt att lösa en flexibel utvecklingsprocess som är rätt för ett team. Azure DevOps innehåller olika processmallar. Team som letar efter olika baslinjestrukturer i planeringen kan använda dessa mallar som utgångspunkt. Information om hur du väljer en processmall som passar bäst för ett teams kultur och mål finns i Välja ett processflöde eller en processmall som ska fungera i Azure Boards.

När organisationer växer kan det vara en utmaning att hålla sig disciplinerade. Läs mer om att skala Agile till stora team.