24.10.2015 Views

BE15_Agile_Backend_Peter_Sjöstrand

BE15_Agile_Backend_Peter_Sjöstrand.pdf

BE15_Agile_Backend_Peter_Sjöstrand.pdf

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Peter</strong> <strong>Sjöstrand</strong> 2015-10-21 BLOCK 3: AGILA METODER Sid 1<br />

<strong>Backend</strong>utvecklare C# - Uppgift 3.1, 2015-11-01.<br />

DEL 1 - Agila metoder (max 1/2 A4)<br />

Beskriv i korthet vad agila metoder är och hur de skiljer sig från andra äldre projekt metoder såsom<br />

Vattenfallsmodellen.<br />

Agila metoder är en genre inom arbetsmetodik för att driva projekt eller utveckling som betonar<br />

snabba mindre del-leveranser eller iterationer och flexibilitet utan att alltid ha hela slutleveransen klart<br />

för sig vid starten. Agila metoder är starkt kundorienterad och tydligare affärsmässighet då själva<br />

utvecklingsarbetet bygger mycket på samarbete och relationer och små arbetsgrupper i tätare kontakt<br />

med kunden. Denna metod skiljer från tidigare projekt-metoder genom att man går ifrån att ta fram<br />

hela slutprodukten innan leverans. En viktig aspekt är att undvika att produkten hinner bli föråldrad vid<br />

leveransen samt att öppna upp för möjlighet för verksamheten att kunna ändra inriktning och design<br />

genom den dynamiska specifikationen allteftersom det blir klarare för kunden vad det handlar om<br />

utifrån delleveranserna. Dessutom kan kunden ha hunnit få nya behov på vägen. Ytterligare kan<br />

kunden kamma hem nyttorna i sin verksamhet pga kortare leveranstider. Om man jämför med<br />

Vattenfallsmetoden som har rötter i hårdvarutillverkningen inom främst byggsektorn handlar det mer<br />

om att för hela produkten ta fram komplett plan, kravspecifikation, design, utveckling/konstruktion,<br />

integration, test och installation. Om det visar sig inte klara testfasen måste man backa tillbaka till<br />

föregående process successivt tills felet åtgärdats. Men genom att bryta ner hela totalleveransen i<br />

små del-funktioner som kunden vill ha går alla delmomenten mycket snabbare och till viss fördel även<br />

hoppa över vissa nedprioriterade moment såsom omfattande dokumentation för att få så sabb<br />

leverans som möjligt. Det gör att kunden och dess verksamhet får mycket större inflytande redan vid<br />

starten av utvecklingsprocessen och under hela resan till den slutliga leveransen.<br />

Man kanske skulle kunna säga att genom det agila manifestet fick mjukvaruindustrin en egen<br />

skräddarsydd arbets- och utvecklingsmetodik mer anpassat för mjukvaran och ett fokus på tidig<br />

kundnytta och troligtvis även besparingar för verksamheten.<br />

Det hela förutsätter att utvecklare och konsulter är välvilligt samarbetsvilliga i ständig täta interaktioner<br />

med engagerade kunder som känner till behovet.<br />

Idag finns några populära agila tillämpningar Lean, Kanban, Scrum och XP samt en kanske mer<br />

individuellt betonad variant som heter Pomodore. Kanske är det så att vilken metod/tillämpning man<br />

än väljer inte spelar så stor roll så länge man tänger och arbetar agilt.


<strong>Peter</strong> <strong>Sjöstrand</strong> 2015-10-21 BLOCK 3: AGILA METODER Sid 2<br />

<strong>Backend</strong>utvecklare C# - Uppgift 3.1, 2015-11-01.<br />

DEL 2 - De olika metoderna (max 1 A4)<br />

<br />

<br />

<br />

<br />

<br />

Lean härstammar från fordonstillverkningsindustrin och fokuserar på att minimera svinnet eller<br />

slöseriet såsom resurser, tid och potentiella felkällor. Lean är väst svar på japanska erbjuder i<br />

huvudsak ett förhållningssätt och övergripande principer snarare än detaljer eller instruktioner<br />

om hur man ska driva utvecklingen. Känns tok för fyrkantigt och upplevs som om det inbjuder<br />

till skygglapps mentalitet. Ställer höga krav på individens överlåtelse till att följa ett visst lean<br />

mönster än att tillåtas vara kreativ och ta ut svängarna.<br />

Kanban är främst en logistikmetodik ifrån bilindustrin där kärnan i idén är att man åskådliggör<br />

status för produktionen och leveransen med ”skyltar” som i mjukvarubranschen övergått till<br />

post-it lappar på whiteboard. Då metoden tar fasta på leveranstider och budget ligger den mitt<br />

i mellan verksamhetsbetonade och projektbetonade utvecklingsstilen.<br />

Scrum är betydligt mer projektorienterat och typiskt teamfokuserad utvecklingsmetodik med<br />

målsättning att leverera med högst en periodicitet minst en gång i månaden i starkt samarbete<br />

med produktägaren som utgör kundens röst och bevaka dennes intresse och behov delvis via<br />

en så kallat scrum master.<br />

Extreme Programming karaktäriseras av begreppet ”refactoring” dvs där ständig öppenhet för<br />

förändringar till säkrare, tydligare och enklare programkod med sikte på daglig leverans. Tar<br />

mycket fasta på den enskilde utvecklaren snarare än team tänkandet och helheten. I stilen<br />

ligger den något mitt i mellan projektstilen och den mer egen individuella utvecklingsstilen.<br />

Pomodoro är en tidsdispositiv utvecklingsmetodik på ett mer personligt/individuellt plan och<br />

har ett pragmatiskt förhållningssätt till hur man disponerar sin tid. Typiskt är att man har en<br />

äggklocka som man sätter på 25 minuter under den tid man disciplinerat skall utveckla sig<br />

själv såsom studier och träning eller annat arbete man vill få bra framdrift på.


<strong>Peter</strong> <strong>Sjöstrand</strong> 2015-10-21 BLOCK 3: AGILA METODER Sid 3<br />

<strong>Backend</strong>utvecklare C# - Uppgift 3.1, 2015-11-01.<br />

DEL 3 - Scrum (max 1 A4)<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

Scrummaster är en person som betjänar och underlättar för utvecklingsteamet med att<br />

undanröja hinder för arbetet samt skall motverka störningar utifrån. Det är alltså inte fråga om<br />

teamledare i traditionell bemärkelse med samordningsansvar med styrande funktion.<br />

Scrummaster följer även upp teamets fortskridande arbete och åskådliggör detta i en så kallad<br />

burndown-diagram.<br />

Product owner är en som sätter prioritet för de produkter som skall prioriteras utifrån att<br />

utagera som kundens företrädare i produktutvecklingsarbetet.<br />

Daily Scrum/Stand up meeting är korta informella möten som hålls dagligen ståendes. Man<br />

delar med varandra status och lyfter fram eventuella önskemål, funderingar, hinder mm inför<br />

hela teamet inklusive scrummaster som då får extra lyssnaransvar.<br />

Backlogg önskelista är en framtagen lista på behov uttryckta i så kallade användarfall(user<br />

story) och beställningar från kunden tillsammans med scrum-produktägaren. Dessa samlade<br />

önskemål kallas för product backlog. Önskelistan fördelas om i prioriterade aktiviteter på ett<br />

kort/lappar per aktivitet. Därefter tar scrum-teamet och gör om dessa till genomförbara sprint<br />

backlog som är av teamet identifierbara och genomförbara tidsbestämda uppgifter.<br />

Iteration/Sprint innehåller ett begränsat antal beslutade funktionaliteter/uppdrag(user stories),<br />

nedbrutna ’elefanten’ i dess minsta beståndsdelar/funktionsdelar från scrum-produktägare.<br />

Inom scrum kallas iterationerna för sprintar som bör vara avverkade inom en till åtta veckors<br />

tid.<br />

Burn-down chart är ett klassiskt x-y-diagram där man åskådliggör sprintavverkningshastighet<br />

och återstående tid till slutleverans men även hur mycket tid som gått åt och hur mycket som<br />

återstår avspeglas i diagrammet.<br />

Sprint review/Sprint retrospective är en slags utvärderings- och test-fas som görs för att hitta<br />

eventuella fel, buggar, förbättringar mm. Men speciellt i sprint review lyfter man blicken lite för<br />

att se vad man lyckats åstadkomma och demar produkten eller funktionen. Både Sprint review<br />

och Sprint retrospective är korta informella möten om ca 1 timme. Förberedelserna inför dessa<br />

möten får max ta ca 2 timmar.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!