Kan vi börja prata svenska, please?

Är svenska världens dåligaste språk, eller är kanske vi IT-folk dåliga på svenska? En presentation under en konferens om lättrörliga arbetssätt, fick mig att fundera på varför jag själv brukar ägna tid åt att förklara alla dessa uttryck som vi brukar slänga oss med om dagarna.

Jag gillar att prata om och arbeta enligt Scrum och vi som jobbar i projekt med hjälp av det här sättet, använder dagligen uttryck som Product Backlog, Sprint, Daily Scrum och Scrum Master.

Varför inte använda orden prioriteringslista, etapp, dagliga möten och lagkapten istället?

Jag tror inte att man behöver förklara vad ett dagligt möte är för något. De flesta av oss här i Sverige förstår nog också, på ett ungefär, vad som menas med en prioriteringslista. Hur många svenskar vet vad en Scrum Master är?

Jag brukar använda lättrörlig istället för det engelska ordet Agile, har du något annat förslag?

Börja dagen med att svara på tre frågor

Varför är det så komplicerat att jobba i team då man sysslar med IT? Är det våra verktyg som hindrar oss - skärm, tangentbord, skrivbord och mus - som inte direkt bjuder in till samarbete? Varför kan det inte vara som i datortillverkarnas annonser i tunnelbanan? Där några personer i fräsch kontorsmiljö ler stort och pekar på något spännande på datorskärmen.

De där annonserna är ju bluff, men jag har en idé: vi lämnar datorerna en stund och pratar med varandra istället!

Så här kan man göra
Alla som är med i projektet deltar i ett kort möte varje dag, som är max en kvart långt och förslagsvis klockan nio på morgonen. Under mötet svarar varje person på de här tre frågorna:

Vad har jag gjort sedan förra mötet?

Vad ska jag göra till nästa möte?

Har jag några problem som hindrar mig att lösa uppgiften?

Frågorna svarar jag på till hela laget och inte bara till chefen, projektledaren eller bästa jobbarkompisen. Eftersom mötet varar i en kvart, gäller det att vara kortfattad och hålla sig till ämnet. Eventuella problem löser man inte under denna kvart, men de personer i laget som kan hjälpa till träffas direkt efter mötet för att tillsammans komma fram till något bra.

Men blir det inte samma sak man står och pratar om varje morgon?

"Ja, jag sysslar fortfarande med dokumentationen..." eller "jag håller på med login-sidorna...".

Ja, det blir så om arbetsuppgiften är för omfattande.

Ett nytt problem har snabbt synliggjorts: vi behöver dela upp uppgifter till mindre delar. Allra helst deluppgifter som man kan göra klart på en arbetsdag. Dokumentationsuppgiften kan man ju dela upp till att skriva enskilda kapitel och systemutveckling är mycket enkelt att dela upp till mindre delar. Som login-exemplet ovan: ett formulär för att fylla i uppgifter, anrop till en användardatabas och så vidare.

Som projektmedlem känns det bra att berätta vad jag gjort klart under gårdagen och vad jag ska göra idag. Varje dag gör jag och laget små framsteg och kommer allt närmare ett avslut. På köpet får vi i laget dagligen en uppfattning om hur vi ligger till i projektet.

Det jag beskriver här är en av delarna i Scrum och kanske det enklaste att börja med i ett projekt. Vilka erfarenheter har du av att arbeta i team?

Några vanliga missförstånd om Scrum

Det verkar som att Scrum och andra lättrörliga (agile) arbetssätt provocerar många i vår IT-bransch. Vad beror det på? Kan det vara så att vi, som gillar att prata om sådant här, helt enkelt fokuserar på fel grejer? Jag tror att vi argumenterar för mycket och ofta ställer metod ett mot metod två: "så här dåligt fungerar det idag och så här fantastiskt blir det med Scrum!".

Jag tror att många slutar att lyssna när argumenten haglar och nyfikna frågor trycks ner av ännu mer agile-hagel. Det här bäddar för missuppfattningar.

Här är några vanliga missförstånd som jag ofta stöter på och förhoppningsvis lyckas jag med att reda ut dem.

I Scrum sysslar man inte med dokumentation
Den här nivån av detaljstyrning finns inte i processen. Dokumentation är ju uppgifter i att-göra-listan, oftast som en självklar del av en leverans och det är projektet som avgör vad som ska finnas dokumenterat.

Varifrån kommer den här uppfattningen? Jag tror att det kan vara just den där jämförelsen vi ofta gör mellan metod ett (till exempel RUP) och metod två, där man tar upp tung dokumentation som en dålig grej som inte behövs och är tråkig. Det kanske inte är så konstigt att tro att man inte jobbar med dokumentation i Scrum, när man lägger upp det så här.

Scrum är en hetsjakt mot projektledare
Varför kallas projektledaren för Scrum Master, var en av mina första frågor? När jag förstod att Scrummästaren inte är en projektledare, undrade jag då vem som styr och planerar projektet när man tagit bort rollen. Är projektledarens uppgifter onödiga?

Självklart inte! I Scrum har hela teamet leveransansvar. Laget planerar tillsammans, tidsuppskattar dagligen och varje individ tar själv uppgifter att göra: "jag tar den här pucken!". Scrummästaren är en del av laget och är i princip en person som ser till att alla arbetar enligt processen.

Man kanske kan säga att den traditionella projektledarrollens uppgifter finns både i ett team och hos beställaren (som brukar kallas produktägare i Scrum). Uppgifterna har alltså inte tagits bort, utan snarare fördelats om.

Scrum har hittats på av en dyr IT-konsult i kostym
Scrum är en variant av Lean, kan man kanske säga. Och Lean Production hittades på i Japan för mer än femtio år sedan! På Toyota har man sysslat med det här sättet att arbeta på i många år och vi som jobbar i IT-branschen ligger tyvärr hopplöst efter resten av världen. Här i Sverige: inom bank & finans, bilindustri och läkemedel är Lean ett välkänt begrepp. Men hur står det till bland dessa företags IT-avdelningar?

Vilka fler missförstånd tycker du finns?

Finns det roligare sätt att fixa buggar?

En situation: en användare har upptäckt ett fel på webbplatsen som ett företag byggt och förvaltar. Utvecklarna har fått några sura blickar från kompisarna på marknadsavdelningen, som i sin senaste kampanj berättat om hur bra webbplatsen är. Nu är det bråttom att fixa buggen!

Var och hur ska man börja sitt buggfixande?

Man brukar oftast börja med att försöka återskapa felet genom att surfa till webbplatsen, logga in och klicka sig fram på samma sätt som användaren gjort. Till hjälp kan man köra webbplatsen i "felsöknings-läge", då man på skärmen kan se information som skickas fram och tillbaka i koden. Eventuellt hittar man något som kan vara fel och gör en uppdatering, surfar till webbplatsen, loggar in och klickar sig fram igen för att se om problemet är löst. Om det fortfarande är fel gör man samma sak igen. Det är jobbigt, tar tid, osäkert och ganska trist, faktiskt.

Det finns enklare sätt att arbeta på än det helt manuella och här kommer ett förslag.

Vad finns det egentligen för krav på webbplatsen? När man vet hur produkten ska fungera, kan man ganska enkelt göra om kraven till så kallade automatiserade enhetstester. Låt dig inte luras av ordet "test"! Det är faktiskt krav i form av kod man skriver. Så, börja med att skriva ett testfall som provocerar fram felet - innan någon förändring i koden påbörjas. Man hittar ganska snabbt var det förväntade beteendet inte uppfylls, när man arbetar så här. Testfallet lyser rött och buggen är fixad när det lyser grönt! Jag har märkt att det är en bra grej att ha som stöd när jag självsäkert säger att det fungerar. När en utvecklare säger något i stil med "nu ska det vara klart" eller "det borde fungera nu" är det dags att bli orolig som beställare. Fråga efter de gröna lamporna!

Vore det inte bra om de där testfallen redan fanns där från början?

Ja, det vore bra! Och det är precis det som testdriven utveckling handlar om: att automatisera de förväntningar som finns på en viss funktionalitet, innan man börjar koda. Redan från dag ett har alla som arbetar med produkten möjlighet att köra enhetstester för att se att krav uppfylls. Ett arbete som är mycket snabbare än det manuella. När alla i utvecklarlaget kontrollerar kodens beteende och skriver nya enhetstester, minskar risken för buggar i produktionsmiljö. Jag hävdar att det rinner iväg många gånger fler timmar för att fixa buggar i efterhand än att göra det i utvecklingsfasen. Men kom ihåg, låt dig inte luras av ordet "test"! Jag tycker att man borde kalla det för kravdriven utveckling eller beteendedriven utveckling istället.

Behövs det inga tester då?

Jo, det gör det! Testdriven utveckling handlar ju inte om test. Enhetstester är byggda för att kontrollera små delar, inte en serie av händelser eller verksamhetsflöden. Man kan säga att testdriven utveckling belyser behovet av manuella tester. Tester som man för övrigt också bör göra löpande under utvecklingens gång. Men det har jag redan tjatat om i en annan artikel.

Automatisera krav, inte test

Jag tror att det idag finns en övertro på att automatisering av testning är något som är heltäckande och tillräckligt för att säkerställa kvaliteten på en produkt. Vi som utvecklar mjukvara går ofta i fällan och tror att automatiserade enhetstester är en garanti, att produkten är testad och klar när våra testfall lyser grönt. Automatiserat test blir ett slags ersättare till det kostsamma, tråkiga - och kanske till och med överflödiga - manuella testandet. Är kvalitet är för dyrt?

Varifrån kommer denna tro och detta synsätt på automatisering? Jag tror att det kan vara själva ordet test - testdriven utveckling, enhetstest, acceptanstest, automatiserade tester - som lurar oss. Men det vi skriver är ju egentligen inte testfall, utan krav. Automatiserade testfall borde kanske ses som krav i form av kod. Krav på mjukvarans beteende och inte ett test av mjukvaran.

Det kanske är dags att gå vidare från testdriven utveckling till krav- och beteendedriven utveckling. Men vad är egentligen skillnaden? Jag ser det som ett förhållningssätt för att ta fram mjukvara, där beteendedriven utveckling hjälper oss att utveckla bara det som krävs, låter design av mjukvaran växa fram steg för steg och där man i projektet synliggör behovet av testare i team. Jag tycker att begreppet utvecklare också borde omfatta testare.

En programmerare kan vara bra på att skriva automatiserade testfall och att skriva kod - och i regel är programmeraren en dålig testare, när det handlar om att testa den egna koden. Riktigt usel, faktiskt. Jag som programmerare vet ju hur jag tänkt att lösningen ska fungera och det är mycket svårt att ta steget från den smala vägen man redan vet fungerar. En annan person som inte alls vet hur min kod uppfyller kraven, väljer andra vägar till att säkerställa mjukvarans kvalitet. Har vi verkligen råd att inte ha manuella tester?



Läs mer om Behaviour Driven Development.