Sommarprojekt

Nu har midsommar kommit och gått när jag gör min sista arbetsvecka innan semestern, därefter väntar 4 veckors underbar ledighet. Min flickvän Emma ska jobba under sommaren så det blir mycket ledig tid på dagarna för min del.

Min plan är dock inte att låta tiden gå helt utan syfte. Länge, länge har jag gått och tänkt på en idé till ett spel. Det är väl egentligen inte lika mycket en idé som ett tema då jag vill göra ett golfspel i kortformat. Det är något i tanken att göra ett spel av ett spel som tilltalar mig.

Min plan är att uppdatera under projektets gång för att sporra mig själv, det är viktigt att det är något lustfyllt och inget som jag ”måste” göra. För då är det enkelt att tappa suget och bara konsumera spel istället.

Scrum vs. Vattenfallsmetoden

Inledning

”Scrum är en metodik för systemutveckling skapad av Jeff Sutherland och Ken Schwaber. Scrum har tillämpats sedan tidigt 1990-tal och formaliserades 1995. Scrum är ett kraftfullt sätt att fördela arbetsuppgifter i tiden med bibehållet fokus på levererad affärsnytta.”

–          Wikipedia om Scrum.

Denna spännande projektmodell har jag alltså haft nöjet att få prova på när vi arrangerade vår klassfest. Till skillnad ifrån våra vanliga projektmodeller så var vi helt plötsligt i en mycket större symbios än tidigare även om det hela kändes mycket ostrukturerat. Just i vårt fall så kände jag även att det egna ansvaret var stort, nästan större än i vanliga projektgrupper eftersom projektledaren eller Scrum-mastern i detta fallet inte var så kontrollerande. I detta fallet så skulle vi som sagt arrangera en klassfest med allt vad det innebar. Scrum-modellen lämpade sig inte jättebra för detta eftersom vi var en liten grupp och det inte fanns några tydliga krav på leverans eller kvalité. När jag fick höra att Scrum är designad för större mjukvaruföretag så föll polletten ner, det är definitivt en projektmodell som lämpar sig för sådana företag. Jag har försökt att jämföra Scrum som projektmodell med den vanliga vattenfallsmetoden som jag vanligtvis arbetat i och sorterat dessa jämförelser under olika rubriker.

Transparens

Scrum är ett i sanning transparent arbetssätt. Till skillnad ifrån vanliga projektmodeller där man arbetar i stängda grupper med enskilda uppgifter så arbetar man sida vid sida med alla som deltar i projektet. Alla vet vad alla håller på med och man kan lätt se vad som behövs göras eftersom den allsmäktiga backloggen sitter på väggen och dikterar vad som behöver göras. Varje gång den förändras så syns det väldigt tydligt och man märker hur viktigt det är att backloggen sitter centralt så att alla har koll. En annan fördel med transparensen var att man kunde ta hjälp av den sammanlagda kompetensen som fanns i projektgruppen som stort. Man är inte på något sätt begränsad till en enskild projektgrupp och kan därmed alltid se till att man har ”rätt man på rätt plats” för att därmed öka produktiviteten och kvalitén.

Hierarkier

 

I Scrum så fungerar hierarkierna väldigt speciellt. Just i vårt fall så fann jag det svårt att definiera exakt vad Scrum-mastern skulle göra. Hierarkin var väldigt platt och alla deltog i arbetet tillsammans som i ett trevligt kollektiv. Backloggen satt på väggen och definierade prioriteringen och Scrum-mastern pratade med product ownern för att hela tiden hålla backloggen uppdaterad. När Scrum-mastern sedan kom tillbaka ifrån det dagliga mötet så hände inte så mycket eftersom arbetet redan var i full gång. Jag skulle känna mig tryggare om respektive Scrum-master hade haft ett stående möte med sin grupp för att alla skulle få bättre koll på vad som hände i respektive grupp, så att man verkligen utnyttjar den transparensen som finns medfött i Scrum-modellen.

 

Kommunikation

 

Kommunikationen skedde sporadiskt och utan scheman. Man rapporterade till Scrum-mastern men försökte ändå att hålla sig uppdaterad om vad som hände i de grupper som man arbetade bredvid. Det var väldigt skönt att hela tiden veta vad som hände runtomkring sig men jag känner fortfarande att jag skulle vilja ha mer struktur i kommunikationen. Det som är bra är att alla möten ska ske stående i Scrum eftersom de inte får ta så lång tid. Med detta i baktanken så behöver man inte vara rädd för att schemalägga möten, något som hade behövts för att hela tiden se till att alla i gruppen har koll på backloggen och vet hur prioriteringen ser ut och hur långt alla har kommit. Man kan se grupperna som hjul där Scrum-mastern är navet i hjulet istället för de vanliga projektgrupperna där projektledaren är toppen på en pyramid.

 

Leveranser

 

Detta skede av processen var också väldigt otydligt för mig när vi använde Scrum. Det kan som sagt bero på att jag inte var Scrum-master och därmed missade en hel del av själva överlämnandet. Eftersom vi inte heller arbeta med några produkter utan bara delar av ett arrangemang så var det svårt att leverera. När jag själv levererade så var det helt enkelt så att jag sa att min uppgift var fixad och så arrangerade vi om i backloggen. Vad som var positivt var att vi hela tiden kunde se hur det vi låg till i projektet eftersom backloggen hela tiden förändrades. Man kunde också se väldigt tydligt hur projektet hela tiden skrider framåt och vad som behöver göras.

 

Kvalité

 

Kvalitén på de saker vi levererade var väldigt svår att bestämma när vi arbetade eftersom det handlade om arrangerat av en fest och inte levererande av faktiska produkter. Festen i sig blev väldigt lyckad och många tyckte om det men det är fortfarande svårt att mäta kvalitén på festen då vi inte hade någon tydlig kravspecifikation. Jag tror att kvalitén på de produkter man tillverkar i en Scrum-process rimligtvis blir högre på grund utav transparensen. Man kan utnyttja vilken kompetens som helst i vilken grupp som helst för att se till att kvalitén alltid blir den bästa.

 

Slutsats

 

Scrum-modellen är en välutvecklad och genomtänkt projektmodell designad för större företag. Detta märks tydligt i hur arbetet förflöt och vilka problem som uppstod när 3 av 4 personer i en grupp var frånvarande. Arbetet förflöt hela tiden framåt och man kände verkligen att man fick saker gjort, speciellt eftersom man kunde skrida över projektgruppsgränserna för att utnyttja olika personers kompetenser. Jag skulle mer än gärna arbeta i Scrum igen, gärna i ett projekt där man framställer produkter eller delar av en produkt där man belyser leverans- och kvalité-aspekterna av projektet. Det hade varit kul att vara Scrum-master eller se hur en riktig Scrum-master arbetar för att kunna se de verkliga skillnaderna mellan projektmodellerna. Jag kan rekommendera alla som arbetar med projektledning att prova på Scrum för att aktivt jämföra med de projektmodeller som de vanligtvis använder och verkligen känna på de skillnader som finns. Många har sagt att när man en gång använt Scrum så kan man aldrig vända tillbaka men jag måste ändå accentuera att det inte är något fel på vattenfallsmodellen och att det i flera fall kan löna sig istället för att använda Scrum. Nyast är inte alltid bäst i alla fall.

Vecka 3+4 eller ”fan vad tiden går fort”

Tjo!

”Helgen flög förbi som ”snails on speed” och veckan påbörjades med möten av alla de slag, möten med handledare, möte med handledares chef, möte på hdk, lunchmöte, telefonmöte och möte på stadsbiblioteket.”

Stycket ovanför skrev jag förra veckan och sparade för att jag inte hade tid att posta det o.O

Nu är det slut på även denna vecka och jag sätter alltså punk för v.4 av 6 i min LiA-praktik. För er som nu blir förvirrade så kör jag och Martin en vecka extra för att det passar oss bättre med datum och tider.

Denna veckan så har Martin varit sjuk sen i tisdags tills…han är fortfarande sjuk. Börjar ju tro att det är något riktigt allvarligt, ligga febersjuk i 4 dagar kan fan inte vara ”friskt”. Saker och ting har däremot verkligen rullat på i arbetet. Vi har bokat in ett 11-manna band som heter Pickadoll och är riktigt grymt! Vi har fått värdar ifrån en event-linje på lindholmen och catering med konferencier bokad. Nu ska det detalj planeras med körscheman och kartor över dekorationer, det skall även skaffas fram tekniker som kan lösa tekniken åt vårat band och våra vackra dansare som skall uppträda.

7 dagar kvar tills deadline. 7 arbetsdagar. Det där med deadlines är ett jävla gissel ändå…

Viskningsspelet

 

Antal spelare: 2-4
Spelarnas roller: Äventyrslystna trolldödare 

Vilken sort spelarinteraktion används i spelet: Players vs Player vs Game 

Vad är målet med spelet: Att först ta sig upp till trollet och dräpa det 

Vilka spelmekaniker/procedurer används (vad gör man för att uppnå målet): Ett tärningsbaserat levelsystem, när man besegrar fiender så blir man starkare. 

Beskriv kortfattat de regler ni hann skriva ner: Man får bara flytta sig ett steg i taget och varje rutas effekter går in direkt när man hamnat på dem. Förlorar man en strid förlorar man antingen ett liv eller blir tvungen att backa en nivå. Vinner man får man gå vidare.  

Beskriv de resurser som används: MoFo’s (pappfiender), Spelarmarkörer, Provisorisk livmätare… 

Beskriv den konflikt som dominerar spelandet: Striderna mellan Mofosen och spelarna genomsyrar spelet men i slutändan handlar det om vem som tar sig upp snabbast.  

Spelets styrka är det faktum att man kan välja flera vägar att ta sig upp till trollet. Spelplanen är varierad och det kan hända mycket olika saker på rutorna, bland annat kan man ju återfå liv på Hospitalet och överfalla sina medspelare i skogen. Det blir dock mycket slump och mycket tärnings-kastande då man i princip har två val. Antingen tar man det lugnt och levlar försiktigt eller så chansar man för att kunna komma upp först. Enda sättet att ta sig upp till trollet och för att ens ha en chansMan måste givetvis ta till i beräkningen att spelet är långt ifrån färdigt och hade kunnat förvandlas till en riktigt bra talisman-klon.

Läs även andra bloggares åsikter om spelanalys, brädspel, speldesign, projekt