Om Joeltestet skulle skrivas idag, hur skulle det då se ut? Citerus konsult Ola Rende blickar tillbaka på The Joel Test och delar här med sig av resterande punkter.
Börja att läsa Dags att förnya Joeltestet – del 1
7. Har ni en specifikation?
Joel är på denna punkt inte glasklar i sin definition av en specifikation, men antyder att det handlar om en funktionell specifikation över hur enskilda funktionaliteter i programmet skall fungera. Personligen är jag motståndare till Big Design Up Front-tänket och föredrar att behoven formuleras i form av user stories och användningsscenarier.
Ännu en viktig följdfråga är här: vem skriver specifikationen? Är det någon som är inblandad i teamet (bra) eller är det någon utomstående? (varningstecken). Jag har väldigt svårt att förstå varför vissa organisationer väljer att hålla sig med arkitekter som inte ingår i utvecklingsteamen, som inte själva skriver kod och som inte är insatta i driftsmiljön eller användarnas krav men som ändå skriver kravspecifikationer på hur koden ska fungera och som utvecklarna förväntas följa slaviskt. För mig är det ett tecken på att organisationen kanske inte litar på sina utvecklare. De negativa effekterna av detta på arbetsmiljön behöver nog inte understrykas.
Slutligen bör det sägas att inte ens den bästa specifikationen kan ersätta kundnära arbete, alltså att regelbundet kunna tala direkt till beställare och användare för att få deras åsikter om hur mjukvaran ska fungera och utformas. När man väl har fått till en regelbunden feedbackcykel och nära samarbete med användare och kunder så kan man till och med börja ställa sig frågan om den formella specifikationen verkligen behövs.
8. Talar utvecklarna direkt med slutanvändarna?
En ganska enkel fråga, men en som alltför många företag inte kan svara ja på. Om man som utvecklare (eller egentligen i stort sett vilket annat yrke som helst) utvecklar en produkt utan att få feedback från faktiska användare av produkten, då bör man börja ifrågasätta meningen med arbetet man gör. Frågor som “kommer användarna förstå detta?”, “är detta något användarna faktiskt vill ha?” eller påståenden som “jag hoppas att användarna läser manualen” är typiska tecken på att det finns brister i feedbackcykeln mellan användare och utvecklare.
Nyttiga följdfrågor här är “hur ofta?” eller “varför inte?”.
9. Talar utvecklarna direkt med domänexperterna?
En fråga rotad i Domändriven design (DDD) och vars svar kan säga en del om organisationens arbetssätt. Om utvecklarna arbetar i en komplex domän, exempelvis medicinsk teknik eller bank- och finanssystem, samtidigt som det saknas domänexperter så är en intressant följdfråga hur utvecklarna kan verifiera att koden som skrivs faktiskt är korrekt ur domänsynpunkt.
10. Har ni tvärfunktionella team?
Med tvärfunktionella team menar jag här team som består inte enbart av programmerare utan även av testare, användbarhetsexperter och utövare från andra yrken vars kompetens är relevant för den produkt som utvecklas. Arbetar man med hårdvara kan det exempelvis röra sig om de elektronikdesigners eller firmwareutvecklare. Oavsett vilka yrkesgrupper som ingår så är det viktiga här att de alla ingår så är det det viktiga att de ingår i samma team, då detta hjälper att minska feedbackcyklerna och förenkla integrationsarbete.
Att i en modern organisation ha separata team för utvecklare och testare skulle slå mig som märkligt. Hur förutsätts testare göra sitt jobb effektivt om man inte har hela bilden bakom en ny feature och åtminstone de huvudsakliga stegen bakom dess utveckling? Många intressanta följdfrågor kan uppstå ur svaret på denna fråga.
11. Gör ni en leverans efter varje sprint?
En fråga med bakgrund i det agila manifestets 12 principer, främst följande två punkter: “Vår högsta prioritet är att tillfredställa kunden genom tidig och kontinuerlig leverans av värdefull programvara” samt “Leverera fungerande programvara ofta, med ett par veckors till ett par månaders mellanrum, ju oftare desto bättre”.
Även här är baktanken att få reda på hur täta feedbackcyklerna är mellan organisationen och användarna samt hur flexibel organisationen är. Den direkta följdfrågan vid ett nekande svar blir “varför gör ni inte en release efter varje sprint?”. Även här bör man noggrant tänka över det givna svaret och fundera på om det är tekniska skäl att man inte levererar oftare (“ändringar i koden kräver att elektroniken i slutprodukten görs om”) eller om det är rent organisatoriska problem (“Driftsavdelningen klarar inte av att genomföra nya driftsättningar av programmet hos varje kund för varje avslutad sprint”) som ligger bakom oförmågan att ha tätare leveranser?
12. Kan koden end-to-end testas automatiskt?
Denna fråga är relaterad till både den andra och den tredje frågan i listan och är ämnad att undersöka hur långt organisationen har kommit i sin automatisering. Personligen tycker jag att alla delar av testprocessen som kräver manuell handpåläggning bör betraktas som problem och lösningar bör eftersträvas, då dessa med stor sannolikhet kan leda till flaskhalsar i projektet.
En viktig följdfråga kan vara “vem skriver end-to-end-testerna? Utvecklingsteamet eller ett separat team?”. Om det är ett separat team som sköter detta så kan det potentiellt vara ett varningstecken, då det leder till överlämningar och sena varningar om felaktig kod.
