Inlägg om Agil utveckling

Publicerat Personligt
Sebastian Appler Olsson - Projektledare och systemutvecklare på Spinit

Sebastian om dynamiska arbetssätt och projektledning

När man jobbar med digital­isering i projekt­form så är ett bra fungerande arbets­sätt en av nycklarna till att komma framåt. Dåliga arbets­metoder gör att det tar längre tid, kostar mer och de man byggt har inte de funktion­erna man vill ha.

På Spinit kallar vi våra projekt­ledare för kaptener och så har det varit under många år. Kaptenen tar ansvar för att samordna alla funk­tioner i det vi bygger och leder teamet av ut­vecklare. Varje nytt upp­drag är unikt och vi jobbar i olika steg för att skapa förstå­else och sedan utveckla det som kunden vill att vi ska göra.

Jag pratade med Sebastian Appler Olsson, en av kapten­erna på Spinit, om hur han ser på sitt jobb.

Hur jobbar du när du leder ett nytt uppdrag för Spinit?

– Jag jobbar alltid dynamiskt och använder mig av de arbets­tekniker som passar in för det spec­ifika upp­draget.

– Det första jag gör att identifiera vad en kund har och inte har tillgång till när dom kommer till oss. Har de någon som kan generera design­skisser då tar de ansvar för det. Eller har de någon som är bra på att skriva tydlig dokumentation om hur systemet ska fungera. Likaså vet de vilken data som ska skickas var, och vilka rättig­heter olika använd­are ska ha då är ju vissa delar av jobbet redan gjort.

– Om specifika­tionen är klar från början så behöver vi inte lägga ner energi på det, och vi fyller upp de delarna som kunden inte har. Ofta har en kund inte allt i sina team de behöver för att bygga det de vill. Då går vi in och komp­letterar med våra kunskaper.

– Jag tycket inte det är kul att följa ett färdigt arbets­sätt bara för att det står så i projekt­hand­ledar­hand­boken. Det kan bli jätte­tråkigt och så vill man ju inte ha det. En av an­led­ningen till att jag tycker så är för det tillför onödigt gnissel mellan projekt­ledaren och teamet. Inför man många ritualer och arbets­sätt som projekt­ledare kan det orsaka tids­krävande krångel som teamet kanske inte är i behov av.

Publicerat Nyheter
Olika bilder av samma sak

”Men vi kör ju typ Scrum”

Igår kväll föreläste Sebastian Appler Olsson om den agila arbetsmetodiken ScrumnForum. Före­läs­ningen handlade om att många säger sig köra ”typ Scrum” och inte fullt ut, men vad syftar de olika del­arna egent­ligen till och var­för är de bra?

Sebastian pratade om vad som händer om man inte kör scrum, syftet med stand­ups och retro­spekt, och vikten av en produkt­ägare med mera. Målet är ju att alla skall vara nöjda med ett projekt – både beställ­are och utveck­lare.

Före­läsningen hoppas vi var upp­skattad. Har ni ett behov för ett ut­vecklar­team att få en genom­gång av scrum så tveka inte att höra av er och se om Sebastian kan hjälpa till.

Se presentationen på Slideshare.

Sebastian Appler Olsson på nForum, pratar om Scrum
Sebastian Appler Olsson på nForum, pratar om Scrum

 

 

Publicerat Tech
Illustration: Nhan Ngo
"Continous Delivery" by Nhan Ngo is licensed under CC BY SA

Vägen till Continuous Delivery

Continuous delivery är ett begrepp som används inom system­­utveckling och betyder kontinu­erlig leverans. Syftet är att snabbt kunna leverera ny mjuk­vara till kunden. Behovet av Continuous delivery kommer från agila utveck­lings­prin­ciper där man jobbar i korta, fokuserade perioder där man efter varje period levererar ny funktion­alitet till kunden som kan testa av och ge feed­back inför nästa period.

Continuous integration

Continuous delivery är någonting som är tätt relaterat till Continuous inte­gration som är en process som knyter an till käll­kods­hantering. Det normala är att när kod checkas in i käll­kods­hantering så finns det en process som hämtar ut koden, kompil­erar den, kör tester, valid­erar och lagrar arti­fakter (kompilerad kod). På så sätt kan man i slutet av processen få en kvittens på att allt fungerar som det skall.

Continuous delivery kan ta vid där Continuous inte­gration slutar och använda de arti­fakter från varje bygge till att leverera koden i kompil­erad form till en miljö där den kan testas. Det kan vara en intern ut­veck­lings­miljö, en demo-server eller till och med en server i kundens egen server­miljö.

Historiska leverans­processer

Mjuk­varu­leveranser har tradition­ellt varit en manuell process och kan ha bestått i att klippa och klistra filer, använda verktyg som kan synka över filer, jämföra xml-filer rad för rad, jämföra data­baser och generera script som skall köras i en magisk ordning eller batch-script som gör delar av ovan nämnda jobb mer eller mindre till­för­lit­ligt. Till sist hänger dock ändå allt på att personen som gör lever­ansen förstår och kommer ihåg hur allt hänger ihop och inte glömmer något vilket är lättare sagt än gjort, speciellt om det är ett större system med många olika kompon­enter.
Ett annat problem är att veta vilken version av filer som släppts. Utan att ha en process för versions­hantering är det svårt att veta vilken version av källkoden som hör ihop med de filer som ligger lever­erade på en server och därmed också smått omöjligt att göra hotfixar utan att även leverera all ny kod på en gång.

Git flow

Git-flow versionhantering

Publicerat Tips
Agil utveckling not

Agil utveckling – vad, hur och varför?

Begreppet ”agil utveckling” florerar flitigt i diskussioner kring t.ex. system- eller mjukvaru­utveckling. Är du en av dem som funderat på vad det betyder och vad fördelarna är? Vi hjälper dig att sätta det mest grundläggande ramverket för att få förutsättningarna att lyckas med detta.

Agile” är engelska och betyder smidig, vig och lättrörlig och ”agil utveckling” står för en samling metoder och förhållnings­sätt kring hur arbete organiseras bäst på en komplex och ständigt föränderlig global marknad. För förändringar kommer att ske, det är det enda vi kan vara säkra på och att försöka kringgå detta genom fyrkantiga regelsystem och processer är lönlöst.

En reaktion mot ”vattenfallsmetoden”

Det agila arbetsättet uppkom från början som en reaktion mot den metod som de flesta företag traditionellt tillämpat, nämligen vattenfallsmetoden. Den består av detaljerade, sekventiella faser med enbart slutmålet i sikte. Metoden har sitt ursprung i tillverknings­industrin och associationen ”vattenfall” beskriver hur framstegen i processen flödar nedåt genom olika faser och ändringar i en sådan process, om de ens är möjliga, får kostsamma konsekvenser.

Flexibilitet i en föränderlig miljö

Den agila metoden tar, till skillnad från vattenfalls­metoden, hänsyn till att förutsättningar kan komma att förändras under en lång processtid. Många gånger kan man annars tvingas inse att verkligheten har kommit ifatt och löpt förbi utvecklingen av en produkt eller tjänst innan den når marknaden. Ett agilt arbetssätt bygger på att man i förväg inte kan ange exakt hur till exempel en mjukvara ska utvecklas, då det i själva verket ofta är kunskap som uppstår under processens gång. Möjlighet till anpassningar är ofta avgörande för ett lyckat resultat.