Citerus konsult Ola Rende blickar tillbaka på The Joel Test och har funderat på hur det skulle kunna se ut idag.
I augusti 2000 skrev Joel Spolsky en artikel med namnet: The Joel Test – 12 Steps To Better Code. Detta kom med tiden att bli en mycket betydelsefull artikel och de kommande åren fick Joel mycket epost från läsare som berättade vad deras organisationer fått för poäng eller att de använt testet för att förbättra sina processer. Än idag gör sig testet påmint, bland annat i Stack Overflow-sajtens jobbannonssektion, där företag i annonserna kan inkludera vilka av de tolv punkter de uppfyller. Det är dock inte enbart i intervjusituationer som testet kan vara till nytta, utan även vid tillfällen då man behöver göra en analys av nuläget i en organisation och sätta målen man vill röra sig mot.
De ursprungliga 12 punkterna (fritt översatta från engelska) ser ut som följer:
- Använder ni versionshanteringssystem?
- Kan ni göra ett bygge i ett steg?
- Gör ni dagliga byggen?
- Har ni en buggdatabas?
- Rättar ni buggar innan ni skriver ny kod?
- Har ni en aktuell tidsplan?
- Har ni en specifikation?
- Har programmerarna en tyst arbetsmiljö?
- Använder ni de bästa verktygen pengar kan köpa?
- Har ni testare?
- Skriver arbetssökande kod under intervjuer?
- Gör ni korridortestning av användbarheten?
(se originallistan här: http://www.joelonsoftware.com/articles/fog0000000043.html)
Många av punkterna är (enligt min åsikt) fortfarande relevanta och viktiga frågor, medan andra känns något mindre relevanta utifrån mina erfarenheter. När jag nyligen läste igenom listan och Joels förklaring av dess punkter började jag fundera på hur en sådan lista skulle se ut idag. Jag kom fram till följande variant:
- Använder ni versionshanteringssystem?
- Kan ni göra ett releasebygge i ett steg?
- Gör ni (åtminstone) dagliga byggen?
- Har ni en buggdatabas?
- Är utvecklarna delaktiga i driftsättning och underhåll?
- Har ni en aktuell tidsplan?
- Har ni en specifikation?
- Talar utvecklarna direkt med slutanvändarna?
- Talar utvecklarna direkt med domänexperterna?
- Har ni tvärfunktionella team?
- Gör ni en release efter varje sprint?
- Kan koden end-to-end testas automatiskt?
1. Använder ni versionshanteringssystem?
En viktigt fråga även idag. Jag skulle till och med gå så långt som att säga att om du ställer denna fråga i en intervju och svaret är “nej”, res dig upp och gå. Det finns inga ursäkter för att inte använda versionshanteringssystem numera.
Jag skulle rekommendera att följa upp frågan med vilket system som används och varför. En intressant sak med frågan är nämligen att den kan berätta en del om hur den svarandes organisation fungerar. Använder man till exempel Clearcase för att “vi har använt det sen 80-talet och vi har inte haft tid att byta” så väcker det en drös nya frågor om prioriteringar, arbetsbörda och utveckling av arbetssätt. Använder man Git enligt Linuxkärnans committer-modell så kan det vara bra att få veta varför den hierakiska och nitiska kontrollen av all incheckad kod är så viktig. En annan intressant följdfråga är hur företagets eller teamets branchningsmodell ser ut och varför.
2. Kan ni göra ett releasebygge i ett steg?
Även denna fråga kommer från ursprungslistan och är fortfarande relevant. Fullständig automatisering av byggen, integration (CI) och driftsättning (CD) är något som många organisationer vill uppnå men relativt få har uppnått.
3. Gör ni (åtminstone) dagliga byggen?
Denna fråga är nästintill identisk med ursprungsfrågan, med undantag för tillägget av ordet åtminstone. Vid tiden för originalartikeln var det kanske för tidskrävande att bygga och automattesta varje incheckning av kod, men numera är det ofta möjligt (även om undantag finns). I så lång utsträckning som möjligt bör man nog ändå sträva efter att bygga och köra en betydande del av testerna vid varje incheckning för att få tidiga varningar om fel uppstått. En vanlig strategi i utvecklingsteam med en andel tester som tar mycket lång tid att genomföra är att köra en delmängd av testerna vid varje incheckning för att sedan köra tidskrävande tester under nätter och/eller över helger. Att vänta med tidskrävande tester till precis innan release är ett riskabelt arbetssätt som bör undvikas.
4. Har ni en buggdatabas?
Ännu en tidlös fråga. Dokumentation av buggar bör betraktas som en lika viktig artefakt av utvecklingsarbetet som koden själv. Idag finns en uppsjö av verktyg för att hantera buggrapporter, både proprietära och öppna, så precis som med versionshanteringssystem så finns det inget vettigt skäl att inte använda det. Personligen skulle jag inte heller rekommendera att buggar spåras enbart med exempelvis post-its i kontorsmiljön, främst då dessa löper risk att lossna och försvinna.
Vidare rekommenderar Joel att buggrapporter innehåller åtminstone (och egentligen inte mycket mer, i min åsikt) följande information: vilka steg krävs för att reproducera buggen, vilket är det förväntande beteendet (det korrekta), vilket är det faktiska beteendet (det inkorrekta), vem som arbetar med buggen samt huruvida buggen är rättad eller ej.
En risk som finns med buggdatabaser är dock att innehållet tappar betydelse för teamen med tiden om man har en alltför slapp hantering av buggrättning. Ett sätt att stävja detta är att planera in buggar i backloggen allt eftersom de rapporteras in, vilket gör att buggar inte tillåts glömmas bort. En annan metod kan vara att sätta en kvalitetsnivå, exempelvis att en release inte får innehålla några (kända) buggar över en viss risknivå.
5. Är utvecklarna delaktiga i driftsättning och underhåll?
Denna fråga grundar sig i devops-rörelsen och är ett uttryck för min strävan efter att bryta ner de ibland vattentäta skotten mellan avdelningar ansvariga för utveckling och avdelningar ansvariga för drift. Ju större applikationer blir, ju fler användare det får och ju högre krav som ställs på hög tillgänglighet desto viktigare blir det att utvecklare är inblandade i valet av och det fortskridande arbetet med miljöerna i vilka koden ska driftsättas. I organisationer där utvecklarna är avskärmade från driften kan det hända att buggar introduceras för att utvecklare inte vet något om driftsmiljön eller att programmets arkitektur inte byggs för att skala i samma miljö som det sedan körs i (exempelvis att programmet byggs kring en databas som inte kan skalas horisontellt eller att det finns en Single Point of Failure).
Det finns självklart olika grader av delaktighet som är lämpliga eller mindre lämpliga. Frågan är ändå nyttig för att få sig en klarare bild av hur organisationen fungerar.
6. Har ni en aktuell tidsplan?
I denna punkt återvänder jag till originallistan då frågan är fortsatt relevant. Använder organisationen någon av de agila metoderna för utveckling, exempelvis Scrum, så bör svaret på denna fråga bli jakande.
En intressant följdfråga som än en gång säger mycket om organisationen är: Vad gör ni om en tidsplan ser ut att spricka? Här bör man dra öronen åt sig. Är svaret att man flyttar ut ofärdiga features ur releasen för att färdigställas till nästa release (ett gott tecken) eller att man senarelägger hela release tills dessa är klara? (ett varningstecken)
Följ den spännande fortsättningen på artikeln på Citerus blogg, inom kort!
