Scrum är uppbyggt kring begreppet sprint. En sprint är en period på två till fyra veckor som upprepas om och om igen. Varje iteration innehåller utveckling, tillbakablickar och förbättring. Tanken är att man efter varje period får en verklighetskoll på att man gör rätt saker, det kunderna vill ha och har möjlighet att reagera på om man gör fel snabbt. Hela tiden försöker man också förbättra hur man utvecklar mjukvara genom att ha former för att fånga upp sådant som fungerar dåligt.

På pappret är scrum utöver sprinten tre roller, tre artifakter och fyra olika sorters möten. Vi börjar med rollerna:

teamet

Sju personer plus minus två som utför själva utvecklingen. Teamet skall vara “korsfunktionellt” och innehålla all kompetens som behövs för utvecklingen: t.ex. testare, kodare och grafiker.

Teamet jobbar tillsammans med produkten och det är viktigt att uppnå en känsla av gemensamt ansvar för utvecklingen. Man får aldrig säga – det går dåligt för att han eller hon är så dålig. Att någon saknar kompetens är ett gemensamt problem som måste lösas genom kunskapsspridning och utbildning.

scrum master

En person som är ansvarig för att hjälpa teamet att vara så produktivt som möjligt. Det kan handla om att undanröja olika typer av hinder och störningar på arbetsplatsen allt från tekniska problem till chefen som kommer och stör med frågor i tid och otid. Scrum mastern är också ansvarig för att teamet förstår scrum och att processen fungerar. Kan vara en i teamet, men det finns både för och nackdelar med det.

produktägare

Den person som är ansvarig för att rätt delar av produkten utvecklas i rätt ordning och omfattning (mer om det strax). Skall ha koll på kundnytta, affärsnytta, företagets strategi och baserat på det prioritera.

Artefakterna då. Lite skum term men i princip handlar det om vilka dokument och saker man faktiskt producerar. Tre stycken:

product backlog

Produktägaren ordnar all funktionalitet som skall in i produkten i ganska övergripande “backlog items” i en lång lista. Varje item skall vara ett tvärsnitt genom applikationen som utvecklas och handla om en slutanvändarfunktion – en bra form är userstories.

Listan är sorterad på en prioritetspoäng på varje item, inga item får ha samma prioritet. De saker som är överst skall vara mer detaljerade och kortare än de lägre prioriterade items:en i listan. Syftet är att lägga tid på att utreda detaljer så nära själva utvecklingen som möjligt.

sprint backlog

I början av varje sprint plockar teamet åt sig så mycket arbete från toppen av produktbackloggen som de tror att de tillsammans kommer klara av att få färdigt under sprinten. De backlog items de plockat åt sig placeras i en prioritetssorterad lista där saker inte får tas bort eller läggas till under sprinten.

Under sprinten jobbar sedan teamet tillsammans med att färdigställa varje item. Ett item skall aldrig vara reserverat för en utvecklare i teamet – “pinpointat”. Tanken är att undvika flaskhalsar när någon blir sjuk eller inte är tillgänglig.

produkten

Det viktigaste så klart. Produkten man utvecklar. Kodbasen och det man “bygger” produkten av skall vara i sådant skick att man kan göra en ny version till kund i slutet av varje sprint.

Och så mötena. Alla möten är “timeboxade” vilket innebär att de har en fast längd, om mötet drar ut på tiden så skall man ändå avbryta det efter timeboxen och lära sig till nästa gång att man pratade för mycket detaljer eller inte såg till att mötet flöt på bra. De tre mötena är:

sprintplaneringsmöte

Första dagen på sprinten, teamet och produktägaren. Mötet har två delar, först går teamet och produktägaren igenom de högst prioriterade sakerna i produktbackloggen, teamet ställer frågor om saker de behöver veta för att upskatta hur lång tid varje backlogitem tar att implementera.

Den andra delen av mötet går ut på att teamet delar upp varje backlog item i mindre och mer tekniskt orienterade delar: tasks. När teamet uppskattat tiden det tar att uföra ett item så har produktägaren möjlighet att “scopa” om det – dela upp det i mindre delar och prioritera ned vissa. Produktägaren får däremot inte kräva att teamet gör ett item snabbare genom att tumma på kodkvalité och liknande.

daily scrum

En gång varje dag under sprinten har man ett femtonminutersmöte där varje person i teamet besvarar frågorna “vad har du gjort sedan senaste mötet“, “vad kommer du göra tills imorgon” och “vad har förhindrat dig från att vara optimalt produktiv“.

Det är bara scrum master och teamet som får prata på detta möte men andra är välkomna att vara med och lyssna. Om några i teamet behöver diskutera något ytterligare bestämmer man en mötestid på detta möte.

sprint review

I slutet av varje sprint skall en handgriplig demo genomföras där varje funktion som är klar skall visas på en dator för alla de som kan vara intresserade. Kunder och chefer får vara med på detta möte, teamet, scrum mastern och produktägaren skall vara med. Bara sådana backlog item som är helt klara får demonstreras här, ett item som saknar någon del räknas inte som klart och måste vara med i en till sprint för att vara klart.

sprint retrospect

På det här mötet så går scrum mastern och teamet igenom vad som varit dåligt och bra under sprinten, vilka beslut man tagit, vilka störningar man haft och vad man skall förbättra nästa sprint. En bra grej eftersom saker som går dåligt ofta kan vara jobbiga att ta upp – det blir lättare att ta upp känsliga problem i ett konkret forum än att bara resa sig upp en dag och säga dem rakt ut.

Många utvecklingsprocesser försöker vara detaljerade och innehålla en kokbokslösning på alla aspekter av hur man bedriver mjukvaruprojekt. Scrum lämnar istället ganska många dörrar öppna och man måste i princip alltid anpassa processen efter de speciella krav som finns i varje företag. Nästa scruminlägg tänker jag ägna åt att berätta lite detaljer om scrumimplementationen på min arbetsplats.

Det mest bisarra är att man under hela mjukvaruindustrins existens inte verkar hittat något sätt att komma runt detta. Man kanske saltar sin tidsuppskattning på något sätt för att ta höjd för att man gissat fel, (säg t.ex. att man alltid multiplicerar hur lång tid det tar med 2).

Ett annat problem är att när man håller på med ett stort mjukvaruprojekt så kanske inte det en kund ville ha från början är samma sak som de vill ha ett år senare när det är klart. Ändå gör man först en förstudie och försöker mycket detaljerat dokumentera exakt vad man vill ha – vad man kallar för kravspecifikation. Denna dokumentation skall man sedan kunna använda som “bevis” för att beställningen är färdig. Utöver att världen är föränderlig är det mycket svårt att lyckas fånga varenda detalj man vill ha på papper. Det är möjligt att uppfylla en kravspec exakt men ändå ha skrivit ett system som är helt oanvändbart – ett något raljerande exempel: “det stod att man skulle kunna skicka mail, inte att det skulle gå utan att trycka på tio knappar och sedan snurra ett varv med händerna över huvudet”.

En kravspec kan också göra att man får en situation där kund och utvecklare är som motparter istället för att som det egentligen är de faktiskt har ett gemensamt mål som allt blir bäst om de hjälps åt att nå (en situation jag upplevt själv).

När kunden lagt två månader på att skriva ett jättedokument om exakt vad de vill ha finns en risk att man som utvecklare stänger in sig med dokumentet och kodar på för glatta livet. Ett år senare släpper man sin produkt och det visar sig att man feltolkat hälften av kraven totalt. “Att man skall kunna skicka mail” betyder ju inte att alla skall det, det är ju självklart! “Det kan ju inte ta en halvtimme att visa sitt banksaldo” – “Det stod inget om hur lång tid det fick ta”.

På min arbetsplats (Databyrån) har vi sedan ett och ett halvt år tillbaka (tror jag) arbetat enligt ett “lättrörligt” eller “agilt” arbetssätt som kallas Scrum. Jag är en av initiativtagarna men att vi arbetar på detta sätt är ganska väl förankrat i hela företaget. I framtiden tänker jag skriva och berätta mer om Scrum och hur det löser de problem jag nu beskrivit och fler.

Jaja. Det är väl bara att sätta sig och börja rippa om hela skivsamlingen dårå. :P

Vi har i vår applikation jag jobbar med en JPA-lyssnare som vi vill skall sköta spårbarheten, när en entitet blir insertad eller uppdaterad i databasen skall det slängas med en tidsstämpel och användarnamn på användaren som ändrade/skapade entiteten. Normalt är man ju i en sessionsböna och kan komma åt användaren med getCallerPrincipal() på en injicerad EjbContext men eftersom vi är i en pojo så kan vi inte komma åt vår principal den vägen.

Lyssnaren ser ut såhär:

Men när jag körde så fick jag NullPointerException eftersom getContext inte behagade returnera någonting. Efter mycket letande hittade jag en diskussion på en JBoss-mailinglista där det visade sig att man måste specificera säkerhetsdomän även för modulen som innehåller entiteterna/lyssnaren. Vi hade tidigare bara specat detta för vårt affärslogiklager eftersom det bara är det som innehåller remote-ejb:er.

Så, glöm inte att sätta upp security-domain i en jboss.xml för den modul som innehåller entiteter/fasadbönor/lyssnare om du inte har dem i samma modul som dina remotebönor.

Bit i den du, Joga!

När jag kollade i loggarna så dök det upp ett sådant här varje gång jag försökte slå på det trådlösa nätverkskortet:

Sökte lite på google utan att hitta något. Startade om macbooken ett par gånger utan att problemet löstes. Jag testade att stoppa och starta interfacet med ifconfig i en terminal och då började nätverket fungera igen (en1 är mitt wifi-kort):

Om någon stal datorn och hade pc-körkort är det ju inte helt omöjligt att de vet hur man startar datorn med t.ex. en linux-cd och får tillgång till allt på hårddisken, även om de inte kan klura ut inloggningslösenordet. I OsX finns ju file-vault som krypterar hela ens hemkatalog, men jag har rätt mycket data där t.ex. virtuella maskiner på tiotals gigabyte som jag inte har något intresse av att kryptera.

Jag läste lite på nätet och upptäckte en typ av skivavbildsfiler som finns i OsX 10.5 som skapar ett filsystem i en katalog med “band” om 8Mb var. När en fil i skivavbilden ändrats är det bara det band som filen ligger i som ändras och det gör att det funkar fint med backup. Med vanliga filsystem i filer så ändras ju hela filen så att backupen måste innehålla hela filsystemet vid varje backuptillfälle.

Bundlen ser ut som en fil i findern

När Sedan såg jag till att Mail.app var nedstängt. Skivverktyget hade redan automatmonterat det krypterade filsystemet, annars hade jag kunnat dubbelklicka på det för att montera det. Monteringspunkten är /Volumes/Secure. Jag flyttade helt sonika mails datakatalog från ~/Library/Mail till /Volumes/Secure/Library/Mail och sedan skapade jag en symlänk från den nya platsen till ~/Library/Mail

Sedan startade jag Mail.app igen och vips så var datat krypterat utan att Mail vet om det. Det jag saknar nu är något sätt att automatmontera Secure-filsystemet när jag loggar in.

Det tråkiga är att när den nu skall göra första backupen från den återlästa hårddisken så fattar den inte att det är samma filer som redan finns på backuphårddisken så den måste göra en ny full backup, typ 50 Gb. När jag drar igång så går det med 500 Kb/s vilket skulle leda till att det blir klart om en vecka eller så.

Jag upptäckte att det är spotlight (indexerings och sökverktyget i OsX) som är problemet, att den indexerar (eller vad den nu gör) samtidigt som den kopierar. Efter att ha lagt till både min laptophårddisk och time-machine backupdisken till spotlights lista över platser att inte söka på så går överföringen upp från runt 500 Kb/s till ungefär 10 Mb/s.

Observera att det inte skall vara några radbrytningar i [faad]-raderna.