2009 års IT-ord redan här!

Det tog bara femtio år för begreppet att komma till vår bransch, men som de säger:
om IT inte kan komma till Lean, får Lean komma till IT.

Är Scrum och Agile ute nu, ska man prata Lean istället?

Gör det om det känns bättre för dig! Man kan kanske säga att Scrum är en implementering av Leanprinciperna. För skeptikern på avdelningen med armarna i kors finns Toyota att visa som gott exempel, som i hela sin organisation arbetar enligt principerna. Toyota har en kvarts miljon anställda Lean-människor, det tycker jag är ganska tufft. Bank- och läkemedelsvärlden har i några år nu arbetat enligt Lean i verksamheten, är det bara IT-avdelningarna kvar?

Några IDG-artiklar om Lean och Scrum

Lean: det mentala avgör

Unibet effektiviserar med Lean och Scrum

IT är sista utposten mot Lean

Nu kommer Lean till IT-avdelningen

Windows Vista plus ett = Windows sju

För en vecka sedan presenterade Microsoft några nya grejer för cirka tjugo tusen förväntansfulla IT-nördar på konferens - jag var en av dem - och jag släpper de agila idéerna en stund för att prata om moln, windows utan väggar och touch-skärmar istället.

Windows 7
Nästa version av Windows kommer att ha en del häftiga och bra grejer, men påminna väldigt mycket om Vista. Vilket är bra, att byta design igen skulle vara väldigt konstigt. Microsoft har satsat på att förbättra prestandan (Vista-användare jublar) och har tagit bort och förenklat en hel del irritationsmoment, som till exempel användarbehörighets-kontrollen (popup-rutan som dyker upp hela tiden då man vill göra något i Vista) och de små meddelanden om uppdateringar, säkerhetsbrister och annat som ploppar upp på skrivbordet. Lokala nätverk och skrivare hemma och på arbetsplatsen ska fungera mycket smidigare, om man till exempel är medlem i en domän på jobbet och på ett enkelt sätt vill kunna ansluta sig till sitt hemmanätverk.

Windows 7 är också mycket mer anpassat till touch-skärmar och som utvecklare blir det enklare att skriva program som utnyttjar dra-och-släppteknik med fingrarna istället för muspekaren på skärmen. Har man provat Microsoft Surface (storbildsskärm där man kan flytta, förstora och förminska fotografier med fingrarana) och iPhones gränssnitt, kan man kanske tänka sig hur ett operativsystem på datorn kommer att se ut i framtiden. Ganska tufft!

Rikare användarupplevelser på webben med Silverlight

För en vecka sedan presenterade Microsoft några nya grejer för cirka tjugo tusen förväntansfulla IT-nördar på konferens - jag var en av dem - och jag släpper de agila idéerna en stund för att prata om moln, windows utan väggar och touch-skärmar istället.

Silverljus i webbmörkret
Silverlight är Microsofts svar på Adobe Flash och sk "applets" gjorda med Java, som gör en webbplats mer lik ett vanligt program man har på sin dator. En stor del av konferensen ägnades åt Silverlight och som .NET-utvecklare är det mycket attraktivt att skapa något i den miljön. Jag skulle hellre välja Silverlight än Flash och Java, eftersom man skriver programmen i .NET-miljö (det gör man inte när man skriver Flash- eller javaprogram). Ett hinder är att Silverlight kräver att man installerar ett tillägg till webbläsaren - på samma sätt som Flash, men Flash följer idag redan med i webbläsaren från start och som användare behöver man inte bry sig om vilken teknik webbplatsen använder sig av.

Snart är säkert även Silverlight där, förinstallerat, och med den här miljön kommer man förbi många av de hinder som finns i en webbläsare. Jag tror att en bra start kan vara att utveckla intranät med Silverlight. Där vet man vilka användarna är och har en lättare uppgift att få tillägget installerat i webbläsaren.

Microsoft satsar mycket på Silverlight, faktiskt även för skrivbordsprogram verkar det som, och avgränsningen mellan webbplats och program på den lokala datorn börjar suddas ut mer och mer. Det tycker jag är bra och spännande!

Windows utan väggar

För en vecka sedan presenterade Microsoft några nya grejer för cirka tjugo tusen förväntansfulla IT-nördar på konferens - jag var en av dem - och jag släpper de agila idéerna en stund för att prata om moln, windows utan väggar och touch-skärmar istället.

Live Mesh och Live Services, eller "Windows without walls"
Idag är det fortfarande så att Internet, den personliga datorn på skrivbordet och mobiltelefonen inte är sammanlänkade på ett naturligt sätt. Det finns fortfarande ganska stora hinder i vägen för att på ett enkelt sätt kunna dela information mellan dem. Det är med Live Mesh som Microsoft vill riva väggarna mellan de olika enheterna. Live Mesh finns där ute i molnet och är en samlingsplats för saker man vill dela mellan sin dator och mobiltelefon eller musikspelare. Med automatisk synkronisering av till exempel sin musik, sina fotografier, filmer och Office-dokument. I nästa version av Office kommer man kunna skriva och uppdatera dokument direkt i sin webbläsare, med automatisk och nästan omedelbar synkronisering med dokument på sin och kollegornas datorer. Live Services är en lösning för att kunna ha all sin information på ett ställe, eller egentligen all sin information på alla sina ställen! I Live Services ingår också Msn Messenger och de personliga sidorna som finns på Microsofts Live Spaces.

Det här verkar vara en konsumentprodukt och jag tycker att det ser ut som en konkurrent till bland annat Facebook, Flickr, Google Docs och Apples MobileMe - som alla fyra är en typ av små stackmoln som redan finns där ute. Windows Azure tror jag kan bli en succé, eftersom det (förhoppningsvis) innebär att det blir så mycket enklare att utveckla mjukvara än vad det är idag, speciellt för .NET-utveckling. Live-konceptet tror jag blir lite knepigare, eftersom det redan finns ganska bra lösningar för sådant redan och de lär nog inte blunda för den nya konkurrenten. Facebook och Google Docs är också något som spridit sig med "mun till mun"-metoden och utan någon traditionell reklam. Jag tror att Microsoft jobbar lite i uppförsbacke och har nog inte samma populärfaktor som Google, Flickr eller Facebook. Så, det kommer nog att bli ganska molnigt på Internet framöver!

Allt ska finnas i molnet!

För en vecka sedan presenterade Microsoft några nya grejer för cirka tjugo tusen förväntansfulla IT-nördar på konferens - jag var en av dem - och jag släpper de agila idéerna en stund för att prata om moln, windows utan väggar och touch-skärmar istället.

Windows Azure, eller "The Cloud - ett operativsystem för webben"

Vad är det och vad ska man ha det till?
Microsofts ambition är att det ska vara ett operativsystem för webben - i princip är Azure ett antal sammanlänkande servrar placerade över hela världen, med tjänster för utvecklare att använda. Man ska alltså inte behöva ha egna databaser, webbservrar eller backup-lösningar längre, all information man lagrar ska finnas i molnet. Som företag och utvecklare av mjukvara kan man fokusera på lösningen som ska ge affärsvärde och inte behöva lägga ner tid på hårdvara, skalbarhet och komplicerade driftsättningar. Det är alltså både ett slags webbhotell och en plats där all information lagras.

Hur använder man "molnet"?
Man arbetar i sin miljö som vanligt med utveckling av mjukvara, all kommunikation med molnet sker med ett fåtal rader kod. Som utvecklare tänker man inte längre i termer av rader i databastabeller, utan snarare i formen av sin domänmodell med objekt och egenskaper som speglar företagets affärsverksamhet. Man kanske kan säga att man klipper bort biten längst ner i den klassiska uppdelningen användargränssnitt, affärslogik och datalager. Det är användargränssnittet och affärsreglerna man arbetar med och data finns någonstans i molnet - osynligt, men enkelt att slänga in saker och enkelt att hämta ut saker. För att publicera räcker det med att kompilera sitt program och skicka iväg det till molnet. Det ska ta minuter - inte månader - att driftsätta sin mjukvara.

Jag tycker att "The Cloud" påminner ganska mycket om idéerna från förr, då man trodde att det i framtiden skulle räcka med fem datorer i hela världen för att hantera all information. När Ray Ozzie presenterade Windows Azure kändes det spännande och futuristiskt, på ett gammaldags sätt!

Starta ett gerilla-team!

Vad betyder det att vara långt ner i en företagshierarki, när man vill genomföra förbättringar i sitt arbetssätt och i sina processer? Jag brukar ofta höra kommentarer i stil med "Vi vill jobba så här, men beslutsvägarna är så långa...". En sådan här situation brukar innebära passiva medarbetare och en ganska stelbent organisation.

I det traditionella organisationsschemat har vi ju en VD högst upp, följt av olika chefsroller. Längst ner hittar vi team och individer, som producerar produkter som företaget säljer eller utför de tjänster som erbjuds. Det är något som inte riktigt är okej med den där bilden.

Det traditionella organisationsschemat borde ju egentligen vändas upp-och-ner! Jag tycker att en chefsroll egentligen innebär att vara stödorganisation, till de individer och team som tar initiativ och hittar lösningar till gamla och nya problem. Som också ställer krav på sin stödorganisation – hur ska de annars kunna leverera rätt grejer? De som har idéer och provar nya sätt att öka produktiviteten, kommer hela tiden att försöka bli bättre. Jag tror att det blir en naturlig del av arbetet och man känner också personligt ansvar för de initiativ man tagit. Det blir ju inte riktigt samma sak när det kommer direktiv från ovan.

Varför vänta på att någon annan högre upp i organisationen ska ta beslut och hitta på nya idéer, när man på plats redan nu vet vad som kan förbättras? Starta ett gerilla-team och prova olika lösningar! Det kan vara startskottet till att få hela företaget att bli mer lättrörligt och så blir det säkert roligare att gå till jobbet. Det ska ju vara kul att jobba!

Äggklockan - kontorsjobbarens bäste vän

Hur kommer det sig att det som plingar till i e-postlådan ofta får högre prioritet än det man för tillfället arbetar med? Man släpper ofta omedelbart allt för att istället läsa e-posten. Hur påverkar det produktiviteten egentligen? I en artikelserie i DN kan man läsa om hur mycket tid som faktiskt försvinner och hur mycket avbrott i arbetet kostar i form av tid.

Ska man inte svara när det ringer och strunta i mejl helt och hållet på jobbet? Det är nog ingen bra idé, det kan ju faktiskt vara så att meddelandet har med jobbet att göra... Ska man kolla inboxen och sitt mobilsvar två gånger om dagen på fasta tider? Det håller nog inte riktigt heller, tycker jag.

Jag har provat en grej som jag tycker funkar bra och till hjälp kan man använda sig av en äggklocka! (kommentar: mobiltelefonens timer-funktion går också bra)

När arbetsdagen börjar, skriver jag ned det jag planerar att arbeta med under dagen. En uppgift per rad. Jag tidsuppskattar varje uppgift i formen av tjugofemminuterspass. Tar uppgiften ett pass eller tre att bli klar med?

I princip handlar det om att dela upp sin dag i små bitar. Jag brukar ha som mål att genomföra tre pass före lunch och cirka fem pass på eftermiddagen. Det blir totalt knappt fyra timmar (med korta pauser mellan) och då har man hela fyra timmar kvar till exempelvis möten.

Nu är det bara att vrida upp äggklockan och sätta igång!

När man väl startat ett pass finns det några viktiga regler: då det till exempel plingar till i e-postlådan har man två val - att avbryta passet för att läsa mejlet, eller vänta till passet är avklarat. Mellan varje pass tar man nämligen korta pauser (cirka fem minuter) för att hämta kaffe, läsa e-post, ringa, snacka med sina jobbarkompisar och så vidare.

Under ett pass tar jag alltså aktivt ställning till om avbrottet i arbetet är så viktigt att det inte kan vänta några minuter, eller om jag kan ta det då passet är avklarat. Avbryter jag ett pass markerar jag det, genom att sätta ett "x" bredvid uppgiften på pappret. Då arbetsdagen är slut ser man hur ofta man faktiskt blir avbruten. Man kan fundera på om det går att prioritera sina dagar på ett bättre sätt.

Om en kollega kommer förbi och vill prata lite då? Med äggklockans hjälp blir man ganska bra på att förhandla: "kan jag komma förbi om tio minuter, jag är mitt uppe i ett pass?".

Prova med frasen:
"Jag är mitt uppe i en Pomodoro, kan vi snacka om tio minuter?".

Det här sättet att arbeta kallas nämligen för The Pomodoro Technique. Det var en italienare som började med det här och till sin hjälp hade han en äggklocka som såg ut som en tomat.

Det här inlägget tog två pass att skriva. Ett avbrott mitt i ett pass gjorde att jag fick vrida tillbaka klockan och starta ett nytt.

Vi vill spela poker på jobbet!

Hur svårt kan det egentligen vara att gissa hur lång tid en arbetsuppgift tar att bli klar med? Vi som jobbar i IT-projekt brukar ju misslyckas med det här. Det har till och med gått så långt att våra misslyckanden av många betraktas som ett skämt!

Men det är ju en gissningslek och jag tror inte att det går att veta i förväg hur många timmar man behöver för en helt ny uppgift. Min erfarenhet är också att de som ska göra jobbet är bäst på att gissa och att fler personer gissar bättre än en person. Och det är här kortleken kommer in.

För att spela poker behövs en kortlek, som har en uppsättning av sifforna 1, 2, 3, 5, 8, 13 och 21 till varje person. Det går bra att riva papperslappar att skriva siffrorna på för att snabbt komma igång.

Innan man alls funderar på antalet timmar, pratar man lite om uppgifterna och försöker hitta den som verkar enklast. Den uppgiften får värdet en (1) poäng.

Nu är det dags att spela kort! Ta fram nästa uppgift och fundera en kort stund på hur mycket svårare den uppgiften är, i förhållande till den som var enklast. När alla med pokerfejs funderat klart: "Ett, två, tre!" och alla slänger samtidigt sina valda kort på bordet.

Man upptäcker snabbt att det ofta kastas kort med olika poäng och det är precis det som är poängen. Vi ser problem från olika håll och har kanske till och med tolkat arbetsuppgiften olika! Då korten skiljer sig, pratar man lite mer och berättar hur man tänkt. Sedan är det dags att spela igen - med samma uppgift. Så här håller man på till alla är överens.

När alla uppgifter är klara är det dags att prata om hur många timmar en poäng egentligen är. Är en poäng fyra timmar? Eller en dag? När korthajarna kommit överens har projektet nu en lista med uppgifter som tidsuppskattats. Troligtvis är den här typen av gissning bättre än då en ensam människa vid sitt skrivbord gör sina uppskattningar.

Den här metoden kallas planeringspoker och används ofta vid planeringsmöten i projekt som drivs med Scrum. Tro det eller ej, men det är också väldigt kul att tidsuppskatta med hjälp av poker.

Det ska vara kul att jobba!

Från Fragile till Agile

Visst är IT-leveranser alltför ofta som ömtåliga paket och kanske till och med som skadat gods ibland? Kvalitet har länge varit en svår grej i vår bransch, men många av oss arbetar för att hela tiden bli bättre på det vi sysslar med.

Sedan en tid tillbaka arbetar vi i vårat lag så här:

Levererar ofta
Vi delar upp projekt i etapper om tre veckor, där varje etapp har en leverans. Det är faktiskt lättare att hantera, än att ha en enda jätte-leverans i slutet av ett projekt.

Testar ofta
Vi har skrotat den traditionella testfasen, som brukar vara i slutet av ett projekt. Då är det ju redan försent, eller hur? I varje etapp är istället test en naturlig del av utvecklingen.

Kompetens istället för fasta roller
För oss är det inte ett dugg kontroversiellt att inte ha någon i laget som vi kallar "projektledare". Projektledning sysslar vi däremot med i allra högsta grad, hela laget och varje dag.

Och vad får vi ut av det här då?

Personligen tycker jag att det är riktigt roligt att arbeta så här! Jag går till jobbet med ett leende. Glada projektmedlemmar är produktiva, det tror jag på.

Vi levererar bättre produkter med färre buggar. Tvärfunktionella lag hittar problem och löser dem snabbare, det är vår erfarenhet.

Vi har valt Scrum som arbetssätt och efter några projekt känns det som rätt vägval. I systemutvecklingsprojekt är också testdriven utveckling något som behövs; när man levererar var tredje vecka behövs automatisering. Läs gärna mer i tidigare inlägg.

Hur gör ni i er organisation för att leverera produkter med kvalitet, har du några tips?

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.