DevOps
DevOps är en sammansättning av Dev (development – utveckling) och Ops (operations – drift) och är föreningen av människor, process och teknik för att ge fortsatt mervärde till kunderna. Det finns inte ett specifikt verktyg för DevOps utan det är istället en uppsättning av verktyg som används i en så kallad toolchain där varje verktyg passar in i en eller flera av faserna. För varje steg i DevOps-principen finns det ofta verktyg som hjälper till att skapa ett automatiserat flöde och hantering för att underlätta varje steg.
DevOps-Metoden brukar delas upp i följande delar:
- Utveckling För utveckling spelar det ingen större roll vilken editor man använder, det viktigaste är att man använder en versionshanterare som till exempel Git. Det är viktigt att ha ett spikat flöde hur gruppen använder versionshanteringen.
- Bygga applikationen (automatiserat) Att bygga applikationen ska med fördel ske automatiskt via ett byggsystem. Byggsystemet kan direkt hämta från versionshanteringssystemet och bygga för både test, staging och release.
- Testa (automatiserat) Viktigt är att utvecklare får återkoppling på när tester går fel så att man snabbt kan åtgärda problemen och låta bygg/test-system köra nya tester.
- Paketera (versionshanteras automatiskt) Paketering av leverabler i ett versionshanterat format behövs för att enkelt kunna skapa stage och testmiljöer samt göra tillbakarullningar av releaser som skapat problem.
- Distribuera till produktion/staging/test Även distribution bör ske automatiskt. Det finns många verktyg för att göra det.
- Konfiguration av infrastruktur (manifest som beskriver miljön) Infrastruktur som kod är ett numera populärt begrepp. Vad det innebär är egentligen att man specificerar sin driftsmiljö med hjälp av manifest eller konfigurationsfiler.
- Monitorering (prestanda, resursutnyttjande, skalning, användarupplevelse etc.) Den sista delen i DevOps flödet är monitorering. Det finns många verktyg som hjälper till med det.
Kanban
Kanban är en agil metod som betraktas som en del av Lean systemutveckling och som hämtat inspiration från produktionsindustrin. Förenklat är Kanban ett visuellt system för att hantera arbetet som rör sig genom en process som skapar värde. Det är ett system för att visualisera arbete, minska slöseri genom att begränsa pågående arbeten och leverera ett fortlöpande värde till kunden.
Kanban har tre grundprinciper:
1. Visualisera arbetsflödet (Visualize workflow)
I Kanban använder man sig av en Kanban-tavla för att visualisera arbetsflödet och flaskhalsar i processen. Visualisering av arbetsflödet inom teamet eller inom organisationen är en av metodens huvudsakliga styrkor. Genom att vi lokaliserar flaskhalsar ger detta oss en möjlighet att åtgärda eventuella brister och effektivisera arbetet. Teamet får samtidigt en bra överblick över arbetsprocessen vilket förenklar samarbetet mellan krav, utveckling och test men även mellan olika projektteam.
2. Pågående arbete (Work In Progress)
Kanban-metoden har till uppgift att sätta en gräns för antalet parallella pågående uppgifter som man arbetar med inom teamet. Ett sätt för att säkerställa att teamet arbetar efter sin egen arbetskapacitet är att sätta en siffra ovanför varje kolumn på Kanban-tavlan. Varje siffra motsvarar de antal uppgifter man får arbeta med parallellt. Genom att sätta en gräns för antalet parallella uppgifter i flödet så blir det en jämnare fördelning av arbetsuppgifter mellan exempelvis krav, test och utveckling. Vi förhindrar på detta sätt att flaskhalsar uppstår och sänker stressnivån då alla arbetar efter sin egen kapacitet.
3. Ledtid (Lead Time)
Ledtiden är den genomsnittliga tid det tar att slutföra en uppgift från att man påbörjat den. Exempelvis kan man mäta nyutveckling, defekter och hur mycket tid det tar att lösa supportärenden. Genom att identifiera och eliminera flaskhalsar samtidigt som man korrigerar pågående uppgifter utifrån teamets arbetskapacitet kommer ”ledtiden” att kunna förkortas. ”Ledtiden” kan även användas som ett mått på hur effektivt Kanban-teamet arbetar och när kunden kan väntas få sin leverans. Desto bättre man blir på att mäta ledtiden desto bättre blir man på att beräkna leveranstiden och hålla den, vilket ger kunden bättre och punktligare leveranser.
Lean
Begreppet har fått sitt namn från engelskans ”lean meat” de vill säga kött utan fett, och är en metafor till de mål som man vill att organisationer ska arbeta mot. Begreppet ”lean” har funnits sedan 1990. Tidigare kallades det för TPS (Toyota Production Systems) efter begreppet i det japanska företaget Toyota. TPS var grundat på två koncept: ”jidoka” (som kan översättas till ”automatisering med en mänsklig touch”) och ”Just-in-Time” som betyder att varje process producerar bara vad som krävs för nästa process, så att det skapas ett flöde. I första hand är Lean en uppsättning styrande principer, eller värderingar, som tillsammans utgör en ledningsfilosofi och en företagskultur.
Lean handlar till exempel om:
- Principen att allt alltid kan bli bättre (kaizen). Ju mer som förbättras, desto fler nya möjligheter till förbättringar kan identifieras.
- Principen om att problem ska ses som möjligheter istället för att man letar syndabockar.
- Principen att man bör börja med att förändra sig själv eftersom man själv vet bäst var skon klämmer. Var och en ansvarar för sin förbättring.
- Principen om att alltid fokusera på kundvärde (både interna kunder och externa).
Lean arbetssätt
Den andra beståndsdelen i Lean är ett gemensamt och visuellt arbetssätt. Genom att kartlägga de processer man jobbar i och lyfta fram förbättringsåtgärder på tavlor på väggen blir alla delaktiga och arbetet går snabbare framåt. Man möts i arbetsgrupper vid tavlorna och kommer gemensamt fram till nya åtgärder och prioriteringar. Tavlornas utformning är inte det väsentliga – huvudsaken är att man fångar upp ett flöde av arbetsuppgifter, till exempel från ”Idéer” till ”Pågående” till ”Avslutat”.
Lean verktyg
Slutligen består Lean en låda med verktyg för att successivt ta förbättringsarbetet vidare. Ett centralt verktyg är 5S som handlar om att sortera, systematisera, städa, standardisera och sköta om.
Scrum
Är ett ramverk för att utveckla, tillhandahålla och underhålla komplexa produkter formulerat av Jeff Sutherland och Ken Schwaber. Ordet ”scrum” kommer från rugbyn där det är ett moment när bollen sätts i spel. I scrum finns det inte en klassiskkravspecifikation utan man har istället en backlog. En backlog är kort sagt en prioriterad och levande lista med önskemål. Detta innebär att i ett projekt kan önskemål som är aktuella vid projektets start falla bort om de prioriteras ned under projektets gång och nya önskemål kan också läggas till.
I Scrum finns tre uttalade roller
1. Produktägare (product owner): Produktägaren sammanställer
och prioriterar önskemål om tillägg och ändringar främst
utifrån affärsnytta. I ett webbprojekt är det vanligt att produktägaren
är en projektledare hos beställaren.
2. Scrum master: Scrum mastern coachar teamet och ser till att
allt rullar på smidigt. Scrum mastern stämmer av mellan aktörer
samt ser till att det inte finns några hinder för teamet.
3. Team: Teamet är självorganiserande och bestämmer gemensamt
vem som gör vad och hur man löser olika uppgifter.
Vilka komponenter finns inom Scrum?
Backlog (Product backlog) En prioriterad lista med alla önskemål om produkten. Produktägaren prioriterar och ansvarar för
backlogen. En backlog skrivs ofta i form av user stories men kan även vara organiserad på andra sätt.
Sprint backlog Den del av produktbacklogen som teamet åtar sig att implementera under en sprint.
Sprint I Scrum delas arbetet in i sprintar. En sprint kan vara mellan 3 och 30 dagar lång. En sprint inleds med en planeringsmöte (Sprint planning) och avslutas med en demonstration och genomgång av det som utvecklats under sprinten (Sprint review). Under sprinten sker dagliga Daily scrums och sist i en sprint görs en återblick (Sprint retrospective).
Daily Scrum Ett kort statusmöte för teamet. Scrum master går igenom alla personer i teamet som besvarar tre frågor:
- Vad har jag gjort sedan igår?
- Vad ska jag göra till imorgon?
- Finns det något som hindrar mig?
Sprintgenomgång (Sprint review) En genomgång av status på det arbete som genomförts i sprinten samt demonstration av
funktionaliteten för produktägare, kunder och andra inbjudna intressenter. Syftet är att alla intressenter ska få bästa möjliga förståelse för dagsläget.
Återblick (Sprint retrospective) Team, Scrum master och produktägare går tillsammans igenom erfarenheter från sprinten
och identifierar möjliga förbättringar i arbetssättet. Några punkter väljs ut och åtgärdas i kommande sprint.
Sprint planning Produktägaren, Scrum master och teamet går igenom de önskemål som finns. Därefter bryter teamet ned kraven och tidsestimerar (ofta med planning poker och ibland med story points istället för timmar). Genom att jämföra de tidsestimerade och prioriterade önskemålen med tillgänglig tid tas en sprint backlog fram, som teamet åtar sig att genomföra.
Svenskt Projektforums guide över agila metoder
I en artikelserie kommer vi här att presentera grunderna för agilt arbete samt metoder och ramverk för att implementera de agila principerna. Vi börjar med grunderna.
En grundtanke i agila metoder är att arbetet bedrivs inkrementellt och iterativt vilket innebär att fungerande delleveranser av funktionalitet sker regelbundet enligt ett schema och att planer och metoder löpande utvärderas och förbättras. Ändamålsenlig och användarcentrerad utveckling eftersträvas genom ett nära samarbete under hela utvecklingstiden med täta och regelbundna möten mellan utvecklare och beställare/mottagare.
Man formulerar tidigt mål och visioner, istället för att arbeta mot hårda och detaljerade tekniska krav. Den detaljerade kravspecifikationen blir ett slutresultat av utvecklingsprojektet istället för ett ingångsvärde. Det agila synsättet anser att det oftare är människor och kommunikation än verktyg och formella dokument som löser problem under utvecklingsarbetet.
Manifest för Agil systemutveckling
Individer och interaktioner framför processer och verktyg.
Fungerande programvara framför omfattande dokumentation.
Kundsamarbete framför kontraktsförhandling.
Anpassning till förändring framför att följa en plan.
Det Agila Manifetet har snart 20 år på nacken, men är fortfarande fullt giltigt. Det handlar om hur man ska prioritera. Det finns värde i punkterna till höger, men punkterna till vänster värdesätts högre.
De tolv principerna för Agilt arbete
För att utveckla hur grundvärderingarna ska tolkas i det dagliga arbetet innehåller Det Agila Manifestet även tolv principer. Här följer de i enlighet med sin ursprungsdefinition samt med kommentarer.
1. Högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara.
Genom att jobba i korta iterationer som levererar en fungerande produkt som går att utvärdera, kan åsikter som kund eller användare har snabbt prioriteras och åtgärdas inför nästa utvärdering.
2. Välkomna förändrade krav, även sent under utveckling. Agila metoder utnyttjar förändring till kundens konkurrensfördel.
Korta iterationer som är lätta att utvärdera innebär snabb Time To Market för eventuella förändringar. Kravförändringsprocessen är inbyggd i den Agila metoden, vilket gör att ingen byråkrati sinkar projektet.
3. Leverera fungerande programvara ofta med tidsskala från ett par veckor till ett par månader, med en förkärlek till den kortare tidsskalan.
Den produkt som levereras i slutet av varje iteration ska leverera värde till kunden. Att den ”fungerar” behöver inte betyda samma sak som att den är färdig, utan snarare att man gjort den lite bättre än sist och att denna förändring fungerar samt kan utvärderas.
4. Affärsfolk och utvecklare måste arbeta tillsammans dagligen under hela projektet.
Genom att kommunicera dagligen (helst ansikte mot ansikte), får frågor snabba svar, kunskapsöverföring sker i det lilla och det stora.
5. Bygg projekt kring motiverade individer. Ge dem den miljö och det stöd de behöver och lita på att de får jobbet gjort.
Motivation skapas genom ansvar och förtroende. Låt teamet jobba i den miljö de vill, på det sätt de vill och när de vill.
6. Den mest effektiva metoden för att förmedla information till och inom ett utvecklingsteam är konversation på plats mellan individerna. (en: face-to-face).
Feedback går fortast när man pratar direkt till varandra.
7. En fungerande programvara är det främsta måttet på framsteg.
För kunden är produkten det mätbara resultatet. Framsteg är att produkten uppdateras enligt tidigare utvärdering och fungerar efter varje iteration.
8. Agila processer främjar en hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en jämn utvecklingstakt på obestämd tid.
Agila metoder verkar för uthållighet. Att arbeta agilt innebär att se till att teamet har välplanerade iterationeroch att kunden vet vad nästa release innehåller samt att teamet inte tar på sig mer än vad de faktiskt bedömer att de ska klara av.
9. Kontinuerlig uppmärksamhet på förstklassig teknik och god design ökar flexibiliteten.
Agilt arbete fokuserar på att göra ”rätt” från början. Bättre att bygga enligt konstens alla regler i avgränsade områden än att bygga om allt senare. Det gör att man i senare skeden kan fokusera på att faktiskt utveckla produkten snabbt och slippa bygga om och bygga rätt.
10. Enkelhet – konsten att maximera mängden arbete som inte görs – är grundläggande.
Genom att hela tiden prioritera vad som är viktigast för just denna iteration, kommer teamet enbart att levereravärde för produkten. Detta fokus hjälper till att eliminera mycket övrigt onödigt arbete runtomkring.
11. Bäst arkitektur, krav och design växer fram med självorganiserande team.
Genom att teamet själva utvärderar sina metoder och arbetssätt ofta, kommer det (för varje enskilt team) bästa sättet att jobba med krav, utveckling och leverans att utvecklas över tid – förutsatt att de får möjligheten till det.
12. Med jämna mellanrum reflekterar teamet hur det kan bli mer effektivt och justerar sitt beteende därefter.
För att ständigt utvecklas har teamet regelbundet utvärderingar, helst inom ramen för varje iteration. Detta leder till att förbättringar sker ofta och i små steg. Små fel och brister kan tidigt upptäckas och undvikas i framtiden.
Ovan nämnda principer och värderingar är i sig självt inte en konkretiserad process, utan pekar mot att agilt arbete är en filosofi. Att arbeta agilt är inte målet. Ett företags mål kvarstår, om det så handlar om att skapa produkter eller tjänster. Däremot ger ett agilt tankesätt möjligheter att lättare följa (eller leda) i en föränderlig värld utan att falla i fällan av för mycket dokumentation och byråkrati. Lättrörligt, helt enkelt.
För att införa dessa principer i praktiken finns flera metodologier och ramverk som implementerar de Agila principerna till din hjälp som kommer att följa i kommande artiklar.